Бекап захищає від багатьох сценаріїв: помилкового DELETE, збою диска, зламу, програм-вимагачів, що шифрують дані й вимагають викуп. Але лише якщо його зроблено правильно.
Правило 3-2-1:
- 3 копії даних (основна + дві резервні);
- на 2 різних носіях чи типах сховищ;
- 1 копія поза основною інфраструктурою - інший провайдер, регіон, обліковий запис.
Захист від вимагачів і зловмисників:
- зловмисник, що отримав доступ до сервера, видалить і бекапи, якщо сервер має права на їх видалення. Тому:
- сервер має лише право дописувати нові копії, але не видаляти чи перезаписувати старі;
- незмінні копії - Object Lock в S3-сумісних сховищах (режим compliance), версіонування бакетів;
- окремий обліковий запис для бекапів, до якого немає доступу з продакшену;
- офлайн- чи ізольовані копії - CISA рекомендує тримати хоча б одну копію поза мережею.
Шифрування: бекапи містять усі персональні дані й секрети. Вони мають бути зашифровані, а ключ - зберігатися окремо від бекапів (і не лише на тому самому сервері).
Що бекапити:
- базу даних (дамп чи фізична копія + журнали для відновлення на момент у часі);
- файли користувачів (
storage/app, бакет S3); - конфігурацію й секрети (зашифрованими) - без них відновлений застосунок не запуститься.
Найважливіше - перевірка відновлення. Бекап, який жодного разу не відновлювали, - лише надія. Регулярне (автоматизоване) відновлення в окреме оточення з перевіркою:
- дамп розгортається без помилок;
- ключові таблиці мають очікувану кількість записів;
- застосунок запускається на відновлених даних.
Так заодно вимірюється реальний час відновлення - і він часто неприємно дивує.
Моніторинг: сповіщення, якщо бекап не створився чи його розмір різко змінився (і раптове зменшення - ознака проблеми).
Докладніше в документації: CISA: посібник з протидії програмам-вимагачам
