This adapted from an essay I wrote for an English class assignment on "process analysis:"
The intended audience would be more towards university students with shell accounts and limited resources than Unix sysadmins.
...There are many complicated methods of backing up important system data on Unix systems, and entire software applications have been written to handle this task. What I will show you is the simple and secure way a regular, non-privileged user can accomplish this task with the standard utilities available, and only a moderate amount of technical knowledge.
First, you must have shell accounts on two servers. The Unix shell is the command environment. Most universities provide students with shell access to one or more servers.
...You need to have a remote place to store your backed up data in the case of a system failure on the server you are working on.
...It is important that you establish a secure mode of transfer between the two servers. Older protocols, such as Telnet and File Transfer Protocol, transmit data in clear-text (unencrypted) format. An attacker can intercept and reassemble these packets to steal your information. To facilitate the secure transfer of data, the Secure Shell protocol, known as SSH, was developed. Normally to establish an SSH connection to a server, you must enter your username and password, but since you want this process to be automated, and you do not want your password sitting around in a text file, you must use shared key authentication. This will enable you to establish a secure, encrypted tunnel for your data to traverse from server to server.
The following steps will allow you to enable shared key authentication between two servers:
1. Enter the following command at the prompt ($):
ssh-keygen -t rsa
2. The following dialog will ensue:
Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/.ssh/identity /home/user/.ssh/identity already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/identity. Your public key has been saved in /home/user/.ssh/identity.pub. The key fingerprint is: d0:43:31:b9:6d:6c:0f:b2:25:73:d4:58:2c:e3:8f:d0 user@local
3. Copy the public key over to the remote server:
user@local$ scp /home/user/.ssh/iddentity.pub user@remote:local.ssh user@remote's password: identity.pub 0% 0 0.0KB/s --:-- ETA^Midentity.pub 100% 233 0.2KB/s 00:00
4. SSH to the remote server and add the key to the list of authorized keys.
user@local$ ssh user@remote
"user@remote's password"
user@remote$ cat local.ssh >> .ssh/authorized_keys
user@remote$ exit
logout
Connection to remote closed
5. Verify that the account can now log in without a password.
user@local$ ssh user@remote (notice that no password is required this time) user@remote$ exit
logout Connection to remote closed
(Note: having recently set this up on an HP-UX system, the process for adding the generating and adding the keys to the keychain is a bit different. The above method worked on FreeBSD, Linux and MacOSX at the time I originally did the essay.)
Next, you need to decide what data you want to save, and make the backup file. Space may be limited, so it is critical that you weigh the importance of your data. Financial records, business correspondence and academic work are prime candidates for archival. Once you have chosen your data you can use Unix’s native backup utility, tar, to backup your data. The syntax for this is:
$ tar –cf file.tar directoryA/ directoryB/ somefiles.
This will create a single file that when extracted will exactly duplicate the existing directory structure. After this data is backed up, move this data over to the remote server for storage:
$ scp file.tar user@remoteserver:file.tar
Now that you have completed your first backup, and verified that everything has gone according to plan, you are ready for the final step, automation. The first step in automation is the authoring of a shell script. Though it sounds intimidating, a shell script is merely a text file that contains a list of commands to be executed in chronological order. As you can imagine, the script you will be writing will contain the three commands previously discussed. It will also contain an additional line at the beginning that must read “#/bin/sh”. This tells your system that this file is a shell script. You can use any text editor to write the script. After you save your file, make it executable and unreadable to anyone else on the system:
$ chmod 700 script.sh
Here is a sample backup script:
#bin/sh
tar -cf /backup/stuff.tar /home/user/stuffiwanttosave #creates the backup
scp /backup/stuff.tar user@remote:stuff.tar - transfers the backup to the remote server
rm /backup/stuff.tar – deletes the backup file
exit
Next, use the crontab utility to schedule your back up. You can invoke the crontab editor by typing:
$ crontab –e.
This will open a vi session to edit the config file, $man vi to see more details on using vi. Crontab entries are formatted:
* * * * * command to be executed
Minutes, Hours, Day of month, Month of the year, Day of the week(0-6)
To schedule your backup for 1:55 AM every Sunday, your entry would read:
55 1 * * 0 /home/user/script.sh
This will automate the process of your backups so that you can set it and forget it.
IFOSSLR – First Issue
7 months ago