Бекапи є в кожної компанії. Відновлення — у значно меншої кількості. Ми регулярно зустрічаємо команди, у яких нічний cron з pg_dump тижнями тихо падає, бекапи лежать на тому самому сервері, що й база, або ніхто ніколи не міряв, скільки насправді триває відновлення їхньої бази на 400 ГБ. У гайді — як бекапити PostgreSQL так, щоб справді можна було відновитися: типи бекапів, відновлення на момент часу, інструменти на кшталт pgBackRest, цифри, які варто погодити з бізнесом, і навчальні відновлення, що перетворюють бекапи з надії на доказ.

Почніть з RPO і RTO

Стратегію бекапів визначають дві цифри:

  • RPO (Recovery Point Objective) — скільки даних ви можете дозволити собі втратити. «До 5 хвилин замовлень» — це RPO.
  • RTO (Recovery Time Objective) — скільки система може простоювати, поки ви відновлюєтеся. «Знову онлайн протягом 1 години» — це RTO.

Нічні дампи дають RPO до 24 годин. Якщо бізнес очікує хвилин, потрібне безперервне архівування WAL. Якщо очікує майже нульового простою — потрібні репліки й failover на додачу до бекапів. Погодьте ці цифри письмово до вибору інструментів.

Логічні й фізичні бекапи

PostgreSQL пропонує дві родини бекапів (PostgreSQL: backup and restore):

Тип Інструмент Сильні сторони Обмеження
Логічний pg_dump, pg_dumpall Переносимий між версіями й платформами, вибірковий (одна база чи таблиця) Повільний для великих баз, лише стан на момент дампу
Фізичний pg_basebackup, pgBackRest, Barman, WAL-G Швидкий для великих баз, дає відновлення на момент часу Та сама мажорна версія і платформа, увесь кластер

Логічні дампи чудово підходять для міграцій, копіювання бази на staging чи архівування окремої бази (pg_dump). Для аварійного відновлення в продакшені будь-чого більшого за невелику базу стандартом є фізичні бекапи з архівуванням WAL.

Відновлення на момент часу (PITR)

PostgreSQL записує кожну зміну в журнал попереднього запису (WAL) перед її застосуванням. Якщо зробити фізичний базовий бекап і безперервно архівувати файли WAL, можна відновити базовий бекап і «програти» WAL до будь-якого моменту — наприклад, до секунди перед тим, як хтось виконав DELETE без WHERE (PostgreSQL: continuous archiving and PITR).

Складові:

  1. wal_level = replica (значення за замовчуванням) і archive_mode = on.
  2. archive_command або бібліотека архівування, що копіює завершені сегменти WAL у безпечне сховище.
  3. Регулярні базові бекапи (щотижня повний, щодня інкрементний чи диференційний).
  4. Перевірена процедура відновлення, що задає recovery_target_time і програє WAL.

У PostgreSQL 17 з'явилися нативні інкрементні бекапи в pg_basebackup, що об'єднуються в повний бекап через pg_combinebackup, а pg_verifybackup перевіряє цілісність бекапу (реліз PostgreSQL 17; pg_combinebackup; pg_verifybackup).

pgBackRest на практиці

PITR можна побудувати вбудованими інструментами, але спеціалізований інструмент бекапів бере на себе деталі: паралельне стиснення, ротацію, шифрування, об'єктне сховище, перевірку і відновлення. На більшості самокерованих інсталяцій ми використовуємо pgBackRest; Barman і WAL-G — надійні альтернативи.

Мінімальна конфігурація, що надсилає бекапи й WAL у S3-сумісне об'єктне сховище з шифруванням:

# /etc/pgbackrest/pgbackrest.conf
[global]
repo1-type=s3
repo1-s3-endpoint=s3.eu-central-1.example.com
repo1-s3-bucket=pg-backups-prod
repo1-s3-region=eu-central-1
repo1-path=/cluster-main
repo1-retention-full=4
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=<з менеджера секретів>
process-max=4
compress-type=zst
start-fast=y

[main]
pg1-path=/var/lib/postgresql/18/main

# postgresql.conf
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'

pgbackrest --stanza=main stanza-create
pgbackrest --stanza=main --type=full backup     # щотижня
pgbackrest --stanza=main --type=diff backup     # щодня
pgbackrest --stanza=main check                  # перевіряє, що архівування працює

# Відновлення на момент часу на новому сервері
pgbackrest --stanza=main --type=time \
  --target="2026-06-01 14:31:00+03" --target-action=promote restore

Ротацію, кілька репозиторіїв і налаштування standby описано в посібнику користувача pgBackRest.

Де зберігати бекапи: правило 3-2-1

Тримайте щонайменше три копії даних на двох різних носіях чи сервісах, з однією копією поза основним майданчиком (CISA: варіанти резервного копіювання). Для PostgreSQL це зазвичай: продакшен-база, репозиторій бекапів у того самого провайдера в іншому регіоні чи класі сховища і другий репозиторій в іншого провайдера. Додайте незмінність (object lock) або окремий акаунт з обмеженими правами, щоб ransomware чи скомпрометований сервер не міг видалити бекапи.

На наших кластерах у Hetzner, наприклад, бекапи йдуть на Storage Box і до стороннього S3-сумісного провайдера, як описано у статті Kubernetes на Hetzner.

Kubernetes: доручіть це оператору

Якщо PostgreSQL працює в Kubernetes, використовуйте оператор, а не самописні StatefulSet'и. CloudNativePG — проєкт CNCF — декларативно керує репліками, failover, архівуванням WAL і бекапами в об'єктне сховище (CloudNativePG; CNCF).

Навчальні відновлення: єдиний доказ, що бекапи працюють

Бекап, який ви ніколи не відновлювали, — це гіпотеза. Плануйте навчання:

  • Щомісячне автоматичне відновлення: відновіть останній бекап на тимчасовий сервер, виконайте контрольні запити (кількість рядків, час останнього замовлення), запишіть тривалість і знищіть сервер.
  • Щоквартальне навчання з PITR: відновіть стан на конкретний момент і перевірте, що очікувані дані на місці.
  • Щорічна повна аварійна вправа: припустіть, що основного регіону більше немає; пройдіть runbook від початку до кінця, включно з DNS і конфігурацією застосунків.

Порівнюйте фактичний час відновлення з RTO. Відновлення бази на 500 ГБ через повільний канал може тривати години — краще дізнатися про це на навчанні.

Моніторинг бекапів

  • Алерт, якщо останній успішний бекап старіший за очікуване.
  • Алерт на збої архівування WAL; pg_stat_archiver показує невдалі спроби.
  • Відстеження трендів розміру й тривалості бекапів.
  • Звітування про результати навчань власникам RPO і RTO з боку бізнесу.

Передавайте ці метрики в ту саму систему observability, що й метрики застосунків; див. Observability з OpenTelemetry. Для інсталяцій Odoo бекапи й продуктивність ідуть разом, див. Оптимізація продуктивності Odoo.

Типові помилки

  • Бекапи зберігаються на тому самому сервері чи диску, що й база.
  • Лише нічний pg_dump для бази, де втрата дня даних неприйнятна.
  • Немає шифрування, або ключі шифрування лежать поруч із бекапами.
  • Архівування WAL тихо падає, доки не заповниться диск.
  • Немає задокументованої й перевіреної процедури відновлення.
  • Репліки вважають бекапами — але репліка сумлінно відтворює випадковий DROP TABLE.

Шаблон runbook для відновлення

Запишіть процедуру до того, як вона знадобиться, і тримайте її поруч із документацією для чергових:

  1. Оголосіть інцидент і визначте ціль відновлення: останній стан чи момент часу до виникнення проблеми.
  2. Створіть новий сервер з інфраструктурного коду, а не ремонтуйте пошкоджений.
  3. Відновіть дані інструментом бекапів, за потреби задавши цільовий час, і дочекайтеся завершення програвання WAL.
  4. Перевірте дані підготовленими перевірками: кількість рядків ключових таблиць, час останнього замовлення чи рахунку, smoke-тести застосунку.
  5. Переключіть трафік: оновіть рядки підключення чи DNS, перезапустіть пули застосунків.
  6. Одразу ввімкніть бекапи й архівування на новому primary.
  7. Напишіть розбір інциденту з фактичними RPO і RTO порівняно з цілями.

FAQ

Чи є репліки бекапом? Ні. Репліки захищають від відмови заліза, але не від людської помилки чи пошкодження даних, які вони реплікують миттєво. Потрібні і репліки, і бекапи.

Як часто робити повні бекапи? Щотижневий повний плюс щоденні диференційні чи інкрементні бекапи з безперервним архівуванням WAL — розумне значення за замовчуванням для більшості баз.

Чи достатньо pg_dump для невеликих баз? Для невеликих некритичних баз, де втрата до одного дня даних прийнятна, — так, якщо дампи зберігаються поза сервером і їх відновлення перевіряється.

А як щодо керованих баз на кшталт RDS чи Cloud SQL? Вони беруть на себе бекапи й PITR, але відновлення все одно варто тестувати і тримати незалежну копію на випадок інцидентів на рівні провайдера.

Джерела

  1. PostgreSQL. Backup and restore і Continuous archiving and PITR.
  2. PostgreSQL. pg_dump, pg_basebackup, pg_combinebackup, pg_verifybackup.
  3. PostgreSQL Global Development Group (2024). PostgreSQL 17 released.
  4. pgBackRest і його посібник користувача; Barman; WAL-G.
  5. CISA. Data backup options.
  6. CloudNativePG.