Знімок — це представлення на певний момент часу із захистом, визначеним його реалізацією. Стратегія резервного копіювання додає навмисне збереження, розділення доступу та перевірене відновлення. Деякі знімки є резервними копіями; інші залежать від оригінального сховища. Запитайте, що переживе видалення, компрометацію або втрату основного середовища.
Опишіть копію, перш ніж називати її
Слово «знімок» говорить вам, що певний момент часу було представлено, але не про те, де зберігаються відновлювані дані чи хто може їх видалити. Знімок файлової системи на оригінальному сховищі та керований провайдером знімок блоку можуть мати різні межі збоїв. Почніть із реалізації, а не розглядайте мітку як універсальну обіцянку.
AWS документує знімки EBS як інкрементальні резервні копії томів на певний момент часу. Це конкретна реалізація, а не доказ, що кожен варіант знімків поводиться однаково. Для будь-якої служби запитайте, чи залежить відновлення від оригінального тому, чи залишають копії основний домен збоїв і що станеться, коли джерело буде видалено.
Порівняйте збої, які ви очікуєте пережити
Швидкий відкат після оновлення та відновлення після втрати облікового запису — різні проблеми. Локальний знімок може бути зручним для першої, пропонуючи мало розділення для другої. Незалежні копії можуть додати захист, але лише якщо їхні шляхи зберігання, доступу та видалення достатньо відокремлені від інциденту, до якого ви готуєтеся.
Запишіть збій і потрібний результат. Це ілюстративне порівняння — допоміжний засіб для рішення, а не список функцій для SwissOctet. Воно заохочує запитання про копії та контроль, а не твердження, що одна технологія завжди краща. Фактичний результат залежить від конфігурації та задокументованого процесу відновлення оператора.
| Сценарій | Питання для знімка | Питання для резервної копії |
|---|---|---|
| Погане оновлення застосунку | Чи можу я повернутися до потрібного моменту? | Скільки часу займає придатне відновлення? |
| Втрачено основний диск | Чи залежить копія від цього диска? | Чи можу я відновити на нове сховище? |
| Скомпрометовано адміністративний обліковий запис | Чи може цей обліковий запис видалити кожну копію? | Чи розділені права на видалення? |
| Помилку виявлено через тижні | Чи збережено ще той момент? | Чи покриває збереження затримку виявлення? |
Перевірте узгодженість застосунку
Диск може зафіксувати файли, поки застосунок ще змінює їх. Залежно від програмного забезпечення та процесу знімка результат може представляти стан, узгоджений із аварійним завершенням, а не скоординований стан застосунку. Не припускайте, що читабельні файли означають узгодженість бази даних і пов'язаних із нею завантажень. Використовуйте метод резервного копіювання, задокументований застосунком або базою даних.
Дизайн безперервного архівування PostgreSQL ілюструє різницю: відновлення потребує відповідної базової резервної копії та безперервної послідовності потрібних файлів журналу попереднього запису. Каталог, скопійований недбало під час роботи бази даних, не є еквівалентною процедурою. Якщо застосунок також зберігає файли поза базою даних, сплануйте, як ці два набори даних відновлюються разом.
Розглядайте збереження як вікно відновлення
Збереження має враховувати, як довго помилка може залишатися непоміченою. Десятиденне вікно не допоможе при випадковому видаленні, виявленому через місяць. Збереження кожної копії безстроково створює іншу проблему: витрати, зростання впливу чутливих даних і нечітка політика видалення. Вибирайте збереження з конкретних операційних вимог і вимог до обробки даних.
Позначайте точки відновлення корисним контекстом, як-от версія застосунку та час завершення завдання, не вбудовуючи секрети. Зберігайте достатньо історії, щоб відрізнити добрий стан від пошкодженого. Перед очищенням підтвердьте, як вибрана система обробляє спільні або інкрементальні дані; видалення позначеної точки може не відповідати видаленню простого окремого файлу.
Відокремте успішні завдання від перевірених даних
Повідомлення інструмента резервного копіювання про успіх засвідчує, що його процес завершився за його правилами. Це не доводить автоматично, що всі важливі дані застосунку було вибрано, кожен збережений байт залишається цілим або новий сервер може використати результат. Це різні перевірки. Включіть стан репозиторію, перегляд вибору та репрезентативне відновлення в операційний план.
Restic документує різницю між перевіркою репозиторію за замовчуванням і перевіркою, яка читає збережені дані пакетів. Повна перевірка з читанням даних може споживати більше часу та пропускної здатності. Цей приклад робить планувальний момент конкретним: вирішіть, що саме читає перевірка, і розподіліть бюджет роботи. Використовуйте документацію інструмента, а не припускайте, що кожна команда з назвою check має однакове покриття.
Перевірте невелике повне відновлення
Уявіть видання з базою даних, завантаженими зображеннями та конфігурацією. Відновіть усі три в приватному тестовому середовищі, потім відкрийте статтю та перевірте її вкладення. Тримайте заплановані інтеграції пошти, платежів і публікації вимкненими під час вправи. Перевірка лише випадкового текстового файлу пропустила б зв'язки, які роблять застосунок корисним.
Виміряйте потрібний час і запишіть, яких облікових даних, версій пакетів або зовнішніх залежностей бракувало. Перегляньте дозволи на відновлених файлах, а не лише їхній вміст. Вправа з відновлення часто виявляє, що дані існують, але інструкції чи доступ, потрібні для їх використання, ніколи не зберігалися разом з операційним планом.
Читайте додаткові резервні копії як окрему службу
Налаштовуючи SwissOctet, перегляньте точний варіант резервного копіювання та період збереження для сімейства. Запитайте, які томи та дані застосунку він охоплює, чи є відновлення самообслуговуванням і що станеться, коли основна конфігурація зміниться. Сама мітка опції не встановлює незалежну копію, незмінний репозиторій або точку відновлення, узгоджену з базою даних.
Використовуйте знімки там, де вони відповідають навантаженню, і тримайте ширшу стратегію резервного копіювання для збоїв, які вони не покривають. Запишіть незалежний шлях відновлення для важливих даних, захистіть облікові дані, які можуть стерти копії, і перевірте процедуру. Найсильніший вибір — той, що переживає ваш визначений сценарій, а не той із найбільш заспокійливою назвою.
Ваш практичний контрольний список.
- Визначте, де зберігаються відновлювані дані.
- Перелічіть збої, які має пережити копія.
- Використовуйте метод узгодженості, підтримуваний застосунком.
- Виберіть збереження для вікна виявлення.
- Захистіть права на видалення окремо.
- Відновіть повний застосунок в ізоляції.
Деталі, які мають значення.
Чи знімок ніколи не є резервною копією?+
Деякі реалізації знімків є резервними копіями. Корисна відмінність — їхня залежність від сховища, збереження, модель доступу та перевірене відновлення, а не сама мітка.
Чи доводить успішна перевірка цілісності, що застосунок працюватиме?+
Вона доводить лише те, що охоплює ця перевірка. Перевірте відновлення застосунку, конфігурацію, дозволи та зв'язки даних окремо.
Чи слід зберігати резервну копію на тому самому сервері?+
Копія на тому самому сервері може допомогти з обмеженими помилками, але поділяє важливі збої. Важливі дані потребують шляху відновлення поза межею збою, яку ви маєте намір пережити.
Перейдіть до джерела.
Ці джерела підкріплюють технічні концепції в цьому посібнику. Дотримуйтеся поточної документації перед зміною робочої системи.
- Amazon EBS: Знімки docs.aws.amazon.com
- PostgreSQL: Безперервне архівування та відновлення на певний момент часу www.postgresql.org
- Restic: Робота з репозиторіями та перевірками цілісності restic.readthedocs.io
Редакційне керівництво від SwissOctet. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо.