Зашифровані резервні копії, які ви справді можете відновити.

Виберіть межу репозиторію

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

Збирайте узгоджені дані

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

Ускладніть видалення

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

Плануйте перевірки та навчання відновленню

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

Відокремте додавання копії від видалення історії

Призначення лише для додавання може дозволити робочому серверу додавати знімки, зберігаючи право на видалення на окремій довіреній машині. Термін зберігання все одно потребує ретельної перевірки: підроблені новіші знімки можуть підірвати деякі політики вибору за календарем. Перевірте настанови інструмента, виконайте пробний запуск політики зберігання та відстежуйте ємність. Операція forget у Restic вибирає знімки; очищення видаляє збережені дані без посилань.

• Тримайте облікові дані для обслуговування репозиторію поза робочою машиною
• Виконайте пробний запуск збереження перед дозволом видалення
• Використовуйте нову порожню ціль для кожної навчальної процедури відновлення

restic check
restic snapshots
restic restore latest --target /srv/restore-drill

Офіційна документація: Збереження та очищення Restic

Навчальне відновлення з умовою успіху

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

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

Створіть маніфест відновлення перед вибором виключень

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

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

Офіційна документація: Borg: шифрування, узгодженість і відновлення

Перевіряйте збережені дані, а також метадані репозиторію

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

restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill

Офіційна документація: restic: перевірки репозиторію та верифікація даних

Тримайте обслуговування поза досяжністю скомпрометованого клієнта

Сховище Borg лише для додавання зберігає зафіксовані дані сегментів, але клієнт усе ще може змінити видимий список архівів; відновлення й ущільнення потребують задокументованої адміністративної процедури. Обмежте віддалені облікові дані резервного копіювання серверною командою Borg, а не необмеженою оболонкою чи входом до файлової системи, що міг би обійти ці захисти. З restic перегляньте настанови щодо keep-within для зберігання лише для додавання. Перед будь-яким обслуговуванням, що може видалити історію, перевірте стан репозиторію та попередньо перегляньте вибір із довіреної машини.

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

Офіційна документація: Borg: робота та обслуговування в режимі лише додавання · restic: збереження та міркування щодо режиму лише додавання