Proxmox

Настройка репликации виртуальной машины в Proxmox VE

Пошаговая настройка встроенной репликации виртуальной машины между узлами Proxmox VE с ZFS-хранилищами, расписанием и проверкой состояния.

Встроенная репликация Proxmox VE позволяет регулярно копировать виртуальные диски между узлами кластера. Она основана на снапшотах ZFS и передаёт только изменившиеся данные после первой полной синхронизации.

Репликация полезна, когда VM хранится на локальном ZFS и требуется иметь её актуальную копию на другом узле.

В этой инструкции рассматривается только настройка репликации одной виртуальной машины между двумя узлами Proxmox VE.

Подходит для: Proxmox VE 8 и 9
Требование: кластер Proxmox VE и локальные ZFS-хранилища
Уровень сложности: высокий
Время выполнения: около 20–40 минут без учёта первой синхронизации
Требуемый доступ: права управления кластером, VM и replication jobs

Важное ограничение

Репликация не является резервной копией.

Она не защищает от:

случайного удаления данных внутри VM;
повреждения файловой системы, которое уже попало в реплику;
шифровальщика внутри гостевой системы;
ошибочного удаления VM;
компрометации всего кластера;
одновременного отказа исходного и целевого узлов.

Для восстановления по истории всё равно нужны отдельные backup.

Что будет настроено

После выполнения инструкции:

будут проверены ZFS-хранилища на двух узлах;
будет проверена конфигурация VM;
будет создан replication job;
будет задано расписание;
будет выполнена первая синхронизация;
будет проверено состояние реплики;
будут разобраны ошибки и ограничения.

Требования к инфраструктуре

Для встроенной репликации необходимы:

минимум два узла в одном Proxmox-кластере;
рабочий quorum;
ZFS storage на исходном узле;
ZFS storage на целевом узле;
совместимая конфигурация storage;
стабильная сеть между узлами;
достаточное свободное место;
уникальный VM ID в кластере.

Проверка состояния кластера

На любом узле:

pvecm status

Проверьте:

Quorate: Yes

Покажите узлы:

pvecm nodes

Исходный и целевой узлы должны иметь статус online.

Проверка ZFS на исходном узле

zpool status

Пул должен находиться в состоянии:

ONLINE

Покажите свободное место:

zpool list

Покажите datasets и zvol:

zfs list

Проверка ZFS на целевом узле

Выполните те же команды на целевом узле:

zpool status
zpool list
zfs list

Целевой пул должен иметь достаточно места для полного размера виртуальных дисков и дальнейших изменений.

Проверка storage в Proxmox VE

pvesm status

Найдите ZFS storage.

Пример:

local-zfs

Проверьте конфигурацию:

cat /etc/pve/storage.cfg

Пример:

zfspool: local-zfs
    pool rpool/data
    content images,rootdir
    sparse 1

Одинаковый Storage ID

Для удобной репликации ZFS storage на узлах обычно имеет одинаковый Storage ID.

Например:

local-zfs

При этом физические ZFS pools могут быть локальными для каждого узла.

Проверьте поле:

Nodes

в настройках storage.

Проверка VM

qm status VM_ID

Покажите конфигурацию:

qm config VM_ID

Проверьте диски:

qm config VM_ID |
grep -E '^(scsi|virtio|sata|ide|efidisk|tpmstate)[0-9]*:'

Какие диски попадут в репликацию

Реплицируются диски VM, расположенные на поддерживаемом локальном ZFS storage.

Диски на:

NFS;
Ceph;
обычном directory storage;
LVM-thin;
внешнем iSCSI;

не реплицируются встроенным ZFS replication job.

Проверка всех дисков VM

Пример:

scsi0: local-zfs:vm-100-disk-0,size=64G
scsi1: local-lvm:vm-100-disk-1,size=100G

В такой конфигурации только scsi0 находится на ZFS.

Репликация VM может завершиться ошибкой или оказаться неполной из-за неподдерживаемого локального диска.

Все необходимые локальные диски VM должны быть размещены на реплицируемом ZFS storage.

Проверка unused-дисков

qm config VM_ID |
grep '^unused'

Неиспользуемые volumes могут занимать место, но не участвовать в текущей конфигурации VM.

Перед удалением подтвердите их назначение.

Проверка снапшотов

qm listsnapshot VM_ID

Репликация использует собственные служебные снапшоты ZFS.

Не удаляйте их вручную командами zfs destroy.

Управляйте replication job средствами Proxmox VE.

Проверка сети между узлами

Проверьте связь:

ping -c 3 TARGET_NODE_IP

Проверьте SSH:

ssh TARGET_NODE_NAME hostname

Кластер Proxmox VE использует SSH между узлами для административных операций.

Проверка скорости сети

На целевом узле:

iperf3 -s

На исходном:

iperf3 -c TARGET_NODE_IP

Если iperf3 отсутствует:

apt update
apt install -y iperf3

Первичная репликация крупного диска создаёт значительную сетевую нагрузку.

Проверка резервной копии

Перед созданием replication job выполните backup VM:

vzdump VM_ID   --storage BACKUP_STORAGE   --mode snapshot   --compress zstd

Дождитесь:

TASK OK

Репликация не должна быть единственной копией VM.

Создание задания через веб-интерфейс

Выберите виртуальную машину.

Откройте:

VM → Replication

Нажмите:

Add

Выбор целевого узла

В поле:

Target

выберите второй узел кластера.

Пример:

pve02

Целевой узел не должен совпадать с текущим узлом VM.

Настройка расписания

Поле:

Schedule

задаёт период запуска.

Примеры:

Каждые 15 минут:

*/15

Каждый час:

Каждые 30 минут:

*/30

Конкретный формат проверяйте по подсказке интерфейса текущей версии Proxmox VE.

Выбор интервала

Чем чаще выполняется репликация:

тем меньше потенциальная потеря данных при отказе;
тем выше нагрузка на сеть и диски;
тем чаще создаются служебные снапшоты;
тем больше операций ZFS send/receive.

Для обычной VM начальным вариантом может быть интервал 15–30 минут.

Для активно изменяющейся базы данных требуется отдельная оценка.

Rate limit

При наличии поля ограничения скорости можно задать максимальную пропускную способность.

Это полезно, если replication traffic конкурирует с:

пользовательским трафиком;
backup;
migration;
storage network;
Corosync.

Не ограничивайте скорость слишком сильно: job может не успевать завершаться до следующего запуска.

Комментарий

Добавьте описание:

Репликация VM 100 на pve02

Сохраните задание.

Создание через CLI

Показать справку:

pvesr help create

Создать job:

pvesr create   VM_ID-0   TARGET_NODE   --schedule '*/15'

Пример:

pvesr create   100-0   pve02   --schedule '*/15'

Идентификатор job обычно состоит из:

VM_ID-JOB_NUMBER

Проверка списка заданий

pvesr list

Для конкретной VM:

pvesr list |
grep '^100-'

Подробная конфигурация:

pvesr config

Запуск первой синхронизации вручную

pvesr run JOB_ID

Пример:

pvesr run 100-0

Первая синхронизация передаёт все используемые данные виртуальных дисков.

Она может занимать продолжительное время.

Наблюдение за первой синхронизацией

Проверяйте статус:

pvesr status

Покажите список:

pvesr list

На узлах можно наблюдать процессы:

ps aux |
grep -E 'zfs send|zfs receive|pvesr' |
grep -v grep

Сетевая нагрузка:

sar -n DEV 1

Дисковая нагрузка:

iostat -xz 1

Проверка журналов

journalctl --since today |
grep -iE 'replication|pvesr'

Проверьте pvedaemon:

journalctl -u pvedaemon   --since today   --no-pager

В веб-интерфейсе откройте task log replication job.

Проверка результата

pvesr status

Для job должен отображаться успешный последний запуск.

Проверьте:

Last Sync;
Duration;
Next Sync;
Error;
Target.

Проверка ZFS volumes на целевом узле

На целевом узле:

zfs list |
grep "vm-VM_ID"

Пример:

zfs list |
grep "vm-100"

Реплицированные volumes существуют на целевом узле, но VM остаётся зарегистрированной на исходном узле.

Почему VM не появляется второй раз

Репликация создаёт копию виртуальных дисков, а не вторую одновременно работающую VM.

VM ID остаётся единым в кластере.

Запуск VM на целевом узле выполняется после миграции или восстановления управления ресурсом.

Последующие синхронизации

После первой полной передачи Proxmox VE использует incremental replication.

Передаются только блоки, изменившиеся после предыдущего replication snapshot.

Поэтому следующие job обычно выполняются быстрее.

Изменение расписания

Через веб-интерфейс:

VM → Replication → Edit

Через CLI:

pvesr update JOB_ID   --schedule '*/30'

Пример:

pvesr update 100-0   --schedule '*/30'

Отключение задания

Через интерфейс отключите job.

Через CLI проверьте параметры:

pvesr help update

Используйте параметр disable, поддерживаемый вашей версией.

После отключения проверьте:

pvesr list

Удаление задания

pvesr delete JOB_ID

Пример:

pvesr delete 100-0

Перед удалением убедитесь, что реплика больше не нужна.

Что происходит с данными после удаления job

Удаление replication job и удаление реплицированных ZFS volumes — не всегда одно и то же действие.

Проверьте task log и состояние целевого storage.

Не удаляйте ZFS datasets вручную, пока не подтверждено, что они не используются Proxmox VE.

Миграция VM на целевой узел

Наличие актуальной реплики может ускорить миграцию VM на целевой узел, поскольку большая часть данных уже скопирована.

Проверьте последнюю синхронизацию:

pvesr status

Затем используйте штатную миграцию Proxmox VE.

Миграция VM рассматривается в отдельной статье.

Репликация и HA

Replication jobs можно использовать вместе с HA для VM на локальном ZFS.

При отказе узла HA может запустить VM на другом узле, используя последнюю доступную реплику.

При этом возможна потеря изменений, появившихся после последней успешной синхронизации.

Это значение соответствует фактическому RPO.

RPO репликации

Если replication job выполняется каждые 15 минут, потенциальная потеря последних изменений может составить примерно до одного интервала плюс время незавершённой синхронизации.

Репликация не гарантирует нулевую потерю данных.

Для критичных баз данных нужны прикладные механизмы репликации.

Базы данных внутри VM

ZFS replication копирует состояние виртуального диска.

Она не обеспечивает логическую репликацию:

PostgreSQL;
MySQL;
MariaDB;
Microsoft SQL Server;
Elasticsearch;
других СУБД.

Для критичной базы используйте:

штатную database replication;
WAL или binlog;
дампы;
application-consistent backup;
тест восстановления.

Согласование с backup

Не запускайте тяжёлые jobs одновременно:

backup
replication
migration
ZFS scrub
large VM snapshot

Разнесите расписания по времени.

Проверьте:

Datacenter → Backup
VM → Replication

ZFS scrub

Проверка пула:

zpool status

Запуск scrub:

zpool scrub POOL_NAME

Во время scrub replication может выполняться медленнее.

Расписание scrub следует планировать отдельно.

Мониторинг свободного места

На обоих узлах:

zpool list
zfs list

Проверяйте:

свободное место;
рост VM volumes;
количество снапшотов;
состояние пула;
ошибки checksum.

Не допускайте полного заполнения ZFS pool.

Проверка снапшотов ZFS

zfs list -t snapshot |
grep "vm-VM_ID"

Служебные replication snapshots имеют специальные имена.

Не удаляйте их вручную.

Типичные проблемы

Storage does not support replication

Диск VM расположен не на ZFS storage.

Проверьте:

qm config VM_ID |
grep -E '^(scsi|virtio|sata|ide)'

Перенесите диск на ZFS storage отдельной штатной операцией.

Target storage not found

Проверьте:

pvesm status
cat /etc/pve/storage.cfg

Storage ID должен быть доступен на целевом узле.

Недостаточно места на целевом узле

Проверьте:

zpool list
zfs list

Освободите место либо выберите другой узел.

Не запускайте повторную полную синхронизацию при почти заполненном pool.

Replication job завершается timeout

Проверьте:

сеть;
нагрузку дисков;
объём изменений;
параллельный backup;
ZFS pool health;
SSH между узлами.

Последующие sync снова передают много данных

Возможные причины:

удалены служебные snapshots;
job был пересоздан;
изменился целевой узел;
выполнена полная миграция storage;
нарушена цепочка incremental snapshots.

VM содержит неподдерживаемый диск

Проверьте все диски и EFI/TPM state.

Необходимые локальные volumes должны находиться на ZFS.

Replication работает, но приложение после failover повреждено

Репликация дисков не гарантирует прикладную согласованность.

Используйте database replication и application-aware backup.

Безопасный порядок настройки

Проверить quorum.
Проверить ZFS pools.
Проверить свободное место.
Проверить все диски VM.
Создать backup.
Проверить сеть между узлами.
Создать replication job.
Запустить первую синхронизацию вручную.
Проверить task log.
Проверить volumes на целевом узле.
Настроить расписание.
Разнести backup и replication по времени.
Провести тестовый перенос VM.

Быстрый набор команд

Проверить кластер:

pvecm status

Проверить ZFS:

zpool status
zpool list

Проверить VM:

qm config VM_ID

Создать job:

pvesr create   VM_ID-0   TARGET_NODE   --schedule '*/15'

Запустить вручную:

pvesr run VM_ID-0

Проверить:

pvesr status
pvesr list

Итог

После выполнения инструкции:

проверены кластер и ZFS pools;
проверены диски виртуальной машины;
создан replication job;
выполнена первая полная синхронизация;
проверена incremental replication;
настроено расписание;
рассмотрено использование с HA;
объяснено отличие репликации от backup.

Репликация Proxmox VE уменьшает время восстановления после отказа узла, но должна использоваться вместе с отдельными резервными копиями и прикладной защитой данных.