Коротко — у вас есть два приемлемых пути, в зависимости от того, что именно нужно сохранить (только конфигурацию или ещё и исторические данные) и от того, можно ли делать апгрейд «на месте» на текущем инстансе:
1) Рекомендуемый (самый простой и надёжный) — последовательный in‑place апгрейд текущего инстанса Zabbix
- Официальный путь: 5.0 → 6.x → 7.0 (по мажорным версиям). При каждом шаге обновляете пакеты (server, web, agent) и запускаете сервер — он выполнит обновление схемы БД автоматически.
- Плюсы: сохраняется вся конфигурация и вся историческая информация, не нужен дополнительный инстанс и не надо делать дамп/реимпорт.
- Минусы/внимание: обязательно делать бэкап БД (если дамп невозможен — хотя бы сделать снапшот или резервную копию файлов), тестировать на стенде, читать release notes (изменения в item types, LLD, preprocessing, шаблонах). Подготовьте нужные версии PHP/СУБД, которые требуют Zabbix 6/7.
- Если вам категорически нельзя разворачивать отдельный инстанс — это лучший вариант.
2) Если in‑place апгрейд невозможен или вы хотите переносить на отдельно стоящий 7.0 без дампа БД — комбинированный перенос через API + zabbix_sender
- Что реально переносится:
- Конфигурация (хосты, шаблоны, items, триггеры, группы) — можно выгрузить через Zabbix API или экспортировать XML/JSON и затем воссоздать через API на целевом сервере.
- Исторические данные — Zabbix не предоставляет «удобного» встроенного инструмента для массового переноса истории между серверами: придётся «реплеить» значения на новый сервер (через zabbix_sender) или восстанавливать БД (это вы не хотите).
- Подход:
1. С помощью API (pyzabbix / zabbix-api) выгрузить конфигурацию из 5.0: шаблоны, хосты, items, триггеры, LLD правила, макросы, права и т.п.
- Экспорт через веб-интерфейс XML у вас не подходит (формат меняется) — лучше скриптом получить структуру и пересоздать объекты на целевой стороне через API. Скрипт позволяет трансформировать/адаптировать поля.
2. На целевом 7.0 через API создавать шаблоны/хосты с теми же keys/имёнами (важно — item keys должны совпадать, если планируете реплеить историю).
3. Перенос истории:
- Извлечь значения из старой БД (или через API history.get — но API медленный и ограничен по объёму). Из БД — SELECT history / history_uint / trends по интересующим itemid и периодам, затем сопоставить itemid через host+key.
- Сформировать файл для zabbix_sender в формате: <host> <key> <timestamp> <value> (одна строка) и отправить через zabbix_sender -z <zabbix_server> -i <file>.
- Ограничьте объём данных (например, последние N дней/месяцев), чтобы перенос был реалистичен.
- Минусы: перенос истории трудоёмкий; возможны расхождения в параметрах items (тип, preprocessing) между версиями; LLD/макросы могут требовать ручной корректировки.
3) Обходной путь — промежуточная конвертация XML шаблонов
- Если проблема только в несовместимости XML экспортов 5.0 → 7.0, можно:
- Экспортировать XML из 5.0, написать скрипт/XSLT для приведения XML к схеме 7.0 (убрать/переименовать устаревшие теги), и затем импортировать в 7.0.
- Это быстрее, чем полный API‑репликационный скрипт, но требует разбирательства с отличиями в структуре шаблонов (особенно LLD, preprocessing, value maps).
- Полезно, если у вас немного шаблонов и вы готовы править XML вручную или программно.
4) Если вы хотите избежать любых прямых манипуляций с БД и не хотите писать скрипты — единственный гарантированный путь сохранить всё (включая историю) — апгрейд текущего инстанса по официальному пути (см. пункт 1).
Практические советы и подводные камни
- Всегда тестируйте процесс на стенде/копии (если возможно).
- Делайте резервную копию БД и конфигурации веба перед любым апгрейдом. Если дамп БД запрещён — по крайней мере снимите том/снапшот.
- Проверяйте совместимость PHP и СУБД с новыми версиями Zabbix.
- Внимательно относитесь к LLD/LLD-примочкам: правила могут меняться между релизами.
- При реплее истории через zabbix_sender: отправляйте значения на items типа Zabbix trapper (или на нативные, если ключи совпадают). Zabbix позволяет указывать временные метки в zabbix_sender, так что можно восстанавливать исторические метки.
- Ограничьте объём переносимых данных — перенос всей истории за годы может быть непрактичен.
Как я могу помочь дальше
- Если хотите, могу:
- Составить пошаговый план in‑place апгрейда вашей версии ОС/репозиториев с конкретными командами.
- Подготовить пример скрипта на Python (pyzabbix) для выгрузки конфигурации из 5.0 и загрузки в 7.0.
- Подготовить пример генерации файла для zabbix_sender из выборки БД.
- Помочь с адаптацией XML экспорта (пример XSLT/преобразования) для импорта в 7.0.
Уточните, пожалуйста: что конкретно нужно сохранить (только конфигурацию шаблонов/хостов или также история/события), есть ли доступ к БД для чтения (не дамп, но SELECT — доступен?), и вы готовы апгрейдить текущий сервер «на месте»? Тогда предложу конкретный набор команд/скриптов.