Learn Aria2 - Resume, Continue & Download Control

#Introduction

Up to episode 4, all your downloads ran smoothly — maybe too smoothly for the real world. The reality: connections drop mid-way, laptops close, quotas run out, and a 10GB download can't wait for you to stare at the screen. This episode is about resilience and control — making aria2 resume interrupted downloads, throttle its speed, and start being controlled from afar.

Imagine a professional courier: when the truck breaks down mid-route, he doesn't restart the journey from scratch — he continues from the last kilometer, adjusts his speed so the fuel lasts, and reports his position to the control center. That's exactly what we'll build into aria2 in this episode — a pattern summarized by aria2c -c URL.

#Resume & Continue: -c

The most common scenario: a download interrupted mid-way. aria2 has already left a partial file on disk along with the .aria2 control file. Instead of starting from zero, aria2 can resume from the last position with the -c option (or --continue):

aria2c -c https://example.com/backup.iso

Here's how it works: aria2 reads the .aria2 control file to know which segments are already complete, then sends a request with a Range header to the server. A server that supports resume replies with 206 Partial Content and sends only the remaining part; a server that doesn't replies with 200 and the full content, forcing aria2 to start from the beginning.

#The Role of the .aria2 Control File

We met the .aria2 control file in episode 2. In this episode 5 its role becomes clear: it's the progress notebook that makes resume possible. Without it, aria2 has no way to know how far the download got — every segment is treated as empty and re-downloaded.

Practices to remember:

• While a download is incomplete, there will be backup.iso and backup.iso.aria2 in the same directory.
• Don't delete the .aria2 file if you still want to resume.
• Don't rename the target file without also updating the control file — the two must stay in sync.
• When the download finishes, .aria2 disappears automatically — a signal scripts can use to check completeness.

#Speed Control: Limit Download & Upload

Not every download may run at full throttle. aria2 provides two speed-limit options:

aria2c --max-download-limit=1M https://example.com/big-file.iso

Why limit speed? Because downloading large files can suck up all your bandwidth and disrupt other services on the same server — SSH gets slow, web apps lag. A speed limit is like keeping a safe following distance on the highway: the download keeps running, but doesn't endanger other road users. The K, M, and G suffixes mean kilobytes, megabytes, and gigabytes per second respectively.

#Limit Concurrency: --max-concurrent-downloads

When you download many files at once via an input file, aria2 runs up to 5 downloads simultaneously by default. The -j option (or --max-concurrent-downloads) sets this number:

aria2c -j 3 -i urls.txt

This isn't just about speed — it's also about politeness: downloading 50 files with 16 connections each can be seen as rude by a server. A sensible concurrency limit keeps you on good terms with the resources you use.

#Introduction to Control via RPC: Pause & Resume

Here's the aria2 differentiator we touched on in episode 1: downloads can be controlled from outside. Start aria2 as an RPC server with a secret for authentication:

aria2c --enable-rpc --rpc-secret=rahasia-saya

Now the aria2 server is listening on port 6800. You can ask to pause all downloads via JSON-RPC — for example before shutting down the server — using curl and jq:

curl -s http://localhost:6800/jsonrpc -d '{"jsonrpc":"2.0","id":"1","method":"aria2.pauseAll","params":["token:rahasia-saya"]}' | jq

To resume them again, change the method to aria2.unpauseAll. Paused downloads can be resumed any time — and combining pause with -c makes the whole process genuinely reliable.

#A Production Combination

Combining all this episode's lessons into one realistic command:

aria2c -c -j 4 --max-download-limit=2M -i urls.txt --log=/tmp/aria2.log

Read it as: resume interrupted downloads (-c), at most 4 downloads at once (-j 4), cap speed at 2 MB/s (--max-download-limit=2M), take the list from urls.txt (-i), and log everything (--log). This is a solid pattern to schedule via cron or a systemd timer — a topic we cover in the production episodes.

#Common Pitfalls

1. Deleting the .aria2 file. All progress records are lost and the download restarts from zero. Treat the control file like something valuable while the download is incomplete.

2. -c on a server without Range support. If the server answers 200 instead of 206, no resume happens — a server limitation, not an aria2 bug.

3. Speed limit set too low. --max-download-limit=10K on a 1GB file will take days. Match it to a realistic time target.

4. -j too large for a big batch. Hundreds of simultaneous downloads burden the server and network. Start at 3 to 5, then increase gradually.

#Closing

In episode 5 you equipped aria2 with resilience and control: resuming interrupted downloads with -c and understanding the role of the .aria2 control file, limiting speed with --max-download-limit and --max-upload-limit, limiting simultaneous downloads with -j, and learning the pause-resume pattern via RPC using curl and jq.

Key takeaways:

• -c resumes a download from the last position; it needs Range support from the server (206 Partial Content).
• The .aria2 control file is the key to resume — don't delete or rename it before the download finishes.
• --max-download-limit and --max-upload-limit limit speed; -j limits concurrency.
• RPC enables pause-resume from outside the server — the foundation of the download server we'll build in the coming episodes.

In the next episode, episode 6, we'll cover batch download & input file — downloading many files at once from a list, using per-download options in the input file, and combining it with -x, -s, -c, and -j for reliable batch jobs. See you in episode 6!