On 08/27/2013 04:51 PM, helix84 wrote:
> On Tue, Aug 27, 2013 at 6:53 PM, Thomas Ronayne
> <ronayne.thomas@...> wrote:
>> doing the same with /var/lib/pgsql -- files are just files after all else is
>> said and done, eh? Stop PostgreSQL on both servers, do the rsync and restart
>> the DBMS on both. Maybe stop Tomcat, too, but that might be overkill.
> Oh, no, completely unnecessary downtime.
Well, it would be done with a cron job in the middle of the night --
don't like to do back up when folks have access to things.
> Just do pg_dump on a running database and you'll have one nice sql
> file instead of database files specific to a particular postgres
> version. More importantly, as you noticed, you'd have to worry about
> hot backup - but why go through all that trouble?
Yeah, good point.
> There is one theoretical issue - there might be an item submitted to
> DSpace between pg_dump finishes and rsync finishes (or vice versa),
> which would mean you backed up the database with the item record, but
> not its bitstream (or vice versa). It would affect only this item, the
> rest would work perfectly fine. In practice, the backup process will
> be a nightly cronjob that will finish pretty fast, so I wouldn't worry
> about it at all.
Well, that's why I'd shut down Tomcat so nobody can get at anything in
the middle of the night. But, yeah, rsync might just be overkill and
pg_dump ought to do just fine. I generally keep copies of configuration
files (in a tart file) so I can quick and easy do a complete software
installation, copy the configuration file (just extract the tar file) on
to the new install and be up and running quickly. Keeping a data base
back up and loading from scratch has worked before and I'm pretty sure
would work again (and it's easy). As long as both machines don't poop
their diapers at the same time... life is good. And, of course, a copy
of the back up is off on media too.
> Compulsory reading: DSpace Mailing List Etiquette
Thanks for the thoughts.