Втратити базу даних через битий бекап — біль будь-якого адміна. Ми бачили десятки інцидентів, коли pg_dump мовчки створював порожній файл або дамп не відновлювався через помилки з'єднання. Тому в нашій практиці кожен бекап проходить верифікацію: pg_restore --list перевіряє цілісність, а ми додатково тестуємо відновлення на стенді.
Типова помилка — зберігання дампів на тому ж диску, де працює база. При збої диску ви втрачаєте і базу, і бекап. Ми завжди розміщуємо бекапи в окремому об'єктному сховищі, наприклад S3, з налаштуванням життєвого циклу. Наш досвід показує, що 30% продуктових інцидентів з PostgreSQL пов'язані з некоректними бекапами. Ми гарантуємо, що після нашого налаштування ви зможете відновити базу протягом години при RPO не більше 24 годин.
Чому pg_dump залишається стандартом для резервного копіювання?
pg_dump — утиліта для логічного дампу, не потребує зупинки бази (pg_dump documentation). Працює на будь-якій версії PostgreSQL, дамп переносимий між версіями (за умови, що цільова версія >= вихідної). Для баз до 100 ГБ це оптимальний вибір. Ключова перевага — гнучкість: можна вибірково відновити таблиці, схеми або дані.
Але у pg_dump є обмеження: великий дамп може займати години, а при збої під час виконання дамп буде неповним. Тому ми використовуємо користувацький формат (-Fc) — він стискає дані, підтримує паралельне відновлення і дозволяє перевіряти цілісність. Custom-формат (-Fc) приблизно в 5 разів компактніший за Plain SQL, а відновлення з pg_restore -j 4 пришвидшується в 3-4 рази на багатоядерних серверах.
Якщо потрібно забекапити весь кластер з ролями та tablespace, використовуйте pg_dumpall. Але для однієї бази pg_dump швидший і дає більше можливостей при відновленні.
Порівняння форматів дампу
| Формат | Флаг | Стиснення | Паралельне відновлення | Вибіркове відновлення | Розмір дампу |
|---|---|---|---|---|---|
| Plain SQL | -Fp | Ні | Ні | Так (вручну) | Великий |
| Custom | -Fc | Так (gzip) | Так (pg_restore -j) | Так | Середній |
| Directory | -Fd | Так (кожен файл) | Так | Так | Середній |
Custom-формат (-Fc) — наш вибір за замовчуванням: стиснення 5-10x, pg_restore запускається в кілька потоків, можна відновити лише потрібні таблиці.
PostgreSQL Documentation
Порівняння pg_dump і pg_dumpall
| Інструмент | Призначення | Швидкість | Відновлення |
|---|---|---|---|
| pg_dump | Одна БД | Швидше | Вибіркове |
| pg_dumpall | Всі БД + глобальні об'єкти | Повільніше | Повне |
Як ми налаштовуємо бекапування PostgreSQL: кейс з 50 ГБ базою
Розглянемо реальний проєкт: база 50 ГБ, щоденний повний дамп, зберігання 30 днів, S3 як віддалене сховище. Вимога: RTO < 1 година, RPO < 24 години. Відновлення 50 ГБ бази у форматі -Fc на тестовому стенді з 4 ядрами займає 20 хвилин.
Ми підготували скрипт з верифікацією, завантаженням у S3 та сповіщенням у Telegram при збої. Скрипт запускається по cron, логи пишуться у файл і надсилаються до системи моніторингу.
Код бекапу:
#!/bin/bash
set -euo pipefail
DB_HOST="localhost"
DB_PORT="5432"
DB_USER="postgres"
DB_NAME="production"
BACKUP_DIR="/backup/postgresql"
S3_BUCKET="s3://backups-company/postgresql"
RETENTION_DAYS=30
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_${DATE}.dump"
mkdir -p "$BACKUP_DIR"
echo "Starting backup at $(date)" | tee "$LOG_FILE"
# Створення дампу
PGPASSFILE="${HOME}/.pgpass" pg_dump \
-Fc \
-h "$DB_HOST" \
-p "$DB_PORT" \
-U "$DB_USER" \
-d "$DB_NAME" \
--no-password \
-f "$BACKUP_FILE" 2>> "$LOG_FILE"
# Перевірка цілісності
pg_restore --list "$BACKUP_FILE" > /dev/null 2>&1 || {
echo "ERROR: Backup integrity check failed" | tee -a "$LOG_FILE"
exit 1
}
# Завантаження в S3
aws s3 cp "$BACKUP_FILE" "${S3_BUCKET}/${DB_NAME}_${DATE}.dump" \
--storage-class STANDARD_IA \
--server-side-encryption aws:kms 2>> "$LOG_FILE"
echo "Upload to S3 completed" | tee -a "$LOG_FILE"
# Очищення локальних копій старше RETENTION_DAYS
find "$BACKUP_DIR" -name "*.dump" -mtime +${RETENTION_DAYS} -delete
echo "Backup completed successfully at $(date)" | tee -a "$LOG_FILE"Параметр --no-password змушує pg_dump читати пароль із ~/.pgpass, що безпечніше, ніж змінна середовища. Файл .pgpass має права 600.
Приклад вмісту .pgpass: localhost:5432:production:postgres:yourpassword
Моніторинг віку бекапів
Щоб не пропустити момент, коли бекап перестав створюватися, ми додаємо перевірку в Nagios/Icinga:
#!/bin/bash
DB_NAME="production"
LAST_BACKUP_DATE=$(aws s3 ls s3://backups-company/postgresql/ \
--recursive | grep "${DB_NAME}_" | sort | tail -1 | awk '{print $1" "$2}')
AGE_HOURS=$(( ($(date +%s) - $(date -d "$LAST_BACKUP_DATE" +%s)) / 3600 ))
if [ $AGE_HOURS -gt 25 ]; then
echo "CRITICAL: Last backup is ${AGE_HOURS}h old"
exit 2
elif [ $AGE_HOURS -gt 13 ]; then
echo "WARNING: Last backup is ${AGE_HOURS}h old"
exit 1
else
echo "OK: Last backup is ${AGE_HOURS}h old"
exit 0
fi
Цей скрипт перевіряє, що вік останнього дампу не перевищує 25 годин. Якщо бекап не створювався понад 13 годин — warning, понад 25 — critical. Такий підхід дозволяє виявити проблеми до того, як RPO буде порушено.
Чому важливий моніторинг бекапів?
Без моніторингу ви дізнаєтеся про проблему лише при спробі відновлення. На той момент може бути пізно. Ми включаємо в налаштування моніторинг не тільки віку, але й розміру дампу: різке зменшення розміру може вказувати на помилку в скрипті або проблеми з базою. Крім того, ми налаштовуємо алерти в Telegram або Slack.
Відновлення бази з дампу за допомогою pg_restore
Відновлення з custom-дампу виконується однією командою:
pg_restore -j 4 -d new_db -U postgres -h localhost production_backup.dump Флаг -j 4 запускає 4 паралельних потоки — це скорочує час відновлення на 50-70% на багатоядерних системах. Якщо потрібно відновити лише одну таблицю, вкажіть -t table_name.
Що входить у налаштування під ключ
- Аудит поточної схеми бекапів та вимог до RPO/RTO
- Розробка скриптів з верифікацією дампу та завантаженням у S3
- Інтеграція з системами моніторингу (Prometheus, Zabbix, Telegram)
- Документація процедури відновлення (покрокова інструкція)
- Навчання чергової зміни
- Супровід протягом першого місяця після впровадження
Процес роботи
- Аналіз: оцінюємо розмір бази, вимоги до RPO/RTO, доступне сховище.
- Проектування: вибираємо формат дампу, схему зберігання (локально + S3), плануємо розклад.
- Реалізація: пишемо скрипти, налаштовуємо cron, інтегруємо з S3.
- Тестування: виконуємо тестове відновлення на стенді, перевіряємо цілісність.
- Деплой: встановлюємо в продакшен, налаштовуємо моніторинг.
- Документація: описуємо процедуру відновлення, контакти відповідальних.
Строки та вартість
Налаштування базового сценарію (pg_dump + S3 + моніторинг) займає від 1 до 3 робочих днів залежно від складності. Вартість розраховується індивідуально, виходячи з обсягу робіт та вимог до відмовостійкості. Ми гарантуємо, що після нашого налаштування ви зможете відновити базу за інструкцією за 1 годину.
Типові помилки при налаштуванні бекапів
- Зберігання дампів на одному диску з базою.
- Використання plain SQL без стиснення (дамп займає багато місця, довго відновлюється).
- Відсутність верифікації дампів.
- Пароль у відкритому вигляді в cron (використовуйте .pgpass).
- Немає моніторингу віку бекапів.
Наша команда має понад 5 років досвіду в адмініструванні PostgreSQL і реалізувала більше 50 проєктів з резервного копіювання для компаній різного масштабу. Зв'яжіться з нами для аудиту вашої поточної схеми бекапів — ми запропонуємо оптимальне рішення. Замовте налаштування під ключ і отримайте гарантію відновлення за 1 годину. Отримайте консультацію з налаштування бекапів PostgreSQL вже сьогодні.
