Re: CVS corruption/mistagging? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: CVS corruption/mistagging?
Date
Msg-id 46C31C84.9010407@dunslane.net
Whole thread Raw
In response to Re: CVS corruption/mistagging?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CVS corruption/mistagging?  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
List pgsql-hackers

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>   
>> Tom Lane wrote:
>>     
>>> Good, but the salient followup questions to that are (1) backed up to
>>> where exactly?, and (2) how many days' past backups could we get at,
>>> if we had to?
>>>       
>
>   
>> They are dumped to a NFS share on this schedule. That NFS share is
>> dumped to tape by systems at Conova - I'll let Stefan fill in the
>> details about that.
>>     
>
> That's good as far as it goes, but seeing that PG is a worldwide
> organization now, I wonder whether our primary CVS shouldn't have
> backups on several continents.  Pardon my paranoia ... but our
> collective arses have been saved by offsite backups at least once
> already ...
>
>
>   

Yes, I think we could improve on that. Have we considered more 
sophisticated solutions that provide incremental backup on a more 
frequent basis? I'd be inclined to use Bacula or similar (and it uses 
Postgres for its metadata store :-) ). Ideally I think we'd like to be 
able fairly easily and quickly to roll the repo (or some portion of it) 
back to a fairly arbitrary and fairly precise (say within an hour or 
two)  point in recent time.

Meanwhile, those of us who rsync the entire repo could easily make 
rolling backup copies. Arguably this might be better done from a repo 
made using --numeric-ids. Tarred and compressed it's a shade under 90 
Mb, which isn't huge. If people do this at various times of the day we'd 
get pretty good coverage :-)


cheers

andrew


pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: is this trigger safe and efective? - locking (caching via triiggers)
Next
From: Bruce Momjian
Date:
Subject: Another idea for index-only scans