Що гарантують режими vzdump у Proxmox

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

Спершу коротко, потім докладно:

Слово, яке робить у цій таблиці всю роботу, це crash-consistent. Воно означає, що архів має вигляд, який мав би диск, якби хтось у ту саму мить висмикнув кабель живлення. Журнальована файлова система після такого підніметься. База даних, у якій була транзакція в польоті, може й не піднятися, а застосунок, що тримає стан у двох файлах, не знатиме, що один із них старіший за інший.

Режим snapshot не заморожує гостя

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

Є спосіб зробити той архів кращим: гостьовий агент QEMU може заморозити файлову систему всередині гостя на мить, коли робиться знімок, а це скидає записи на диск і дає архів, який сам гість вважає чистим. Якщо гостьовий агент встановлено, запущено й він відповідає, стається саме це.

Пастка сидить у тому «якщо». Ніщо у відповіді API не каже вам, чи заморозка сталася. Завдання vzdump повертає ідентифікатор завдання, а після завершення статус. Чи відповів qemu-guest-agent на запит заморозки, це рядок у журналі завдання, а не поле, яке можна прочитати назад.

Це точка вибору для кожного, хто будує автоматизацію поверх, і до неї варто поставитися свідомо. Коли ми будували шлях резервного копіювання для нашої інтеграції з Proxmox, ми зрештою почали записувати узгодженість як те, що сталося, і ніколи як те, про що попросили: копію в режимі stop записано як узгоджену, а snapshot і suspend обидва записано як crash-consistent, і крапка. У нашій схемі є значення для «гостя приведено в узгоджений стан», і агент ніколи його не видає, бо видати його означало б стверджувати знання про заморозку, якого ми не можемо перевірити через API.

Архів, описаний трохи гірше, ніж він є, не коштує вам нічого. Архів, описаний краще, ніж він є, коштує вам того єдиного відновлення, яке має значення.

suspend призупиняє гостя, і це не золота середина

suspend читається краще, ніж поводиться. Люди припускають, що це «snapshot, але безпечніше», компроміс між нульовим простоєм і повним. Насправді ж він призупиняє гостя, поки читаються дані.

Він дає ту саму гарантію crash-consistency, що й snapshot, бо призупинити машину не те саме, що дати їй скинути буфери й заспокоїтися. Ви отримуєте перерву й жодної сильнішої обіцянки. Випадок для нього вузький: бекенд сховища, який узагалі не вміє знімків, де режимові snapshot немає з чого знімати.

stop це єдина чесна гарантія

stop вимикає гостя, копіює його й запускає знову. Це найдовша перерва й єдиний режим, у якому архів однозначно є копією файлової системи, в яку ніхто не писав.

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

Одна деталь реалізації тут має значення. Оскільки stop і suspend обидва перервуть роботу запущеної машини, відсутнє чи нерозпізнане значення режиму ніколи не повинно провалюватися в один із них. У нашій схемі команд режим їде як буквальне слово Proxmox (snapshot, suspend, stop), а не як власний словник, і невиставлене значення розвʼязується в snapshot. Таблиця перекладу між нашими словами та їхніми поставила б помилку перекладу рівно там, де помилка перекладу вимикає машину клієнта.

Параметри, що вирішують, чи завдання запуститься

Перед узгодженістю є нудніше питання: чи vzdump узагалі почнеться. Це вирішують чотири речі в запиті, і три з них падають так, що це важко прочитати.

Цільове сховище має приймати резервні копії. У сховища Proxmox є список content, і лише сховище, чий список містить backup, може прийняти vzdump. Це не порада. Надішліть завдання в сховище, яке тримає самі лише образи дисків, і Proxmox відмовить повідомленням на кшталт storage 'x' does not support vzdump backups. Точно і безглуздо для клієнта, який натиснув кнопку. Це варто перевіряти до відправлення, щоб відмова могла сказати «це сховище не приймає резервних копій».

Суміжний випадок: сховище, що зʼявляється в списку ресурсів кластера зі статусом unknown, налаштоване, але не відповідає. Непрацездатна NFS-шара має вигляд цілком дійсної цілі рівно до моменту, коли завдання впаде.

У стиснення є значення, яке не є тим словом, на яке ви очікуєте.

Proxmox пише «без стиснення» як 0, а не як none. Надіслати none це та помилка, що дає тиху відмову замість зрозумілої, і саме тому наш набір тестів перевіряє точний рядок, який залишає агента, а не лише те, що виклик удався.

Поштові сповіщення усталено гучні й адресовані не тій людині. Без явного mailnotification=failure Proxmox пише на root@pam після кожної копії. На машині, керованій із платформи, це лист провайдерові про те, що зробив клієнт.

Два необовʼязкові поля варто знати. notes-template додає до архіву примітку, і Proxmox розгортає всередині неї власні плейсхолдери, як-от {{guestname}}. protected=1 позначає архів як захищений, і Proxmox після цього відмовиться його підчищати. Це саме той механізм, який потрібен для копії, що її хтось робить перед ризикованою зміною, і рівно неправильне усталене значення для нічного завдання.

Строк зберігання не є параметром vzdump

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

Це має наслідок для дизайну в кожного, хто будує зверху: панель, що пропонує поле «тримати 7 копій», або лізе в конфігурацію сховища, або видаляє архіви сама. Ми не обрали ні того, ні іншого, і кажемо про це, замість натякати на протилежне полем, яке нічого не робить.

Вичерпаний тайм-аут це не те саме, що збій

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

Тож тайм-аут це твердження про ваше зʼєднання, а не про резервну копію. Запуск лишається відкритим, ідентифікатор завдання далі дійсний, і чесне, що може зробити інтерфейс, це сказати «ще виконується» й звірити пізніше. Альтернатива, позначити як збій і дати комусь запустити другу, ставить два завдання vzdump на одне сховище для однієї машини.

Поки воно виконується, справжній поступ доступний: vzdump пише в журнал завдання рядки на кшталт 12% (1.2 GiB of 10.0 GiB). Смужка поступу, яку живить це, чесна. Смужка поступу, яку живить оцінка, це здогад зі знаком відсотка.

Відновлення це інше питання, і unique тут головне

Питання режиму закінчується тоді, коли архів існує. У відновлення своя пастка, і вона мережева.

Відновіть архів у нову віртуальну машину, не попросивши нових ідентифікаторів, і нова машина успадкує MAC-адреси оригіналу. Якщо оригінал усе ще працює, у вас тепер дві машини з однаковим MAC на одному мості, і симптом не «відновлення впало», а «мережа продакшн-машини повелася дивно». Прапорець unique у виклику відновлення це те, що цьому запобігає, і на платформі, яка відновлює поряд із запущеним оригіналом, він не опція, а передумова.

Ще дві речі варто знати перед першим відновленням:

• storage тут означає інше. Під час копіювання це те, куди йде архів, і йому потрібен backup у списку вмісту. Під час відновлення це те, куди лягають відновлені диски, і йому потрібен images. Те саме імʼя поля, інша вимога.
• Повертаються лише диски. Відновлена машина це машина з дисками й обладнанням з архіву. Призначення адрес, правила фаєрвола й будь-яка автоматизація, привʼязана до оригіналу, живуть у ваших власних системах, а не у файлі vzdump, і разом із ним не подорожують.

Що тут не виміряно

Усе сказане вище про форму викликів походить зі схеми API Proxmox і з роботи проти неї; семантика режимів це власна семантика Proxmox, описана в його документації.

Чого ми свідомо не стверджуємо, так це скільки часу коштує кожен режим. У нас немає виміряної тривалості паузи для suspend і немає виміряного простою для stop: це залежить від гостя, сховища й обсягу брудної памʼяті, а число, виміряне на одній машині, цитували б як загальне. Ці числа мають прийти з вашого власного заліза.

Ще дві прогалини варто назвати. Усе тут стосується гостей QEMU; у резервних копій контейнерів свої правила щодо точок монтування й bind mounts, і ми їх не міряли. І в усьому цьому немає інкрементального шляху: vzdump у звичайне сховище щоразу пише повний архів. Інкрементальні копії це те, для чого існує Proxmox Backup Server, а це інше програмне забезпечення з іншим набором обіцянок.

Це вийшло з побудови шляху резервного копіювання Proxmox для Provibr, панелі керування серверами для хостинг-провайдерів, де копія, описана краще, ніж вона є, була б найгіршою можливою вадою. Нотатки з налаштування боку гіпервізора є в документації Proxmox, а сторінка інтеграції з Proxmox описує, що вміє агент.