最近，常听到有朋友提到工作中遇到的问题，就是在备份服务器数据的时候很烦，公司的事情多且杂，而他作为服务器管理员对数据的日常备份又是分内的工作。另外，他又处于热恋阶段，因此每每因为工作而无法与恋人小聚成了他的“肉中刺”，“眼中钉”。为此，他很纠结。呵呵,于是我们在小聚的时候简单的聊了聊备份的思路，以及如何实现远程无人值守备份（自动周期备份）
思路如下：
1.备份不能放在本地（local）本地如果存储的话，一旦出现硬件损坏的话，恢复起来会很耗时间和精力，有时候还会丢失数据，风险太大。因此需要异地备份。
2. 备份数据的时候，对于备份策略要好好的把握，一份糟糕的备份策略有可能会增加SA的工作量，甚至有可能增加企业的TCO（总体拥有成本）原因很简单，因为硬件投入需要银子。
3. 远程也可以实现手动备份数据，但是发现这样做不仅费时费力且不及时，还会出现重复性劳动。因此要避免重复劳动就不能手动备份。要自动化。
从这三个角度出发，我们简单聊了聊制定这个计划的方法,最好的方法就是通过脚本实现服务器之间远程自动无人值守地进行互备。
首先要解决远程登录交互的问题： 不管使用putty还是secureCRT或者别的什么软件通过SSH协议远程登录,都需要输入用户的密码做验证,凡是验证的机制几乎都是交互式的,就是你得做人交互,因此,首先要解决计算机登录时的验证交互,因此我们经过商量,决定利用主机指纹验证,交互的状态就省略了,安全性还可以提升一些.(至少减少了担心骇客监听窃取验证信息的风险)。
实现方法我利用了两台RHEL5的虚拟机来实现，拓扑环境如下：
- 备份服务器架构
那么第一件事情就是让两台主机互相能够无密码交互地访问对方的资源。
ssh-keygen
因此，在/root/.ssh/id_rsa （私钥）和/root/id_rsa.pub （公钥），在生成的过程中提示密码的输入请留空，直接回车就好，然后把HOST-A主机的公钥拷贝到HOST-B机器上去。 切记是将其中的公钥复制到HOST-B主机，而不是私钥哦，私钥是自己保留着的。这点决定实验的成败。呵呵
利用下面的操作来实现：
scp的远程拷贝
我是将生成的公钥拷贝到192.168.10.20这台HOST-B主机的/ 目录下，拷贝成功后，登录到HOST-B主机去处理刚拷贝过去的公钥文件id_rsa.pub。
在HOST-B主机上，执行如下操作：
1. 首先也通过ssh-keygen生成密钥对儿，然后再将刚才从HOST-A机器拷贝过来的那个公钥文件导入一个叫authorized_keys的文件中，并赋权为400 ，一定是400哦，如果你赋权为777 那你登录的时候还是要验证交互的。呵呵
生成authorized_keys
然后就是权限设置了:
赋权并且验证
做完这些后，记得将HOST-A的公钥删除，这样可以保证安全性。可别留下隐患哦。
shell> rm -rf /id_rsa.pub # 这个不截图了，贴图贴的很费劲。呵呵
这里做完就可以到HOST-A机器上测试一下，从HOST-A远程通过SSH登录HOST-B主机是否不要密码了？
ssh远程登录测试
创建备份目录和备份脚本
备份脚本
记得赋予执行权限。利用chmod +x /var/final-back/autobackup.sh ，并且在HOST-B这台主机的/目录下创建一个目录/HOSTA-BACK 来做为HOST-A主机远程数据备份的目标地址。
crond 我定义的是每天凌晨四点整执行本地备份脚本。不是异地哦。异地备份还有一步操作。在脚本里面加入如下内容：scp /var/final-back/*.tar.gz root@192.168.10.20:/HOSTA-BACK/ # 这里的ip是对方主机的IP对方主机也添加这么一条：scp /var/final-back/*.tar.gz root@192.168.10.10:/HOSTB-BACK/ 这样，就可以形成互相备份的状态了，最后备份成功后机器上出现如图所示的备份文件。backup数据
好了，到此，我们的远程无人值守的配置已经完成了。我的朋友他再也不用担心因为需要去备份数据而无法安心陪伴女友了，整个社会和谐了。。。呵呵
