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 email@example.com "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.
22.214.171.124 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 firstname.lastname@example.org "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 email@example.com "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