Encrypted remote backups made easy
Posted by JohanJentell on Mon 27 Nov 2006 at 06:25
This is an easy way to take backups and putting them on a remote site. I invented this script in order to put backups on a reliable remote site where I unfortunatley only have a user account.
The prerequisites for this script is:
- Public key authentication over SSH set up with the remote site. If you dont have this, follow this guide.
- Gnu-PG installed
This is the entire script. Everything written in capital letters should be replaced by your own information. If you want an explanation of each section of the script, look a bit further down...
touch /tmp/$datetime chmod 0600 /tmp/$datetime find /var/www/ -name "*.html" -print >> /tmp/$datum touch /tmp/backup_sql_$datetime.sql chmod 0600 /tmp/backup_sql_$datetime.sql mysqldump --databases YOUR_DATABASE_NAME -u YOUR_USERNAME -pYOUR_PASSWORD >> /tmp/backup_sql_$datetime.sql echo /tmp/backup_sql_$datetime.sql >> /tmp/$datetime tar cjfT /tmp/backup_$datetime.tar.bz2 /tmp/$datetime 2> /dev/null echo SECRET_PASSWORD| gpg --batch --yes --passphrase-fd 0 --symmetric --cipher-algo AES256 /tmp/backup_$datetime.tar.bz2 scp -2 -p -B -q /tmp/backup_$datetime.tar.bz2.gpg REMOTE_USERNAME@REMOTE_HOST:REMOTE_FOLDER/ ssh -2 -lREMOTE_USERNAME REMOTE_HOST chmod 0600 REMOTE_FOLDER/backup_$datetime.tar.bz2.gpg rm -f /tmp/$datetime /tmp/backup_sql_$datetime.sql /tmp/backup_$datetime.tar.bz2 /tmp/backup_aik_$datetime.tar.bz2.gpg
Ok here goes for explaining it:
touch /tmp/$datetime chmod 0600 /tmp/$datetimeCreates a timestamp of when the backup is created.
touch /tmp/$datetime chmod 0600 /tmp/$datetimeCreates a file in which to list all files to back up.
find /var/www/ -name "*.html" -print >> /tmp/$datumFinds all .html documents in the /var/www folder and add to the backup-list.
touch /tmp/backup_sql_$datetime.sql chmod 0600 /tmp/backup_sql_$datetime.sql mysqldump --databases YOUR_DATABASE_NAME -u YOUR_USERNAME -pYOUR_PASSWORD >> /tmp/backup_sql_$datetime.sql echo /tmp/backup_sql_$datetime.sql >> /tmp/$datetimeTakes a backup of your mysql database and add to the backup-list.
tar cjfT /tmp/backup_$datetime.tar.bz2 /tmp/$datetime 2> /dev/nullCreates a compressed file of all files in the backup-list using the bz2 algorithm (you might need support for bz2).
echo SECRET_PASSWORD| gpg --batch --yes --passphrase-fd 0 --symmetric --cipher-algo AES256 /tmp/backup_$datetime.tar.bz2Encrypts the compressed file using AES encryption.
scp -2 -p -B -q /tmp/backup_$datetime.tar.bz2.gpg REMOTE_USERNAME@REMOTE_HOST:REMOTE_FOLDER/Copy the encrypted file to a remote location
ssh -2 -lREMOTE_USERNAME REMOTE_HOST chmod 0600 REMOTE_FOLDER/backup_$datetime.tar.bz2.gpgMake sure the remote file does not have any read/write privileges to the backupfile.
rm -f /tmp/$datetime /tmp/backup_sql_$datetime.sql /tmp/backup_$datetime.tar.bz2 /tmp/backup_aik_$datetime.tar.bz2.gpgCleans upp all locally used documents during the backup procedure
The bad things with this script: It will allow anyone with local root privileges to see the passwords you have entered into the script file. It will also reveal MySQL and GPG passwords used if someone is monitoring the processes on the local machine.
The good things: It is darn easy to use. Seen from a remote perspective, it is a very safe way of taking backups. All transmissions are using SSH v2. The remote backup using AES-256 and your choice of a strong password should keep your backups safe from evil decrypters during the next 20 years at least (unless any huge technical breakthrough or exploit found in the encryption algorithm)
Thoughts about the script: All STD Error output from tar is piped to /dev/null. This is only because tar otherwise always outputs "removing leading /", which is good that the program does, but is a bit irritating in your logfiles as it looks as something actually went wrong in the script. There should be a nicer solution to this.
"Duplicity backs directories by producing encrypted tar-format volumes and uploading them to a remote or local file server. Because duplicity uses librsync, the incremental archives are space efficient and only record the parts of files that have changed since the last backup. Because duplicity uses GnuPG to encrypt and/or sign these archives, they will be safe from spying and/or modification by the server."
(from the Debian package description)
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I'm a big fan of using rsnapshot since it uses rsync to create diffs it means that the backups are very space-efficient.
Although on the downside there is no explicit encryption at least the files are transferred via openssh.
I just export all databases prior to backing up to get them via the same process.
(For reference we've covered using duplicity in the past.)
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Description: encrypted bandwidth-efficient backup
Duplicity backs directories by producing encrypted tar-format volumes
and uploading them to a remote or local file server. Because duplicity
uses librsync, the incremental archives are space efficient and only
record the parts of files that have changed since the last backup.
Because duplicity uses GnuPG to encrypt and/or sign these archives, they
will be safe from spying and/or modification by the server.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
find /var/www/ -name "*.html" -print >> /tmp/$datumbe
find /var/www/ -name "*.html" -print >> /tmp/$datetime?
You might want to make sure that you don't open yourself to symlink attacks from predictable filenames, too. For example, another user on your source host might be malicious. That malicious user might write a script to watch the contents of /tmp and trigger an event as soon as something that looks like /tmp/$datetime. If it catches it before your find invocation is complete, the malicious script could create a dangerous symlink like this:
ln -s /home/youruser/yourimportantfile /tmp/backup_sql_$datetime.sqlThen the mysqldump process could actually overwrite the contents of /home/youruser/yourimportantfile on your behalf (hey, you wanted to redirect output to this symlink, right?), clobbering your important data.
Even more devious attacks can be crafted which exploit predictably-named files in world-writable directories like /tmp, potentially even forcing arbitrary users to execute arbitrary code.
A good way to avoid this sort of thing, when you need to work with temporary files is to use something standard like mktemp. here's a typical invocation:
## make a working directory, readable/writable only by me: WD=$(mktemp -d) ## stuff some data into a file in that working directory: find /var/www/ -name "*.html" -print >> "$WD/find.out"Hope this is helpful!
[ Parent | Reply to this comment ]
http://www.backup-manager.org/
"Backup Manager is a command line backup tool for GNU/Linux, designed to help you make daily archives of your file system.
Written in bash and perl, it can make tar, tar.gz, tar.bz2, and zip archives and can be run in a parallel mode with different configuration files.
Archives are kept for a given number of days and the upload system can use ftp or scp to transfer the generated archives to a list of remote hosts. The configuration file is very simple and basic and gettext is used for internationalization."
It uses gnupg for encryption.
[ Parent | Reply to this comment ]
I think the $datum is a typo...
Cheers,
Neil Greenwood.
[ Parent | Reply to this comment ]
This week both my laptop and my internal server died and I decided to do everything from scratch including xen and stuff.
This also made me rethink about my backup setup and I decided to go with boxbackup.
It's working great now and I'm also creating documentation (in case I die or something)
I'll post my way of setting stuff up soon too.
boxbackup makes backups of my stuff automagically without the need for cronjobs or manual actions.
It stores the backups encrypted and the backup connection is encrypted as well.
The system is developed at OpenBSD and runs on *nix and windows.
All that makes it the perfect backup tool for the job.
Stay tuned for my article about this....
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]