OSSのサーバー監視ツール Zabbix はMySQL（やPostgreSQLなど）にデータを保存するのでDBのダンプ（とzabbix_server.conf）を取得しておけば概ねのバックアップが可能ですが、ログデータ（ヒストリ、トレンド）が巨大なデータになりがちです。おそらくログ系のテーブル以外をバックアップする事でコンパクトなバックアップにする事が出来る物と思われます。
ただ、Zabbix公式のドキュメントにはデータベースの中身の構造についての内容が見当たりません。
Database Schemas – Zabbix.org
https://www.zabbix.org/wiki/Database_Schemas
真偽不明な情報としては上記がZabbix 2.4のER図になります。これを参考にZabbix 3.0.10をインストールした状態のDBと見比べてみると、いくつかのテーブルで追加カラムが有る他、以下のテーブルが増えています。
- application_discovery
- application_prototype
- item_application_prototype
- opinventory
- screen_user
- screen_usrgrp
- slideshow_user
- slideshow_usrgrp
- sysmap_user
- sysmap_usrgrp
結構な数のテーブルが増えていますが、いずれも設定系のテーブルであり、ログ系のテーブルではないものと思われます。つまり以下のようなmysqldumpコマンドを投げれば設定のみをバックアップする事が出来る物と思われます。
mysqldump -u [ユーザー名] -p –single-transaction –hex-blob \
–ignore-table=[DB名].alerts \
–ignore-table=[DB名].history \
–ignore-table=[DB名].history_uint \
–ignore-table=[DB名].history_str \
–ignore-table=[DB名].history_text \
–ignore-table=[DB名].history_log \
–ignore-table=[DB名].trends_uint \
–ignore-table=[DB名].trends \
–ignore-table=[DB名].auditlog \
–ignore-table=[DB名].auditlog_details \
–ignore-table=[DB名].events [DB名] | gzip > [ファイル名].gz
バイナリデータ（中身は画像）を含んだテーブルが有るので –hex-blob を付けておいてください。また、ファイル名は取得時刻が秒単位で分かるようにしておいた方がいいでしょう（後述）。
例: zabbix_configuration_only_backup_20170817_151515.sql.gz
復旧時の注意点
上記コマンドで取得したダンプデータですが、まっさらなZabbixに設定を投入するなら良いのですが、例えばZabbix画面上で設定変更を色々と行い、元に戻したいといった用途に使用しようとすると、ログに残ったアイテムIDなどでつじつまが合わなくなってくる可能性が有ります。安全を期すためには「itemid」カラムのあるテーブルに注意する必要が有ります。
データが欠けても良いのであれば、バックアップを取った時点以降のログデータを吹き飛ばすのが一番簡単だと思います。clockカラムにUNIXタイムの形式で日付が入っているので、それ以降のデータを飛ばします。
DELETE FROM alerts WHERE clock >= [UNIX時間];
DELETE FROM events WHERE clock >= [UNIX時間];
DELETE FROM history WHERE clock >= [UNIX時間];
DELETE FROM history_uint WHERE clock >= [UNIX時間];
DELETE FROM history_str WHERE clock >= [UNIX時間];
DELETE FROM history_text WHERE clock >= [UNIX時間];
DELETE FROM history_log WHERE clock >= [UNIX時間];
DELETE FROM trends_uint WHERE clock >= [UNIX時間];
DELETE FROM trends WHERE clock >= [UNIX時間];
DELETE audit_d FROM auditlog_details AS audit_d
LEFT JOIN auditlog USING(auditid)
WHERE auditlog.clock >= [UNIX時間];
DELETE FROM auditlog WHERE clock >= [UNIX時間]
auditlog_detailsはauditlogに関連しており、単体ではclockカラムを持っていないのでdetailsの方を先にDELETEする必要が有ります。これらDELETE分をzabbix-serverが停止した状態で実行し、その後バックアップのダンプデータをDBに流し込みます。
最後に
あくまでDBのテーブルのカラム名などから推測してバックアップをしているので、この方法には何かしら不具合が含まれる可能性が有ります。非公式なバックアップ方法なので、自己責任でのご利用の程お願いします。
また、あくまでZabbix 3.0.10時点でのテーブル内容を参考にしているので、3.2等ではそのまま動かない事も有るかと思います。
なお、Zabbixの有償サポートに入っているユーザーであれば、公式で（おそらくより高機能な）設定のみのバックアップと復元が可能なようです。整合性をチェックをするような記載も有るので、この方法のようにデータを飛ばす必要も無いのかもしれません。ミッションクリティカルな用途で使うなら、サポートの有るツールを使った方がいいでしょう。
Zabbix設定バックアップツール | Zabbix Enterprise
http://enterprise.zabbix.co.jp/solutions/3661
2017年10月16日追記
PHPで動くCLIインタフェースの様な物を作りました。
https://github.com/lf-uraku-yuki/zabbix_db_config_backup