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