[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Automating backups
- Subject: Re: Automating backups
- From: "Chris Travers" <..hidden..>
- Date: Wed, 4 Apr 2007 09:46:56 -0700
I also have maintained a set of shell scripts that may provide some of
the missing people Peter was looking for. Take a look at the sec-bk
project on the following site: http://www.metatrontech.com/projects/
I don't know whether I put PostgreSQL support in it yet since it was
commissioned by a customer using MySQL... But the framework allows
for local encryption and remote storage. Technologies used include
gpg and openssh. It is a set of bash scripts so would not run on
On 4/4/07, Joshua D. Drake <..hidden..> wrote:
Peter Houppermans wrote:
> [pg_dump et al]
> I think there's scope for creating some script that handles the backup
> automagically so it can be stuck in a cron job. The idea is to give
> people a framework to work with - adding FTP/SCP/DVD burning/switching
> on coffee makers is up to local conditions - and ideally this backup
> should be in a format that allows restore of the complete accounts as
> well as the code (also allows for making backups prior to fundamental
> structural changes in code/database - always nice to be able to go back
> the old "machine").
Well from a database perspective, pg_dump gives you that. I don't think
it is unreasonable to expect people that are running LedgerSMB to also
knows the basics of backing up PostgreSQL.
Granted pg_dump does not give you code, which would have to be handled
differently, and yes it does make sense to allow someone to click a
button in the app and have it correctly create a backup, and then allow
you to download said backup.
As far as adding crons for automated backups? That is a system
administrators job and I for one would be ticked if an APP automagically
starting add crons to one of my production machines.
Granted, we should document how one could do it themselves.
> In addition to that, lesson no 1 of Business Continuity Processes is
> that a backup is not a backup unless you (a) can restore it and (b)
> regularly test and exercise the restore process - ergo a restore
> methodology would not go amiss either.
> Bottom line: good question that probably deserves more attention re
> answer, not everyone is a (very responsive) top coder like you :-).
Not suggesting that this is not a good question. The answer to your
question is pg_dump, which is a PostgreSQL application. You can see the
> As for disasters, I've been there re. failing and incomplete backups -
> it's not the most popular discovery at 4am when you're busy reviving a
> system that is needed 9am.. This means that the steps prior to
> restoring the DB as you describe in part (2) of your answer probably
> need scripting too (most likely by using a complete tar.gz archive of
> code and db dump).
True all of this would need scripting for automation. We take
Joshua D. Drake
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
Ledger-smb-users mailing list