Brian Stempin on 19 Nov 2011 13:00:23 -0800

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

Re: [PLUG] Incremental backup via cron

Backup ninja is something that I've used in the past for simple backups.  It allows you to choose intervals, if you want it GPG'd, and if you want it transported somewhere.  It also allows you to execute custom scripts.


On Nov 19, 2011 3:12 PM, "Rich Freeman" <> wrote:
On Sat, Nov 19, 2011 at 12:33 PM, Paul Walker
<> wrote:
> Do folks mind sharing their backup strategies? I'd
> rather use command line tools that I can invoke via cron.

Probably a good topic for a lightning talk.  I use a shell script
invoked by cron daily.  Quick outline of the steps:

1.  Use sarab to create the backups.  Sarab is itself a script that
handles dar with rotating media.  It just dumps the backup into a
directory tree (with subdirs for each backup).  It supports just about
any incremental rotation scheme you can come up with.

2.  I then identify the latest backup and pipe all the files through
gpg into a new directory tree.  So, that is an encrypted copy suitable
for remote storage.

3.  I use s3cmd to sync the encrypted directory tree to Amazon S3.  It
ensures all data is successfully uploaded before anything outdated
gets deleted.

4.  I'm lazy so whenever I do a full backup I prune out all the
useless incrementals manually.  However, it is easier still to keep
everything forever, or you can overwrite media sets as they are
replaced, or whatever.

Sarab has two configuration files - one that sets up its behavior
around media sets, and another that is just a bunch of dar rules.  In
your case that could be a one-liner, but if you want to set up
exclusions or whatever you can tweak that.

The only downside is that it is a bit duct-taped together, but it
works fine for me.  I run it daily but set up cron properly and you
can run it ever 30 seconds if you want to.  Of course, I didn't design
it for concurrency so all bets are off if it takes longer than your
cron interval to run (though I think most cron implementations won't
re-spawn a job if the last one is still running, so don't fork and
you're fine).  It does consume disk space for those backups.

Here is my script (watch the line breaks though):
#(might run fine on sh)

BACKDIR='<unencrypted backup output directory>'
UPDIR='<encrypted backup output directory>'
BUCKET='<s3 bucket - create manually one time>'

#insert a call to a script here to do a mysql dump to someplace in the backup

ionice -n 7 nice -n 20 /usr/bin/
# (use of ionice / nice is of course optional - I like my disks
working - I avoid -c 3 otherwise it takes too long)

CURBACK=`ls --sort=time -1 | head -n 1`
mv "$UPDIR/$CURBACK" /tmp/
# can just delete instead - I move for speed (keep it on the same
filesystem) and safety and let tmpreaper take care of it
for encfile in * ; do nice -n 20 gpg -o "$UPDIR/$CURBACK/$encfile" -r
<insert gpg key id here> --encrypt $encfile ; done

cd "$UPDIR"
ionice -c 3 nice -n 20 s3cmd
--no-delete-removed sync . "$BUCKET/" || exit
ionice -c 3 nice -n 20 s3cmd
--add-header=x-amz-storage-class:REDUCED_REDUNDANCY --delete-removed
sync . "$BUCKET/"

More notes:
1.  I use a key id to avoid risk of confusion.  It obviously has to be
in your keyring.  I recommend a dedicated key, and keep backups of it
2.  You need to set up s3cmd with your passcodes/etc in the
enviornment (or however it works - forget offhand).
3.  Use of reduced redundancy storage is optional, but I figure the
risk of amazon and I both losing our data at the same time has to be
low, so saving 2/3rds of the cost is a nice tradeoff.
4.  It might be ok to just do both upload/delete in a single command,
but I haven't tested the failure modes on that.  It should just
generate extra requests and not extra data transfer so cost is
virtually non-existent.
5.  Shell script is not very clean - I'm sure there are error
conditions that I'm not handling, and it will definitely need more
quoting if you have spaces in your backup output locations.  Spaces in
the files being backed up won't matter at all since the script doesn't
see those.  If the backup fails it probably ends up re-encrypting and
re-uploading the last one, but that shouldn't hurt unless something
bad happened to those files since the last time.

Works for me...

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --