Typically you will be backing up files and databases, these are some useful little shell scripts that I can never remember off the top of my head.
Requirements
- Command line access to your hosting, and the ability to login as root.
- You have some separate backup space mounted at
/mnt/backup/
- You are using MySQL for the database (although I assume most have a similar command to ‘hotcopy’).
Backup databases
I have a file which includes several database backups like this WordPress example:
# Backup wordpress rm -R /mnt/backups/wordpress/*; mysqlhotcopy -u root --password=RootsPassWord wordpress /mnt/backups/wordpress/; tar -cf /mnt/backups/wordpress/wordpress.tar /mnt/backups/wordpress/*; rm /mnt/backups/wordpress/wordpress/wp*; rmdir /mnt/backups/wordpress/wordpress/; gzip /mnt/backups/wordpress/wordpress.tar;
This script:
- Removes the previous copy.
- Uses MySQL hotcopy to dump the database to files.
- Copies the files into a tar ball.
- Removes the files.
- Removes the directory.
- zips the tar file.
MySQL dump is another method, there’s a useful article on backing up with mysqldump.
Backup files
Rsync is a great utility, and after the first time it will only send across updates. At the end of the backup file I have this to backup the web site files:
rsync -av --exclude="cache" /home/username/www/* /mnt/backups/username/www/
The -a
is for the ‘archive’ mode, and tries to maintain all the structures & permissions etc. The -v
is for verbose, and you can remove this when you know it’s working ok.
The exclude line there means I don’t backup the cached copies of pages from wordpress or other items, which would quickly become a massive amout of files.
Automating the backups
You don’t want to have to remember to backup, and Debian provides some easy ways of regularly running scripts. I’ve tried adding things to my ‘crontab’, but it didn’t seem to work. I’ve found it best to just add things manually to the main crontab file.
As root, open the crontab file (/etc/crontab
), and add the data here:
# m h dom mon dow user command 10 3 * * 0 root /path/to/YourBackupScript
That wil run at 3:10am each sunday, as root. Check your logs to see when things are quiet.
Restoring you data
Most backup pages I’ve come across don’t actually tell you how to restore your data! Trying not to fall into that trap, if everything goes pear-shaped and you have to restore something the process is simply to copy the file across, or for a database:
- Login as root.
- Find the current copy of the database, often in
/var/lib/mysql/DatabaseName
. - Stop MySQL (
/etc/init.d/mysql stop
). - Move the previous files (I would put them in my home directory for now).
- Copy the backed up files into that directory. Go into that directory.
- Correct the ownership:
chown mysql.mysql *
- Correct the permissions:
chmod 660 *
- Restart MySQL:
/etc/init.d/mysql start
Wraping up
That is the basic building blocks of a back-up plan, if you’ve any questions, comments or improvements feel free to leave a comment below and I’ll update the page. For more advanced usage, there are some good ideas & scripts on the Bytemark forum.
Hi.
I could not find a date on this page, so I really don’t know if it’s still up to date/relevant.
However, I’d like to point out an important security issue: Giving passwords on the command line as in
is almost certainly a bad idea. For two reasons:
If the process does not overwite its command line arguments immediately, they can be observed in the table of running processes (using the ps command or the /proc file system). If it does, the argument may still be visible in the timespan between process invocation and argument deletion. Furthermore altering ones command line arguments is a dirty hack.
The password is stored in plain text in your shell history. I.e., you have to take care abut (who has access to) this file even more, than about the system password file which stores only encrypted passwords. Also think about backing up your $HOME.
And I miss a preview button for the comment
In my case I’m the only user with access to the system, however, it’s a good point.
What is the alternative?
I don’t know the ‘mysqlhotcopy’ tool. It should prompt for the pwd itself if not given on the command line. It’s a serious bug if it does not! Note, that any user (unless restricted to incredible lengths) can see the process table. So you really have to be the only one logged in.
To avoid the line popping up in your history, using bash, you may set the environment variable $HISTIGNORE to ‘ *:&’, and add a space before ‘mysqlhotcopy’. This setting of $HISTIGNORE does not add lines with leading space to the history. Maybe you can tweak $HISTIGNORE into never memorise lines that start with ‘mysqlhotcopy’, read bash(1).
In fact I just stubled over this page by accident and was attracted by the word Debian. I don’t use any DB software, but that’s another story…
Good tip on the shell variable. Looking into it, perhaps storing the password in an option file is the way to go.