Rich Freeman on 19 Nov 2011 12:12:08 -0800 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [PLUG] Incremental backup via cron |
On Sat, Nov 19, 2011 at 12:33 PM, Paul Walker <starsinmypockets@gmail.com> 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): #!/bin/bash #(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/sarab.sh # (use of ionice / nice is of course optional - I like my disks working - I avoid -c 3 otherwise it takes too long) cd $BACKDIR CURBACK=`ls --sort=time -1 | head -n 1` cd "$BACKDIR/$CURBACK" 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 mkdir "$UPDIR/$CURBACK" 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 --add-header=x-amz-storage-class:REDUCED_REDUNDANCY --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 offsite!!!!!!! 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... Rich ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug