Free tools Windows power users keep installed
One-click scans. No signup required.
Use rsync --delete only after a complete dry run shows that every planned deletion is intentional. The option removes files and directories from the receiving side when they are absent from the sending side. A safe process verifies both paths, reviews --dry-run --itemize-changes output, keeps ordinary excludes, and uses --backup with a separate --backup-dir when the destination matters. Without a backup, snapshot, or other recovery system, rsync does not provide an undo command for deletions.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What rsync --delete actually deletes
Rsync normally copies new and changed items from a source tree to a destination tree, but it does not remove unrelated items already at the destination. Adding --delete changes that behavior: during the synchronization, rsync removes destination-side files and directories that are not present in the corresponding source tree.
As an Amazon Associate I earn from qualifying purchases.
The deletion is relative to the directories being synchronized. It is not a command to empty an entire disk or destination mount. If you synchronize /srv/source/ to /srv/destination/, rsync compares the contents of those two trees and removes destination entries that are extra within that tree. Files outside the destination path are not candidates merely because --delete is present.
Rsync’s own documentation warns, “This option can be dangerous if used incorrectly!” The danger is usually a wrong source, a wrong destination, an unreadable source, or a filter rule that does not match what the operator intended.
#1 Best Overall
Excluded files are normally protected
Ordinary exclude rules do more than prevent transfer. They also protect matching destination files from deletion. This safety property changes if you add --delete-excluded or use receiver-side filter rules that make excluded names eligible for deletion. Treat that option as a separate, higher-risk operating mode; do not add it simply because a dry run appears inconvenient.
Source-side errors normally stop deletion
If rsync encounters sender-side I/O errors, it normally disables destination deletions for that run. This prevents a partially readable source from making the destination look like an incomplete source. --ignore-errors overrides that protection, so leave it disabled unless you have consciously accepted deletion even when the source could not be read completely.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Start by proving that both paths are correct
Most destructive rsync incidents are path-selection mistakes rather than failures of the comparison algorithm. Before adding --delete, check the source and destination in the same shell, account, mount namespace, container, or host in which the job will run.
Preflight checklist
- Confirm that the source mount is present and readable. A missing or unmounted source can appear empty or incomplete to the process that launches rsync.
- Confirm that the destination is the intended receiving directory, not a parent directory, a different mount, or a test path with a similar name.
- Inspect representative source and destination entries with
lsor an equivalent file browser before starting. - Check that the account running rsync can traverse directories and read every source area that should be mirrored.
- Record the rsync version with
rsync --version. Deletion timing defaults differ between old and current releases. - Decide where recoverable replacements and deletions will live before the first real run.
Use directory paths deliberately
Prefer an explicit tree-to-tree command such as /srv/source/ to /srv/destination/. A shell wildcard such as /srv/source/* is expanded by the shell before rsync starts. That expansion can cause rsync to receive a list of children instead of the source parent directory, changing the tree it considers synchronized and therefore changing deletion behavior.
The trailing slash is also meaningful. In /srv/source/, the slash conventionally means “synchronize the contents of this directory.” Without it, rsync can create or compare a directory named source under the destination. Decide which layout you want, then use the same deliberate path in the dry run and the real run.
Make the dry run the approval gate
The safest routine is to construct the complete command, add --dry-run (or -n), add --itemize-changes, and inspect the result before allowing any write operation.
Basic local-tree review
rsync -a --delete --dry-run --itemize-changes /srv/source/ /srv/destination/-a requests archive-style synchronization. It is a common starting point, not a universal policy: ownership, ACL, extended-attribute, remote-shell, and filter requirements may require additional options in your environment. The important safety rule is that the dry run must contain the same paths, filters, permissions options, and deletion timing you intend to use for the real run.
Read the itemized output
Review the complete output rather than checking only the first screen. Lines marked *deleting identify destination entries that rsync plans to remove. Do not proceed until every such line is expected. Also investigate surprising transfer lines: a source that suddenly appears empty, a large number of changed files, or a different top-level directory often indicates a mount, path, or permissions problem rather than a legitimate synchronization.
Save the dry-run output when the operation is important. A simple shell pattern is:
rsync -a --delete --dry-run --itemize-changes /srv/source/ /srv/destination/ > /var/log/rsync-delete-review.txtReview that file with a pager or text editor, and preserve it with the change record if your operating procedure requires an audit trail. Redirecting output does not change rsync’s safety behavior; it only makes the proposed changes easier to review.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Repeat the review after every material change
Changing an include rule, exclude rule, source mount, destination, archive-related option, or deletion timing changes the operation being approved. Run a new dry run after each such change. Never approve a previous output for a modified command.
Design filters so that “extra” means what you intend
Deletion is evaluated after rsync applies its file-selection rules. A destination name that is excluded by an ordinary exclude remains protected even when --delete is enabled. This is useful for local caches, generated files, and machine-specific configuration that should survive a mirror update.
Review every include and exclude rule
- Write down which destination-only files are intentional and must remain.
- Check whether a pattern matches a file, a directory, or both; a directory rule can affect all descendants.
- Run the dry run with the exact filter file or command-line rules used in production.
- Look for protected files in the destination that do not appear in transfer output; their absence can be correct when an exclude is doing its job.
Use --delete-excluded only as an explicit policy
--delete-excluded removes the protection normally provided by excludes. It may be appropriate when the destination must be an exact projection of a deliberately filtered source, but it also makes a filter typo destructive. Put it in a separate command or reviewed configuration, document why it is required, and inspect all deletion lines in a dry run before execution.
Add a recovery layer with --backup
For valuable data, combine deletion with --backup. Rsync then renames pre-existing destination files as they are replaced or deleted instead of simply discarding them. --backup-dir places those recoverable files in a separate directory.
rsync -a --backup --backup-dir=/srv/rsync-trash/ --delete /srv/source/ /srv/destination/Run this command only after reviewing its dry-run equivalent. The backup directory must have enough capacity, suitable permissions, and a retention plan. Keep it outside the mirrored destination tree, or protect it with explicit filter rules, so a later synchronization cannot treat the recovery area as ordinary destination content and remove it.
Rank #4
Plan retention and access
- Choose a backup location on storage that will not disappear with the destination tree.
- Restrict access to the backup directory if it contains confidential or regulated data.
- Monitor free space; a long-running mirror can accumulate many generations of replaced files.
- Define how long backups remain and how they are deleted separately from the mirror job.
- Test a restore by copying a known backed-up file to a temporary directory before relying on the arrangement.
--backup is a recovery aid, not a complete version-control system. It does not replace independent snapshots or a tested backup strategy, and it cannot recover data that was already deleted by an earlier run without backups.
Choose deletion timing deliberately
Rsync offers three deletion-timing modes. Selecting one explicitly makes behavior more predictable when the same command must run across machines with different rsync versions.
| Mode | When destination deletions occur | Operational characteristics |
|---|---|---|
--delete-during |
While rsync processes each directory during the transfer | Default for rsync 3.0.0 and newer when no timing option is supplied. It generally avoids waiting for a separate all-tree deletion phase and can leave a partially updated destination if the transfer is interrupted. |
--delete-before |
Before file data is transferred | Older rsync versions use this as the default when no timing option is supplied. Deletions happen up front, so an interruption can leave a destination with removals already applied but new or changed files not yet copied. |
--delete-after |
After the transfer pass | Useful when destination deletions should wait until transfers finish or when per-directory merge-file rules need to take effect before deletion. A separate deletion phase can require more time and resources. |
For reproducible automation, include the timing option you have selected instead of relying on a version-dependent default. Whichever mode you choose, the dry run must use the same mode as the real run.
Execute the approved command with logging
Once the dry run is understood, remove only --dry-run; keep the reviewed paths, filters, deletion timing, and recovery options unchanged. A production-style pattern might be:
rsync -a --backup --backup-dir=/srv/rsync-trash/ --delete --delete-during /srv/source/ /srv/destination/Add logging appropriate to your environment so that the command, start and finish times, exit status, and any warnings are retained. Do not enable --ignore-errors as a routine “make it finish” option. If the sender reports I/O problems, stop and repair the source or mount before attempting another deletion run.
Best Value
Run in a controlled window
- Pause applications that are actively creating or removing files in the source when a stable point-in-time view is required.
- Avoid changing filter files while the command is running.
- Keep an operator available for the first real run, especially when the destination is production data.
- After completion, inspect the exit status and review the log for errors rather than assuming that a returned prompt means the mirror is correct.
Diagnose common surprises
Unexpected *deleting lines
Stop the real run, or do not start it if you are still in the dry-run stage. Recheck the source mount, destination path, trailing slash, shell expansion, and filters. A missing source mount or an accidentally empty source directory is a common explanation. Do not “fix” the symptom by adding --ignore-errors or --delete-excluded.
No deletions appear when you expected them
Check whether the files are excluded. Ordinary excludes protect destination entries. Also verify that the paths are actually inside the synchronized tree and that the source is the intended one. If the destination was not writable, rsync should report errors; read the log and exit status before changing options.
Recommended Free Tools
The source had an I/O error
Rsync normally suppresses destination deletion in this situation. Preserve the destination, correct the source read problem, and rerun a dry run. Only use --ignore-errors after a deliberate decision that deleting destination-only files is safer than retaining them despite an incomplete source read.
The job was interrupted
The final state depends on the timing mode. With --delete-before, removals may already have happened before transfers completed. With --delete-during, some directories may be updated while others remain untouched. With --delete-after, deletion may not yet have occurred. Use the log and a fresh dry run to determine the remaining work; do not infer state from the interruption alone.
The command behaved differently on another host
Compare rsync versions and explicitly select --delete-during, --delete-before, or --delete-after. Also compare shell quoting, filter files, mount paths, and user permissions. A command copied verbatim can still select a different tree when a shell wildcard expands differently.
How to undo an rsync deletion
Rsync itself has no general undo operation. Recovery depends on what existed before the run:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- If
--backup --backup-dirwas used, locate the renamed file in the backup directory and restore it to the destination, preserving the required ownership and permissions. - If the destination is covered by filesystem snapshots, restore individual paths or roll back a snapshot according to that system’s procedure.
- If an independent backup exists, restore the missing paths from that backup.
- If none of these exist, stop writing to the affected storage and use an appropriate undelete or forensic process; success is not guaranteed, especially after subsequent writes.
After any restoration, run a dry run without destructive options first to verify that the source and destination now differ in the way you expect. A restore should not be followed immediately by an unreviewed --delete run.
A repeatable operating procedure
- Identify: write down the exact source and destination directory paths, host names, mounts, and account that will run rsync.
- Validate: confirm the source is mounted, readable, and complete; confirm the destination is the intended receiving tree.
- Construct: use directory paths rather than an unexamined wildcard, and include the exact archive, filter, backup, and deletion-timing options required.
- Preview: run the complete command with
--dry-run --itemize-changes. - Review: inspect every
*deletingline, unexpected transfer, warning, and filter effect. - Protect: for valuable data, enable
--backupand a separately managed--backup-diroutside the mirrored tree. - Execute: remove only
--dry-run, keep--ignore-errorsdisabled, and retain logs. - Verify: check the exit status, review errors, and run a non-destructive follow-up dry run if the result is important.
- Maintain: enforce backup-directory retention, test restoration, and revalidate the procedure whenever paths, filters, versions, or storage layouts change.
Decision checklist before pressing Enter
- Can you explain why every planned deletion is present?
- Did you inspect the exact dry-run output generated by the exact command you will execute?
- Are excluded destination files intentionally protected, or is a separately approved
--delete-excludedpolicy required? - Is the source definitely mounted, readable, and complete?
- Is the destination path definitely correct?
- Do you have a backup, snapshot, or other recovery path for data that must not be lost?
- Is the deletion timing explicit and compatible with the rsync versions in use?
- Will sender-side I/O errors stop deletion, with
--ignore-errorsleft off?
If any answer is uncertain, stop at the dry run. The safest rsync deletion is the one you can explain line by line before it changes the destination.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
