Резервні копії віртуальних машин Proxmox: розклад за кроками

Для чого і кому

Резервні копії віртуальних машин Proxmox краще запускати за розкладом, а не пам'ятати про них щоразу. Згідно з Proxmox VE: Backup and Restore (vzdump), завдання копіювання виконуються автоматично в задані дні й час для вибраних вузлів і гостьових систем. Нижче: як це налаштувати й перевірити.

Інструкція стосується компаній, які тримають власні сервери на Proxmox VE: файлові сервери, термінальні сервери, сервери застосунків, внутрішні сервіси. Орієнтуємося на документацію версії 9.2.13. Якщо ваші машини працюють на Hyper-V чи VMware або в хмарі, де копіями займається провайдер, цей текст вам не потрібен. Він також не замінює копії всередині застосунків: для бази 1С/BAS окремі правила описані в статті про резервні копії 1С/BAS на MS SQL.

Для бізнесу наслідки зазвичай буденні. Виходить з ладу диск, невдале оновлення ламає систему в машині, хтось видаляє не ту ВМ, а після раптового відключення світла сервер не стартує. Копія, яку треба запускати вручну, залежить від того, чи згадала про неї конкретна людина. Розклад прибирає цей чинник.

Пріоритет такий. Якщо жодного завдання за розкладом ще немає, налаштуйте його цього тижня, а для машин з обліком чи базами запустіть одну копію вручну вже сьогодні. Якщо розклад є, перевірку з цієї статті достатньо провести при плановому обслуговуванні.

Що знадобиться

Потрібен доступ адміністратора до вузла Proxmox VE, окреме сховище для копій і вікно часу, коли навантаження на сервер мінімальне, зазвичай це ніч. Також корисно мати список ВМ із позначкою, які з них критичні для роботи.

Сховище для копій

Перш ніж копіювання запрацює, треба визначити сховище (backup storage). Документація описує два варіанти: Proxmox Backup Server, де копії зберігаються дедуплікованими блоками з метаданими, або файлове сховище, де це звичайні файли. Для Proxmox Backup Server радять окремий хост, а NFS-сервер названо хорошою альтернативою. Не кладіть копії на той самий диск, що й самі машини: вихід із ладу диска забере і ВМ, і копію.

Пам'ятайте, що копії в Proxmox VE завжди повні: вони містять конфігурацію ВМ і всі дані. Тож місця потрібно більше, ніж здається, якщо тримати кілька копій поспіль. Для відновлення після пожежі чи втрати приміщення документація пропонує згодом переносити копії на стрічку для архіву поза майданчиком. Той самий принцип працює з будь-яким віддаленим сховищем, це корисно і для захисту від програм-вимагачів.

Режим копіювання

Режим (параметр mode) визначає баланс між узгодженістю даних і простоєм. Для ВМ є три варіанти. Режим stop коректно вимикає машину, дає найвищу узгодженість, але з коротким простоєм. Режим snapshot копіює блоки, поки ВМ працює: простій мінімальний, ризик неузгодженості невеликий. Режим suspend залишено для сумісності, документація радить натомість snapshot.

Для більшості робочих серверів логічно обрати snapshot і ввімкнути гостьовий агент (agent: 1). Якщо агент увімкнений і працює, перед копіюванням і після нього викликаються команди guest-fsfreeze-freeze та guest-fsfreeze-thaw, що покращує узгодженість. Для Windows-гостей агент треба налаштувати, якщо всередині машини працює ще й інша програма резервного копіювання. Для контейнерів режими працюють інакше: stop може означати дуже довгий простій, а snapshot вимагає сховища зі знімками.

Якщо немає свого адміністратора

Це типове завдання для обслуговування серверів, і вимагає воно скоріше регулярності, ніж багато часу. Якщо у вашій компанії немає людини, яка стежить за серверами й резервними копіями, налаштування розкладу та перевірку відновлення можна передати команді TakeIT.

Кроки

1. Підготуйте сховище. Додайте у Proxmox VE сховище для копій (Proxmox Backup Server на окремому хості або NFS) за розділом документації про storage. Перевірка: сховище з'явилося в інтерфейсі, доступне вузлу й дозволяє зберігати резервні копії.
2. Складіть список машин і оберіть режим для кожної. Для більшості ВМ підійде snapshot, для тих, що терплять коротку зупинку й потребують максимальної узгодженості, stop. Перевірка: у конфігурації ВМ, які копіюються в режимі snapshot, є agent: 1, а агент у гостьовій системі справді запущений.
3. Створіть завдання резервного копіювання за розкладом. У веб-інтерфейсі знайдіть налаштування завдань (Backup Jobs), вкажіть вузли, потрібні гостьові системи, сховище, режим, дні й час. Запускайте вночі й не розносіть критичні машини за різними завданнями без потреби. Перевірка: завдання збережене й видно в переліку разом із вибраними ВМ.
4. Для навантажених машин увімкніть fleecing. Коли копіювання стартує, нові записи в ще не скопійовані ділянки чекають, поки старі дані підуть у сховище копій, тому швидкість сховища впливає на роботу ВМ. Fleecing кешує ці дані в окремому образі, що може допомогти й навіть уникнути зависань, але потребує додаткового місця. В інтерфейсі налаштування є на вкладці Advanced у редагуванні завдання, а fleecing-сховище має бути швидким локальним, з thin provisioning і підтримкою discard, наприклад LVM-thin, RBD або ZFS. Перевірка: під час пробного запуску ВМ не підвисає, а на fleecing-сховищі вистачає місця.
5. Запустіть пробну копію вручну. Копію можна почати з інтерфейсу або командою vzdump, наприклад для машини 123 з fleecing: vzdump 123 --fleecing enabled=1,storage=local-lvm. Перевірка: завдання завершилось без помилок, а архів з'явився в сховищі з правильною датою і розумним розміром.
6. Дочекайтеся першого запуску за розкладом. Перевірка: наступного ранку в журналі завдання немає помилок, а для кожної ВМ зі списку є свіжа копія.

Як перевірити результат

Успішний запис у журналі ще не означає, що копію можна відновити. Тому перевірка складається з трьох рівнів. Перший: щотижня дивитесь, чи для всіх ВМ є свіжі копії та чи не зростає розмір так, що сховище скоро закінчиться. Другий: після змін у конфігурації (нова ВМ, новий диск) оновлюєте список у завданні. Третій: раз на кілька місяців відновлюєте копію як окрему тестову машину, не чіпаючи робочу, і переконуєтесь, що система стартує, а дані на місці.

Не лякайтеся, якщо під час копіювання вимкнена ВМ у списку виглядає запущеною. Документація пояснює: копію виконує фоновий процес QEMU, який читає диски, а сама машина не завантажується. Як вписати відновлення в ширшу практику компанії, читайте на сторінці про резервне копіювання й відновлення.

Типові помилки

Копії лежать поруч з оригіналом

Сховище на тому самому диску або в тому самому масиві, що й ВМ, захищає лише від помилок у системі всередині машини. Від поломки заліза чи втрати приміщення воно не врятує. Бажано мати хоча б одну копію на іншому пристрої, а найкраще ще й поза офісом.

Не всі диски та точки монтування потрапили в копію

Для контейнерів додаткові точки монтування, окрім кореневого диска, за замовчуванням не копіюються. Пристрої та bind-монтування не копіюються ніколи, бо їхній вміст керується поза сховищем Proxmox VE. Якщо важливі дані лежать саме там, їх треба захищати окремо.

Режим snapshot без гостьового агента

Без агента копія створюється, але узгодженість даних нижча. Для машин із базами це критично: перевірте агент у ВМ і, де потрібно, додайте окремі копії самих баз.

Вибір suspend через звичку

Режим suspend довше зупиняє машину й не обов'язково покращує узгодженість. Документація радить snapshot, а для максимальної узгодженості stop.

Копії ніколи не відновлювали

Буває, що розклад працює роками, а відновлення вперше пробують під час аварії. Тестове відновлення, описане в розділі про перевірку, допомагає помітити проблему заздалегідь.

Висновок

Після налаштування розклад щоразу запускає копіювання сам, а вам лишається періодично переглядати звіти й пробувати відновлення. Почніть із однієї критичної машини, переконайтеся, що її копія відновлюється, і додавайте решту по черзі.

Джерела

Proxmox VE: Backup and Restore (vzdump), офіційна документація, версія 9.2.13, дата: 2026-11-04.