Proxmox

Резервное копирование LXC-контейнера в Proxmox VE

Пошаговое резервное копирование LXC-контейнера в Proxmox VE через веб-интерфейс и vzdump, проверка архива и восстановление.

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

В Proxmox VE резервное копирование контейнеров выполняется через веб-интерфейс или командой vzdump.

В этой инструкции рассматривается только резервное копирование одного LXC-контейнера, проверка архива и базовое восстановление.

Подходит для: Proxmox VE 8 и 9
Уровень сложности: начальный
Время выполнения: около 15 минут без учёта времени копирования
Требуемый доступ: учётная запись с правами на backup и restore

Что потребуется

Перед началом подготовьте:

существующий LXC-контейнер;
хранилище с типом содержимого VZDump backup file;
достаточный объём свободного места;
доступ к веб-интерфейсу;
при работе через CLI — доступ к shell узла Proxmox.

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

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

проверить backup-хранилище;
создать резервную копию контейнера;
выбрать режим snapshot, suspend или stop;
проверить созданный архив;
выполнить backup через vzdump;
восстановить контейнер с новым CT ID;
проверить сеть и сервисы после восстановления.

Проверка хранилища резервных копий

В веб-интерфейсе откройте:

Datacenter → Storage

Выберите нужное хранилище.

В поле:

Content

должен быть разрешён тип:

VZDump backup file

Для локального хранилища часто используется:

local

Проверка свободного места

Через CLI:

pvesm status

Для файлового хранилища:

df -h

Размер каталога резервных копий:

du -sh /var/lib/vz/dump 2>/dev/null

Перед backup убедитесь, что свободного места больше ожидаемого размера архива.

Проверка контейнера

Покажите список контейнеров:

pct list

Проверьте статус:

pct status CT_ID

Пример:

pct status 200

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

pct config CT_ID

Режимы резервного копирования

Proxmox VE поддерживает несколько режимов.

Snapshot

Snapshot

Контейнер продолжает работать во время резервного копирования.

Режим доступен не для всех storage backend.

Suspend

Suspend

Контейнер временно приостанавливается, затем его файловая система копируется.

Сервис будет недоступен на время suspend.

Stop

Stop

Контейнер корректно останавливается перед backup и запускается после завершения, если был запущен до начала операции.

Это наиболее предсказуемый режим, но требует простоя.

Какой режим выбрать

Для обычного контейнера на storage с поддержкой snapshot:

Snapshot

Для базы данных или приложения с активной записью безопаснее:

выполнить штатный дамп;
остановить запись;
использовать режим Stop;
либо применять согласованную прикладную стратегию.

Резервная копия контейнера не заменяет штатный дамп базы данных.

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

Выберите контейнер.

Откройте:

Backup

Нажмите:

Backup now

Укажите:

Storage: local
Mode: Snapshot
Compression: ZSTD

Нажмите:

Backup

Дождитесь завершения задачи.

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

В журнале должно появиться:

TASK OK

Если задача завершилась ошибкой, откройте полный лог и найдите первую значимую ошибку.

Особенно проверьте сообщения о:

свободном месте;
недоступном storage;
неподдерживаемом snapshot;
ошибках чтения;
bind mount;
внешних mount point.

Проверка созданного файла

Откройте:

Storage → Backups

В списке должен появиться файл вида:

vzdump-lxc-200-2026_07_26-12_00_00.tar.zst

Проверьте:

CT ID;
дату;
время;
размер;
выбранное хранилище;
описание.

Поиск backup через CLI

Для стандартного локального хранилища:

ls -lht /var/lib/vz/dump/ |
head

Только LXC-backup:

ls -lht /var/lib/vz/dump/vzdump-lxc-* 2>/dev/null |
head

Резервное копирование через vzdump

Базовая команда:

vzdump CT_ID   --storage STORAGE_ID   --mode snapshot   --compress zstd

Пример:

vzdump 200   --storage local   --mode snapshot   --compress zstd

После успешного завершения:

TASK OK

Backup в режиме stop

vzdump 200   --storage local   --mode stop   --compress zstd

Проверьте после завершения:

pct status 200

Если контейнер был запущен до начала backup, Proxmox обычно запускает его снова.

Добавление заметки

vzdump 200   --storage local   --mode snapshot   --compress zstd   --notes-template 'Перед обновлением контейнера'

Описание помогает понять назначение архива.

Проверка mount point

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

pct config CT_ID |
grep -E '^(rootfs|mp[0-9]+)'

Пример:

rootfs: local-lvm:vm-200-disk-0,size=16G
mp0: /srv/shared,mp=/mnt/shared

Важная особенность bind mount

Bind mount может указывать на каталог хоста:

mp0: /srv/shared,mp=/mnt/shared

Такие данные могут не входить в backup контейнера.

Проверьте каждый mount point отдельно.

Если данные находятся на хосте, для них нужна отдельная резервная копия.

Исключение mount point из backup

В конфигурации mount point может присутствовать:

backup=0

Пример:

mp0: local-lvm:vm-200-disk-1,mp=/data,backup=0

Такой mount point не войдёт в архив.

Проверьте:

pct config CT_ID |
grep -E '^(rootfs|mp[0-9]+)'

Проверка содержимого архива

Для .tar.zst можно вывести список файлов:

zstdcat /var/lib/vz/dump/BACKUP_FILE.tar.zst |
tar -tf - |
head -100

Либо:

tar --use-compress-program=unzstd   -tf /var/lib/vz/dump/BACKUP_FILE.tar.zst |
head -100

Проверка списка файлов не заменяет тестовое восстановление.

Восстановление через веб-интерфейс

Выберите хранилище:

Storage → Backups

Выберите нужный архив.

Нажмите:

Restore

Укажите:

целевой узел;
новый CT ID;
целевое хранилище;
сетевые параметры при необходимости;
режим privileged или unprivileged только с пониманием последствий.

Для безопасной проверки лучше использовать новый CT ID.

Восстановление с новым CT ID

Пример:

Исходный CT ID: 200
Новый CT ID: 250

После восстановления:

не запускайте копию сразу в production-сети;
проверьте IP;
проверьте hostname;
исключите конфликт адресов;
проверьте сервисы;
сравните конфигурацию.

Восстановление через CLI

Найдите архив:

ls -lht /var/lib/vz/dump/vzdump-lxc-*

Восстановите:

pct restore   NEW_CT_ID   /var/lib/vz/dump/BACKUP_FILE.tar.zst   --storage TARGET_STORAGE

Пример:

pct restore   250   /var/lib/vz/dump/vzdump-lxc-200-2026_07_26-12_00_00.tar.zst   --storage local-lvm

Проверка восстановленного контейнера

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

pct list

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

pct config 250

Проверьте статус:

pct status 250

Запустите:

pct start 250

Войдите:

pct enter 250

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

Внутри контейнера:

cat /etc/os-release
hostnamectl
ip addr
ip route

Проверьте сервисы:

systemctl --failed

Проверьте SSH:

systemctl status ssh --no-pager

Проверьте приложение.

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

Исходный и восстановленный контейнер могут иметь одинаковые:

IP-адрес;
hostname;
MAC-адрес;
конфигурацию приложения;
идентификаторы сервисов.

До одновременного запуска измените сетевые параметры копии.

Пример через CLI:

pct set 250   --net0 name=eth0,bridge=vmbr0,ip=192.0.2.50/24,gw=192.0.2.1,type=veth

Используйте адреса своей сети.

Проверка backup на практике

Самая надёжная проверка — восстановить архив в отдельный контейнер.

Проверьте:

запуск;
сеть;
SSH;
сервисы;
данные приложения;
mount point;
права файлов;
scheduled tasks;
доступность базы данных.

Только наличие архива не гарантирует успешного восстановления.

Удаление старого backup

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

Storage → Backups

Выберите архив и нажмите:

Remove

Через CLI для обычного локального каталога:

rm /var/lib/vz/dump/BACKUP_FILE.tar.zst

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

Контроль места после backup

pvesm status

Для локального storage:

df -h /var/lib/vz

Размер backup-каталога:

du -sh /var/lib/vz/dump

Крупнейшие архивы:

du -h /var/lib/vz/dump/* |
sort -h |
tail

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

Snapshot mode недоступен

Storage backend может не поддерживать snapshot для контейнера.

Используйте:

Suspend

или:

Stop

Backup не включает bind mount

Это ожидаемо для некоторых mount point на хосте.

Проверьте:

pct config CT_ID |
grep -E '^(rootfs|mp[0-9]+)'

Создайте отдельный backup каталога хоста.

Недостаточно места

Проверьте:

pvesm status
df -h

Не удаляйте архивы без проверки их назначения.

Контейнер не запускается после восстановления

Проверьте:

pct start CT_ID

Посмотрите журнал:

journalctl -u pve-container@CT_ID   -n 100   --no-pager

Проверьте mount point, права и сетевую конфигурацию.

После восстановления нет данных приложения

Возможно, данные находились:

в bind mount;
в mount point с backup=0;
на внешнем NFS;
на CIFS;
в отдельной базе данных;
на другом сервере.

Проверьте архитектуру приложения до backup.

Восстановленная копия конфликтует с исходной

Измените IP, hostname и другие уникальные параметры до подключения к production-сети.

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

Проверить свободное место.
Проверить конфигурацию контейнера.
Проверить mount point.
Выполнить прикладной дамп базы данных.
Создать backup.
Убедиться в TASK OK.
Проверить файл архива.
Выполнить тестовое восстановление.
Проверить сеть, сервисы и данные.
Настроить срок хранения резервных копий.

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

Проверить контейнер:

pct status CT_ID
pct config CT_ID

Создать backup:

vzdump CT_ID   --storage local   --mode snapshot   --compress zstd

Показать архивы:

ls -lht /var/lib/vz/dump/vzdump-lxc-* |
head

Восстановить:

pct restore   NEW_CT_ID   /var/lib/vz/dump/BACKUP_FILE.tar.zst   --storage TARGET_STORAGE

Итог

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

проверено backup-хранилище;
создана резервная копия LXC-контейнера;
рассмотрены режимы snapshot, suspend и stop;
проверены mount point;
выполнено резервное копирование через vzdump;
показано восстановление с новым CT ID;
рассмотрена проверка сети и сервисов.

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