Hi all,
I know that backup zabbix is as easy as backup database
but I think db should be divided into config data and history data. I am trying to open discussion here about standard backup mechanisms. It is not so easy even due locking of database during backup (some backup tools like mysqldump are doing this by default). During backup, zabbix cannot modify history. And only zabbix maintainers know, which tables are interesting and which are only "states" so we do not need to backup them.
Would be nice to integrate backup into web frontend. It is not so hard to call this eg. by lynx and make regular backups.
Backup should have parameters:
- to backup history or not
- time range for history backup
- to backup config or not (if we want only history)
- format of backup (best is probably directly SQL code)
With regards,
Lukas
I know that backup zabbix is as easy as backup database
but I think db should be divided into config data and history data. I am trying to open discussion here about standard backup mechanisms. It is not so easy even due locking of database during backup (some backup tools like mysqldump are doing this by default). During backup, zabbix cannot modify history. And only zabbix maintainers know, which tables are interesting and which are only "states" so we do not need to backup them.Would be nice to integrate backup into web frontend. It is not so hard to call this eg. by lynx and make regular backups.
Backup should have parameters:
- to backup history or not
- time range for history backup
- to backup config or not (if we want only history)
- format of backup (best is probably directly SQL code)
With regards,
Lukas
Isn't it better to load config data first and than load history and trends ? Is there any scenario where this can brake some triggers or do something wrong ? Or another way, load config first, then some amount of recent history and trends, then rest.

Comment