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