Cliffhanger：备份就在……这里……对吧？

你总是必须从头到尾解决这些问题。

当前的备份策略是否得到管理层的支持和理解？如果没有，那就没用了。

执行管理层需要了解这些问题以及涉及哪些风险（丢失您需要合法获取以生存的财务数据，还是需要数​​年才能收集的客户数据？）并在决定采取行动或决定让某人（比如你）采取行动。

如果您无法进入管理层，请尝试业务控制或其他财务职位，其中数据检索及其完整性对公司的报告非常重要。如果需要，他们反过来可以“开始风暴”......

从哪里开始？这是一场等待发生的灾难。系统管理员的主要工作职能是确保数据备份和可恢复。其他一切都是次要的。不，如果不是但是。

以下是您可以做的几件事：

1. 跟踪恢复的 KPI。应该可以生成一份报告，显示有多少恢复请求已成功。任何低于 100% 的情况都应进行彻底调查。管理层喜欢报告，这是确凿的证据。

2. 应该有所有备份和恢复操作的记录程序，包括所有系统及其备份策略、磁带轮换、时间表、升级路径、测试恢复等。要求查看。

3. 与系统管理员的经理交谈并表达您的疑虑。准备好恢复不起作用的证据。如果没有快乐，就走得更高。

说真的 - 大惊小怪。像这样的事情可以摧毁一个公司。

建议（至少）每年进行一次灾难恢复测试。成功执行测试所需的工作应该揭示缺点。

在我工作的地方，我们有一个非常出色的 IT 部门，每年他们从欧洲各地的每个办公室聚集在一起，在数据中心租用的服务器上举行“恢复盛宴”，有效地模拟如果有一天员工上班并发现办公室在夜间被烧毁。

让大老板参与进来，提醒他如果发生灾难，那年他将失去奖金（或更糟！），因此组织类似的灾难恢复演习可能是明智的。这不应该花费很长时间或花费太多 - 管理员会带着他们的异地备份磁带被送走，并被告知要从他们那里建立一个相同的办公环境。

然后坐下来看着 IT 变得更好——一旦管理层意识到公司数据危险地接近永久丢失，火花就会飞扬（从战略上放置在上述管理员中的火箭）

责备管理员很容易——但奥斯卡说得对：这些事情是从高层推动的。如果管理层不花钱将备份作为优先事项，那么系统管理员通常会不走运，并且会利用他们拥有的资源尽力而为。

关键是，如果您是那些不幸的管理员之一——而且我一直在这艘船上参与一些客户活动——是您确保以书面记录可确认的方式反复向管理层进行简报，这是对企业构成风险。

我的策略是不断地解决问题。如果你这样做，有时问题会得到解决，但这主要是为了让我报告的任何人都不能躲在“我从未被告知过”的借口后面。作为一名顾问，我通常可以做得更好。我可以让我的老板向比我更高级的管理层通报存在漏洞。这分散了责任，或者至少将其集中在比我更高的水平上。

同时，您必须具有创造力并努力工作，以利用客户可以提供的任何资源将风险降至最低。

虽然在某些情况下管理员可能是有罪的，但管理层始终要负责：要么知道风险但没有采取足够的措施来减轻风险，要么雇用没有提醒他们注意这些风险的人。

我负责分布在英国西北部的大约 200 台服务器，这显然太多了，无法手动检查。

我配置备份，以便在完成后运行（VBScript）脚本，查看备份日志，确定备份是否有效，并将记录与备份结果一起写入中央数据库。然后在总部我运行一个脚本来查询这个数据库并向我提供一个站点列表，其中备份报告了错误或没有来自该站点的报告。

最终结果是，当我坐在办公桌前时，我有一份需要检查备份的所有站点的列表。

所有这一切的重点是，默认假设是备份失败，只有当我的 VBScript 没有检测到错误并将这个结论写入我的数据库时，备份才被认为是有效的。这可以确保备份失败不会被忽视。

一些服务器使用 Backup Exec，一些 NTBackup 和一些只是将它们的文件复制到网络上的另一台服务器。服务器执行哪种类型的备份并不重要，因为很容易调整我的 VBScript 以检查错误。我的脚本实际上非常基本，它只是将备份报告作为文本文件打开，并用 greps 查找诸如“挂载失败”、“磁带已满”、“CRC 错误”等短语。我相信专业程序员会这样做一个更漂亮的工作。然而，整个事情是简单而强大的，它是主动的，无论我是否愿意，我都会看到备份失败报告，如果我有意识地决定忽略该报告，我只会没有注意到错误。

JR

PS 99% 的备份失败是因为用户忘记更换备份磁带。你不只是喜欢 luser 吗:-)

未经测试的备份不是任何备份。