# Is rsync reliable enough?



## sdf (Aug 26, 2018)

Hello everyone,

When the source file is being written, if using rsync for synchronization at this time, will get a corrupted file?

Furthermore, if the source host is corrupted at this time, it will not work properly for the synchronized target host to replace the corrupted source host because it has files that have not yet been written.  Is this the case?


And which one is the best choice for the "--delete" option?

--delete-before
--delete-during
--delete-delay
--delete-after


Thanks.


----------



## `Orum (Sep 2, 2018)

sdf said:


> When the source file is being written, if using rsync for synchronization at this time, will get a corrupted file?


If you're worried about that happening, why not just remove that possibility from the equation and only rsync from snapshots?  Or better yet, just sync with the snapshots themselves (e.g. `zfs send/recv`)...


sdf said:


> Furthermore, if the source host is corrupted at this time, it will not work properly for the synchronized target host to replace the corrupted source host because it has files that have not yet been written.  Is this the case?


I'm not sure what you're asking here.


sdf said:


> And which one is the best choice for the "--delete" option?


This depends.  There's a reason for each one.


----------



## TomHsiung (Sep 2, 2018)

I use this syntax to copy files between my hosts. And it's OK.


----------



## kpa (Sep 2, 2018)

If you have corruption on the sending host at the time when rsync is running there's nothing that can help you, faulty hardware and operating level software bugs are on a different level altogether. It's not something that net/rsync could guard against because software can't be written with the assumption that it runs on quicksand foundations.


----------



## TomHsiung (Sep 2, 2018)

kpa said:


> If you have corruption


That's why we need HASH and MD5.


----------



## kpa (Sep 2, 2018)

TomHsiung said:


> That's why we need HASH and MD5.



You're missing the point of what I'm saying. I know very well that rsync uses cryptographic hashes for checking if the files need updating on the destination side and making sure nothing got corrupted in transit and this works as expected as long as you can trust both the hardware and the operating system you're using.

However, it all breaks down as soon as you can no longer trust the system you're using, all bets are off, cows may fly. The tools you're using such as rsync can't be expected to catch hardware or OS level software problems, it simply isn't their responsibility.


----------

