完整的备份系统需要什么？

我们为一个目的build立备份系统：启用恢复。 没有人关心备份; 他们关心恢复。

有三个原因可能需要恢复文件：意外删除文件，硬件故障或归档/法律原因。 一个“完整的”备份系统将使您能够在所有这些情况下恢复文件。

对于意外的文件删除，Dropbox和RAID之类的东西都会失败，因为它们只是反映了对文件系统所做的所有更改，并且在这些情况下删除的文件不见了。 您的备份系统应该能够很快地将文件恢复到最近的时间点; 最好还原会在几秒到几分钟内完成。

对于硬件故障，应尽可能使用诸如RAID和其他高可用性方法的解决scheme，以确保您的服务保持正常运行，因为系统的完整恢复可能需要几个小时甚至几天才能完成，因为需要读取和写入到（相对）缓慢的媒体。

最后，档案或系统在特定时间点的完整备份（或同等）可以在法律和灾难恢复情况下进行恢复。 这些通常会存储在异地，以防meteormeteor将您的数据中心变成吸烟坑。

您的完整备份系统应该能够支持这三种types的恢复，具有不同的服务级别（SLA）。 例如，您可能会决定删除的文件可能会在过去六个月中以一个工作日的粒度和过去三年的一个月粒度进行恢复; 并且在不超过两个工作日的数据丢失的情况下，磁盘故障应该能够在四小时内恢复。 备份系统必须能够在备份计划中实施SLA。

您的备份系统必须完全自动化 。 这个不能太强调。 如果备份不是完全自动化的，他们根本就不会发生。 您的备份系统必须能够进行全自动备份，不需要特别的configuration或脚本，即可使用。

您必须定期testing恢复。 任何备份系统是完全无用的，如果从备份恢复失败的工作。 我想大多数人都有这样的恐怖故事。 您的备份系统必须能够在您正在实施的SLA中恢复单个文件或整个系统。

您必须持续购买备份媒体。 无论您是在进行现场磁带备份还是使用非现场云备份，请确保您在预算中支付您需要的千兆字节（或千兆字节）的空间。

这是对“系统和networkingpipe理实践”第二版第二十六章的一部分的简要总结，任何想成为或希望成为系统pipe理员的人都应拥有，阅读和记忆。

我已经掩盖了很多不一定适用于你的特定情况的东西，或者在你描述的那个小环境下没有意义的东西。 尽pipe如此，它应该是对你的“完整”备份系统应该具有的function的合理描述，以及为什么它们是必要的。

1. DropBox将是一个有风险的做备份的方法。 没有SLA / QoS，它可能会违背他们正常的TOS，以自动的方式将这么多的数据转储到他们的服务器上。 他们明确表示不承担访问您的数据的任何责任 – 他们可能会自行决定切断访问，销毁数据或破产，而且不会有任何警告。
2. 没有备份程序是“有效的”，直到你真的从中恢复，这是唯一的方法来确定。 许多备份软件提供了“validation”function，这对于大多数人来说是无用的，因为它仅仅证实某些东西被写入到备份介质中， 而不是在恢复操作系统中真正有用的东西 。
3. 无情地完成文档确保您能够在灾难发生时遵循还原过程 – testing文档应该是testing系统恢复的一部分。 另外，如果你遇到一辆公共汽车（墨菲定律等等），别人就能完成这个程序。
4. 恢复只有在有意义的时间内完成才有用。 例如，如果花了一年的时间恢复你的数据是没用的。 您应该确定哪些时间框架对于您的情况需要三个级别的function：最less的function，日常操作，完整的。 testing你提出的解决scheme，看看是否符合时间要求。

诺。 你现在很好。 至less在概念上…

• 考虑备份时系统的状态。 也许你不想备份一个活的数据库…
• 或者考虑一下你的硬件。 你是否尽一切可能使机器尽可能有弹性？ 例如，我想从备份恢复到最后的事情，我必须在紧急情况下做。
• 可以通过使用高质量的硬件来减less停机和小型服务中断，因此请确保您使用的是RAID，服务器级设备，并且正在寻找更加本地的数据保护方法。
• 想想你所面临的失败和情况的types。
• 我不一定会使用DropBox，但是异地保护的想法是正确的。

我的首选，尝试和真实的备份系统是：

1. 所有数据库每小时快照（一个快照每两天存档一次，一个快照每周存档一次）。
2. 一次性服务器。 也就是说，所有的服务器站点都存储在git中并自动部署（与puppet的说法非常相似，我们首选的工具是厨师）。从本质上讲，一个新的服务器可以从头开始使用只有你有代码在git中，意味着任何开发主机都是以与生产服务器类似的方式构build的。

在这种情况下，木偶大师或厨师服务器可能是潜在的失败点; 再次，尽可能自动地重build它们，并且在现有脚本允许现有节点尽快引导到新的服务器pipe理主机的情况下，如果旧盒子被击倒。 我发现从备份重build这种主机有时会花费更长的时间，而不是从头开始重新build立一个新的主机（并且从备份恢复可能会无意中重新引入导致其在备份中出现的相同缺陷或问题第一名。）

换个angular度来说，如果你有多台服务器，主机等，使用中央日志服务器是非常值得的投资。 如果他们从一个来源安置（并备份），它可以节省您login其他主机时堆积并占用空间的头痛。 日志数据是黄金，但是如果我有20个api服务器，所有服务器都提供stream量，而且我受到类似DDoS的攻击，没有聚集我的日志意味着我在大海捞针。 如果您要存储您的基础架构日志（并且您应该！），然后将它们存储在一个强大的备份平台上。

G'luck〜！

RAID和像Dropbox这样的服务“备份” 所有的变化。 包括你想从备份中恢复的错误。

这就是为什么我们所有的系统pipe理员types都变得非常非常尴尬，为什么像RAID或toytown云文件存储服务，依赖镜像更改您的文件的变化，而不是备份。 这并不是说这些服务没有用处。 他们是，但他们不是备份，因为他们并不真正给你数据的完整性。

备份应该是备份时的情况的快照，而不是在数据发生时所发生的所有好事和坏事的连续覆盖的实时日志。 有云提供商会给你实际的备份，如果你看，他们的工作方式不同，Dropbox / SkyDrivetypes的服务。

当涉及到这个问题时，您可以select自己承担哪种风险，以及如何降低风险。 如果你认为像Dropbox这样的东西足够好，那就取决于你。 但是你需要清楚自己会做什么，不会做什么 – 请不要自欺欺人，这是一个真正的备份。