AVGZ / INSIGHTS
RTO, RPO та перевірка відновлення
Як розділити час відновлення, втрату даних і доступність сервісу.
Постановка задачі
RTO описує цільовий час повернення функції; RPO — допустиму втрату даних у часі. Вони не тотожні відсотку uptime. Узгоджувати їх слід для конкретної функції, а не лише для сервера.
Порядок перевірки
Складіть перелік даних, конфігурацій і залежностей. Відновіть систему в ізольованому середовищі, перевірте логін, читання та запис. Виміряйте фактичний час, зафіксуйте останній доступний запис і звірте цілісність.
Межі та типові помилки
Успішне створення архіву не доводить можливість відновлення. Потрібні ключі розшифрування, сумісні версії та робоча процедура. PostgreSQL PITR — приклад відновлення за базовою копією та журналом WAL; це не доказ використання такого механізму в кожному проєкті AVGZ.
Приклад перевірки
Після помилкового видалення даних резервний сервер також отримав цю зміну. Перемикання на нього не повертає попередній стан: потрібна придатна історична копія або відновлення до моменту перед помилкою. Це навчальний сценарій, а не опис інциденту AVGZ.
| Контроль | Питання до системи |
|---|---|
| Функція | Яка операція користувача має знову працювати? |
| Дані | До якого підтвердженого моменту їх можна повернути? |
| Залежності | Чи доступні конфігурації, ключі та потрібні версії? |
| Приймання | Чи перевірені читання, запис і цілісність після відновлення? |
Результат тесту оформлюють як протокол: початок інциденту, початок робіт, момент повернення функції та виявлена втрата даних. Якщо перевіряли лише окрему базу, не слід називати результат часом відновлення всього сервісу. Повторіть перевірку після суттєвої зміни архітектури.
Чи достатньо репліки?
Ні. Репліка може повторити логічну помилку. Історична копія та процедура повернення даних вирішують іншу задачу.
Джерела та подальше читання
PostgreSQL: Continuous Archiving and PITR — технічна довідка. Описаний порядок перевірки є редакційним інженерним підходом, а не звітом про впроваджений проєкт.