Налаштований pg_dump за розкладом або автоматичні снепшоти в хмарному провайдері створюють відчуття захищеності. Це відчуття рідко перевіряється до моменту, коли щось іде не так. І саме тоді з'ясовується, що резервна копія є, але відновлення займає не дві години, а вісімнадцять.
Де досвідчені команди помиляються
Початківець може взагалі не налаштувати резервне копіювання. Досвідчена команда налаштовує його і вважає задачу закритою. Але стратегія резервного копіювання - це не про створення копій, а про відновлення. Різниця принципова: можна мати щоденні бекапи за останні 30 днів і при цьому не мати реального плану відновлення під тиском.
Конкретні прогалини, які варто перевірити
- Час відновлення повної бази на ізольованому середовищі - чи вкладаєтесь у допустимий RTO?
- Чи перевіряється цілісність резервної копії після створення, а не тільки факт її наявності?
- Логічний бекап проти фізичного - чи підходить ваш формат для часткового відновлення окремих таблиць?
- Чи є у команди задокументована послідовність дій при відновленні, яку хтось виконував хоча б раз?
WAL-архівування у PostgreSQL або binary log у MySQL дозволяє відновлення на довільний момент часу - але тільки якщо це налаштовано і перевірено заздалегідь. Інцидент - погане місце для першого знайомства з процедурою відновлення.