Move Zabbix to another server

[snakefox]

Hi.

I need to move Zabbix to another server, due to company policy. The way I understand it, I have to follow this plan:

1. Create a backup of all sql databases on my current Zabbix server.
2. Export those backups to my new server.
3. Install sql on the new server from scratch.
4. Install zabbix on the new server from scratch.
5. Upload the backup to the sql on the new server.

I have several questions:

1. Is the plan above correct?
2. Will all elements be transferred this way? Including users, notfication setups, etc.
3. Do the newly installed sql db and zabbix need to be the same version?

I currently use CentOS8, MariaDB 10.6.8 and Zabbix 6.0.5

[MRedbourne]

Technically, yes, it'll be fine. Be mindful of a few things though.

1. CentOS 8 is EOL and has been for over 3 years. The packages in CentOS 8 are also end of life.
2. Zabbix Server 6.0.5 is severely out of date (almost 3 years as well).

In light of this, I would recommend a couple things.

1. Patch the entire server. Zabbix (all components), Database (and ZBX Schema) and OS to the latest levels.
2. CREATE A VM BACKUP
3. Elevate from C8 Stream -> EL9 (Alma, Rocky, CentOS) > AlmaLinux OS - Forever-Free Enterprise-Grade Operating System
4. Follow your outlined plan above (create DB backup, import to new server, install latest version 6.0.39 of Zabbix.)

To answer your questions directly

1. Is the plan above correct?
   1. Yes, mostly.
2. Will all elements be transferred this way? Including users, notfication setups, etc.
   1. Yes. Information, Notifications, Users, etc are stored in the DB.
3. Do the newly installed sql db and zabbix need to be the same version?
   1. It's highly recommended. I've done this one before and had a hell of a time getting it to work.

[LukeAB93UK]

Technically, yes, it'll be fine. Be mindful of a few things though.

1. CentOS 8 is EOL and has been for over 3 years. The packages in CentOS 8 are also end of life.
2. Zabbix Server 6.0.5 is severely out of date (almost 3 years as well).

In light of this, I would recommend a couple things.

1. Patch the entire server. Zabbix (all components), Database (and ZBX Schema) and OS to the latest levels.
2. CREATE A VM BACKUP
3. Elevate from C8 Stream -> EL9 (Alma, Rocky, CentOS) > AlmaLinux OS - Forever-Free Enterprise-Grade Operating System
4. Follow your outlined plan above (create DB backup, import to new server, install latest version 6.0.39 of Zabbix.)

To answer your questions directly

1. Is the plan above correct?
   1. Yes, mostly.
2. Will all elements be transferred this way? Including users, notfication setups, etc.
   1. Yes. Information, Notifications, Users, etc are stored in the DB.
3. Do the newly installed sql db and zabbix need to be the same version?
   1. It's highly recommended. I've done this one before and had a hell of a time getting it to work.

I agree with this. Update to the latest supported version and ditch Centos 8. I migrated 12 or so Centos VMs using the Elevate guide from AlmaLinux and even moved over my live Zabbix Proxies and my Zabbix Test environment to AlmaLinux that way (Live is running on RedHat).

Once that has done follow this advice posted above and you should be good.

[snakefox]

Thanks for the answers!

Updating the OS is one of the reasons why I must move Zabbix to the new server, yes. Unfortunately, there is no way to elevate CentOS to what I need (Astra Linux). At the moment I plan to try and install zabbix 6.0.5 version on my new server, restore my backup and try to update zabbix to newer versions after that (and hope that the difference in OS won't interfere with it). Is this a worse plan than trying to elevate to Alma linux in my case?

[MRedbourne]

Thanks for the answers!

Updating the OS is one of the reasons why I must move Zabbix to the new server, yes. Unfortunately, there is no way to elevate CentOS to what I need (Astra Linux). At the moment I plan to try and install zabbix 6.0.5 version on my new server, restore my backup and try to update zabbix to newer versions after that (and hope that the difference in OS won't interfere with it). Is this a worse plan than trying to elevate to Alma linux in my case?

Are you Russian? Astra is a very uncommon OS outside the Russian Federation or perhaps close allies like Belarus. If you're not Russian, I'd recommend - heavily - that you stick with a western operating system. If you're Russian or intend to continue using Astra, just know that Astrea doesn't have documented support from Zabbix. You're way outside the wheelhouse of support here. If you need to use Astra, then your plan outside in #4 is probably fine. I have no idea how Zabbix and Astra will interact though.

[Anahronist]

MB can share my experience of moving Zabbix server to another location with timescaledb enabled as an update to the first post of the thread (Ubuntu 22.04, Postgres 16, timescaledb 2.15.3 on original server) .
Plane above but:

1. Patch the entire server. Zabbix (all components), Database (and ZBX Schema) and OS to the latest level
2. CREATE A VM BACKUP
3. Configure (if u have) all zabbix proxies to adjust timeout and buffer for local metrics storage during the database migration. This is especially true if u are using Active Proxy (where only 1 server connection can be configured at a time)
4. Install on new server latest compatible versions of zabbix packages and configure it (all in stopped state), the same major db version, timescale libs
5. CREATE NEW VM SHAPSHOT
6. Stop the original zabbix server + web server
7. Create backup to according to the timescale docs
8. Move the backup to the new server
9. Create in db zabbix user and clean zabbix db
10. Add the timescale extension of the same version to new db (for safety, I believe it is necessary to update the extensions and software version separately from the migration process).
11. Restore the database backup according to the timescale documentation.
12. Start and enable the Zabbix stack (server/agent/php, etc.).
13. Check the new Zabbix server address for the initial PHP configuration (this will create the correct PHP configuration for Zabbix).
14. Reconfigure agents/proxies to the new server.
15. PROFIT