备份检查的最佳做法？

运行消防演习…每隔几个月，说XYZ系统崩溃是一个好主意，然后实际上是通过将它重新联机到一个新的虚拟机等运动。它保持诚实，并帮助你赶上错误。

肥皂盒模式：打开

我可以这么说，就是那个没有经常testing的备份是没有价值的。

我以前的工作，我们有一个政策，每个系统（生产，testing，发展监测等）应该每6个月testing一次。

这也是最初级pipe理员的工作，所以文档是最新的。 初级的定义是他/她在特定的系统上做了多less工作，有时（通常实际上）是“团队经理”

我们有专门的硬件（一个英特尔和一个IBM / AIX机箱），除了磁盘空间以外都是低规格的，因为我们不需要在恢复的主机上真正运行任何东西。

前几轮的工作很多，但是这使我们简化了作为备份重要组成部分的恢复过程。

由于您似乎指的是pipe理员没有注意到备份作业“中断”的事实，而不是说工作备份不能正常工作，所以我会build议在备份的周围build立某种监视脚本。

在构build本土备份解决scheme时，我会这样做：

• build立一个脚本来备份你的数据。
• 执行testing恢复以确保脚本正常工作。
• 在脚本中，或通过其他方式，实现一种方式来跟踪备份的状态（成功，失败，跑，没有运行）。
• 有跟踪状态监测（电子邮件，数据库，东西）

一旦完成了这一切，你应该没问题。 一个额外的事情将执行定期testing恢复。 如果你有额外的硬件捐赠的原因是。

在我工作的地方，我们有一个温暖的地方，每月一次，我们随机select一个系统或数据库，然后到我们温暖的地方进行裸机testing恢复练习，以确保能够恢复我们的数据。

老实说，如果你的数据对你来说非常重要，那么投资一些软件来pipe理你的备份对你来说是最有利的。 这里有数以百计的产品，从便宜，简单到企业级。

如果您依赖于crontab中为您的公司备份运行的一组手写脚本，迟早您可能会被烧毁。

我们有60％的“参考”版本的“生产”系统，我们使用它们进行最终的变更testing，我们将“生产”备份恢复到这些系统 – testing备份，确保两个环境相互协调。

一种方法是脚本定期运行“恢复”作业，例如从最近的备份中抓取特定文本文件并将其内容发送给您。 如果可能的话，这应该 – 至less有时 – 使用与创build或备份数据不同的盒子来完成，只是为了确保在需要时能够工作。 好处是你可以确定你的encryption/解密，压缩和存储机制都在工作。

这对于诸如电子邮件和数据库服务器等专业备份稍微有点涉及，尽pipe从小型数据库或砖级邮箱备份执行某种小规模恢复，并validation内容当然是可能的，只是多一点参与。

这种方法也不应该取代定期的完全恢复，以确保在紧急情况下可以恢复数据 – 它只是让您对日常备份工作的完整性更有信心。

1. 消防演习。
2. 每6个月testing一次备份的策略是一个非常好的主意
3. 当涉及到testing时，您需要查看每个应用程序或系统的备份。 理想情况下，备份的“成功”或“可恢复”备份应在服务描述或SOP（操作文档）中列出，以及其他详细信息，例如保留时间，bladibla。

您可能会发现某些备份types可以通过脚本（如数据库）轻松进行恢复testing，而其他备份types需要手动input（Active Directory恢复）。 尽可能多地自动化，确保某种报告已经到位，并确保“某人”也定期进行手动testing。 一个独立的环境（prod的缩小副本）将使执行恢复testing变得更容易。

在进行testing恢复时，我并不觉得很舒服，“这看起来不错，文件恢复，似乎没有文件丢失，甚至尺寸匹配”，或者在“这看起来不错，我开始我的申请。 ..不会崩溃，显示一些体面的数据“。

我想从头开始恢复服务器/集群，然后实际使用它进行生产 。 不是一分钟，不是一个小时，而是永久的 。 如果你声称你的恢复是成功的，那么绝对没有理由不开始生产。 这不是一些“肮脏”的系统，应该被遗忘。 这是一个真正的灾难后，你将面对的系统。 所以，如果它通过“看起来不错”的阶段，与它生活。 支持第二天晚上。 忘记原来的一个。 你可能会发现使用这种方法的一些小故障，你将被迫 解决所有这些问题 。 同一个系统的下一次恢复有一个很好的机会是100％成功的。

这包括您的备份软件和服务器。 是的，你也需要恢复这些。

没有预算购买专用硬件进行恢复？

• 说一点，你绝对需要一个预算。 在每一次提醒决策者，一个有效的，整个恢复testing还没有发生。 （是的，收集证据来掩盖你的屁股。艰难的世界。）
• 在大多数组织中，偶尔有业务需要将某个系统迁移到另一个硬件，所以要利用这个机会。 总是select“从备份还原”方法进行迁移，假装你刚刚丢失了原来的硬件。 是的，这意味着更多的停机时间，对此感到遗憾。 至less你会有信心，你的备份是有用的。
• 没有迁移？ 也许你可以借用一些硬件两个星期，并执行两个恢复testing（恢复到借用的硬件，等待超过一个星期，从借用恢复到原来的，与它同住）。 通常情况下，如果某个新系统购买了新的硬件，并且安排得当，那么可以轻松借用它 – 通过提供详尽的testing两周。 如果新硬件与旧硬件不完全相同，那将会使你的testing更好。 你如何知道在真正的灾难情况下是否有相同的硬件？
• 目前您正在执行任何新系统？ 你现在可以testing恢复吗？ 不要使用额外的硬件，只要覆盖新的系统，因为你有新的知识如何快速重新实施​​。 如果它没有重要的数据，这将起作用。 再次，在恢复的版本上进行生产，而不是在刚刚重新安装的版本上。

虽然我们不testing备份，但我们在BackupRadar.com系统中有集中的备份检查和报告组件。 随时检查一下，看看它是否有助于该组件。 它将成功/失败电子邮件的副本附加到备份策略中，如果备份软件也能够发送这些邮件，则还会附加屏幕截图。

谢谢，帕特里克

确保logging下备份活动，然后写一些东西（当然是perl），parsing那些查找故障的日志，将其提取出来并作为每天的电子邮件发送。