EMZETT.Point-in-time recovery: повернення бази даних на певний момент
Коротко: Point-in-time recovery (PITR) відновлює базу даних на будь-який момент у минулому, відтворюючи журнал транзакцій поверх базової резервної копії до цього моменту.
Докладніше: Нічна резервна копія мало допомагає, якщо о 14:03 випадково видалено таблицю: бракує половини дня. PITR закриває цю прогалину, зберігаючи на додачу до резервної копії кожну окрему зміну.
Подробиці
Принцип
Бази даних записують кожну зміну спершу в журнал випереджувального запису (WAL). За PITR є базова резервна копія (повна копія даних) плюс безперервно архівований WAL. Щоб відновити, ви повертаєте базову копію й дозволяєте WAL програватися до моменту безпосередньо перед помилкою (recovery_target_time). Результат: стан на 14:02:59 замість учорашньої ночі.
Реалізація (PostgreSQL)
archive_mode = onіarchive_commandкопіюють готові сегменти WAL у надійне місце.- Базова копія через
pg_basebackup(або інструменти на кшталт pgBackRest, Barman, WAL-G). - Відновлення: помістити копію на місце, створити
recovery.signal, задати цільовий час, запустити сервер. - Керовані сервіси (наприклад, Neon, Supabase, RDS) пропонують PITR як функцію, часто з обмеженим вікном (від годин до днів залежно від плану).
Важливі зауваження
- PITR захищає від помилок оператора та несправних оновлень, але не від відмови сховища, якщо архів WAL лежить у тому самому місці: зберігайте його поза майданчиком.
- Перевіряйте відновлення; неперевірена резервна копія — лише надія.
- Зазвичай відновлюють у новий екземпляр і забирають лише потрібні дані.
- Строк зберігання має відповідати обов’язкам зберігання та захисту даних (видалені персональні дані зникають із резервних копій лише після спливу строку).
- Ключові показники: RPO (яка втрата даних допустима) та RTO (скільки може тривати відновлення).
Див. також: pg_dump і psql, Транзакції та ACID, Neon