Коли база даних займає десятки гігабайт, повний дамп може тривати години і створювати навантаження на диск. Наприклад, повний дамп бази 500 ГБ на HDD може зайняти 8 годин, а інкрементальний — 15 хвилин. Інкрементальні бекапи зберігають лише зміни з останнього бекапу, скорочуючи час і обсяг у 10–50 разів. Економія дискового простору досягає 80%, що при вартості $0.1/ГБ/міс дає $400 економії на 500 ГБ. Час відновлення скорочується в 2–5 разів. Ми налаштовуємо інкрементальні бекапи для PostgreSQL та MySQL — під ваш стек і навантаження. Використовуємо лише перевірені інструменти: pgBackRest для PostgreSQL, Percona XtraBackup для MySQL, а для хмарного зберігання — Restic з дедуплікацією. Усі рішення супроводжуються моніторингом та алертингом. Додатково знижується навантаження на диск та CPU. Ми гарантуємо, що після налаштування ви будете спати спокійно — дані в безпеці, а відновлення займе хвилини. Ми маємо 5+ років досвіду та 50+ реалізованих проектів. Економія на хмарному зберіганні може досягати $2000 на рік для великих баз.
Як вибрати тип інкрементального бекапу?
Differential — зберігає всі зміни з останнього повного бекапу. Відновлення: повний + один differential. Incremental — зберігає лише зміни з останнього будь-якого бекапу. Відновлення: повний + ланцюжок incremental. WAL-based (PostgreSQL) — безперервна архівація журналів транзакцій, основа для PITR. Incremental ефективніший за Differential за розміром — він зберігає лише дельту, але складніший у відновленні: потрібен ланцюжок. На практиці рекомендуємо комбінацію: повний раз на тиждень, диференціальний щодня — баланс розміру та швидкості відновлення.
| Тип | Обсяг даних | Швидкість відновлення | Складність |
|---|---|---|---|
| Differential | Помірний | Висока (повний + 1 файл) | Низька |
| Incremental | Мінімальний | Низька (повний + ланцюжок) | Середня |
| WAL-based (PITR) | Мінімальний | Середня (точка в часі) | Висока |
| Інструмент | СУБД | Тип бекапів | Дедуплікація | Шифрування |
|---|---|---|---|---|
| pgBackRest | PostgreSQL | Повний, diff, incr | Ні | Так (TLS) |
| Percona XtraBackup | MySQL | Повний, incr | Ні | Ні (можна зовні) |
| Restic | Будь-які файли | Інкрементальний блоковий | Так | Так (AES-256) |
| Borg Backup | Будь-які файли | Інкрементальний блоковий | Так | Так (AES-256) |
Як налаштувати WAL-архівацію в PostgreSQL?
- Встановіть pgBackRest.
- Налаштуйте конфіг:
# /etc/pgbackrest/pgbackrest.conf [global] repo1-path=/var/lib/pgbackrest repo1-retention-full=2 repo1-retention-diff=7 log-level-console=info [myapp] pg1-path=/var/lib/postgresql/14/main - Виконайте ініціалізацію та перший повний бекап:
pgbackrest --stanza=myapp stanza-create pgbackrest --stanza=myapp --type=full backup - Додайте в cron:
# Повний (неділя 01:00) 0 1 * * 0 pgbackrest --stanza=myapp --type=full backup # Диференціальний (пн-сб 01:00) 0 1 * * 1-6 pgbackrest --stanza=myapp --type=diff backup Для MySQL використовуйте Percona XtraBackup, який виконує бекап без блокувань, що в 2-3 рази швидше за звичайний mysqldump:
# Повний бекап xtrabackup --backup --target-dir=/var/backups/mysql/full/ # Інкрементальні на основі попереднього xtrabackup --backup --target-dir=/var/backups/mysql/incr1/ \ --incremental-basedir=/var/backups/mysql/full/ xtrabackup --backup --target-dir=/var/backups/mysql/incr2/ \ --incremental-basedir=/var/backups/mysql/incr1/ # Відновлення: підготовка повного + застосування інкрементів xtrabackup --prepare --apply-log-only --target-dir=/var/backups/mysql/full/ xtrabackup --prepare --apply-log-only \ --target-dir=/var/backups/mysql/full/ \ --incremental-dir=/var/backups/mysql/incr1/ xtrabackup --prepare \ --target-dir=/var/backups/mysql/full/ \ --incremental-dir=/var/backups/mysql/incr2/ Хмарне сховище та дедуплікація
Для зберігання бекапів у хмарі використовуйте Restic — він підтримує S3, GCS, B2 та шифрування на льоту. Restic забезпечує дедуплікацію на рівні блоків, що скорочує обсяг сховища ще на 30–50% поверх стиснення — це в 2-3 рази краще за звичайне стиснення за обсягом.
# Ініціалізація репозиторію restic -r s3:s3.amazonaws.com/my-bucket/db-backups init # Бекап директорії з дампами restic -r s3:s3.amazonaws.com/my-bucket/db-backups \ backup /var/backups/postgres/ \ --password-file /etc/restic-password Налаштування моніторингу та алертингу
Критичні метрики: розмір останнього бекапу (різке зменшення на 50% — сигнал проблеми), час виконання (норма до 30 хв для інкрементального), успішність. Використовуйте Healthchecks.io для перевірки:
# Кінець скрипту — перевірка та healthcheck if pgbackrest --stanza=myapp check; then curl -s "https://hc-ping.com/${HC_UUID}" else curl -s "https://hc-ping.com/${HC_UUID}/fail" fi Додатково налаштуйте збір метрик через Prometheus та дашборди Grafana. Це дозволить бачити тенденції та вчасно реагувати. pgBackRest виконує інкрементальний бекап у 10-50 разів швидше ніж звичайний pg_dump.
Типові помилки при налаштуванні
- Не налаштована ротація бекапів. Старі бекапи не видаляються, диск переповнюється. Вкажіть retention у pgBackRest або скриптах.
- Забули про моніторинг. Якщо бекап не виконався, ви дізнаєтесь про це тільки коли дані втрачені. Налаштуйте алерти.
- Ігнорування тестового відновлення. Бекап може бути битим. Регулярно відновлюйте на тестовому сервері.
- Вибір неправильного типу. Для великих баз з частими змінами WAL-архівація краща.
Тестування відновлення
Кожен налаштований бекап ми перевіряємо на відновлення в staging-середовищі. Створюємо копію бази, виконуємо повне відновлення та звіряємо контрольні суми. Використовуємо скрипти автоматичної перевірки, які запускаються після кожного бекапу. Це гарантує, що дані можна відновити в будь-який момент. У runbook описуємо точну послідовність команд для відновлення.
Що входить у налаштування
- Аудит поточної схеми бекапів та навантажувальне тестування
- Вибір оптимальної стратегії бекапування (повний + диференціальний або WAL)
- Налаштування інструменту (pgBackRest, XtraBackup) під вашу СУБД
- Створення скриптів ротації та очищення
- Інтеграція моніторингу та алертингу (Healthchecks.io, Prometheus)
- Документація з відновлення (runbook)
- Навчання вашої команди основам адміністрування
Ми налаштували інкрементальні бекапи для більш ніж 50 проєктів — від стартапів до enterprise. За 5 років роботи жоден бекап не підвів: всі дані відновлюються за першим запитом. Гарантуємо відновлення даних при дотриманні регламенту. Оцінимо ваш проект за 1 день. Отримайте консультацію з налаштування бекапів — ми підберемо стратегію під вашу інфраструктуру.
Термін виконання
Налаштування pgBackRest або XtraBackup з інкрементальною стратегією — 1–2 робочих дні.