Sure, you could use cPanel’s built in backup function to create nice, tidy backups of each user’s account every day – you can even have it FTP those backups to another server of your choice for safe keeping.
That’s not good enough for you, though. No, you, you live for danger and know that danger can appear around any corner, ready and willing to wipe out things you never thought needed to be backed up, or change too often for a daily backup to suffice. You need a beefier backup. You need rsync.
Rsync is a powerful linux tool that basically keeps files and directories insync between two servers. This is different from a straight backup, as straight backup does not have any comparison functions that are at the core of what gives rsync its power.
I’m going to show you how to setup a second server today as a backup server which will produce a single set of synced files every day to a directory of your choice of the files on your main (Master) server. This method is ONLY ONE WAY of doing this. There are many options and features available in rsync which you can tweak to bring the full power of rsync into your machine and have it performing to your exact needs.
REQUIRES: One fully operating cPanel server to act as the Master (the data you want backed up) and One server with a clean CentOS install and lots of free disk space (no servers installed – no Apache, no mail, etc.) to act as the Slave (Backup server). You can also use a cPanel DNSOnly server as the backup if you want to save resources and you have sufficient disk space – I’ve done this on one server and it works beautifully.
TIME REQUIRED: 30-45 Minutes
DANGER LEVEL: Medium-Low
1. LOG IN to WHM as ROOT on your BACKUP (Slave) machine.
2. The first thing we’re going to do is add a user to the system that is allowed to perform the rsync backups. You don’t want to perform your backups as root and you should choose a username that is difficult to guess. Don’t use “backup” or “rsync” or “bkup” or anything that might give a potential hacker a toehold on the way in to your system. Now, type this line, substituting your new backup username as indicated:
3. Just in case anything goes wrong here before we set a password, let’s go ahead and expire the current password on your new user so that a password change will be forced on first login. Enter this:
/usr/bin/chage -d 0 newusername
4. Now, let’s go ahead and set a password for our new user. MAKE IT DIFFICULT. This user will have direct access to copies of files that exist on your main server, so no matter how secure your master machine is, if your backup machine is easily accessible, you’re screwed. I would suggest a minimum of 12 characters including special characters, uppercase, lowercase, and numbers and not using any human-recognizable words. Type this and follow the prompt to set your new password:
5. Next, we need to decide where we’re going to store the backups on the Backup Server’s disk. NEVER, EVER put the backups in any place where Apache or ANY OTHER public-facing service has access to. This is a sure recipe for disaster. For this example, I’m going to place the files in a new folder inside of our new user’s home directory. This will make the files inaccessible to anyone except ROOT and our new user. You can put this folder anywhere you like, though. If you decide to use a location OTHER than the user’s home directory, just change the tilde ‘~’ in the examples below to the root location where your backup folder will be located (e.g., ‘/’ or ‘/backups’) Let’s first change into our new user for this part. Type:
6. Tadah! You are now your new user. Let’s change to his home directory just to be sure we’re in the right place:
7. Now, let’s create the directory to hold our backups. You can name the directory whatever you want (be sure to include the tilde ‘~’):
8. We will need to create some keys to be used with SSH when our Master server connects to the backup server. When rsync tries to connect from Master to Backup, we don’t want it sending a plain text password over the internet where anyone could intercept it. Instead, we’re going to use an SSH key which is infinitely more secure. So the first step here is to make a place to put our key information. Go ahead and enter:
9. And then let’s create an empty file to hold the keys that will be authorized to access our server:
10. THIS STEP IS OPTIONAL BUT HIGHLY RECOMMENDED. Let’s go ahead and close off SSH to ALL users except your new user. Once you’ve done this no one but newusername will be able to access your server via SSH at all. (If you want to access the server as root from then on, you’ll need to first log in as newusername and then ‘su’ to change yourself into root):
AND THEN FIND THE LINE THAT STATES: PermitRootLogin yes AND CHANGE IT TO:
FINALLY, ADD THIS LINE TO THE VERY END OF THE FILE:
NOW, SAVE AND EXIT THE FILE AND RUN THIS COMMAND TO RELOAD SSH:
service sshd restart
FINALLY, YOUR NEW ACCOUNT NEEDS TO BE IN THE WHEEL GROUP TO SU TO ROOT LATER:
gpasswd -a newusername wheel
11. Go ahead and log out of SSH on your backup server. NOW, it’s time to concentrate on our Master server (the cPanel server you want to perform the rsync backup FROM). Log in to your Master server through SSH as ROOT. (Note: if you were substituting a different directory for the tildes ‘~’ above, you can stop now – the tildes below MUST be used as we are on a different machine now)
12. Let’s change into your key directory (if it doesn’t exist, create it by typing mkdir ~/.ssh):
13. Let’s check to see if a key already exists. If you see any printout (it will look like a bunch of nonsense) from this next command, skip to step 15. If you get a “no such file or directory” message, continue to step 14.
14. Let’s go ahead and create our key. Type EACH one of these commands on a SEPARATE line and run them ONE AT A TIME (IF YOU ARE ASKED ANY QUESTIONS, AND THERE MAY BE SEVERAL, JUST HIT ENTER – DO NOT ANSWER THE QUESTIONS!!):
ssh-keygen -t rsa
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
15. Now, we need to copy our key to the backup server so it will know to let us in when it is time to do our backups. We’ll use secure copy for this. You will need the IP ADDRESS of the BACKUP machine and the newusername password for the BACKUP machine (substitute where indicated) – you may also be asked if you want to continue connecting, just type ‘yes’ as indicated:
scp id_rsa.pub email@example.com:~/
16. Let’s log in remotely to our backup machine from this one to perform some commands (enter the newusername password when asked):
17. Okay, let’s put our keys and info where they go. Type EACH one of these commands on a SEPARATE line and run them ONE AT A TIME:
cat id_rsa.pub >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
18. Okay, that last command just ejected us back to our main cPanel server. Let’s try it! Enter this command. If you are NOT prompted to enter a password, your key setup worked:
19. If everything went ok, just go ahead and exit the new SSH session you created (if not, re-check every step above and make sure you followed the directions exactly as listed).
20. Now, let’s decide what we’re going to want backed up and when. Here are some examples to help you put together your rsync command string:
TO SYNC YOUR WHOLE DRIVE (starting at /), INCLUDING ADDITIONS AND DELETIONS (e.g., files added since last backup will be added, files deleted since last backup will be deleted) [command should be all one line - note that there are two dashes - - in front of the word 'delete']:
rsync -a –-delete -e ssh / firstname.lastname@example.org:~/backupdir > /dev/null 2>&1
TO SYNC ONLY YOUR USER’S FILES (starting at /home), INCLUDING ADDITIONS AND DELETIONS, this is the command you want [command should be all on one line - note that there are two dashes - - in front of the word 'delete']:
rsync -a –-delete -e ssh /home email@example.com:~/backupdir > /dev/null 2>&1
TO SYNC ONLY ADDITIONS (e.g., do NOT delete files that were deleted on the Master), simply remove the –delete switch from the above commands. Note that this will not affect changed files, they will still be changed on the backup and you may also find yourself quickly running out of disk space with this option as no files ever get deleted.
TO BACK UP INTO A SUBDIRECTORY (e.g., use a subdirectory of the main backup directory), simply add the subdirectory to /backupdir (e.g., /backupdir/seconddir).
21. Now that you’ve decided on the rsync command you’re going to use simply stick it into crontab to run as often as you desire. For example, to sync all files on the entire disk every morning at 2:00 a.m., just type crontab -e and enter this line at the end (note: the word ‘delete’ has two dashes in front of it ‘–’:
0 2 * * * rsync -a –delete -e ssh / firstname.lastname@example.org:~/backupdir > /dev/null 2>&1
22. That’s all there is to it! I would suggest running your first sync at a time when your servers will be really idle – the first one could be a whopper. After that, rsync will intelligently only copy those files that have changed or been added. Rsync has other options and can perform other functions as well. For even more information on rsync, see its man page.
Notice that you could add multiple crontab entries to create multiple daily backups into different directories, so you could create rolling backups if you wanted and more. Pretty much whatever sync or backup plan you had in mind, rsync will do it for you.
Let me know how you use rsync and if you have any tips, tricks, or tweaks in the way you use rsync by submitted a comment below!