Zabbix灾难备份多种方式分享（建议收藏）

感谢本文译者田川 ! 欢迎更多资深用户翻译原厂博文（https://blog.zabbix.com/）！

►对于 Zabbix，有几种不同的备份方法，而一切都是从数据库级别开始的，因为 Zabbix 前端和 Zabbix 服务器都将其数据写入 Zabbix 数据库中，如下图所示：

►这意味着我们的配置以及收集的所有监控数据都保存在同一个 Zabbix 数据库中，如果进行数据库备份，将备份几乎所有需要的内容。因此，就让我们从这里开始，看看如何进行数据库备份。

►让我们从 Zabbix 数据库最常用的版本开始：MySQL 和它的分支，如 MariaDB 和 Percona。所有这些版本都可以使用内置功能（如 MySQL dump 命令）轻松备份，当然我们也可以使用其它商业解决方案进行备份。

►首先，我们必须了解数据库中的表。Zabbix 环境中的大多数表都包含配置数据，因此，它们对备份都很重要。不过，我们需要重点关注几个表，因为它们可能包含 GB 甚至 TB 的数据量。主要是下表所列的历史、趋势和事件表：

►可以考虑从备份中省略这些表，从而进行更小、更易于管理的备份。

►为了进行备份，我们可以使用 MySQL dump 等工具：

►备份完成后，我们可以使用 MySQL import 命令或简单地使用 cat 命令轻松地将其导回到原环境中：

►备份和恢复大量数据时可能需要很长时间。这完全取决于 MySQL 数据库性能调整设置以及 CPU、内存和磁盘 I/O 等底层资源。请确保查看 MySQL 文档以获取最新产品信息：

MySQL Dump:  https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html / https://mariadb.com/kb/en/making-backups-with-mysqldump/MySQL Import: https://dev.mysql.com/doc/refman/8.0/en/mysqlimport.html / https://mariadb.com/kb/en/mysqlimport/

►也可以使用 xtrabackup 和 mariadbackup 等工具创建备份。

►我们实际上可以对 PostgreSQL 备份使用和 MySQL 类似的方法。记住所需的表，并使用内置工具进行：

►然后我们可以通过将文件加载进 postgres 来恢复：

►一旦我们有了数据库备份，一切就都被备份了吗？差不多吧。只有一个数据库备份，我们的业务基本算是安全的，但（这经常被忽略）Zabbix 环境里还有很多配置文件，甚至可能需要考虑自定义脚本！这方面分为三部分 —— Zabbix 服务器、Zabbix 前端，以及 Zabbix 附加组件。它们都有自己的一组配置文件和位置（用于存储自定义脚本）。

►Zabbix 前端位置和配置文件可能会有所不同，这取决于具体安装方式，因为我们有一些不同的安装方式选择。比如运行的是 Apache 还是 Nginx？运行在什么 Linux 发行版上？在进行配置备份时，必须考虑所有这些因素。通常，配置文件所在的位置如下：

/etc/nginx/
/etc/httpd/
/etc/apache2

►还有一个指向 Zabbix 前端配置文件的符号链接，该文件位于 /etc/zabbix/ 中，我们稍后再介绍该文件。

►然后是 Zabbix 服务器本身，它把配置文件保存在 /etc/zabbix/ 中，如果我们遵循最佳实践，任何脚本都应该放在 /usr/lib/zabbix 中。所以，我们还需要备份以下目录：

/etc/zabbix/
/usr/lib/zabbix

►让我们将它们添加到列表中，并找到备份这些文件的方法。crontab 是我们可以使用的内置工具，但肯定还有其它（也许更好）的解决方案。

►让我们将以下内容添加到 cron 中：

►在这里还添加了一个 find 命令，它将查找超过180天的文件，并将其从 /mnt/backup/config_files/ 中删除。确保选择一个好的（也可以是网络共享）位置来保存这些文件，因为保证这些文件的安全很重要。当然我们也可以根据需要更改保存这些文件的天数。

►Zabbix 代理、Zabbix Java 网关和 Zabbix web service（用于 PDF 报告）等其它组件呢？。它们也有配置文件。确保在运行这些附加组件的主机设备上运行备份。

►对于 Zabbix 代理，它们的配置文件位置与 Zabbix 服务器的相同：

►对于 Zabbix Java 网关和 Zabbix web service，我们可以省略 /usr/lib/zabbix/ 文件夹。

►一般来说，数据库备份很慢，恢复也很慢，除非我们不备份 history/trends 表中的数据。然而即便如此，仅仅因为某人在单个模板上配置出错而恢复整个数据库也是一件麻烦事。Zabbix 自带内置的前端导出功能，允许我们立即导出（然后导入）整个前端配置。我们也可以单独备份以下这些前端配置中的一部分：

• Hosts
• Templates
• Media types
• Maps
• images
• Host groups (只能通过 API 实现)
• Template groups (只能通过 API 实现)

►所有这些前端配置都可以通过 Zabbix API 获得，从而允许我们选择是在前端页面进行手动备份，还是使用 API 实现自动化操作。如果编写了相关脚本，我们甚至可以完全通过 git 来管理和更新 Zabbix 配置。

►要从前端页面导出配置，只需要跳转到受支持的页面（比如配置 -> 模板），然后选择导出数据格式。如果选择了多个配置时，请注意它们都将被导出并保存到同一个文件中。

►然后，我们可以编辑这些文件并从前端页面重新导入：

►对于模板，会弹出一个漂亮的差异比较窗口，详细说明模板的所有更改、删除和新增内容：

►对于 API，由于我们需要从多种方式中选择其中的一种来执行，事情会变得更加复杂。当然，可以从 CLI 执行 curl 命令，甚至可以使用 Postman：

►请求正文

►响应将如下所示

►不过一旦我们将其与自动化脚本相结合，这个特性就真正开始发挥威力。请妥当地使用它！

►高可用呢？它是不是某种形式的备份？

►是，也不是。高可用不是确保我们可以用来恢复被损坏的东西的“IT 备份”。但它是另一种形式的备份，即如果 Zabbix 服务器的一个实例发生故障，另一个实例将接管代替它。HA 在本文中有些超出范围，但仍值得一提。有几种解决方案可以将 Zabbix 设置为一个完整的高可用集群。对于 MySQL 我们可以使用 Primary/Primary 设置，对于前端我们可以使用 HAProxy 等负载平衡技术，对于 Zabbix 服务器，我们可以使用内置的高可用方法。将所有这些结合在一起，一定能够满足每一个生产环境的需求。

►总之，有许多方式可以备份 Zabbix 环境。这一切都是从数据库开始的，这些备份对于在发生灾难时确保安全至关重要。进行备份时，不要忘记配置文件和自定义脚本以及前端的备份。结合所有这些解决方案将保护我们的 Zabbix 监控环境，如果这些还不够，请不要忘记快照等方案。甚至可以在多个层面上综合使用以进一步保护我们 Zabbix 监控环境。