备份数据库时的12个常见错误

作者：Alexey Kovyazin，2015年11月11日

下载 PDF（英文版） 本文最初面向 Firebird DBMS 开发人员和管理员，但与其它数据库管理员的接触清楚地表明，大多数错误在他们当中同样普遍，几乎每个人都会在同一块石头上绊倒。如果您能为这份清单补充内容（甚至是特定于某个 DBMS 的内容），请通过我们的电子邮件 [email protected] 联系我们。

1. 在新的备份副本创建之前删除先前的备份副本

这个错误在新手当中最为常见，他们没有意识到数据库备份副本的主要目的不仅仅是创建一份数据库副本，而是让信息系统（数据库是其重要组成部分）的停机时间尽可能短。

结果就是，从最新的备份副本被删除的那一刻起，直到新的备份副本被创建为止，系统一直处于无保护状态，因为在此期间数据库没有任何一份备份副本。由于创建备份副本可能需要相当长的时间，这正是墨菲定律发挥作用的绝佳时机。这种方法与第 7 个问题（见下文）结合使用时效果尤佳。

建议：在新的备份副本创建之前，不要删除先前的备份副本！（也不要将新的备份副本写入已存在的文件）。

针对 Firebird 的建议：包含在 HQbird（Firebird 的高级发行包）中的 FBDataGuard 工具只会在新的备份副本创建之后才删除历史中最早的备份副本。

2. 从备份副本还原时覆盖现有数据库

这个错误不那么常见，但后果可能严重得多。如果备份副本未经校验并且被发现已损坏（见第 6 个问题），您将既没有先前的数据库副本，也没有有效的备份副本。

这种混乱通常发生在周五晚上，那时事情忙乱不堪，管理层的指示又有些自相矛盾。再加上一点坏运气，一个漫长难熬的周末就在机房里等着您了。

Firebird 对此错误有一定程度的保护——如果 gbak 工具默认的 -create 开关处于开启状态，并且指定的文件名指向一个已存在的数据库，那么就无法借助它从备份副本还原数据库。不幸的是，有办法绕过这一保护：-rep 开关仍然允许覆盖已存在的文件。

建议：在没有管理层书面指示的情况下，绝不要覆盖正在运行的数据库文件。

针对 Firebird 的建议：使用 FBDataGuard，因为它从不覆盖数据库文件。

3. 使用一步式备份/还原而不使用中间备份文件

标准输入/输出流使得在许多 DBMS（包括 Firebird）上实现一个有趣的技巧成为可能：执行流式备份并立即从中还原数据库。结果是不会创建任何中间备份文件。这对于日常维护和运行测试还原操作（前提是还有另一份可用的备份副本）很方便，但绝不能将其用于自动备份！

例如，如果在此备份/还原过程中发生严重的磁盘故障，初始数据库可能会损坏，而新的数据库尚未创建。当然，如果您考虑到第 1 个问题，并且存在上一次尝试留下的数据库副本，那么只会丢失在该副本创建之后数据库中创建或更新的数据。

建议：不要在自动模式下使用一步式备份/还原，在手动模式下始终检查是否有足够新的副本可用。

4. 将备份副本和数据库存储在同一台物理设备上

你们中的许多人可能会觉得我们给出的建议有点幼稚——这是备份的入门常识。没错，确实如此，但由于虚拟环境的流行，数据库和磁盘最终可能会存储在同一个数据存储系统上。而它肯定会在最不恰当的时刻发生故障。此外，仍然有人相信只要使用 RAID 阵列（版本 1 或更高 :））他们的数据就不会出任何问题。另外，还有人相信某些“品牌”服务器是万无一失的，但那是特殊情况。

建议：无论某个设备看起来多么可靠，都不要将备份副本和数据库存储在同一台设备上。

5. 对备份过程是否成功完成缺乏控制

这是管理员和 IT 部门负责人当中相当常见的错误。如果您不检查备份过程的结果，那还不如根本不执行备份。您必须通过电子邮件收到备份过程成功完成的通知，更好的做法是同时通过短信接收。而此类通知的缺失就是问题的征兆！

细心的读者读到这里（虽然现在还不到发奖品的时候）可能会问：“但这与管理层有什么关系？”关系是这样的——管理员通常配置备份过程，但他觉得检查通知太无聊了，尤其是当通知存储在单独的文件夹中时，因此多要求一些关于过程状态的额外报告永远不嫌多。这关系到当备份副本看起来存在、但在您需要它们的那一刻实际上并不存在时，该由谁来负责 :)

！一旦与第 2 个问题结合，我们就既没有数据库也没有它的备份副本了。

建议：使用能够监控成功和不成功备份过程、向用户通知问题并提供汇总控制工具的备份自动化工具（当您需要控制不同服务器上数十个乃至数百个备份过程时，这一点尤其重要）。

针对 Firebird 的建议：FBDataGuard 会检查备份过程是否已完成并发送相应的通知。对于拥有大量数据库的系统，可以借助 Control Center 工具进行第二级汇总监控，它允许您在一个页面上查看所有受监控服务器和数据库的状态。

6. 没有备份校验

备份副本存储在某个地方这一事实，并不意味着能够从那里读取它们。

这就是为什么您必须定期校验您创建的备份副本，以确保它们没有损坏，也没有被复制到 /dev/null。

针对 Firebird 的建议：您可以借助 FBDataGuard 自动化备份校验。

7. 在使用未校验的备份副本时没有进行数据库健康检查

通常，数据库使用多种类型的备份——转储、常规备份副本等。不深入细节，我们可以区分出两类：已校验的和未校验的。就 Firebird 而言，就是 gbak 和 nbackup。

Gbak 在记录级别读取整个数据库以创建备份文件，并通过将记录插入新数据库来创建数据库，从而校验备份副本（存在让错误潜入还原副本的方式，但那是数据库管理员把事情搞砸的另一种方式，与组织不善的迁移有关）以及数据库本身（如果它能从头到尾被读取，那么它很可能没有损坏）。

Nbackup（即增量备份）临时锁定主数据库文件以进行更新（处于一致状态），并使得快速复制数据库文件（全部或部分/增量）成为可能。

对于大型 Firebird 数据库（大于 500 GB），建议使用 nbackup 以免拖慢用户操作，但同时必须校验数据库，因为它创建的未校验备份副本是数据库页面的副本，如果错误存在于记录级别（由于内存故障）或逻辑级别，未校验的备份副本将和原始数据库一样包含该错误。

为避免这种情况，您应该对原始数据库使用在线验证（借助 gfix 的在线验证从 Firebird 2.5.4 版本开始可用，而我们的 FBDataGuard 工具支持 1.5-2.5 版本的在线数据库验证）。

此外，建议在未验证备份之外，偶尔执行一次已验证备份（例如每周一次）。

针对 Firebird 的建议：除了在线健康检查外，FBDataGuard 还允许您以自动模式测试备份还原过程。

8. 未控制备份副本的可用空间

实际上，这是一个经典错误：如果空间不足，备份副本会占用所有可用空间，进程最终以错误结束。将备份副本与数据库存储在同一磁盘上可能导致数据库运行中断，而将其存储在系统磁盘上则可能导致系统故障。

结合问题 4 来看，最好的结果将是系统停止运行，因为数据库也需要可用空间，但它被备份副本占用了。至于与问题 5 和问题 2 的结合，则又会让我们既失去数据库也失去其备份副本。

建议：使用能够预测备份大小并警告您可能缺少可用空间的备份工具。

针对 Firebird 的建议：FBDataGuard 会控制用于备份的可用空间大小，以及数据库所在磁盘和系统磁盘上的可用空间大小。

9. 未控制创建备份副本所需的时间

半年前备份过程只花了 40 分钟，然后突然就需要三个小时了——为什么会这样？数据库大小可能增加了，或者 RAID 阵列中的某块磁盘掉线导致写入性能大幅下降，您的所有备份副本可能都即将消失。或者您的一位好同事可能同时运行了另一个备份系统（顺便说一句，Firebird 允许同时运行多个备份进程，尽管不太清楚为什么有人会需要这样做）。如果您不控制创建备份副本所需的时间，您可能会忽视新出现的问题，并错过在问题变得严重之前修复它的机会。

此外，如果备份系统不监控备份任务的状态而只是按计划运行它们，您很容易"操之过急"，即系统在前一个备份进程尚未结束时启动新的备份进程。

建议：使用能够控制备份过程所需时间的工具！

针对 Firebird 的建议：FBDataGuard 会控制备份过程所需的时间。

10. 在应用操作系统更新时备份数据库

这是一个非常常见的问题，尤其是与问题 9 结合以及启用了 Windows 自动更新时（默认情况下，更新在凌晨 3 点应用）。最好的情况是导致速度变慢，但如果操作系统为了应用更新而重新启动，备份副本将损坏。好消息至少是操作系统并非每天都更新。

建议：将操作系统更新安排在不会干扰备份过程的时间。

11. 在数据库服务器运行时借助文件备份工具或虚拟机备份工具备份数据库

许多管理员忘记了任何 DBMS 都有一个活跃且复杂的缓存，其中包含正在读取和写入的数据，而数据库文件本身是以随机访问模式打开的。这就是为什么有必要使用特殊的备份类型，而不是单纯的文件备份（包括仅复制数据库文件）或虚拟机备份。文件备份工具按顺序读取数据库，这可能需要相当长的时间，尤其是对于大型数据库，因此无法保证所创建备份副本的完整性。

虚拟机可能使用快照和 Changed Block Tracking 机制，但必须同步所创建的备份副本才能获得一致的数据库备份副本，因为在整理变更块集合时如果对数据库有任何活跃的写操作，备份副本将不一致。

对于那些希望借助文件或虚拟机备份工具备份数据库的人，我们可以提供两种方法：

1. 完全关闭 DBMS 服务和进程，使缓存中没有任何内容，
2. 使用代理和/或脚本将数据库切换到特殊模式，使按顺序复制数据库文件变得安全。例如，MSSQL 数据库有一种称为 VSS writer 的机制。应请求，它会在制作快照时将数据库切换到适合快照的模式。如果您使用基于 Changed Block Tracking 的机制，您自己应确保数据库在同步时是一致的。

如果您不将数据库切换到适合备份的模式，生成的数据库副本看起来就像主机发生了硬重置（例如断电）。这种可靠性水平对大多数企业来说绝对不够。您可以在文章"在虚拟机上使用数据库的特殊性"中了解更多相关信息。

对于 Firebird，有必要在备份过程开始前借助 nbackup 锁定数据库的主文件，并在过程结束后解锁它。对于其他 DBMS，也有类似的工具来开启/关闭相应模式。

一些数据库管理员确信，如果 DBMS 有事务日志，他们就可以借助标准文件备份工具安全地备份数据库，因为最多只有该日志会损坏。这是一种危险的误解，DBMS 开发者并不支持这种观点。

这种误解的根源很清楚：虚拟机和备份工具开发者的激进广告通常不会提到数据库以及其他频繁更新的文件需要高级配置。不要相信炒作——并非所有酸奶都有相同的益处。

建议：在没有相应的数据库自动化工具的情况下，不要使用文件和虚拟机备份工具。

针对 Firebird 的建议：使用 FBDataGuard（来自 HQbird 发行包），它提供与支持 VSS 的备份工具的集成。

12. 用复制替代备份

数据备份和数据复制都用于提高可靠性并防止数据丢失，但它们仍然截然不同。

每个人都喜欢复制，因为它能以最小延迟同步另一台服务器上的数据，但备份也有一些无可争议的优势。例如，在意外（或故意）删除数据的情况下，复制会快速且无动于衷地将更改发送到副本，而备份（尤其是副本存储在只读介质上时）对此类操作免疫。正确配置复制和备份都需要一定的努力，而且仍然存在出错的可能性。

建议：如果您配置了复制，不要忽视备份副本，两者都要使用。

针对 Firebird 的建议：使用 HQbird Enterprise 发行包，它同时包含备份和复制工具。

总结

为您喜爱的 DBMS 配置备份并不那么容易，因此重视其数据的组织中的数据库管理员通常使用专业备份工具，这些工具允许他们考虑上述问题并预防问题。

对于 Firebird（请原谅做广告），有一个名为 HQbird 的包，其中包含 FBDataGuard。

此外，我们公司为 Firebird 和其他数据库提供完整的备份和维护支持，对于那些不了解备份所有技术细节的人来说，这是一个不错的选择。

当然，也要继续保持你那份管理员式的偏执，比如现在就起身去检查一下你的备份副本吧 :)

联系方式

有任何问题请随时提问：[email protected]

想获取关于 Firebird 的新闻和文章？欢迎加入我们的 Telegram https://t.me/firebirdsql