Уявіть: о 14:37 хтось випадково видалив таблицю orders, або о 09:15 стався масовий неправильний UPDATE на мільйон рядків. Без PITR відновлення — тільки до останнього бекапу, і всі дані після нього втрачені. Ми вирішуємо цю проблему, налаштовуючи Point-in-Time Recovery для PostgreSQL та MySQL, щоб ви могли відкотитися на будь-яку секунду. Стандартні бекапи рятують від повної відмови, але не від логічних помилок. PITR дає можливість відновити дані з точністю до транзакції. Ключові метрики: RPO (Recovery Point Objective) — максимальні втрати даних. При archive_timeout=300 RPO ≤ 5 хвилин. RTO (Recovery Time Objective) — час відновлення. Для бази 100 ГБ — 15–40 хвилин. Без PITR відновлення може зайняти дні замість годин, а втрачені дані часто невідновні. Згідно з документацією PostgreSQL, WAL-архівація є основою PITR. Економія на одному інциденті з видаленням даних може перевищувати $5000. Середня економія клієнтів від використання PITR — до $5000 на інцидент.
Налаштування PITR PostgreSQL та MySQL включає конфігурацію WAL архівації та pgBackRest, що забезпечує відновлення бази даних на будь-який момент часу. Для MySQL налаштування binlog відновлення з RPO до 1 хвилини дає змогу відновити базу даних на момент до помилки.
Чому PITR — не опція, а необхідність?
Без PITR ви втрачаєте всі зміни після останнього бекапу. Це може коштувати годин роботи та репутації. З PITR ви відновлюєтеся на момент до помилки, втрачаючи лише кілька хвилин. Економія часу при відкаті — в 10 разів швидше, ніж повторне введення даних. Використання PITR дозволяє зменшити RTO в 3 рази порівняно з традиційними бекапами.
Ключові терміни: WAL-сегменти, checkpoints, LSN, binlog position — всі вони використовуються в процесі точкового відновлення.
Які бази даних ми підтримуємо?
- PostgreSQL — pgBackRest з реплікацією в S3.
- MySQL — бінарні логи з
binlog_format=ROW.
Як працює PITR
Потребує двох компонентів: базовий снапшот (повний бекап) і безперервний потік транзакційних логів від снапшота до поточного часу (WAL для PostgreSQL, binlog для MySQL). Відновлення = базовий снапшот + відтворення логів до потрібного моменту. Вартість зберігання WAL-архівів у S3 для бази 100 ГБ — близько $15/міс.
Налаштування PITR для PostgreSQL
Конфігурація WAL-архівації
У postgresql.conf:
wal_level = replica archive_mode = on archive_command = 'pgbackrest --stanza=myapp archive-push %p' archive_timeout = 300 Перезапуск PostgreSQL обов'язковий після зміни wal_level.
pgBackRest: повна конфігурація PITR
# /etc/pgbackrest/pgbackrest.conf [global] repo1-path=/mnt/backup-storage/pgbackrest repo1-retention-full=3 repo1-retention-archive=14 repo2-type=s3 repo2-path=/pgbackrest repo2-s3-bucket=company-db-backups repo2-s3-region=eu-west-1 repo2-retention-full=2 [myapp] pg1-path=/var/lib/postgresql/14/main pg1-port=5432 Відновлення на конкретний момент
systemctl stop postgresql pgbackrest --stanza=myapp restore \ --target="YYYY-MM-DD HH:MM:SS" \ --target-action=promote \ --delta systemctl start postgresql Замініть --target на потрібний момент. --delta відновлює лише змінені файли, прискорюючи процес.
Налаштування PITR для MySQL через binlog
Конфігурація бінарних логів
# /etc/mysql/mysql.conf.d/mysqld.cnf server_id = 1 log_bin = /var/log/mysql/mysql-bin.log binlog_format = ROW expire_logs_days = 14 max_binlog_size = 500M binlog_row_image = FULL Відновлення через mysqlbinlog
mysql -u root myapp < full_backup_YYYYMMDD.sql mysqlbinlog \ --stop-datetime="YYYY-MM-DD HH:MM:SS" \ /var/log/mysql/mysql-bin.000040 \ /var/log/mysql/mysql-bin.000041 \ /var/log/mysql/mysql-bin.000042 | mysql -u root myapp Пропуск проблемної транзакції: вкажіть --start-position та --stop-position у mysqlbinlog для виключення пошкодженої події.
Як вибрати між PITR на PostgreSQL та MySQL?
| Параметр | PostgreSQL (pgBackRest) | MySQL (binlog) |
|---|---|---|
| RPO за замовчуванням | 5 хвилин | ≤ 1 хвилина (без затримки) |
| RTO для 100 ГБ | 15–40 хвилин | 10–30 хвилин |
| Базова реплікація | Вбудована (streaming) | Вбудована (async/semi-sync) |
| Зберігання архіву | S3, локальний, NFS | Файлова система, S3 (через інструменти) |
| Відновлення по LSN | Так | Ні (тільки за часом/позицією) |
PostgreSQL дає більше гнучкості (відновлення по LSN, паралельне застосування), але потребує більш ретельного налаштування. MySQL простіший у конфігурації, але binlog-файли можуть займати багато місця при ROW форматі.
Порівняння локального та S3-сховища для архіву WAL
| Параметр | Локальний диск | S3 (хмарний) |
|---|---|---|
| Швидкість запису | Висока (NVMe) | Середня (залежить від каналу) |
| Надійність | Обмежена (відмова диска) | Висока (реплікація 7*9) |
| Вартість | Одноразова | Щомісячна (~$15/міс для 100 ГБ) |
| Відновлення через інтернет | Тільки локально | З будь-якої точки |
| Рекомендація | Для баз < 50 ГБ | Для баз > 50 ГБ та DR |
Процес налаштування PITR у нашій компанії
- Аудит поточної інфраструктури — визначаємо обсяг бази, частоту змін, вимоги до RTO/RPO.
- Конфігурація архівації — налаштовуємо WAL/binlog, вибираємо репозиторій (локальний диск + S3).
- Тестове відновлення — перевіряємо відновлення на випадковий момент в ізольованому середовищі.
- Документування — фіксуємо процедуру, створюємо runbook для чергових інженерів.
- Навчання — проводимо воркшоп для вашої команди з ручного та автоматичного відновлення.
Типові помилки та як їх уникнути
- Пропущений WAL-сегмент через неправильний
archive_command— перевіряйте, що команда завершується з кодом 0. Використовуйтеpgbackrest --stanza=myapp check. - Завеликий інтервал
archive_timeout— збільшує RPO. Тримайте не більше 5 хвилин. - Не налаштована реплікація архіву — використовуємо S3 в іншому регіоні для disaster recovery.
- Відсутність регулярних навчань — відновлення без перевірки може провалитися у критичний момент.
Заплануйте хоча б раз на квартал тестове відновлення. Ми допомагаємо з цим.
Що входить у послугу
- Повне налаштування PITR для PostgreSQL та/або MySQL.
- Конфігурація pgBackRest або binlog з резервуванням у хмару.
- Тестове відновлення та звіт з результатами.
- Документація по процедурі відновлення (runbook).
- Навчання ваших інженерів.
- Гарантія відновлення на будь-який момент часу в рамках налаштованого періоду.
Терміни та вартість
Термін налаштування — від 2 до 5 робочих днів залежно від складності інфраструктури (реплікація, S3, кластеризація). Вартість розраховується індивідуально після аудиту. Замовте налаштування PITR прямо зараз — захистіть свої дані. Для консультації зв'яжіться з нами: ваш персональний менеджер оцінить систему за один день.
Ми маємо понад 10 років досвіду в адмініструванні PostgreSQL та MySQL, виконали понад 40 проектів з PITR. Наші інженери сертифіковані та регулярно проходять навчання. Гарантуємо відновлення даних в обумовлені RTO/RPO. Зв'яжіться з нами для отримання консультації.
Як замовити
Ми пропонуємо налаштування PITR під ключ для PostgreSQL та MySQL. Оцінимо ваш проект безкоштовно — напишіть нам. В послугу входить повний цикл: аудит, конфігурація, тестування, документація та навчання. Гарантуємо відновлення даних відповідно до обумовлених RTO/RPO.
Для поглибленого вивчення: офіційна документація PostgreSQL по WAL та MySQL Binary Log.