Як тестувати відновлення, а не лише резервну копію

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

Що насправді доводить зелене завдання

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

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

Крок перший: перевірте покриття проти реальності

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

Тож порівняйте список того, що існує, зі списком того, що захищене. Експортуйте інвентар з місця, яке знає, що працює, тобто з гіпервізора, хмарної платформи або DCIM, і список захищених об’єктів із системи резервного копіювання, потім порівняйте їх:

sort -u running-inventory.txt > running.sorted
sort -u protected-objects.txt > protected.sorted
comm -23 running.sorted protected.sorted   # running, but not protected
comm -13 running.sorted protected.sorted   # protected, but no longer running

Перший список небезпечний. Другий є сміттям, яке його ховає. Кожен запис у першому списку потребує рішення: додати його до завдання або записати, що він свідомо не має резервної копії, і чому.

Крок другий: відновлюйте більш ніж на одному рівні

Відновлюваність має рівні, і кожен рівень ловить проблеми, які пропускає рівень нижче.

Рівень файлів. Відновіть вибірку файлів в альтернативне місце і порівняйте їх за контрольними сумами з джерелом або відомою доброю копією. Це ловить нечитабельні носії та розірвані ланцюжки інкрементальних копій.

Рівень машини. Завантажте цілий сервер або віртуальну машину з резервної копії. Це ловить відсутні завантажувальні томи, драйвери і диск, який тихо виключили із завдання. Більшість enterprise-платформ резервного копіювання, серед них і Veeam, можуть запустити машину просто зі сховища резервних копій в ізольовану лабораторію саме для цього.

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

# MySQL or MariaDB
mysqlcheck --all-databases --check
mysql -e "SELECT MAX(created_at) FROM orders;"

# PostgreSQL
pg_amcheck --all
psql -c "SELECT max(created_at) FROM orders;"

Для інструментів резервного копіювання на рівні файлів є перевірки цілісності, які читають збережені дані назад, наприклад borg check --verify-data для репозиторію Borg.

Крок третій: відновлюйте в лабораторію, а не в продуктивну систему

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

Тому тестам відновлення місце в ізольованій мережі без маршруту до продуктивної системи і без маршруту в інтернет. Перш ніж запускати будь-який застосунок у цій лабораторії, вимкніть планувальник і вихідну пошту на відновленій копії. Зробіть це записаним кроком тесту, щоб нікому не треба було пам’ятати.

Крок четвертий: заміряйте час

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

Крок п’ятий: запишіть це

Ведіть короткий запис для кожного:

• Дата і хто проводив.
• Що відновлювали, з якої точки відновлення.
• Який рівень тестували: файли, машина чи застосунок.
• Витрачений час, від початку до кінця.
• Усе, що не вдалося, здивувало вас або потребувало знань, яких ніде не записано.
• Що змінили в результаті.

Дизайн під сподом теж має значення

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

Як це робимо ми

Наші резервні копії працюють лише в режимі pull за задумом, і це забезпечують firewall-пристрої; до систем резервного копіювання та відновлення має доступ лише мережа керування. Ми використовуємо Veeam для віртуальних машин, фізичних серверів і серверів SQL, а також дедуплікуючий backup hub, який забирає файлові дані і дані баз даних Linux за допомогою обмежених ключів лише на дописування. Покриття перевіряється проти живого інвентаря, графіки встановлюються за виміряним часом виконання, а повні відновлення проводяться аж до щотижня.

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

cta: Поговоріть з інженером

Related

• /what-we-do/storage-compute/disaster-recovery/
• /what-we-do/storage-compute/storage-replication-federation/
• /what-we-do/storage-compute/network-attached-storage/