Backup script built in

[louis-m]

I would like to see a backup script built in Zabbix. I know there are scripts out there but the creators of these scripts have to keep pace with the development of Zabbix eg schema changes etc.
The ideal place for the backup script would sit with the Zabbix developers as every upgrade to Zabbix would have the change done to the backup script rather than having to wait or manually change the script yourself.
It's a fairly important thing because if people are using Zabbix and they get an issue and can't restore, there's a good chance that they will move onto another product to not get bitten again.
And that would be a shame because Zabbix is an excellent product....

[kloczek]

Why do you want to backup DB schema?

IMO between major releases zabbix upgrade usually is enough well tested to 100% rely on what is doing zabbix server/proxy. Only occasionally in minor releases introduces some small adjustments of the DB schema. Everything is done to not bother joe-zabbix-admin on this area because zabbix is now used in so many paces that if this part of the upgrade would be not enough rock solid this would be real disaster not only for zabbix end users but for zabbix support and Zabbix as the company.

[louis-m]

Hi,
I mentioned schema as an example but really meant the database (with/without history) and maybe the zabbix.conf and my.cnf etc

At the moment, I'm using a script supplied on here but everytime you upgrade zabbix, you have to check the script to ensure you are getting all the tables backed up as the upgrade may have added more tables etc

I don't think it would be hard for the dev's to build in a small script with the options of where to store the backup etc and if they do make changes, they could change the script to ensure it's doing a complete backup.

I just think it would make the product more complete rather than using having to play about with 3rd party scripts.

[kloczek]

There is nothing special in zabbix database or in way how zabbix processes are using DB backend which would not allow you all possible and well known techniques of making SQL engine database content backups.
Content of the zabbix.conf has nothing to to with DB content.

[louis-m]

I'm aware of all of that. I just think it would be a nice addition to Zabbix to be able to do this via the GUI. eg cron job - weekly, backup - db config only/full backup & relevant files eg zabbixserver.conf, backup location
As mentioned, I already back up the db and certain config files which will allow me to recover.
However, on each upgrade to Zabbix, I have to check the tables to make sure there is no extra table added as well as the initial setup of the script.
It would have been so much easier if this had been built in from the start.

[rezwan]

yes i am also agree with built in backup script .it would be very helpful indeed.

[kloczek]

Generally speaking prepare such backup script is not possible in case DB content.
Why?
Local conditions/possibilities will be always highly affecting way how such backup could be done.
For example if DB will be remote, will be enough large only available technique of doing backup will be lock DB content -> flush all not written data -> snapshot db content and do only full binary backup. Snapshoting could not be dine if DB content will be not deployed on btrfs or zfs or other FS but on block device placed on top of the LVM device.
If database will be even larger typically backup cannot be done even using above approach but to the DB backend needs to be added slave database and whole locking, flushing and snapshoting because replication of the btrfs or volume on LVM will kill already cached data in memory affecting overall performance of the database.
In most of the cases giving permission to the zabbix user on the host where is running zabbix server would be not possible/wise from security point of view because it may mean give full root access to some remote systems.

So .. again: such "backup script" is not possible to add not because someone is rude or do not want to support such feature but because it is not possible to generalize it.

[bbrendon]

I can bet this will never get implemented. There are too many ways to do backups depending on the environment.

Simple backup methods don't work because of the amount of data involved which leads to my first point.

[kloczek]

Amount of data has nothing to do w backup.
For example if database is deployed on ZFS volume all what you need to do is:
- flush all not written data to the storage
- lock database for write
- flush all not written data to the storage
- backup current binary position to the file
- create zfs snapshot
- unlock database

Above without first flush may take less than second. Doesn't matter if database has few gigs or hundreds terabytes.
After above you can start "zfs send" to replicate all data to another host or to create file out of those data generated by "zfs send".
Most important in above technique is on reading all data using "zfs send" none of the in memory caches like page cache or ZFS ARC (Adaptive Reclaim Cache) will be affected by reading those data from the storage.

Written to the file current binary position to the root snapshoted volume before making snapshot allows for example rebuild slave database out of such snapshot.

[slartibartfast]

I see that you are all focused on database backup.

What about all templates, hosts and correlations between them, what about scripts on Zabbix server.

Saying to change underlying file system to mask Zabbix backup issues when huge data is stored in db's is ... not good.

[kloczek]

They are all in database and you have simple explanation why I'm focused on database.

External scripts are outside DB, and some additional script which you can add to some menus in web frontend, and because of this everyone are trying to avoid use those scripts