Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two data hard drives on my Linux server and I use second as a backup for a first drive.
I use rsync for that purpose. An example would be:

rsync -r -v --delete /media/disk1/ /media/disk2/

What this does is that it copies every file/directory from /media/disk1/ to /media/disk2/ but also deletes any difference. For example, lets say that files A and B but not file C are on disk1, and on disk2 there is no A and B files, but there is C. The result would be that after the command on disk2 I'd have files A and B, but file C would be deleted, just like on disk1.

Now, a rather disastrous scenario had crossed my mind; what if disk1 dies, system continues to work since system files are on my system disk, but when rsync tries to backup my data on disk2 from broken disk1, it deletes all the files from disk2 because it can't read anything on disk1.

Is this a possible scenario, or is there a protection from it build in rsync?

share|improve this question
up vote 3 down vote accepted

Realistically, in that scenario, the kernel would freak out, and you'd get a bunch of disk I/O errors before rsync deleted anything. But then if you were to reboot, it's possible that /media/disk1 would be empty and unmounted... So...

In your rsync script, just make sure you don't run rsync if there aren't any files in /media/disk1. An easy way to do that would be:

ls /media/disk1/SomeFileYouKnowExists || exit
rsync ....

This will cause the script to exit before running rsync in the case that the target file does not exist.

share|improve this answer
I once had failure of one disk in LVM setting and server continued to work so I would not bet on kernel halt, perhaps this happens if system disk fails.<br> As for the code you've suggested I backup huge amount of files that change and I can't track all of the changes. – enedene Jun 22 '11 at 9:45
That's because when a single disk in LVM fails, the other disk(s) can continue to serve data, and the kernel may not notice until it tries to read data from the failed disk. – Flimzy Jun 22 '11 at 9:47
It also sounds to me like maybe rsync isn't the right tool for your job--you might be better off with a real backup application. – Flimzy Jun 22 '11 at 9:47
@Flimzy, you're probably right about LVM but I can't be sure will this happen to non-system disk as well, since it didn't happen yet. rsync does the job well for now, that's why I'm asking if there is any danger, if not I'd continue to use it because it's easy and practical to me. I also wouldn't be surprised if more complicated solutions used rysnc in the background. – enedene Jun 22 '11 at 9:50
Sure, some backup systems may use rsync as a transfer method, but that's not a reason to trust rsync for valuable backups. That would be like saying "Some backup systems use HTTP, so I'll just upload my files to Gmail over HTTP as my backup method." A "real" backup system will provide versioned backups and history--which would make your question practially obsolete.:) – Flimzy Jun 22 '11 at 9:55

From the rsync manual:

If the sending side detects any I/O errors, then the deletion of any files at the destination will be automatically disabled. This is to prevent temporary filesystem failures (such as NFS errors) on the sending side from causing a massive deletion of files on the destination. You can override this with the --ignore-errors option.

share|improve this answer
Does this include all the possible range of disk errors, or only when there is a hard failure?<br> Disk errors can be strange, you can see the list of some files, but a part of it could be corrupted and so on. – enedene Jun 22 '11 at 9:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.