Why Does an Rsync Mirror Copy Accidental Deletions to the Backup?

An rsync mirror copies accidental deletions because a mirror is designed to make the destination match the current source. When the job uses --delete or a related delete option, a file missing from the home NAS is treated as an extra file on the backup destination and is removed during synchronization. That behavior is correct for a mirror, but it is unsafe as the only recovery history.

Rsync Is Following a Mirror Rule, Not Preserving Every Past Version

Without a deletion option, rsync normally copies new and changed files but leaves destination-only files in place. With --delete, the destination is reconciled to the source. A concise explanation of the flag states that deleting a file from the source also removes it from the destination so that the destination remains a true mirror.

For a ZimaSpace home NAS, this means a deleted family photo, renamed media folder, removed container configuration, or temporarily missing mount can be reflected on the USB or remote mirror at the next scheduled run.

The Deletion Starts With a Missing Source Path

Rsync does not know whether a file disappeared because you intentionally deleted it, an app cleaned it up, a user made a mistake, ransomware changed the tree, or a source dataset failed to mount. It compares the visible source tree with the destination tree. If an object exists only on the receiving side and deletion is enabled, it becomes a deletion candidate.

Delete Timing Changes When Files Are Removed, Not Whether They Are Removed

The related options control the phase of the transfer. --delete-before removes destination-only files before copying, --delete-during deletes while directories are processed, and --delete-after waits until transfers finish. They affect free-space behavior and failure exposure, but they do not turn the mirror into a versioned backup.

Use the timing deliberately. Deleting before the transfer may free capacity but removes the previous mirror state earlier. Deleting after the transfer preserves the old destination content longer, but the final result still matches the source if the job completes.

A Missing Mount Can Look Like a Mass Deletion

One of the most dangerous home-server cases occurs when the scheduled source path still exists as an empty directory after the real storage pool fails to mount. Rsync can then compare an empty source with a populated destination. A proposed safeguard is to run a dry check and count the planned deletions before allowing the real sync.

On a home NAS, make the job fail if the expected source mount, filesystem UUID, marker directory, or minimum file count is missing. Do not let the existence of an empty path count as a healthy source.

Pause the Job Before Trying to Recover a Deleted File

1. Disable the scheduled rsync task immediately.
2. Do not run the command again to “see if it fixes itself.”
3. Check snapshots, recycle bins, versioned backup repositories, and the second offline copy.
4. If the mirror still contains the file, copy it to a quarantine path outside the rsync destination before the next run.
5. Confirm whether the source deletion was intentional before restoring it into the live share.

The ZimaSpace article on keeping family photos in multiple independent copies is relevant here: a synchronized mirror should be one layer, not the only place an older file can survive.

Preview the Exact Deletion Set

Run the same command with --dry-run, verbose itemization, and deletion reporting. Review the source and destination paths, trailing slashes, excludes, mount state, and the number of planned deletions. A recent rsync safety article emphasizes that a mirror can reproduce accidental deletion or ransomware damage and therefore needs a separate history layer.

rsync -a --delete --dry-run --itemize-changes   /srv/storage/family/ /mnt/usb-mirror/family/

Treat an unexpectedly large deletion count as a failed preflight check. Stop and verify that the intended NAS dataset is mounted and that the command is not aimed at a parent directory or the wrong removable disk.

Move Deleted Destination Files Into a Recovery Area

If you need a mirror but also want a short recovery window, combine deletion with a backup directory or snapshot layer. Rsync can move replaced or deleted destination files into a dated recovery directory instead of destroying them immediately. Community guidance for retaining deleted rsync data recommends keeping deleted files in a separate location with its own cleanup policy.

rsync -a --delete   --backup   --backup-dir="/mnt/usb-mirror/deleted/$(date +%F)"   /srv/storage/family/ /mnt/usb-mirror/current/

Test the command with noncritical data first. The recovery directory must be outside the mirrored subtree, or a future run may treat it as part of the source or delete it through the same policy.

Use Versioned Snapshots When Past States Matter

A current mirror answers “what does the source look like now?” A backup answers “what did the source look like before the mistake?” If you need both, keep the mirror for fast access and add filesystem snapshots, hard-link snapshot directories, a versioned backup tool, or a second offline disk.

An account of accidental rsync deletion describes the underlying weakness clearly: a hand-built rsync workflow needs explicit rotation and deletion safeguards. Do not rely on one mutable destination to provide both exact synchronization and long-term history.

FAQ

If I remove --delete, does the mirror become a backup?

Not by itself. Destination-only files will remain, but overwritten files may still lose their previous contents, and there is no clean restore point for a specific date. Add snapshots or a versioned backup repository.

Which delete timing option is safest?

--delete-after delays deletions until transfers finish, which preserves the old destination state longer during the run. It still deletes destination-only files at completion, so preflight checks and version history remain necessary.

How do I stop an unexpected mass deletion?

Disable the schedule, run a dry run with deletion output, verify the source mount and path, and set a deletion-count threshold or marker-file check. Do not rerun the live command until the proposed deletion list is understood.

Final Takeaway

Rsync mirrors accidental deletions because deletion options make the backup destination match the visible NAS source. Protect a ZimaSpace home-server workflow by verifying mounts, previewing deletions, quarantining removed files, and keeping versioned or offline recovery points. A mirror can be useful, but an exact mirror without history is not sufficient protection from human error.