Backing up all of your hard work....

[tcweb]

I am fairly new to Zabbix. Loving it. But after spending days setting up templates, items, dashboards....I realize that it would be a lot of work to re-create everything.

My first (and only) step so far has been to setup a cron job that will do a mysqldump to disk, and keep 7 days online.
What are people doing to backup dashboards, templates, etc? I've done template exports/imports, just to play around, but is this something I should be doing regularly? Can it somehow be scheduled, or at least executed from the zabbix server, so I can automate?

Also Dashboards....I'm reading that there does not appear to be an easy way to re-create dashboards. Maybe some information can be saved via API? (which I've barely even thought about learning yet...)

Any tips or suggestions? Any good posts or resources that may help those of us who are still coming up to speed?

Instead of worrying about re-creating various zabbix components, would my time be better spend figuring out how to setup mysql replication to a "DR" instance,?

Lots of questions, I realize. I'll keep researching, but any suggestions would be welcomed.

Thanks,

-Tom

[cyber]

Create the following bash script on your Zabbix server and run it:

#!/bin/bash
# Backup Zabbix

sudo mkdir /opt/zbx-backup/
sudo mkdir /opt/zbx-backup/database/
sudo mkdir /opt/zbx-backup/zbx-config/
sudo mkdir /opt/zbx-backup/nginx/
sudo mkdir /opt/zbx-backup/lib/
sudo mkdir /opt/zbx-backup/shared/
sudo mkdir /opt/zbx-backup/shared/zabbix/
sudo mkdir /opt/zbx-backup/shared/doc/

sudo cp -r /etc/zabbix/ /opt/zbx-backup/zbx-config/
sudo cp /etc/hosts /opt/zbx-backup/

sudo cp -r /etc/nginx/ /opt/zbx-backup/nginx/ # Front end only

# Zabbix PHP files and binaries
sudo cp -r /usr/share/zabbix/ /opt/zbx-backup/shared/zabbix/ # Front end only
sudo cp -r /usr/share/doc/zabbix-* /opt/zbx-backup/shared/doc/ # Front end only

sudo cp -r /usr/lib/zabbix/ /opt/zbx-backup/lib/

This will copy the config files to another folder. It's obviously a quick and dirty and cheap thing to do, and not bullet-proof.
You can run the same script on each proxy, just omit the lines marked # Front end only

none of it backups db contents... Most of it is just files that could be deployed by just reinstalling packages. Only useful part is config ie stuff from /etc/.
EDIT: and keeping backup in same host is anyway risky business...

DB is most important part of Zabbix, so back it up, whatever way you are able to. dumps, DR instance etc.. which way to go depends on your allowed recovery times and allowed data loss etc,
Also keep your config somewhere like git and create somekind of automated deploy for it (ansible and other tools...). It enables you to restore whole system with shorter time... Deploy hosts, install packages, run config install, run the system.

[tcweb]

Thank you both for your answers. Cyber, when you say "keep your config somewhere", what config specifically are you referring to? Just /etc/zabbix/*.*? Assuming we haven't made any UI customizations by modifying PHP, I would assume there's not much value in backing up the zabbix front-end? (Donkey: I can see value in doing that, if you have made significant customizations, like re-branding, etc)

I may consider backing up the UI/modules, I suppose. (I added HeaderMax...super useful)

Anyone have any experience with mysql replication? I may be going down that path...

Thanks for entertaining the discussion...

-Tom

[cyber]

Config like zabbix_server.conf and whatever files there are for UI, nginx or apache configs, DB config, anything that has non-default values. You can create for example an ansible playbook(s) which generates your server config file(s) from template(s), where you can tune count of started processes with inventory vars etc..
you can go as far as create autoamted pipelines to run those playbooks, when you do some config change and push your changes to git. So you get config as a code...

[cyber]

Even a VM snapshot is a thing..