备份数据库时的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. 将备份副本和数据库存储在同一物理设备上

许多人可能觉得我们的建议有点幼稚–备份的ABC。没错，但鉴于虚拟环境的普及，数据库和磁盘最终可能存储在同一数据存储系统上。而且它肯定会在最不合时宜的时刻出故障。此外，仍然有人相信使用RAID阵列（版本1或更高版本：））数据就不会出问题。还有人相信某些“品牌”服务器不会出故障，但那是特殊情况。

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

5. 不控制备份过程的成功完成

这是管理员和IT部门主管中相当常见的错误。如果您不检查备份过程的结果，那还不如根本不执行备份。您必须通过电子邮件收到备份过程成功完成的通知，甚至最好也通过短信接收。而没有此类通知就是有问题的信号！

一位细心的读者读到这里（虽然现在给奖还为时过早）可能会问：“但这与管理层有什么关系？”答案是–管理员通常会配置备份过程，但他觉得检查通知太无聊了，尤其是当通知存储在单独的文件夹中时。因此，要求提供有关过程状态的额外报告永远不会多余。这就是关于当看起来备份副本存在但实际上需要时却不存在时谁该负责的问题：）

！一旦与问题2结合，我们既没有数据库也没有其备份副本。

建议：使用可以监控备份过程成功与失败的备份自动化工具，通知用户问题并提供汇总控制工具（当您需要控制不同服务器上数十甚至数百个备份过程时尤其重要）。

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

6. 不验证备份

备份副本存储在某处的事实并不意味着可以从那里读取它们。

因此，您必须定期验证创建的备份副本，以确保它们没有损坏或被复制到/dev/null。

针对Firebird的建议：您可以使用FBDataGuard自动化备份验证。

7. 使用未经验证的备份副本时不检查数据库健康状态

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

Gbak 在记录级别读取整个数据库以创建备份文件，并通过将记录插入新数据库来创建数据库，从而验证备份副本（错误仍有可能潜入恢复的副本中，但那是数据库管理员因组织不当的迁移而搞砸的另一种方式）以及数据库本身（如果可以从头到尾读取，则很可能没有损坏）。

Nbackup（又称增量备份）临时锁定主数据库文件以进行更新（处于一致状态），并允许快速复制数据库文件（完全或部分/增量）。

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

为了避免这种情况，您应该对原始数据库进行在线验证（从Firebird 2.5.4版本开始，可以使用gfix进行在线验证，而我们的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都有一个活跃且复杂的缓存，其中包含正在读取和写入的数据，而数据库文件本身以随机访问模式打开。因此，有必要使用特殊的备份类型，而不是简单的文件备份（包括仅复制数据库文件）或虚拟机备份。文件备份工具顺序读取数据库，这可能需要相当长的时间，尤其是在大型数据库的情况下，因此无法保证所创建备份副本的完整性。

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

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

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

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

对于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