From: | Cédric Villemain <cedric(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Daniel Farina <daniel(at)heroku(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)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> |
Subject: | Re: Interesting post-mortem on a near disaster with git |
Date: | 2013-03-26 11:42:13 |
Message-ID: | 201303261242.18023.cedric@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le lundi 25 mars 2013 19:35:12, Daniel Farina a écrit :
> 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.
I have the same set up, and same feedback.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-03-26 11:57:34 | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
Previous Message | Robert Haas | 2013-03-26 11:33:24 | Re: Limiting setting of hint bits by read-only queries; vacuum_delay |