介绍
备份数据库是管理数据所涉及的最重要的例程之一。数据通常是组织管理的最重要资产之一，因此能够从意外删除、损坏、硬件故障和其他灾难中恢复是重中之重。
虽然不难认识到可靠备份的价值，但了解细节并不总是那么简单。确定备份机制、介质、时间表、保真度和安全性都是您需要考虑的因素，正确的组合通常因项目而异。
在本指南中，我们将回顾您在决定数据库备份策略时必须做出的关键决定。我们将介绍不同的备份方法，在其生命周期的不同时间点将数据存储在何处，并讨论安全性如何以各种方式与备份设计相交。
在继续之前，强调适当的备份可以为您的团队带来什么价值可能会有所帮助。一些主要好处包括：
- 硬件故障后重建：硬件故障会影响任何系统，而且通常是不可预测的。拥有全面的备份可以让您在更换故障组件后恢复数据。
- 损坏后恢复文件：数据损坏是另一种可能由软件错误、硬件问题或环境因素引起的事件。多层备份可以让您用备份集中的良好版本替换损坏的数据。
- 从意外删除中恢复：用户错误也可能从您的数据库中删除有价值的数据。通过备份，您可以恢复该数据以避免永久丢失。
- 审计和合规性：出于合规性原因，许多行业都有特定的备份和审计跟踪标准。作为以各种身份处理用户数据的协议的一部分，您可能被迫实施强大的备份程序。
- 进行更改时的保证：拥有可靠的备份可以降低更改软件、环境或操作的危险性。您可以放心地进行更改，因为您知道如果出现问题，您不会冒着组织数据的风险。
您可能需要考虑许多不同类型的备份。在本节中，我们将介绍您可以执行的一些不同的备份，以及它们如何组合成一个更全面的系统。
完整备份是从原始位置复制整个数据集的备份。它们具有所有备份的最大范围，因为根据定义，它们将所有数据从源读取和写入到目标。
完整备份很重要，因为它们为您提供了数据集的完整副本，可用于部分或完全恢复丢失的数据。每个策略都应包含完整备份作为其例程的核心组成部分。
虽然完整备份是必要的并且提供了大多数备份策略的基础，但它们也有一些主要缺点。因为他们必须读取和写入整个数据集，所以他们可能需要很长时间才能完成，并且可能会在整个时间内对系统造成负担。此外，随着时间的推移维护数据库的许多完整副本会消耗大量存储空间。
差异备份复制自最近的完整备份以来更改的所有数据。这允许您在每个备份周期执行一次昂贵的完整备份，然后在使用完整备份作为起点的较小备份中记录进一步的更改。
差异备份解决了频繁进行完整备份所带来的一些核心问题。它们比完整备份更小，因此占用更少的存储空间并且执行速度更快。
虽然差异备份比完整备份有所改进，但它们仍然存在一些缺点。自最近的完整备份以来经过的时间越长，差异备份就越大。此外，拥有多个差异备份可以让您构建不同的时间点，但代价是多次备份相同的更改。
增量备份是对差异备份使用的策略的修改。差异备份总是记录自上次完整备份以来的差异，而增量备份记录自上次完整备份或增量备份以来的差异。这意味着增量备份不是总是在完整备份上分层，而是可以通过从完整备份开始然后恢复多个增量备份来恢复数据。
该系统允许您经常备份，同时只记录系统中的每个更改一次。每个备份将仅包含自上次运行任何备份以来发生的更改。这有助于保持每个增量备份的大小可管理，并允许您通过将最近的完整备份与不同数量的增量备份相结合来构建不同的时间点。
增量备份的一个缺点是恢复数据可能会稍微复杂一些。自完整备份以来的时间越长，您必须应用的增量备份就越多才能获得最近的更改。这可能比恢复单个完整备份和（至多）单个差异备份花费的时间更长。
数据库经常实施安全机制以帮助从系统崩溃和不安全关闭中恢复。根据系统的不同，这些可能称为预写日志 (WAL) 或事务日志。虽然这些主要用于崩溃恢复目的，但它们可以用作备份策略的一个组件，以允许更灵活的归档。
基于 WAL 的备份背后的基本思想是定期备份数据库的文件系统，然后使用 WAL 将一致的状态恢复到数据库并重放备份后发生的任何更改。这听起来与增量备份类似，但存在一些关键差异。
第一个重要区别是这两个组件使用不同的介质。此实例中的完整备份是数据库文件的备份，而不考虑将记录锁定在一致状态。然后 WAL 负责修复数据的状态并将其赶上要恢复的点。
该系统也比传统的增量备份更灵活，因为单个 WAL 可以重播到不同的时间点。这使您可以选择要还原的数据量。这种备份方式的一个缺点是它会影响整个数据库系统。您不能只恢复数据库的一部分而保持其他部分完好无损。因此，它不适合恢复单个表或其他数据库对象。
在决定备份策略时要记住的一件事是某些备份机制不能在实时系统上执行。
要求系统离线的备份方法通常具有该限制，以确保该工具可以在特定时间点捕获一致的数据库视图。如果系统正在更新并且记录在执行备份时正在更改，则开始时的数据可能在该过程完成时无效。
然而，离线备份确实有一些优势。关闭数据库意味着它不必与活动用户共享资源，这可以使其更快地完成。备份过程本身也可以简单得多，因为不会有任何进程主动更改数据。
话虽如此，在许多情况下，每次备份都关闭主数据库是不可接受的。幸运的是，有设计用于实时系统的备份方法。通常，这涉及使用实用程序直接查询数据库系统，以便可以将数据库结构和数据复制到文件系统。除了所需的权限外，这与要求表结构信息和其中包含的数据的普通客户端没有太大区别。
这些“逻辑”备份工具（与使用原始文件的物理工具相反）的主要好处之一是它们可以依靠数据库自身的能力在特定的点提供数据的统一一致快照-时间。此上下文中的备份进程作为数据库用户运行，因此此功能的代价是它将与其他客户端争夺有限的数据库资源。
一些用户的一个困惑点是，如果配置了复制，为什么数据库还需要备份。
数据库复制是一种将更改日志从一台服务器流式传输到另一台服务器以在不同系统上镜像更改的方法。与备份一样，这也会创建系统数据的副本。但是，出于一些重要原因，不应将复制视为安全的备份策略。
在大量故障情况下，复制无法像备份那样保护您的数据。确保将所有更改复制到辅助服务器的相同机制也会复制主数据库的任何问题。例如，如果在主数据库上无意中删除了一条记录，则该更改也将在任何下游副本上执行。同样的过程意味着损坏的数据也将被传播。
复制不是备份的另一个原因是它没有任何明显的数据恢复能力。虽然您可以在服务器之间来回复制更改，但复制与保留以前版本的数据无关，并且当日志轮换时，您的数据的任何历史视图都可能会丢失。这种“缺陷”提醒人们，复制主要是为了帮助组织提高可用性和性能而设计的，而不是作为一种数据保存工具。
话虽如此，复制可以成为备份和灾难恢复计划的重要组成部分。例如，复制在主数据库发生硬件故障时很有用。在这种情况下，管理员可以快速将复制跟随者提升为领导者角色，并继续为客户端请求提供服务，以避免冗长的恢复过程。一些组织还设置了一个“延迟”副本，它只在经过一段时间后应用更改，允许他们在必要时通过切换到副本来快速“回滚”数据库状态。
备份过程中经常涉及复制的另一种情况是作为备份操作的目标。很多时候，备份副本比主服务器更容易。例如，要获得一致的文件级备份，您可以将辅助数据库配置为生产数据库的副本。数据库同步后，您可以暂时关闭复制并在不影响生产流量的情况下执行副本备份。备份完成后，您可以重新打开复制以使服务器与备份窗口期间发生的更改重新同步。
备份策略以几种不同的方式与安全考虑相交。
通过在勒索软件攻击等场景中提供辅助数据源，备份可以帮助防止某些安全事件。例如，如果入侵者能够访问和加密您的主数据库的内容，那么访问历史快照可能会为您提供更多解决这种情况的选择。要使其成为一个选项，您的备份目标必须位于与源数据不同的安全上下文中，以防止攻击者也影响您的备份。
重要的是要了解您的安全策略需要反映在您的备份策略中，否则您可能会在备份数据时无意中暴露敏感信息。例如，如果您的生产系统围绕个人身份信息 (PII) 实施安全措施，则您的备份结构应保持该安全级别。这可能意味着对不同类型的数据使用单独的加密或对不同类型的数据使用单独的备份位置。您的具体情况将决定您需要在备份策略中加入哪些类型的保护。
在某些情况下，敏感数据在收集后很长时间内就没有价值了，考虑不备份这些数据是值得的。系统收集或生成的某些类型的数据目前可能有用，但如果长期存储，可能会增加风险。如果您从数据中获得的价值与其新近度密切相关，则最好将其从备份集中排除。
在设计备份策略时，您必须做出的一项决定是您希望存储实际备份数据的位置。许多不同的因素可能会影响哪种类型的备份目的地最适合您。
在许多情况下，选择备份目的地是在易于访问、成本、安全性和便利性之间取得平衡。拥有现场备份可以实现快速备份，但管理物理磁盘可能比您愿意管理的要多。此外，现场备份无法防范火灾、洪水或盗窃等特定地点的灾难。另一方面，基于云的备份可能很方便，但可能会将您绑定到特定的提供商，成本更高，并且可能需要更长的时间才能恢复。
大多数时候，最好使用多个存储位置和介质来帮助平衡风险和收益，并获得额外的保护以防止数据丢失。例如，您可以使用对象存储提供商（如 Amazon S3）作为主要备份轮换的目标。每个月左右，您可能会将其中一些备份移动到 Amazon S3 Glacier 等存档存储中以进行更长时间的存储。您可能还希望将数据备份到不同于您用于生产基础设施的提供商。
既然我们已经涵盖了强大备份策略的许多组成部分，我们可以看看您可能希望考虑的一些一般性建议。
您首先要弄清楚的事情之一是执行备份的频率以及哪种组合备份类型最有帮助。为此，您需要建立备份循环，以便您可以根据需要经常进行备份，而不会使用不必要的存储量。
备份轮换基本上是一个时间表，用于确定在什么时间间隔进行什么类型的备份。通常，组织实施轮换，以便他们可以拥有许多最近的备份，同时仍然保留大量有用的历史备份作为存档。通常根据备份机制的性能影响、需要进行的备份类型、备份存储容量和成本来创建计划。
作为一个相当传统的备份策略的示例，您可以从每周对数据库进行一次完整备份开始。在一周的其他几天，您可以安排增量备份，以便可以恢复到任何特定的一天。您可能希望随时保留两个完整备份以及所有中间增量备份。您也可以连续归档每日 WAL 数据，以便您可以恢复到当天的任何特定时间点。
当发生新备份时，最旧的备份可能会被删除或偶尔转移到长期存储中。这使您可以在需要时访问历史数据，但存档不会保留在您的正常备份轮换中。像这样的系统可以帮助您提供恢复选项，同时最大限度地减少总存储量随时间的增加。
一旦决定备份轮换，重要的是尽可能多地安排和自动化该过程。确保在没有监督的情况下进行备份是保护数据的重要部分。
大多数备份机制都包含调度组件，因此在大多数情况下不需要特别的努力。但是，重要的是要确保您有适当的机制在计划的备份未发生时提醒您。这可能是备份失败时的电子邮件警报，或者是对您的组织监控的聊天频道的 ping。
自动化备份过程可能还需要您考虑如何最好地实现您的安全要求和访问要求。备份目标从您的生产系统中提取数据的基于拉取的备份系统是否有意义？备份过程需要对您的系统进行哪种类型的访问？您可以删除哪些权限以限制备份帐户的范围和影响？这些是您在实施备份系统时需要问自己的问题类型，尤其是在自动化流程时。
健壮的备份系统最重要且经常被忽视的活动之一是测试。您需要定期测试您的备份文件是否可用于成功恢复数据。如果您不能保证您的备份有效，则整个过程的价值有限或毫无价值。
测试备份涉及将备份数据应用到干净的系统或具有部分或不同数据的系统。重要的是要知道您可以在这些情况下进行恢复，以及您需要执行恢复的确切过程。这不仅可以验证备份存档的完整性，还可以确保您的组织知道在高压力情况下必须执行哪些步骤来恢复系统。它还为您提供有关不同类型的数据恢复可能需要多长时间的宝贵数据。
备份可能会不时手动测试，但理想情况下，恢复过程应该是您为其余备份实施的自动化的一部分。可以将备份恢复到测试环境，并且可以运行测试套件以确保数据具有您期望的值和结构。如果您进行自动化备份测试，请不要忘记在恢复失败时设置警报。
在本指南中，我们介绍了为什么数据库备份如此重要，并介绍了在实施它们时需要考虑的一些事项。我们讨论了备份的优势、备份的不同类型和范围、在线备份和离线备份之间的区别、为什么复制不是备份策略等等。
熟悉您作为一个组织有哪些选择以及不同的决策如何影响您的性能、安全性和可用性至关重要。虽然每个项目的备份需求都不同，但在需要持久、可信的长期存储以帮助从数据问题中恢复方面存在共同点。花时间整理您的要求并制定一个全面的计划将使您能够安全自信地前进，减少危险。
原文作者：Justin Ellingwood
原文标题: Introduction to database backup considerations
原文链接：https://www.prisma.io/dataguide/managing-databases/backup-considerations
