CodeSpin

Automating Remote Backups With Linux

Automating Remote Backups With Linux

This brief article outlines the procedure for automating remote backups with Linux using SSH and rsync, including some basic security measures to consider when setting up a new server.  This is written for both the new admin and the seasoned professional whom may be rusty and needs a cheat sheet.  The article assumes you have a general level of understanding of the OS you are using and do not need to be told which text editor to use or how to execute basic actions, such as how to create a user.  Our example server is Debian Linux but the process has been used on other Linux variants, FreeBSD, OSX and others with no real changes in the process.  I refer to the new server that you want to backup as the “remote” server, and the server that will be performing the automated backup as the “local” server.

RULE #1

Rule #1 for all activity as an admin is to make a backup of the file you are about to edit.  Simply copy the file to another name.  I’m surprised how often admins still forget this.  Don’t put yourself in the situation of having to go find a backup or worse.  Save yourself the worry from any potential “OH NO!” moment and make a copy.

/etc/passwd 101

After you have completed a fresh install of any *NIX based OS, whether it be UNIX, Linux or BSD, the first thing you should do is lock down the default accounts.  What I mean by “lock down” is remove all the shells for the default users.  There is generally no need for default accounts to have a shell.  Of course, you will want to keep /bin/sh for root but otherwise, it is generally a good idea to make all your default users have a shell of /usr/local/sbin/nologin or /bin/false.  I use /bin/false in most cases.  This is a precautionary, “better safe than sorry” change.  There are plenty of admins that will say this is unnecessary because the accounts don’t have passwords assigned to them and thus no way for anyone to login as these default users.  However, my view on security is to assume the worst and take preventative measures in advance.

After you have edited and saved /etc/passwd, you can move on to the next step.

Adding The Backup User

For the purposes of this article, the first user I’m adding on this new system will be used by another system to automatically login and make nightly incremental backups.  These commands should be executed as root on the new “remote” server.

# adduser myuser /bin/bash
# mkdir /home/myuser/.ssh
# chmod 700 /home/myuser/.ssh
# touch /home/myuser/.ssh/authorized_keys
# chmod 600 /home/myuser/.ssh/authorized_keys

As you can see, the above commands do the following:

  • Create a user named “myuser” with a bash shell.
  • Create the new user’s .ssh directory and set permissions.
  • Create an authorized_keys file and set permissions.

Now add a public key to the authorized_keys file and verify that you can SSH into this new system from another machine. If you are unsure how to create a key-pair add the public key to authorized_keys, please consult the following page, courtesy of SourceForge:

Using SSH With Keys

Make sure you create a private/public  key-pair that does not have a password.  Once your public key is on the “remote” server, verify that you can SSH in as “myuser”.  On the “local” server, you will need to permanently add the private key to the SSH config using the command ssh-add.  This resolves the need for admin interaction so that you can automate logging in via a cronjob/shell script.

Securing SSHD On Remote Server

I highly recommend configuring your servers so that no one can directly SSH in as root.  This is a simple process; simply edit /etc/sshd_config and change the permitrootlogin from “yes” to “no”, ie. permitrootlogin = no.  Next, restart SSH and verify that you can no longer login to the “remote” server as root using a password.

# ps -ef | grep sshd
# kill -HUP {pid}

Configuring SUDO

The final step to configuring the “remote” server is to allow your new user “myuser” to use sudo and rsync without a password.  Edit /etc/sudoers and add the following line:

%myuser ALL = NOPASSWD: /usr/bin/rsync, /usr/bin/sudo

Testing RSYNC From “Local” Server

Verify that you can remotely backup a directory on the “remote” server by issuing the following command (as root) on your “local” host:

# /usr/bin/rsync -chavzP --delete-before --rsync-path="/usr/bin/sudo /usr/bin/rsync" myuser@192.168.1.100:/etc /usr/local/backup-100-1-168-192

You should now be able to examine the local directory /usr/local/backup-100-1-168-192/  and see a folder called etc, containing a copy of the “remote” server’s /etc directory.  You can add this and similar commands to cron, or to a script which cron executes.  Common folders to backup include /etc, /home, /usr/local/, and /root.  The list of directories which should be backed up depend on what the server does.  You are now on your way to automating remote backups.

Common Problems

The most common problems I’ve seen people have are at the final step.  If you simply cut and paste my rsync command to your box and execute it, it will likely fail.  When testing the rsync command for the first time, double-check the following:

  • Verify the “local” path to rsync.”
  • Verify the user you are executing rsync as has write permissions to the destination directory, /usr/local/backup, or wherever you want the backups to be saved.
  • Verify both servers have rsync installed.
  • Verify the “remote” path to sudo and rsync.
  • Verify the “user”@”server”:”path” is correct.
  • Make sure you use full paths in all cases to avoid cron jobs failing and any potential confusion.

About The Author

Among other things, Kris is an expert system administrator, having worked as both contractor and employee for a number of small and fortune 500 companies since 1994.  Kris has been using UNIX since the late eighties, a Linux user since the early nineties and has experience with practically every UNIX variant, including BSD and OSX.  Kris’ first home Linux box was an Amiga 500 running Apollo Linux 1.0, with a kernel compiled on an Atari 1040ST.