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