使用tar和rsync实现高可用性

我有运行Ubuntu的云服务器，我无法直接访问它，但使用ssh。我正在使用“ tar”克隆或具有此服务器的高可用性。我从[link text] [1]链接中学到了本教程。我尝试过安装相同版本的新服务器。当我提取目标（新）上的tar（tar -xvpzf〜/ clone.tgz -C /）时，最后以类似于以下内容的以下输出结束（不知道这是否是错误的）。

tar: var/run: time stamp 2010-11-09 17:09:11 is 7335.159880406 s in the future
tar: var/spool/postfix/usr/lib/zoneinfo: time stamp 2010-11-09 17:08:26 is 7290.159730037 s in the future
tar: var/lib: time stamp 2010-11-09 17:27:51 is 8455.159349527 s in the future
tar: usr/bin: time stamp 2010-11-09 17:28:02 is 8466.159254097 s in the future
tar: usr/share/sgml: time stamp 2010-11-09 17:27:47 is 8451.158909506 s in the future
tar: usr/share/man/man7: time stamp 2010-11-09 17:27:50 is 8454.158393583 s in the future
tar: usr/share/man/man1: time stamp 2010-11-09 17:28:02 is 8466.158166556 s in the future
tar: usr/share/man/man8: time stamp 2010-11-09 17:27:51 is 8455.158057701 s in the  future
tar: usr/share/omf/time-admin: time stamp 2010-11-09 17:27:52 is 8456.157830449 s in the future
---------------------------------------------
---------------------------------------------
---------------------------------------------

我正在使用以下命令在源系统上创建指定目录的tar文件。

tar -cvzf ~/clone.tgz --exclude ~/clone.tgz --exclude /etc/hosts --exclude /etc/hostname --exclude /etc/udev/ --exclude /etc/network/interfaces --exclude /etc/resolv.conf  /etc /home /opt /tmp /usr /var /mnt

• 使用焦油前有什么预防措施吗？（tar是从那时开始创建的，我将使用rsync）
• 我是否还应该包括bin或lib之类的目录？-建议我
• 我应该排除任何目录吗？就像我遇到了网络设备（eth0）问题（无法启动eth0）一样。因此，在上面的命令中，我排除了“ / etc / udev /”，此后，我感觉还不错。像这样，我需要从/ etc /或包含的任何目录中排除任何东西吗？-给我建议。
• 我如何安排带有ssh组合的rsync（增量bkp）以将目录（以tar指定）同步到远程位置（例如/ mnt / newdir），我可以将其压缩并在以后出现系统故障时将其解压缩。可以将Rsync安排为以root用户身份运行，但是ssh会提示输入密码。仅供参考，sudo被完全禁用，并且直接ssh登录到root也被禁用。

如果有任何更好的方法在不损害服务器的情况下实现这一目标，可以提出建议。

[1]：http：//ubuntuforums.org/showthread.php？t = 525660

我建议您改用rsync，它将允许您执行实时系统到系统的实时同步，而无需临时文件。当您需要更新克隆时，它还提供了进行增量更新的好处。

我只排除：/ proc / / sys / dev / tmp / mnt在克隆系统上，您需要确保/ etc / fstab和/boot/grub/grub.cfg已使用克隆系统分区的UUID更新。

如果您有像mysql这样的数据库，则在执行复制之前，需要格外小心并停止数据库。

首先，许多IaaS云提供商都提供了强大的快照功能，可以很轻松地解决此问题。

在EC2上，如果运行基于EBS的系统，则可以定期对其进行快照。如果源实例发生故障，则可以回滚到全新实例上的上一个快照。如果要存档快照，则可以引导附加了快照的另一个实例，并使用tar + s3之类的东西而不会对生产环境造成负面影响。

这种方法存在许多问题，这些问题目前可能尚不明显。

1. 您将自己锁定在一项技术中。如果您可以在Ubuntu 10.10上使用它，并且想转到11.04，则必须升级源系统，然后再次对其进行快照。同样，如果您使用EC2的EBS快照，那么如果要进入机架空间云，则需要一个新的解决方案。
2. 如果使用rsync，则没有更改历史记录。如果您在系统1上修改了某些内容，则某些内容将中断，并且在rsync时也可能会破坏备份系统。
3. Rsync可能会对您的生产系统产生极大的影响。

您真正想要的是配置管理系统和数据高可用性。

我建议您选择一个配置管理系统，例如puppet（主要是！），chef或cfengine。开始在配置管理系统中进行所有配置，然后可以引导通用系统，并将配置管理应用于该系统。添加“ etckeeper”，您就有历史了。

对于数据高可用性，rsync应该可以工作，并且更直接，因为您可以复制所需的数据。还有drbd具有相当于“网络RAID1”的功能。这些不是数据备份的替代品，数据备份应包括历史快照（无论是通过块设备快照还是tar等），而不是同步到恢复主机（如果有人删除所有已同步到恢复盒的数据，则将其全部删除）还有吗？）

这些消息可能是由于新服务器时钟的时间比旧服务器时钟的时间晚造成的。

如果要克隆程序包管理器配置和数据库，则应该克隆/ bin，/ sbin和/ lib，否则目标系统将处于不一致状态。另一种方法是排除/etc/dpkg.info / etc / apt / var / lib / apt和/ var / lib / dpkg并在目标系统中重新安装所有软件包。

/ var / dpkg和/ var / apt中的文件包含有关系统中已安装内容的信息。如果您不排除它们，则程序包管理器会认为父系统中的所有程序和依赖项都已安装在目标中。但是，如果您未复制/ bin，/ sbin等，则不会。在下一次安装或更新时，很可能会破坏某些内容。

为了保持与rsync的同步，我一直使用基于证书的身份验证，而不是密码。设置非常容易，我记得我是在第一次阅读手册页时才做的。这是一个快速指南，如果您需要更多信息，我相信这值得一个新的问题。