几周前，我们与 Acronis 和 CPanel 共同举办了一场网络研讨会，主题是安全和备份最佳实践，因为这两个公司都在此领域提供软件。Acronis 开发基于云的网络安全软件，特别专注于为其他服务提供商提供备份和灾难恢复。CPanel 则帮助这些服务提供商通过一个功能齐全的仪表板为其客户提供系统管理能力。该网络研讨会是在 CloudFest 上的另一次联合演示的后续活动。网络研讨会提出了许多好想法，我强烈推荐大家观看。再说，网络研讨会总是受时间限制，所以我们未能涵盖我希望涵盖的所有内容。因此，在这篇博文中，我将介绍一些由于时间限制而未讨论的方面，特别是与 MariaDB 相关的方面。
数据备份是一个非常重要但经常被忽视的话题，尤其是在数据库方面。为什么数据备份如此重要？正如 Acronis 的 Jeff Hardy 在网络研讨会中以及在我们 MariaDB Server 安全小型峰会上的“网络保护经济模型”中所说，数据在 IT 行业相当于黄金。这意味着数据丢失可能严重损害公司。再说，并非所有数据都具有同等价值。有些数据更重要。例如，丢失气象站的一些传感器数据的影响远小于丢失客户交易的影响。这种思考方式应指导您考虑备份需求，也是我们在此列表中讨论第一项内容的原因。
考虑您的场景
在开始实施备份系统之前，请先了解系统的需求。您是在维护一个简单的 WordPress 网站，该网站几天或几周才进行一次编辑吗？这是一个日订单量在 100-200 的、人气不错的在线商店吗？或者您可能在运行一个拥有数千并发用户的在线游戏平台，需要记录所有用户的行为。根据您所处的场景，您应该相应地进行规划。
对于我们的 WordPress 示例，可能足以安排每周每晚进行一次备份，并保留每两周或每月一次的快照。备份 WordPress 网站相关的成本通常很低，因为大多数时候数据库本身相当小。
当我们看在线商店的场景时，事情变得有点复杂。如果只进行夜间备份，我们将无法涵盖当天的订单。丢失这些订单可能会代价高昂。此时，根据业务量，我们应该开始考虑在工作日发生中断时如何减轻影响。
然而，当我们看游戏平台场景时，我们开始遇到真正棘手的情况。通常热门服务与停机时间相关的成本很高。尽管高可用性是一个正交主题，我希望将来能涵盖，但高可用性（HA）、备份和灾难恢复是相辅相成的。对于这样的系统，备份是强制性的，但这还不够。快速恢复很重要，这只能通过让多台机器并行运行并随时准备接管来实现。
如您所见，根据具体情况，您的备份策略需要规划。每种备份方法都有与之相关的成本，包括时间、金钱和应用影响（停机时间）。
考虑备份的影响
进行数据库备份不像复制数据目录那么简单。在一个活跃的系统上，数据库系统会几乎持续地对数据目录进行读写。从备份的角度来看，读取操作问题不大，但写入操作则不然。在不加锁以确保一致性的情况下进行复制意味着您的备份将不可用，因为它可能包含过期和当前数据，具体取决于文件哪部分首先被复制。因此，我们得出结论，某种形式的写锁是必要的。这正是我们主要讨论点出现的地方
在备份过程中，数据库将不可用于写入，并且由于硬件忙于复制数据，读取性能也可能变差。这对您的用例是否可接受是一个需要考虑的问题。通常，备份在流量较低的时段（例如夜间）执行，以最大程度地减少影响。创建备份影响的最大因素取决于备份方法本身，这也是我们接下来需要考察的内容。
逻辑备份 vs 物理备份
现在我们已经评估了系统和需求，需要考虑可用于备份的工具。MariaDB 提供了两个专用工具。它们是：mariadb-dump 和 mariadb-backup，虽然最终结果（创建备份）相似，但它们之间的区别在于备份的创建和存储方式，这导致了截然不同的优缺点。
逻辑备份（简单但慢）
mariadb-dump 会有效地生成一个包含 SQL 命令的文本文件。其中一些命令的形式是 CREATE TABLE ...，而另一些则是 INSERT 语句、CREATE USER 语句等。通过运行这些命令，可以重新创建完整的 MariaDB 数据库内容。数据以逻辑方式存储在文本文件中，而不是数据库使用的物理表示形式。
这种方法的优点是运行非常简单，并且生成的 SQL 在数据库系统之间具有很好的可移植性。这意味着这种备份格式（尽管需要一些工作）可以与其他数据库系统互换使用。检查文本文件并理解备份内容也相当容易。
这种方法的缺点是生成的转储文件会相当大。文本文件中不会存储数据的二进制表示，因此整个文件会更大。更大的备份创建时间更长，恢复时间也更长（可能需要成倍的时间）。此外，在备份过程中，除非使用 --single-transaction 作为命令标志之一，否则整个系统将不可用于写入，因为所有表都将在 FLUSH TABLES WITH READ LOCK 状态下。
物理备份（快但复杂）
mariadb-backup 是 mariadb-dump 在进行物理备份方面的等价工具。这意味着备份将包含存储引擎（很可能是 InnoDB 和 Aria）在磁盘上存储的实际字节。
通过进行物理备份，mariadb-backup 相对于 mariadb-dump 具有某些优势。首先，备份创建过程中速度显著提升，因为系统只需复制数据块，而无需在写入磁盘之前将其转换为 SQL 语句。该工具还会考虑数据库系统当前运行的事务，并仅在所需的最短时间内锁定表。此外，该工具能够执行增量备份，这在数据快速变化且关注备份大小时是一个非常有用的功能。
这种备份过程的缺点是备份不容易验证，因为没有简单的文本文件可供检查。此外，基于表的备份实现起来更复杂，需要更繁琐的过程。欲了解更多详情，您可以查阅 InnoDB 的知识库文章。
尽管如此，尽管 mariadb-backup 需要更繁琐的过程，但由于其速度和备份过程提供的额外功能，它仍是 MariaDB 推荐的备份过程。
测试您的备份
不言而喻，备份的目的是在发生故障时使用。然而，经常被忽视的是实际测试恢复是否可行。这意味着如果您无法恢复备份，您实际上就没有备份！因此，经常测试恢复过程以确保确实没有问题非常重要。因此，我强烈建议经常进行灾难恢复模拟，例如每 3-6 个月进行一次。
结论
如您所见，备份并不是一个简单的话题。它有很多细微之处和许多可能的解决方案。在网络研讨会中，与 Acronis 深入讨论了这一主题，我们可以看到没有一种方案适用于所有情况。此外，所需的自动化工作量不小。这就是为什么我印象深刻地看到 Acronis 与 CPanel 一起将这些最佳实践的大部分作为托管服务提供商可通过 Web 界面使用的选项或调整项实现出来。在那里，可以直接通过界面安排备份、执行完整甚至部分恢复（精确到表级别）。这有效地抽象掉了繁琐的细节，同时隐含地遵循了此处概述的最佳实践。
我期待与 Acronis 和 CPanel 就如何设置和管理数据库服务器进行更多讨论。我相信从中获得的见解将有助于为 MariaDB 带来更好的备份功能。如果您对 MariaDB 有功能请求，请记住您随时可以在我们的 JIRA 跟踪器中提交任务。