Remote automatic backup using Linux scripts

I have been busy recently, so I don't have time to write articles. it is because a server in our company is full of hard disks, which makes my work unavailable. I didn't find the reason at the beginning, and I didn't finish my work for a day, at last, I did not hesitate to work overtime to solve this problem. here I will give you some personal opinions .... Information & nbs

 

I have been busy recently, so I don't have time to write articles. it is because a server in our company is full of hard disks, which makes my work unavailable. I didn't find the reason at the beginning, and I didn't finish my work for a day, at last, I did not hesitate to work overtime to solve this problem. I will give you some personal opinions.

 

Considering that data is backed up on the local machine, once the machine's hard disk fails, the data cannot be taken out. Remote manual data backup is time-consuming and time-consuming. The best way is to use scripts to implement remote automatic mutual backup. However, a password is required for remote login through SSH or file copying through scp. To overcome this problem, you first need to implement SSH login without a password, so that you can use rsync, scp, rexec and other commands for remote backup. (Of course, the password is better for security purposes)

 

1. set ssh login without a password. the method is as follows:

Assume that the server A and server B needs to log on to server B with root instead of entering the password on server A. follow these steps:

1) generate A key pair on machine A and execute the following command:

Ssh-keygen-t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/root/. ssh/id_rsa):/root/. ssh/id_rsa

Enter passphrase (empty for no passphrase): Press Enter

Enter same passphrase again: Press Enter

Your identification has been saved in/root/. ssh/id_rsa.

Your public key has been saved in/root/. ssh/id_rsa.pub.

The key fingerprint is:

F6: 61: a8: 27: 35: cf: 4c: 6d: 13: 22: 70: cf: 4c: c8: a0: 23 root @ host1

 

In this way, id_rsa and id_rsa.pub are generated under the/root/. ssh/path, where id_rsa is the key and id_rsa.pub is the public key.

 

2) copy id_rsa.pub generated on machine A to Machine B. assume that it is copied to the temporary directory of Machine B, for example:

Scp/root/. ssh/id_rsa.pub root@218.242.214.20:/tmp

 

 

3) log on to Machine B with the root account, go to its home directory, create the authorized_keys file, and set the permissions.

Cd ~ /. Ssh

Cat/tmp/id_rsa.pub> authorized_keys

Chmod 400 authorized_keys

Rm-f/tmp/id_rsa.pub

 

4) test

Go to the root account on machine A and try to log on to Machine B. Check if the password is not required.

Note:

The authorized_keys file permission is very important. if it is set to 777, you still need to provide a password when logging on.

Remember to delete id_rsa.pub in the temporary directory to make it a good habit.

This method is successfully tested on Red Hat9.0.

 

 

2. edit the crontab file

Vi/etc/crontab

For example, set to execute the script in cron. daily at every day:

00 3 *** root run-parts/etc/cron. daily

 

3. edit the script in cron. daily.

Cd/etc/cron. daily/

Vi backupdb

 

Pg_dump-U postgres voipack>/voipack. SQL

Pg_dump-U postgres regserver>/regserver. SQL

Tar-cvjf/aavm.tgz.bz2/usr/local/aavm

Tar-cvjf/oracle.tgz.bz2/var/oracle

Scp/voipack. SQL root@218.242.214.20:/root/218.242.214.23 _ backup

Scp/regserver. SQL root@218.242.214.20:/root/218.242.214.23 _ backup

Scp/aavm.tgz.bz2 root@218.242.214.20:/root/218.242.214.23 _ backup

Scp/oracle.tgz.bz2 root@218.242.214.20:/root/218.242.214.23 _ backup

 

Copy the backup file generated on 23 to the path 218.242.214.20:/root/218.242.214.23 _ backup.

 

In the same way, data on server B can be backed up to server A to implement dual-host mutual backup.

 

I think it is better to do this. if the server encounters a hard drive failure, the consequences are unimaginable. if you are interested, try again.

 

This article is from the "network technology study room" blog