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