Копія без відновлення не є резервною копією

Із заголовком погоджуються всі. Майже жодна панель його не відображає.

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

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

Три докази, і вони не взаємозамінні

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

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

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

Що насправді стверджує зелений verify

Proxmox Backup Server уміє перевіряти знімок: він перечитує фрагменти й звіряє їх із маніфестом. Коли це сталося, перелік знімків несе обʼєкт verification зі станом усередині.

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

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

Відсутнє поле не є невдачею

Наш стовпець має три значення: ok, failed і unknown. Найцікавішим є не середнє.

Виміряно на живому Proxmox Backup Server 4.2 зі справжніми знімками на ньому: знімок, який ніколи не проходив завдання verify, просто не має ключа verification. Поле відсутнє. Це інша річ, ніж verify, який відпрацював і не пройшов, і злиття їх коштує вам в обидва боки. Поставте типовим ok, і кожен неперевірений знімок стає перевіреним. Поставте типовим failed, і кожен історичний знімок у вашій базі даних раптом горить. Третє значення існує, щоб сказати єдину правдиву річ: нічого не відомо.

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

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

Порожньо має означати порожньо

Ось найгостріше правило в усій цій царині, і воно не має стосунку до перевірки.

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

Тож ми виміряли, що сервер резервних копій насправді відповідає, коли перелік іде не так, бо «порожній масив» і «помилка, схожа на порожній масив» мають бути відрізнювані. Чотири випадки, усі виміряні на тому самому живому примірнику 4.2:

• порожній простір імен відповідає 200 з порожнім масивом;
• простір імен, якого не існує, відповідає 400 з помилкою «не знайдено», а не порожнім списком;
• сховище даних, яке токен не може аудитувати, відповідає 403;
• хибний токен відповідає 401.

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

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

Облікові дані не мають бути здатні щось зламати

Найкорисніше рішення щодо безпеки тут є водночас найнуднішим.

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

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

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

Чим має бути тест відновлення, якщо ви його будуєте

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

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

Йому також потрібна явна політика завершеності, і саме тут уся справа заслуговує на свою назву. Завантажилася це один рівень. Досяжна це інший. Гостьовий агент відповідає це ще інший. Файлові системи змонтовано це ще інший. Застосунок, який відповідає на визначену клієнтом перевірку справності, є рівнем, що збігається з тим, що клієнт розуміє під «відновлюваним». Оберіть один, запишіть поруч із результатом, який саме ви обрали, і ніколи не дозволяйте показувати нижчий рівень із написом вищого.

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

Що ми записали б

1. 01Назвіть три докази окремо у своїй схемі, ще до того, як матимете всі три. У нас це окремі стовпці й таблиця, якої ще немає, і це легше читати, ніж один стовпець із виправдовувальним коментарем.
2. 02Зберігайте «unknown» як справжнє значення. Будь-яке типове значення, яке не є «unknown», є брехнею щонайменше про один із ваших рядків.
3. 03Змусьте порожній перелік довести, що він порожній, і перетворіть кожну іншу відповідь на окрему помилку до того, як вона дійде до чогось, що звіряє.
4. 04Дайте інтеграції облікові дані, які не можуть видаляти, а потім перевірте ззовні, що вони не можуть.
5. 05Запишіть, що мало б означати «відновлення» для вас і на якому рівні завершеності, перш ніж хтось поставить поруч зелену галочку.

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

Інтеграцію, що стоїть за цими вимірами, збудовано для Provibr. Споріднене питання часу, що стається, коли резервне копіювання триває довше за термін, який ви йому дали, розглянуто в тайм-аут не є кнопкою зупинки; контейнерний бік резервних копій Proxmox описано у VM чи контейнер на Proxmox.