How to resume interrupted downloads using wget

Interrupted transfers waste time and bandwidth when a large file has to start over from byte zero. Resuming a partial download lets wget reuse the local bytes already on disk, which is especially useful for large archives, unstable links, and scheduled recovery jobs.

GNU wget resumes with -c or --continue by looking at the size of the existing local file and requesting only the remaining bytes from the server. When the remote endpoint supports HTTP byte ranges, the resumed request returns HTTP 206 Partial Content and appends the missing portion to the current file.

Current GNU documentation also notes that -c is only needed when a partial file from an earlier invocation already exists; losing the connection mid-run is retried automatically by default. Server support for the Range header is still essential, because an endpoint that ignores ranged requests can force wget to restart from the beginning and overwrite the partial file instead of appending to it.

1. Change to the directory that already contains the partial file and confirm its current size.

   $ cd ~/downloads/resume
   $ ls -lh db-backup-20260329.tar.gz
   -rw-r--r-- 1 user user 96M Mar 29 09:18 db-backup-20260329.tar.gz

   Resume works against the existing filename in the current directory, so renaming the partial file changes what wget will treat as the recovery target.

2. Resume the transfer with -c and watch for a partial-content response from the server.

   $ wget -c https://artifacts.example.net/backups/db-backup-20260329.tar.gz
   --2026-03-29 09:18:35--  https://artifacts.example.net/backups/db-backup-20260329.tar.gz
   Connecting to artifacts.example.net (artifacts.example.net)|198.51.100.24|:443... connected.
   HTTP request sent, awaiting response... 206 Partial Content
   Length: 402653184 (384M), 301989888 (288M) remaining [application/octet-stream]
   Saving to: 'db-backup-20260329.tar.gz'
   
           [ skipping 98304K ]
   196608K ........ ........ ........ ........ ........ ........ 50% 47.9M 3s
   294912K ........ ........ ........ ........ ........ ........ 75% 48.2M 1s
   393216K ........ ........ ........ ........ ........ ........ 100% 48.4M=5.9s
   2026-03-29 09:18:41 (48.4 MB/s) - 'db-backup-20260329.tar.gz' saved [402653184/402653184]

   A 206 Partial Content response confirms that the server accepted the range request and sent only the missing bytes.

3. Check the remote headers before relying on resume behavior in automation.

   $ wget --server-response --spider https://artifacts.example.net/backups/db-backup-20260329.tar.gz 2>&1 | grep -iE 'HTTP/|Accept-Ranges'
     HTTP/1.1 200 OK
     Accept-Ranges: bytes

   Treat Accept-Ranges: bytes as a positive preflight signal, but verify resume support with a real wget -c test. If the resumed request does not return 206 Partial Content, assume the download can restart from byte zero and overwrite the partial file.

4. Remove the partial file only after you confirm the source changed or the server cannot resume it safely.

   $ rm -f db-backup-20260329.tar.gz
   $ wget https://artifacts.example.net/backups/db-backup-20260329.tar.gz

   Deleting the partial file is irreversible, so verify the path and filename before removing it.

5. Verify that the file is complete and that a second resume attempt becomes a no-op.

   $ ls -lh db-backup-20260329.tar.gz
   -rw-r--r-- 1 user user 384M Mar 29 09:18 db-backup-20260329.tar.gz
   
   $ wget -c https://artifacts.example.net/backups/db-backup-20260329.tar.gz
   --2026-03-29 09:18:45--  https://artifacts.example.net/backups/db-backup-20260329.tar.gz
   Connecting to artifacts.example.net (artifacts.example.net)|198.51.100.24|:443... connected.
   HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable
   
       The file is already fully retrieved; nothing to do.

   Pair the size check with a checksum when the recovered artifact will be unpacked or executed later.