Re: Interesting post-mortem on a near disaster with git

On 3/26/13 6:42 AM, Cédric Villemain wrote:
> Le lundi 25 mars 2013 19:35:12, Daniel Farina a écrit :
>
>  > On Mon, Mar 25, 2013 at 11:07 AM, Stefan Kaltenbrunner
>
>  >
>
>  > <stefan@kaltenbrunner.cc> wrote:
>
>  > >> Back when we used CVS for quite a few years I kept 7 day rolling
>
>  > >> snapshots of the CVS repo, against just such a difficulty as this. But
>
>  > >> we seem to be much better organized with infrastructure these days so I
>
>  > >> haven't done that for a long time.
>
>  > >
>
>  > > well there is always room for improvement(and for learning from others)
>
>  > > - but I agree that this proposal seems way overkill. If people think we
>
>  > > should keep online "delayed" mirrors we certainly have the resources to
>
>  > > do that on our own if we want though...
>
>  >
>
>  > What about rdiff-backup? I've set it up for personal use years ago
>
>  > (via the handy open source bash script backupninja) years ago and it
>
>  > has a pretty nice no-frills point-in-time, self-expiring, file-based
>
>  > automatic backup program that works well with file synchronization
>
>  > like rsync (I rdiff-backup to one disk and rsync the entire
>
>  > rsync-backup output to another disk). I've enjoyed using it quite a
>
>  > bit during my own personal-computer emergencies and thought the
>
>  > maintenance required from me has been zero, and I have used it from
>
>  > time to time to restore, proving it even works. Hardlinks can be used
>
>  > to tag versions of a file-directory tree recursively relatively
>
>  > compactly.
>
>  >
>
>  > It won't be as compact as a git-aware solution (since git tends to to
>
>  > rewrite entire files, which will confuse file-based incremental
>
>  > differential backup), but the amount of data we are talking about is
>
>  > pretty small, and as far as a lowest-common-denominator tradeoff for
>
>  > use in emergencies, I have to give it a lot of praise. The main
>
>  > advantage it has here is it implements point-in-time recovery
>
>  > operations that easy to use and actually seem to work. That said,
>
>  > I've mostly done targeted recoveries rather than trying to recover
>
>  > entire trees.
>
> I have the same set up, and same feedback.

I had the same setup, but got tired of how rdiff-backup behaved when a backup was interrupted (very lengthy cleanup
process).Since then I've switched to an rsync setup that does essentially the same thing as rdiff-backup (uses
hardlinksbetween multiple copies). 

The only downside I'm aware of is that my rsync backups aren't guaranteed to be "consistent" (for however consistent a
backupof an active FS would be...). 
--
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net