It happens to everyone eventually. The laptop battery dies in the middle of a backup, the external drive cable gets knocked loose, or you have to close the terminal and leave. Hours of copying appear to be wasted, and the natural fear is that you must start the whole backup again from zero.
With rsync, you almost never have to. Rsync was designed to compare what is already at the destination and transfer only what is missing or different. Even better, with the right option it can keep a partly copied large file and finish just that file, instead of sending it all again. This guide shows you exactly how to resume an interrupted backup calmly and safely.
Quick Answer
Simply run the same rsync command again. Rsync checks the destination, skips files that are already complete, and copies only what is missing or changed. To also resume partly transferred large files instead of restarting them, add --partial, or use the combined shortcut -P, which enables both partial saving and progress display: rsync -avhP /home/yourname/ /media/yourname/BackupDrive/home-backup/.
Why Rsync Does Not Start From Zero
Rsync begins every run by building a list of files at the source and comparing it with what exists at the destination. For each file it checks the size and modification time, and when those match, it reasonably concludes the file is already copied and moves on. That quick check is why a resumed backup often races through thousands of already-copied files in seconds and then slows down only when it reaches genuinely new work.
This behaviour is automatic. You do not need a special resume mode for ordinary files, because a normal rsync run is already a resume in practice. The interrupted run left real, complete files on the drive, and the new run treats them as the starting point. The exception is the one file that was mid-transfer when everything stopped, and that is where the partial options come in.
The Partial File Problem
Imagine a 6 gigabyte video was 80 percent copied when the drive disconnected. Without any partial option, rsync keeps no usable record of that unfinished transfer at the destination in a normal local copy, so the next run sends the whole video again. On a fast local drive that is a minor annoyance. Over a slow network or with a huge disk image, it can mean repeating the slowest part of the whole job.
The --partial option changes this. It tells rsync to keep partly transferred files at the destination instead of discarding them, so a later run can append the missing portion. The shortcut -P combines --partial with --progress, which is why you see it so often in backup commands: you get resumable transfers and a live progress display in a single letter. The rsync manual page describes both options precisely, including how they behave over network connections.
Step by Step: Resuming Your Backup
- Fix the original cause first. Reconnect the drive firmly, plug in the laptop charger, or wait for the network to return. Resuming into the same failure just interrupts you twice.
- Confirm the drive is mounted at the same place. Run
df -hand check that the destination path, such as/media/yourname/BackupDrive, is the real external drive and not an empty folder on your internal disk. - Optionally dry-run. Add
--dry-runto your usual command to see what rsync plans to do. A resumed job should list far fewer files than the original full backup. - Run the same command, adding -P. For example:
rsync -avhP /home/yourname/ /media/yourname/BackupDrive/home-backup/. Keep every path exactly as before. - Watch the progress. You will see rsync move quickly past completed files, then settle into real transferring at the point where the interruption left gaps.
- Let it finish and read the summary. The transferred total should be much smaller than the full size of your home folder. That small number is your proof the resume worked.
Keep the Command Identical
The most important rule of resuming is consistency. Use the same source, the same destination, and the same trailing slash as the original run. If your first command used /home/yourname/ with a trailing slash, keep it. Changing the path, even slightly, can create a second folder structure beside the first, and rsync will treat those files as a brand-new backup and copy everything again into the new location.
This is also why keeping your backup command in a small script or shell history note is so valuable. Instead of retyping from memory under stress, you run the identical command every time. Our walkthrough on mirroring your home folder to an external drive with rsync shows a clean command layout that is easy to save and reuse exactly.
Going Deeper: Checksums and Partial Verification
Sometimes quick checks are not enough. If the interruption was messy — a sudden power cut, for instance — you might worry that a file at the destination looks complete but is quietly damaged. Rsync’s --checksum option answers that worry by comparing file contents using checksums instead of trusting size and time alone.
Run a verification pass like this: rsync -avhc --dry-run /home/yourname/ /media/yourname/BackupDrive/home-backup/. The c enables checksum comparison, and the dry run means nothing changes while it reports. If rsync lists almost nothing, your backup matches the source. If it lists a file, that file differs and a real run will fix it. Be aware that checksums read every byte on both sides, so this check is slow on large backups. Use it after a nasty interruption or once in a while as an audit, not as your everyday setting. The official explanation of how rsync works covers the comparison and rolling checksum ideas behind this behaviour.
What About –append and –inplace?
You may see --append suggested for resuming. It assumes destination files are shorter versions of the source and simply adds the rest, without verifying the existing part. That is fast but risky if the existing part is wrong. For a home backup, plain -P is the safer everyday choice, because rsync still checks what it is building on. Special options have their place on slow, trusted network links, but they are not the place to start.
Common Mistakes and Useful Tips
- Deleting the partial backup in frustration. The files already copied are the whole reason resuming is fast. Leave the destination exactly as the interrupted run left it.
- Changing the destination folder name. A new folder means a new, full copy. Resume into the same folder the original command used.
- Resuming before fixing the cause. A loose cable or full destination drive will interrupt you again. Check free space with
df -hbefore restarting. - Forgetting -P on very large files. Without partial saving, a nearly finished huge file restarts completely. Add
-Pto your standard command so every run is resume-friendly. - Closing the terminal too soon after it looks done. Wait for the final summary and prompt. That summary confirms totals and reports any errors from the run.
- Worrying that skipped files were ignored. Skipping is the success case. It means rsync verified those files are already present and complete by its checks.
One extra habit helps on unreliable connections: run rsync inside a session tool or simply keep the machine awake during the job. Preventing the interruption is pleasant, but as this guide shows, it is no longer essential. With rsync, an interruption is a pause, not a disaster.
Conclusion
An interrupted rsync backup is not a failed backup. Run the identical command again and rsync skips everything already complete, copying only what is missing. Add -P so even a half-copied large file can pick up where it stopped, and reach for a checksum dry run when an interruption was rough enough to make you doubt the result. Stay calm, change nothing about the command, and let rsync finish the job it started.
Frequently Asked Questions
Do I need a special resume command for rsync?
No. Running the same command again is the resume. Rsync compares the source and destination at the start of every run and skips files that are already complete, so only missing or changed data is transferred.
What does the -P option actually do?
It combines two options: --partial, which keeps partly transferred files so they can be finished later, and --progress, which shows live progress for each file. It is the most useful single addition to a backup command.
How can I tell the resume actually worked?
Read the final summary. The total size will show your full backup size, but the amount actually transferred will be far smaller, covering only the files that were missing or unfinished when the first run stopped.
Is it safe to resume after a power cut?
Generally yes. Completed files stay valid, and the next run rechecks everything. If the power cut was abrupt, run a checksum dry run afterwards to confirm the destination truly matches the source before trusting the backup fully.
Why did rsync copy everything again on my second run?
Almost always because something about the command changed: a different destination folder, a missing trailing slash, or a drive mounted at a different path. Compare the new command with the original carefully; identical paths are the key to resuming.


Leave a Reply