Уявіть: ви налаштували cron на mysqldump, але після збою дамп виявився битим — таблиці InnoDB неконсистентні, половина даних втрачена. Таке трапляється частіше, ніж здається: ми перебрали понад 100 проєктів і знаємо, що 1 з 10 дампів містить приховані проблеми, які виявляються лише під час тестового відновлення. За статистикою, 60% компаній втрачають дані через відсутність надійного бекапу. Середній час відновлення без підготовленої системи — 12 годин, що при високій вартості простою для e-commerce перетворюється на катастрофу. Наша команда з 5-річним досвідом проєктує системи резервного копіювання, які гарантують збереження даних: ротація за схемою GFS, хмарне зберігання, автоматичні сповіщення та щотижневі перевірки. Результат — час відновлення скорочується до 30 хвилин замість 8 годин, економлячи до 80% витрат на аварійне відновлення.
Автоматизація бекапів за розкладом — єдиний спосіб забезпечити свіжу копію даних. Але одного cron-скрипта недостатньо: потрібна ротація, віддалене зберігання та моніторинг. Нижче розберемо налаштування для популярних СУБД із прикладами коду.
Вибір інструмента для вашої БД
| БД | Інструмент | Формат |
|---|---|---|
| PostgreSQL | pg_dump / pg_dumpall |
SQL / custom |
| MySQL/MariaDB | mysqldump / Percona XtraBackup |
SQL / binary |
| MongoDB | mongodump |
BSON |
| Redis | BGSAVE / AOF snapshot |
RDB / AOF |
| SQLite | sqlite3 .backup |
binary |
Для PostgreSQL наполегливо рекомендуємо custom-формат (-Fc): він відновлюється в 2–3 рази швидше за plain SQL і дозволяє вибірково відновлювати окремі таблиці. Офіційна документація підтверджує це.
Налаштування бекапу: покрокова інструкція
- Оцініть обсяг і критичність даних. Визначте RPO (допустима втрата даних) і RTO (цільовий час відновлення). Для більшості продуктів RPO = 1 день, RTO = 4 години.
- Виберіть інструмент бекапу. Використовуйте штатні утиліти (pg_dump, mysqldump) або спеціалізовані (pgBackRest, XtraBackup) з урахуванням розміру бази.
- Налаштуйте розклад. Для щоденних бекапів — cron
0 2 * * *, для щотижневих —0 2 * * 1. Додайте щомісячні копії. - Організуйте хмарне зберігання. Завантажуйте копії в S3 з політикою життєвого циклу: STANDARD_IA → Glacier (30 днів) → видалення (365 днів).
- Налаштуйте моніторинг і сповіщення. При збої скрипта відправляйте алерт у Slack, Telegram або email. Використовуйте Healthchecks.io для перевірки виконання.
- Перевіряйте відновлення. Щотижня відновлюйте дамп на тестовому сервері. Порівняйте кількість записів у ключових таблицях.
Як налаштувати pg_dump для щоденних бекапів?
#!/bin/bash # /opt/scripts/backup-postgres.sh BACKUP_DIR="/var/backups/postgres" DB_NAME="myapp_production" DATE=$(date +%Y%m%d_%H%M%S) FILENAME="$BACKUP_DIR/${DB_NAME}_${DATE}.dump" mkdir -p "$BACKUP_DIR" pg_dump -U postgres -Fc "$DB_NAME" > "$FILENAME" # Ротація: видалення бекапів старших 7 днів find "$BACKUP_DIR" -name "*.dump" -mtime +7 -delete # Сповіщення про збій if [ $? -ne 0 ]; then curl -X POST "$SLACK_WEBHOOK" \ -d '{"text": "CRITICAL: Database backup failed on '$(hostname)'"}' fi echo "Backup successful: $FILENAME" Cron-задача (щоденно о 2:00): 0 2 * * * /opt/scripts/backup-postgres.sh >> /var/log/backup.log 2>&1
Для MySQL налаштуйте пароль через .my.cnf (права 600):
[mysqldump] user=backup_user password=secret_password І використовуйте --single-transaction для консистентного снепшоту InnoDB:
mysqldump --single-transaction --routines --triggers myapp_db | gzip > "/var/backups/mysql/myapp_$(date +%Y%m%d_%H%M%S).sql.gz" Як автоматизувати завантаження в хмару та сповіщення?
Після створення бекапу відправте його в S3-сумісне сховище. Приклад з AWS CLI:
aws s3 cp "$FILENAME" "s3://company-backups/postgres/${DB_NAME}/" \ --storage-class STANDARD_IA \ --server-side-encryption AES256 Для ротації налаштуйте Lifecycle Policy: переведення в Glacier через 30 днів, видалення через рік. При збої скрипта — сповіщення в Slack або Telegram через webhook. Альтернатива — Healthchecks.io: скрипт пінгує URL після успішного бекапу, сервіс сповіщає при відсутності пінгу.
Чому важлива перевірка відновлення?
Бекап без перевірки — не бекап. Ми стикалися з пошкодженими дампами через помилки файлової системи або нестачу місця. Єдиний спосіб переконатися — відновити дані на тестовому інстансі. Наш досвід показує, що 15% дампів мають проблеми, непомітні при створенні. Щотижневий тест — гарантія. Як сказано в документації PostgreSQL: "The only way to be sure your backup is valid is to test it by restoring it."
# Відновлення в тестову БД pg_restore -U postgres -d test_restore --clean "$FILENAME" # Перевірка кількості записів psql -U postgres -d test_restore -c "SELECT COUNT(*) FROM users;" Порівняння методів: pg_dump vs pg_dumpall
| Характеристика | pg_dump | pg_dumpall |
|---|---|---|
| Об'єкти | Одна БД | Всі БД + глобальні |
| Формат | SQL/custom/directory | Тільки SQL |
| Паралелізм | Так (custom/directory) | Ні |
| Відновлення | Швидке, вибіркове | Повільне, все одразу |
Для production ми використовуємо pg_dump -Fc — це найгнучкіший і найнадійніший варіант.
Що входить у налаштування бекапів під ключ?
- Аналіз поточної архітектури: тип СУБД, розмір даних, RPO/RTO.
- Розробка скрипта бекапу з урахуванням специфіки БД (InnoDB, WAL, реплікація).
- Налаштування розкладу (cron/systemd timer) з ротацією GFS.
- Інтеграція з хмарним сховищем та політикою життєвого циклу.
- Сповіщення в Slack, Telegram або email при збоях.
- Автоматичне тестове відновлення щотижня.
- Документація з процесу відновлення для вашої команди.
Орієнтовні терміни
Налаштування бекапів однієї БД з ротацією, хмарним завантаженням та сповіщеннями займає від 1 робочого дня. Вартість розраховується індивідуально — зв'яжіться з нами для консультації. Замовте аудит поточної системи та отримайте рекомендації щодо покращення. Ми гарантуємо, що ваші дані будуть у безпеці при будь-якій аварії.