Визначте прийнятну втрату даних і час відновлення, зберігайте узгоджену незалежну копію та перевіряйте відновлення фактичного застосунку в ізоляції. Завершене завдання резервного копіювання або перевірка цілісності самі по собі не доводять, що присутні всі залежності, потрібні для відновлення.
Почніть із потрібного вам відновлення
План резервного копіювання починається з двох практичних запитань: скільки нещодавньої роботи ви могли б втратити і як довго сервіс міг би залишатися недоступним? Ці відповіді визначають розклад, дані для включення та метод відновлення. Щоденна копія може підійти для вебсайту, що рідко змінюється, але залишить занадто великий розрив для завантаженого застосунку.
Перелічте все, що забезпечує роботу сервісу, а не лише його найбільшу теку. Дані застосунку, вміст бази даних, конфігурація, завантажені файли та інформація, потрібна для відтворення середовища, можуть мати значення. Ведіть приватний перелік залежностей і ключів відновлення. Резервна копія має підтримувати працездатну систему, а не просто створювати архів, призначення якого забуте.
Зберігайте копію поза межею збою
Другий каталог на тій самій машині може допомогти відновити помилкове редагування, але він залишається вразливим до втрати цієї машини. Локальні знімки можуть бути цінними для швидкого відкату, але все одно потребують незалежної копії для ширших інцидентів. Виберіть окреме місце призначення для відновлення та вирішіть, який доступ має дозволяти читати, записувати або видаляти резервну копію.
Якщо робочі облікові дані можуть видалити кожну копію відновлення, скомпрометований обліковий запис застосунку може зруйнувати всю стратегію. Розділіть доступ, де це можливо, і захистіть облікові дані сховища. Шифрування допомагає захистити збережений вміст, але процес відновлення також залежить від безпечного зберігання його ключа поза пошкодженим середовищем.
Зафіксуйте узгоджений стан застосунку
Копіювання відкритих файлів бази даних без належного методу може зафіксувати непридатний стан. Використовуйте підхід до резервного копіювання, підтримуваний застосунком або базою даних, і з'ясуйте, чи потребує він узгодженого знімка, логічного експорту або короткої паузи в записах. Узгодьте пов'язані дані так, щоб каталог завантажень і його посилання в базі даних описували ту саму точку робочого процесу.
Свідомо документуйте виключення. Кеші та тимчасові файли збірки можуть бути відтворюваними; завантаження клієнтів зазвичай ні. Перегляньте список після додавання функції або переміщення каталогу. Успішне завдання резервного копіювання не може зберегти шлях, який ніколи не було включено.
Перевірте відновлення в ізольованому середовищі
Відновіть репрезентативні дані в окремому місці та перевірте, що вони відкриваються правильно. Для застосунку перевірте як відновлений сервіс, так і файли. Вимкніть вихідну електронну пошту, заплановані завдання та зовнішні інтеграції в тестовому середовищі, щоб репетиція не впливала на реальних користувачів і не дублювала робочі завдання.
Перевірки цілісності репозиторію та тест відновлення відповідають на різні питання. Інструмент може перевірити збережені структури та дані, тоді як застосунку все ще бракує конфігурації або забутого ключа. Зафіксуйте, скільки триває відновлення, які ручні кроки потрібні та де процедуру потрібно вдосконалити. Повторіть вправу після значних змін.
Практичний сценарій: відрепетируйте відновлення перед запуском
Розгляньте застосунок із базою даних, завантаженнями користувачів і невеликим набором приватних файлів конфігурації. Власник створює перелік відновлення та вибирає метод узгодженості, підтримуваний базою даних. Окреме місце призначення для резервних копій зберігає потрібні копії, а ключ відновлення зберігається поза робочою машиною. Перший тест починається з порожнього ізольованого середовища, тому приховані залежності не можна позичити з робочого сервера.
Власник відновлює дані та конфігурацію, потім перевіряє вхід, репрезентативний запис і завантажений файл. Вихідна електронна пошта, заплановані завдання та зовнішні дії залишаються вимкненими під час репетиції. Якщо база даних запускається, але шлях завантаження або секрет відсутній, тест виявив прогалину, яку успішне завдання архівування не показало б. Власник виправляє перелік і повторює відповідну перевірку відновлення.
Нарешті власник фіксує час відновлення та ручні кроки. Розклад і політику зберігання порівнюють із тим, скільки недавньої роботи може бути втрачено та як довго сервіс може залишатися недоступним. Це рішення, специфічні для проєкту, а не гарантії, надані ярликом сховища. Перевірена процедура робить додаткову резервну копію або продукт зберігання корисним у складі ширшої стратегії відновлення.
| Докази відновлення | Що це перевіряє | Питання, що залишилося |
|---|---|---|
| Завдання резервного копіювання завершено | Завдання повідомило про успіх | Чи було включено всі потрібні шляхи? |
| Перевірка цілісності репозиторію | Перевірки збережених структур або даних | Чи має застосунок усі залежності? |
| Ізольоване відновлення застосунку | Репрезентативне відновлення працює | Чи відповідає спостережуваний час вашій меті? |
Зробіть збій видимим, а зберігання — навмисним
Резервна копія, яка тихо зупиняється, — це майбутній сюрприз. Відстежуйте завершення завдань, доступну ємність і вік останньої придатної точки відновлення. Зберігайте достатньо історії, щоб відновитися від проблеми, виявленої пізніше, і розумійте, як очищення впливає на цю історію. Ретельно переглядайте операції видалення, оскільки помилки зі збереженням можуть видалити єдину корисну версію.
Прочитайте область застосування будь-якої опції резервного копіювання на вибраному сервісі SwissOctet і підтвердьте процес відновлення. Vault Storage можна розглядати як компонент ємності, але продукт зберігання сам по собі не є повною політикою відновлення. Вирішіть, що вам потрібно відновити, тримайте копію незалежною та доведіть процедуру, перш ніж сервіс стане критичним.
Ваш практичний контрольний список.
- Встановіть прийнятні втрату даних і час відновлення.
- Включіть бази даних, завантаження та інформацію для відтворення.
- Тримайте незалежну копію та окремі ключі відновлення.
- Відновіть в ізоляції та перевірте застосунок.
- Відстежуйте вік резервних копій, ємність і збереження.
Деталі, які мають значення.
Чи є другий каталог на тому самому сервері незалежною резервною копією?+
Ні. Він залишається вразливим до втрати цього сервера, хоча може допомогти відновити локальну помилку.
Чи замінює перевірка цілісності репетицію відновлення?+
Ні. Дійсний репозиторій усе ще може не містити конфігурації, ключів або даних, потрібних застосунку.
Чому вимикати інтеграції під час тесту відновлення?+
Щоб тестове середовище не надсилало електронні листи реальним користувачам, не повторювало завдання та не запускало робочі дії.
Перейдіть до джерела.
Ці джерела підкріплюють технічні концепції в цьому посібнику. Дотримуйтеся поточної документації перед зміною робочої системи.
- restic: Відновлення з резервної копії restic.readthedocs.io
- restic: Робота з репозиторіями restic.readthedocs.io
- PostgreSQL: Резервне копіювання та відновлення www.postgresql.org
Редакційне керівництво від SwissOctet. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо.