In this month’s Script Teez, I’ll look at a script that performs a backup to a remote system across the Internet. The script uses rsync and ssh to create an encrypted data tunnel so no one can sniff out your important stuff.
If you’re an IT professional who relies on the power and flexibility of Linux, I’ll present a Linux shell script each month that is sure to meet your demanding needs.
First, you’ll need to have these programs installed in order for the script to work:
- the expect language
On the remote site, ssh and rsync will need to be installed as well. Once you’ve installed all of these programs and provided for any other dependencies, we can easily perform this backup. Here’s the script you’ll need to write:
spawn /usr/bin/rsync /etc -ar —delete —copy-unsafe-links -l -t -e ssh email@example.com:./
expect "password: "
Line by line
As you can see, this is a very simple script. It takes advantage of expect, a language that provides interaction with your environment, similar to a PPP dial-in script. Let's walk through the script so you fully understand how it works.
The first line simply tells the shell to use /usr/bin/expect to run the script. The second line tells expect to turn off logging. This is handy if you’re running the script in a cron job and don't want to receive e-mail containing the connection information.
The third line tells expect to spawn the rsync program. This allows expect to have some control over the program so you can interact with it. The command-line options basically tell rsync to back up the /etc directory tree and attempt to keep user/group/file permissions intact. This line also tells rsync to delete any files on the remote site that are no longer on the local site, and to copy symlinks. In addition, this line tells rsync to use ssh to connect so that all of your transmitted data is encrypted. Finally, you’re telling rsync to log in as username user at the remote site remote.site.com. The final ./ tells rsync to copy the files to the user's home directory.
The fourth line tells expect to wait for the passwordprompt that ssh gives. You’re using expect to run this backup because there is no way to give ssh a password on the command line. It will accept passwords only at the password prompt.
The fifth line tells expect to send the password secret once the password prompt has been detected. You need to terminate what expect sends by using \n to simulate pressing the [Enter] key.
The sixth line turns logging back on so that the output of rsync can be recorded in the e-mail cron sends you.
Finally, the seventh line tells expect to turn on user interaction. Because rsync doesn't prompt for anything after it begins, this is a good way to release the backup from the control of expect.
The only problem with this script, of course, is the fact that the password for the user at the remote site is stored in the script. For this reason, I recommend storing the script in the /root directory with file permissions of 700. Instead of making a symlink to the file for cron, write a cron entry to call the script in that location. This provides you with as much security as you can have with such an operation. The script should also be run as root so that you can back up your /home directories as well. A user will never be able to back up another user's directories because of a lack of permissions.
And that's it! Enjoy!
Vincent Danen, a native Canadian in Edmonton, Alberta, has been computing since the age of 10, and he’s been using Linux for nearly two years. Prior to that, he used OS/2 exclusively for approximately four years. Vincent is a firm believer in the philosophy behind the Linux "revolution,” and he attempts to contribute to the Linux cause in as many ways as possible—from his FreezerBurn Web site to building and submitting custom RPMs for the Linux Mandrake project. Vincent also has obtained his Linux Administrator certification from Brainbench . He hopes to tackle the RHCE once it can be taken in Canada.The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.