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