Save time and effort-automatic backup on Linux

Article Title: Saving time and effort-automatic backup on Linux. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
The loss of important data may cause fatal damage. Despite this, countless professionals ignored the backup of their data. Although the causes may vary, the most common explanation is that routine backup is cumbersome. Because the machine is good at completing common and repetitive tasks, the automated backup process is the key to reducing the boring nature of the work and the inherent procrastination.
　　
If you use Linux, you can use extremely powerful tools to create custom backup solutions. The solution in this article allows you to use open source code tools attached to almost every Linux release version to perform simple to more advanced and secure network backup.
　　
　　 Simple Backup
This document describes the procedure in one step. it is very intuitive as long as you follow the basic steps.
　　
Before studying more advanced distributed backup solutions, let's first look at a simple and powerful archiving mechanism. Let's analyze a convenient script named arc, which allows us to create a backup snapshot at the Linux shell prompt.
　　
Listing 1. arc shell script
　　
#! /Bin/sh
Tar czvf $1. $ (date + % Y % m % d %-H % M % S). tgz $1
Exit $?
　　
The arc script receives a separate file or directory name as a parameter, creates a compressed archive file, and embeds the current date into the name of the generated archive file. For example, if you have a directory named beoserver, you can call the arc script to pass the beoserver directory name to it to create a compressed archive file, such as beoserver.20040321-014844.tgz
　　
The date command is used to embed a date and timestamp to help you organize archive files. The date format is year, month, day, hour, minute, and second-although the second domain is used in excess. View the data Command Manual (man date) to learn about other options. In addition, in listing 1, we passed the-v (verbose) option to tar. This enables tar to display the files it is archiving. If you prefer silent backup, delete this-v option.
　　
Listing 2. archiving the beoserver Directory
　　
$ Ls
Arc beoserver
$./Arc beoserver
Beoserver/
Beoserver/bookl. dat
Beoserver/beoserver_ AB _off
Beoserver/beoserver_ AB _on
$ Ls
Arc beoserver beoserver.20040321-014844.tgz
　　
　　 Advanced Backup
This simple backup is practical; however, it still contains a manual backup process. We recommend that you back up data to multiple media sets and back up data to different geographic locations. The central idea is to avoid relying on any independent storage media or independent location.
　　
In the next example, we will address this challenge. we will analyze a hypothetical distributed network shown in 1, which shows the system management of two remote servers and one offline storage server.
　　
　　 Figure 1. Distributed Network
　　
Backup files on servers #1 and #2 will be securely transmitted to the offline storage server, and the entire distributed backup process will be conducted on a regular basis without manual interference. We will use a set of standard tools (part of the Open Secure shell tool kit (OpenSSH), as well as the tape archiver (tar) and cron task scheduling services. All our plans are to use cron for scheduling, use shell and tar applications to complete the backup process, and use OpenSSH Secure shell (ssh) encrypted remote access, authentication, and secure shell copy (scp) to automatically complete file transmission. To obtain additional information, check the manual of each tool.
　　
Use a public/private key for secure remote access
In the context of digital security, a key refers to a piece of data that is used to encrypt or decrypt other data fragments. The public key/private key mode is interesting because only the corresponding private key can be used to decrypt data encrypted with the public key. You can freely publish a public key so that others can encrypt the messages sent to you. One of the reasons that the public/private key mode completely changes digital security is that the sender and receiver do not have to share a common password. Among other contributions, public/private key encryption is possible through e-commerce and other secure transmission. In this article, we will create and use the public key and private key to create a very secure distributed backup solution.
　　
Each machine in the backup process must run the OpenSSH Secure shell Service (sshd), and port 22 can be accessed through any internal firewall. If you access a remote server, you may be using a secure shell.
　　
Our goal is to securely access the machine without providing a password. Some people think that the simplest way is to set password-free access: do not do this. This is not safe. The method we will use in this article may take about one hour, building a system that is as convenient as using a "password-free" account-is generally considered safe.
　　
First, make sure that OpenSSH has been installed. then, check the version number. At the end of this article, the latest OpenSSH release was February 24, 2004, which was released in 3.8. You should consider using a newer and stable release version. at least the version used should be newer than version 2.x. Visit the OpenSSH Security web page to obtain details about the defects of a specific old version (see the link in references later in this article ). So far, OpenSSH is very stable, and it has proved that there are no many defects reported by other SSH tools.
　　
At the shell prompt, enter ssh and give an important V option to check the version number:
　　
$ Ssh-V
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
　　
If the version number returned by ssh is greater than 2.x, the machine is in a relatively good state. In any case, we recommend that you use the latest stable version for all your software, which is especially important for security-related software.
　　
The first step is to log on to the offline storage server using an account that has the privilege to access server 1 and server 2 (see figure 1 ).
　　
$ Ssh accountname@somedomain.com.
　　
After logging on to the offline storage server, use the ssh-keygen program and provide the-t dsa option to create a public key/key pair. The-t option is required to specify the key type to be generated. We will use the Digital Signature Algorithm (DSA) Algorithm, which allows us to use the updated SSH2 protocol. Refer to the ssh-keygen manual for more details.
　　
During ssh-keygen execution, you are prompted to enter the location of the ssh key storage before asking for your password (passphrase. When querying where to store the key, you only need to press the Enter key, and then the ssh-keygen program will create a file named. ssh hidden directory (if it does not exist), and two files, one public key file and one private key file.
　　
An interesting feature of ssh-keygen is that when prompted to enter a password, it allows you to simply press the Enter key. If you do not provide a password, ssh-keygen will generate an unencrypted key! As you think, this is not a good idea. When a password is required, make sure that a long enough character message is entered. it is best to include a mix of characters, not just a simple password string.
　　
Listing 3. always select a password
　　
[Offsite]: $ ssh-keygen-t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/accountname/. ssh/id_dsa ):
Enter passphrase (empty for no passphrase): (enter passphrase)
Enter same passphrase again: (enter passphrase)
Your identification has been saved in/home/accountname/. ssh/id_dsa.
Your public key has been saved in/home/accountname/. ssh/id_dsa.pub.
The key fingerprint is:
7e: 5e: b2: f2: d4: 54: 58: 6a: fa: 6b: 52: 9c: da: a8: 53: 1b accountname @ offsite
　　
　　
　　
Because the. ssh directory generated by ssh-keygen is a hidden "dot" directory, you need to input the-a option to the ls command to view the newly created directory:
　　
[Offsite] $ ls-
... Bash_logout. bash_profile. bashrc. emacs. gtkrc. ssh
　　
Go to the hidden. ssh directory and list its content:
　　
[Offsite] $ cd. ssh
[Offsite] $ ls-lrt
Id_dsa id_dsa.pub
　　
Now, in the hidden. ssh Directory, we already have a private key (id_dsa) and a public key (id_dsa.pub ). You can use text editing tools such as vi or emacs or simply use the less or cat command to analyze the content of each key file. You will see that the contents composed of mixed characters are base64-encoded.
　　
Then, we need to copy and install the public key on server 1 and server 2. Do not use ftp. It is more reasonable to use a secure copy program to transmit the public key to each remote machine.
　　
Listing 4. installing the public key on a remote server
　　
[Offsite] $ scp. ssh/id_dsa.pub accountname@server1.com: offsite. pub
Accountname@server1.com's password: (enter password, not new
Passphrase !)
Id_dsa.pub 100% | ***************************** | 614
　　
[Offsite] $ scp. ssh/id_dsa.pub accountname@server2.com: offsite. pub
Accountname@server2.com's password: (enter password, not new
Passphrase !)
Id_dsa.pub 100% | ***************************** | 614
　　
After installing the new public key, we can use the password specified when creating the private key and public key to log on to each machine. Now, log on to each machine and append the offsite. pub file to a file named authorized_keys, which is stored in the. ssh directory of each remote machine. We can use a text editor or simply use the cat command to append the content of the offsite. pub file to the authorized_keys file:
　　
Listing 5. add offsite. pub to the authorized key list
　　
[Offsite] $ ssh accountname@server1.com
Accountname@server1.com's password: (enter password, not new
Passphrase !)
[Server1] $ cat offs