[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automating backups

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

Best Wishes,
Chris Travers

On 4/4/07, Joshua D. Drake <..hidden..> wrote:
Peter Houppermans wrote:
> Chris,
> [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
docs here:


> 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
contributions :).


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