Date: Wed, 01 Jun 2016 13:18:43 -0500 From: Brandon J. Wandersee <brandon.wandersee@gmail.com> To: Steve O'Hara-Smith <steve@sohara.org> Cc: Luca Ferrari <fluca1978@infinito.it>, freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: rsync or git backups? Message-ID: <86k2i8kc1o.fsf@WorkBox.Home> In-Reply-To: <20160601113332.5e250d300d770ab04e9c9cc2@sohara.org> References: <CAKoxK%2B4MuSFi7ctcAXVzZ61mXzCsnP-qsWxEOTor_T1SFgc-cg@mail.gmail.com> <20160601113332.5e250d300d770ab04e9c9cc2@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve O'Hara-Smith writes: > On Wed, 1 Jun 2016 10:35:06 +0200 > Luca Ferrari <fluca1978@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@gmail.com :: -------------------------------------------------- :: 'The best design is as little design as possible.' :: --- Dieter Rams ----------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86k2i8kc1o.fsf>