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

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Interesting post-mortem on a near disaster with git
Date: 2013-03-25 18:35:12
Message-ID: CAAZKuFYa6bygQPtn6FCTjmhhTu-JoEcXz+eSV3QGWXvj6G2Myw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 25, 2013 at 11:07 AM, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)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.

--
fdr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-03-25 18:41:25 Re: backward incompatible pg_basebackup and pg_receivexlog
Previous Message Magnus Hagander 2013-03-25 18:33:05 Re: Interesting post-mortem on a near disaster with git