rsync or git backups?

[Brandon J. Wandersee]

Steve O'Hara-Smith writes:

> On Wed, 1 Jun 2016 10:35:06 +0200
> Luca Ferrari <fluca1978 at infinito.it> wrote:
>
>> Hi all,
>> so far I'm using rsync to keep in sync a couple of removable media
>> (well, up to four) where one is the "master" and the others are a
>> cascade backups (meaning they are set at different time).
>> So far so good.
>> One problem is that I tend to change things in the master, e.g., bulk
>> file renaming or moving, so when I replicate it on the backups I have
>> to force the deletion of no more existing content.
>> This approach, however, relies on the fact that the master is good. My
>> fear is that if the master corrupts some file, I could possibly loss
>> them if they have also been moved since I will no more be able to
>> recognize them on the slaves.
>> 
>> So I would like to have some feature like git (or fossil) for hash
>> handling, but since I'm talking about 290+ GB of binaries I'm not sure
>> this approach could work.
>> 
>> Any suggestion?
>
> 	Use ZFS with snapshots (the zfs-periodic package is good for this)
> and replace the rsync with send/receive, ZFS will protect you from hardware
> silent corruption (provided you allow some redundancy - use copies on pools
> with no redundancy) while the snapshots will protect you from mistakes.

If ZFS seems like overkill or too much hassle at the moment, you could
instead use sysutils/rsnapshot. It uses rsync to create snapshot-style,
rotating, de-duplicating, incremental backups.  Verbose logging will
show you what files have changed since the last backup, so if you see a
file in the logs that you know you haven't changed in some time, it's
probably corrupt or has otherwise been compromised. Meanwhile, the
previous (good) versions will remain intact.

-- 

::  Brandon J. Wandersee
::  brandon.wandersee at gmail.com
::  --------------------------------------------------
::  'The best design is as little design as possible.'
::  --- Dieter Rams ----------------------------------