[H-GEN] remote backup of server

[ben.carlyle at invensys.com]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

Michael Anthon <michael at anthon.net>
Sent by: Majordomo <majordom at caliburn.humbug.org.au>
29/01/03 13:08
Please respond to general

 
        To:     general at lists.humbug.org.au
        cc: 
        Subject:        Re: [H-GEN] remote backup of server

> > Either the mysqldump tool to dump the grants/structure/data to an SQL
> > file and scp that,
> or this...
> ssh backup_user at host mysqldump --opt --all-databases | gzip > backup.gz

> Particularly useful when there is not enough space on the database host
> to store the full backup.

Of course, this has the downside of not preserving the return code of the 
ssh (and thus the mysqldump). You won't know this command has failed 
unless you check every backup you make.

An alternative implimentation which uses the temporary space on the 
machine actually backing up would leave it as two commands:

#!<preferred shell> -e
ssh backup_user at host mysqldump --opt --all-databases > backup
gzip backup

Of course, there are several ways to catch and deal with such errors even 
in the shell environment:

function failed { ... ; exit 1; }

ssh backup_user at host mysqldump --opt --all-databases > backup || failed 
"ssh failed"
gzip backup || failed "gzip failed"

or use a script to call the one that fails on error:

if ! backup_script >backup_log 2>&1; then
        # Notify administrator in some special way
fi

Ultimately, though, you should verify every backup... or at least as many 
as practical.

Benjamin "Have you caught your errors, today?" Carlyle.


--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/