Hack 38 Secure Backups Over a Network

When it comes to backups, Unix systems are extremely flexible. For starters, they come with built-in utilities that are just waiting for an administrator's imagination to combine their talents into a customized backup solution. Add that to one of Unix's greatest strengths: its ability to see everything as a file. This means you don't even need backup hardware. You have the ability to send your backup to a file, to a media, to another server, or to whatever is available.

As with any customized solution, your success depends upon a little forethought. In this scenario, I don't have any backup hardware, but I do have a network with a 100 Mbps switch and a system with a large hard drive capable of holding backups.

4.5.1 Initial Preparation

On the system with that large hard drive, I have sshd running. (An alternative to consider is the scponly shell; see [Hack #63] ). I've also created a user and a group called rembackup:

# pw groupadd rembackup

# pw useradd rembackup -g rembackup -m -s /bin/csh

# passwd rembackup

Changing local password for rembackup

New Password:

Retype New Password:

#

If you're new to the pw command, the -g switch puts the user in the specified group (which must already exist), the -m switch creates the user's home directory, and the -s switch sets the default shell. (There's really no good mnemonic; perhaps no one remembers what, if anything, pw stands for.)

Next, from the system I plan on backing up, I'll ensure that I can ssh in as the user rembackup. In this scenario, the system with the large hard drive has an IP address of 10.0.0.1:

% sshd -l rembackup 10.0.0.1

The authenticity of host '10.0.0.1 (10.0.0.1)' can't be established.

DSA key fingerprint is e2:75:a7:85:46:04:71:51:db:a8:9e:83:b1:5c:7a:2c.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '192.168.2.93' (DSA) to the list of known hosts. 

Password:

%

% exit

logout

Connection to 10.0.0.1 closed.

Excellent. Since I can log in as rembackup, it looks like both systems are ready for a test backup.

4.5.2 The Backup

I'll start by testing my command at a command line. Once I'm happy with the results, I'll create a backup script to automate the process.

# tar czvf - /usr/home | ssh rembackup@10.0.0.1 "cat > genisis_usr_home.tgz" 

usr/home/

usr/home/dru/

usr/home/dru/.cshrc

usr/home/dru/mail/

usr/home/mail/sent-mail

Password:

This tar command creates (c) a compressed (z) backup to a file (f) while showing the results verbosely (v). The minus character (-) represents the specified file, which in this case is stdout. This allows me to pipe stdout to the ssh command. I've provided /usr/home, which contains all of my users' home directories, as the hierarchy to back up.

The results of that backup are then piped (|) to ssh, which will send that output (via cat) to a compressed file called genisis_usr_home.tgz in the rembackup user's home directory. Since that directory holds the backups for my network, I chose a filename that indicates the name of the host, genisis, and the contents of the backup itself.

4.5.2.1 Automating the backup

Now that I can securely back up my users' home directories, I can create a script. It can start out as simple as this:

# more /root/bin/backup

#!/bin/sh

# script to backup /usr/home to backup server

tar czvf - /usr/home | ssh rembackup@10.0.0.1 "cat > genisis_usr_home.tgz"

However, whenever I run that script, I'll overwrite the previous backup. If that's not my intention, I can include the date as part of the backup name:

tar czvf - /usr/home | ssh rembackup@10.0.0.1 "cat > \

    genisis_usr_home.`date +%d.%m.%y`.tgz"

Notice I inserted the date command into the filename using backticks. Now the backup file will include the day, month, and year separated by dots, resulting in a filename like genisis_usr_home.21.12.03.tgz.

Once you're happy with your results, your script is an excellent candidate for a cron job.

4.5.3 See Also

• man tar

• man ssh

• man pw