☰

使用 tar 和 rsync 实现高可用性

tag-icon • tag-icon rsync tar
使用 tar 和 rsync 实现高可用性

我正在运行 Ubuntu 云服务器，我无法直接访问，但可以使用 ssh。我使用“tar”来克隆或实现此服务器的高可用性。我按照链接 [链接文本][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/ 或我包含的任何目录中排除什么吗？- 给我提个建议。
  • 我如何安排 rsync（增量 bkp）与 ssh 组合以将目录（在 tar 中指定）同步到远程位置（例如 /mnt/newdir），以便在系统发生故障时可以将其打包并稍后提取。可以安排 rsync 以 root 用户身份运行，但 ssh 将提示输入密码。仅供参考，sudo 已完全禁用，并且直接 ssh 登录到 root 也被禁用。

如果有更好的方法并且不对服务器造成任何损害来实现这一点，请提出建议。

[1]：http://ubuntuforums.org/showthread.php頁面=525660

答案1

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

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

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

答案2

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

在 EC2 上，如果您运行基于 EBS 的系统，则可以定期对其进行快照。如果源实例发生可怕的事情，您可以在全新实例上回滚到上一个快照。如果您想存档快照，您可以启动另一个附加了该快照的实例，并使用类似 tar+s3 的东西，而不会对生产设备产生负面影响。

这种方法存在许多问题，现在可能还不明显。

  1. 您将自己锁定在单一技术中。如果您在 Ubuntu 10.10 上运行此系统，并且想要升级到 11.04，则必须升级源系统，然后再次对其进行快照。同样，如果您使用 EC2 的 EBS 快照，则在转到 Rackspace Cloud 时需要新的解决方案。
  2. 如果使用 rsync，则没有更改历史记录。如果您在系统 1 上修改了某些内容，然后出现问题，则在使用 rsync 时，您的备份系统也可能会受到影响。
  3. Rsync 可能会对您的生产系统产生极大的影响。

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

我建议您选择一个配置管理系统，例如 puppet（在主系统中！）、chef 或 cfengine。开始在配置管理系统中完成所有配置，然后您可以启动通用系统，并将配置管理应用于它。添加“etckeeper”，您就有了历史记录。

对于数据高可用性，rsync 应该可以工作，而且更直接，因为您可以直接复制所需的数据。还有 drbd，相当于“网络 RAID1”。这些不是数据备份的替代品，数据备份应该包括历史快照（无论是通过块设备快照还是类似 tar 的东西），而不是同步到恢复主机（如果有人删除了所有被 rsync 到恢复箱的数据，也会在那里删除所有数据，该怎么办？）

答案3

该消息可能是由于新服务器时钟比旧服务器时钟落后而导致的。

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

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

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

相关内容