使用 tar 和 rsync 实现高可用性

Question

我有 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使用前有什么注意事项吗？（tar 是一次创建，从那时起我将使用 rsync）
• 我是否应该包含更多目录，如 bin 或 lib？- 建议我
• 我应该排除任何目录吗？就像我有一个网络设备（eth0）问题（无法启动 eth0）。所以在上面的命令中我已经排除了“/etc/udev/”，之后我觉得这很好。像这样，有什么我必须从 /etc/ 或我包含的任何目录中排除的吗？- 建议我。
• 我如何使用 ssh 组合安排 rsync（增量 bkp）以将目录（在 tar 中指定）同步到远程位置（比如 /mnt/newdir），我可以在系统出现故障的情况下对其进行 tar 和提取。可以安排 Rsync 以 root 用户身份运行，但 ssh 会提示输入密码。仅供参考，sudo 被完全禁用，并且直接 ssh 登录到 root 也被禁用。

如果有没有对服务器造成任何伤害的更好的方法来实现这一点，可以提出建议。

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

Answer 1

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

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

如果你有一个像 mysql 这样的数据库，你需要在执行复制之前小心并停止数据库。

Answer 2

首先，许多 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 的东西），而不是同步到恢复主机（如果有人删除了所有同步到恢复盒的数据，然后将其全部删除会怎样）还有？）

Answer 3

这些消息可能是由于新服务器时钟比旧服务器时钟落后而引起的。

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

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

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