系统pipe理员使用的备份和恢复策略和软件

“备份和恢复”O'Reilly的书。 强烈推荐。

http://oreilly.com/catalog/9780596102463

我对我和我的球队有几条规定。 希望他们中的一些人对你有用。

• 所有数据（日志和caching除外）都应备份。 不要指望系统永远不会崩溃。 它会。 有时我们也会备份日志和caching分区，以加速系统恢复过程，而不需要使用dirs，使用权限等。
• 保留文件备份的内容以及备份的位置。 在处理任何数据时，要习惯于记住备份的位置，恢复的频率和方式。
• 当您select一个平台时，请务必检查备份解决scheme。 尤其是在崩溃后，如何快速恢复系统。 直到你知道如何备份它，然后立即恢复它，不要select一个平台。 尝试备份/恢复它之前安装，广告总是说谎。
• 仅对频繁更改的数据进行频繁备份。 每小时支持整个系统只是愚蠢的。
• 任何关键的服务器应该至less有一个重复，可以自动replace失败的服务器。
• 做一个备份审计。 至less每周一次。 一个自动备份系统就像失败了，特别是在X日之前几天就会失败。
• 将所有可能的数据保存在共享存储上。 这使备份更容易。 但是不要相信你的共享存储，确保你可以快速地将所有的东西切换到备份存储，如果系统可以自动完成的话。
• 使用ZFS快照或类似的技术。 一个完整备份+增量，加上完整。 如果系统需要多次备份 – 这是一个坏的系统（当然除了磁带），我们生活在21世纪。
• 当您select磁带解决scheme时，请始终计算每TB的价格。 如果它与普通硬盘相同或者比普通硬盘便宜一点 – 忘记磁带。 除非您不需要快速恢复数据，否则对于非紧急档案，我宁愿使用磁带，即使它比较昂贵。
• 训练自己。 没有经过培训，你会更长时间地恢复生产。

最后，主要是：

• 人为错误 – 数据丢失的最常见问题。 保留所有数据在两个副本。 足够的分开，以避免与一个或两个命令杀死。 这是RAID不是备份的主要原因。 重大的硬件故障只有一秒钟甚至三秒钟。

我们用什么：

对于服务器 – 我们拥有VMWare VSphere上的所有内容，并且对DataRecovery几乎感到满意。 对于Oracle和其他数据库，我们使用他们的内部工具。 对于工作站 – 我们终于将所有东西都迁移到了iSCSI或瘦客户端，所以没有更慢的Acronis和其他狗屎。

我们有一个混合的环境（70％的Linux和30％的Windows）。 对于（主要）遗留的原因，我们在Windows端使用EMC Networker（使用磁带更换器），在Linux端使用bacula。 所有的Linux服务器都通过bacula进行覆盖，然后在该服务器上生成的备份目录将包含在EMC备份中（我们的夜间备份大小约为3TB）。

基本策略是对于所有的机器，我们只覆盖那些不能通过标准来源获得的部分。 换句话说：数据文件，数据库，configuration文件等等。 在某些情况下，备份过程没有本地客户端，并且使用NFS挂载来访问需要备份的东西（因为除了NFS挂载之外，这些目标服务器总是在变化，而且更容易提供NFS挂载点）。

如果服务器完全离开（从来没有这种情况），我们会购买replace硬件，安装操作系统和所有软件包，恢复configuration文件和数据，并离开你去。 如上所说，我们从来没有这样的情况下，服务器完全doolally挖掘。 我们的备份主要用于意外删除文件或文件损坏的用户。 我们曾经有过这样的情况，一些构build服务器必须从头开始恢复，因为有些工程师把它们置于不可能正常恢复的状态，原理工作得很好（除了恢复30GB数据只需要一些时间） 。 我可能应该补充说，我们所有的关键任务服务器都运行在RAIDarrays和冗余电源上，而且我们通常也保留一些相当多的备用硬件。

我们的备份解决scheme可能不是最好的做法，但它工作得很好。 环境混合Windows（80％）和Linux（20％）。 我们曾经为我们的数据库服务器和源代码控制仓库使用磁带备份，但是最近却放弃了这个想法（这是我的头脑决定的！）

我们在Windows服务器上使用StorageCraft ShadowProtect Server版本，并根据服务的重要性采用不同的策略（例如Exchange每半小时备份一次）。 它创build了系统的基本映像，对性能的影响最小（尽pipe在重负载的数据库服务器上，我们看到了一些问题 – 主要是由于磁盘I / O超出最终导致机器停机）。 它运行得非常好，并给了我们硬件独立恢复的选项，这意味着我们不必过于担心我们用哪个供应商replace硬件（我们有来自IBM，惠普，戴尔和使用泰安准系统的自定义版本的服务器）。

Linux服务器是另一回事，我们主要使用由高级系统工程师编写的自定义脚本。 基本原理是备份重要数据，而不用担心操作系统太多。

我们的文件服务器和邮件服务器提供了40TB的HP EVA StorageWorks SAN，提供了额外的保护。 我们的备份服务器是使用RAID 5定制24TB存储的。我们使用SyncBack Pro对项目文件共享和任何其他需要的文件级备份进行夜间备份。 一旦在主备份服务器上，数据被SCP传送到离线服务器。

我们也确保我们有大部分硬件的支持合同。 台式机24小时修复，戴尔和惠普服务器8小时，让生活变得更简单。

我尝试应用于备份的原则：

1. 构成备份的文件应与正在备份的文件相同，以便恢复。 压缩和encryption，如果需要，应该在文件系统级别进行处理。
2. 备份必须自动进行，并且每天晚上进行一次，并且在完成时应该从进程中收到一封电子邮件，说明备份介质是成功还是失败，
3. 备份应保存在远离他们备份的数据的地理位置
4. 数据库和其他系统如果不能通过复制文件来进行备份，则应定期进行转储，并备份转储文件。

至于软件方面，我发现rdiff-backup是一个很好的解决scheme，可以让我获得最近30天的备份。 我每晚都运行一个简单的包装脚本 ，将所有的Linux服务器备份到备份服务器上，备份服务器位于encryption的LVM分区上。 BackupNinja在所有服务器上运行，并在夜间备份运行之前负责转储数据库等。

备份一下。 有三个“原因”来备份您的数据。

1）灾难恢复
这可以保护您免受“meteor袭击您的build筑”的情况。 您需要一些快速重build整个服务器的方法。 这个问题的经典答案是完整的系统备份。 问题是在一段时间之后，大部分数据对DR（操作系统数据，大量静态的应用程序数据等）几乎毫无价值。

2）用户错误。
这种types的备份覆盖了'呃，我把这个文件丢了2个月以前，这个文件真的很重要'，或者'呃，我们的DBA放弃了这张表，但忘记了这个月度报告我们最后需要运行一次'等等。保留这些备份多长时间是一个商业决策。 我听说从1个月到2年的一切。

3）档案。
这是政府机构经常要求的真正的长期备份……“国税局要求这类财务logging为7或14年”。 好消息是，这通常是您的数据的一小部分。 磁带对此很有好处，或者经常光学媒体。

有了这些数据类（以及对您的环境的良好审计），您可以开始分类实际需要的数据types。

这是我们的备份策略（注意：这有点复杂）。 一般策略：备份到磁盘，将一些数据复制到磁带。 我们每月运行一次完整备份，每周进行一次备份，每天进行一次备份。 我们在磁盘上保留完整备份3个月，在磁带上保留1年。 我们保持L2备份4周，L3备份保持2周。 这为我们提供了过去两周的高分辨率备份，而且分辨率越来越低，这是您需要的时间。 在我们的用户份额（netapp）上，我们不做L3备份，而是依靠快照。 这使恢复更容易pipe理。

我们获得的巨大胜利是我们有3个“网站”。 其中一个是主站点，而我们的备份环境（磁盘，媒体服务器，磁带机器人等）则位于其中一个辅助站点。 这是我们对“数据中心消失”types问题的重大保护。