Автоматичне резервне копіювання бази даних сайту

Як налаштувати автоматичне резервне копіювання бази даних без втрати даних?

Ми часто стикаємося з ситуацією, коли власник сайту впевнений, що бекапи є, але при реальній аварії з'ясовується: копія зберігається на тому ж сервері, файли биті або взагалі відсутні. Втрата бази даних — втрата бізнесу. Наприклад, нещодавно до нас звернувся інтернет-магазин: жорсткий диск вийшов з ладу, а єдиний backup лежав на тому ж диску. В результаті — дві доби простою та збитки понад $10 000. Після налаштування автоматичного бекапу за стратегією 3-2-1 відновлення зайняло 15 хвилин. Наша команда вже 5+ років допомагає бізнесу уникати таких катастроф. Ми налаштовуємо автоматичне резервне копіювання баз даних, використовуючи шифрування (GPG/AES-256), автоматичну ротацію та регулярне тестування відновлення. Результат — ви відновлюєте дані за 15 хвилин, а не добу. У статті розберемо реальні конфіги для PostgreSQL, MySQL і Laravel, які ми використовуємо в продакшені. Наші інженери мають сертифікати AWS Certified Solutions Architect та Linux Professional Institute. Гарантуємо, що backup працюватиме і відновлення пройде без сюрпризів. Оцінимо ваш проект безкоштовно — просто зв'яжіться з нами.

Які проблеми вирішуємо? — автоматичне резервне копіювання

• Відсутність бекапу: до 40% сайтів малого бізнесу не мають резервних копій.
• Локальний backup: при збої сервера втрачається і сайт, і копія.
• Ніхто не перевіряє відновлення: backup вважається робочим, поки не знадобиться.
• Ручний запуск: забули, зробили не вчасно — дані за останні години втрачені.

Як ми це робимо: стек і конфіги

PostgreSQL: автоматичний backup скрипт

#!/bin/bash # /usr/local/bin/pg-backup.sh set -euo pipefail DB_NAME="myapp" DB_USER="myapp" BACKUP_DIR="/var/backups/postgresql" S3_BUCKET="s3://myapp-backups/postgresql" RETAIN_LOCAL=7 # днів RETAIN_S3=30 # днів TIMESTAMP=$(date +%Y-%m-%d_%H-%M-%S) BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_${TIMESTAMP}.sql.gz" mkdir -p "$BACKUP_DIR" # Дамп з компресією pg_dump -U "$DB_USER" -Fp --no-owner --no-acl "$DB_NAME" | \ gzip -9 > "$BACKUP_FILE" BACKUP_SIZE=$(du -sh "$BACKUP_FILE" | cut -f1) echo "[$(date)] Backup created: $BACKUP_FILE ($BACKUP_SIZE)" # Завантажити в S3 aws s3 cp "$BACKUP_FILE" "${S3_BUCKET}/${DB_NAME}_${TIMESTAMP}.sql.gz" \ --storage-class STANDARD_IA # Видалити локальні бекапи старші за N днів find "$BACKUP_DIR" -name "*.sql.gz" -mtime "+${RETAIN_LOCAL}" -delete # Видалити старі бекапи з S3 aws s3 ls "${S3_BUCKET}/" | \ awk '{print $4}' | \ sort | \ head -n -"$RETAIN_S3" | \ xargs -I{} aws s3 rm "${S3_BUCKET}/{}" echo "[$(date)] Backup completed successfully" 

# Crontab: щоденний backup о 2:00 0 2 * * * /usr/local/bin/pg-backup.sh >> /var/log/pg-backup.log 2>&1 # Laravel schedule (у файлі app/Console/Kernel.php) $schedule->command('backup:run')->daily()->at('02:00'); $schedule->command('backup:clean')->daily()->at('03:00'); $schedule->command('backup:monitor')->dailyAt('07:00'); 

MySQL/MariaDB backup

#!/bin/bash MYSQL_DEFAULTS_FILE="/etc/mysql/backup.cnf" # містить [client] user/password TIMESTAMP=$(date +%Y-%m-%d_%H-%M-%S) # --single-transaction для InnoDB (без блокувань) mysqldump \ --defaults-extra-file="$MYSQL_DEFAULTS_FILE" \ --single-transaction \ --routines \ --triggers \ --events \ myapp | gzip -9 > "/var/backups/mysql/myapp_${TIMESTAMP}.sql.gz" 

Laravel Spatie Backup

Пакет spatie/laravel-backup автоматизує backup БД і файлів:

// config/backup.php return [ 'backup' => [ 'name' => 'myapp', 'source' => [ 'databases' => ['mysql'], 'files' => [ 'include' => [storage_path('app')], 'exclude' => [storage_path('app/temp')], ], ], 'destination' => [ 'disks' => ['s3'], 'filename_prefix' => 'backup_', ], 'temporary_directory' => storage_path('app/backup-temp'), ], 'cleanup' => [ 'keep_all_backups_for_days' => 7, 'keep_daily_backups_for_days' => 30, 'keep_weekly_backups_for_weeks' => 8, 'keep_monthly_backups_for_months' => 4, 'delete_oldest_backups_when_using_more_megabytes_than' => 5000, ], ]; 

Перевірка відновлення

Backup без перевірки — не backup. Автоматичне тестування:

#!/bin/bash # Відновити останній backup у тестову БД і перевірити LATEST=$(ls -t /var/backups/postgresql/*.sql.gz | head -1) gunzip -c "$LATEST" | psql -U postgres -d myapp_test # Перевірити кількість записів USERS=$(psql -U postgres -d myapp_test -t -c "SELECT COUNT(*) FROM users;") ORDERS=$(psql -U postgres -d myapp_test -t -c "SELECT COUNT(*) FROM orders;") if [ "$USERS" -gt 0 ] && [ "$ORDERS" -gt 0 ]; then echo "Backup verification OK: $USERS users, $ORDERS orders" # Відправити OK статус в healthchecks.io curl -fsS https://hc-ping.com/your-uuid > /dev/null else echo "Backup verification FAILED" # Алерт fi psql -U postgres -c "DROP DATABASE myapp_test;" 

Чому важливо тестувати відновлення?

Навіть ідеально налаштований backup може виявитися марним, якщо файл пошкоджений або несумісний з версією СУБД. Ми автоматично відновлюємо останню копію в тестову БД і звіряємо кількість записів. Якщо перевірка не пройшла — миттєвий алерт у Telegram. На одному проекті це врятувало від втрати даних: виявилося, що скрипт тривалий час створював порожні архіви через помилку в конфігурації.

Параметри резервного копіювання: частота, ротація, шифрування

Наш процес роботи

1. Аналіз: визначаємо критичність даних, навантаження, бюджет.
2. Проектування: обираємо стратегію 3-2-1, розклад, шифрування.
3. Реалізація: пишемо скрипти, налаштовуємо cron, підключаємо хмарне сховище.
4. Тестування: автоматичне відновлення на тестову БД, звірка цілісності.
5. Моніторинг: алерти в Slack/Telegram, дашборд статусів.
6. Документація: передаємо вам інструкцію та доступи.

Що входить в роботу

• Скрипти бекапу для PostgreSQL/MySQL (адаптація під ваше середовище).
• Налаштування ротації (локально 7 днів, в S3 30 днів).
• Шифрування архівів (GPG/AES-256).
• Моніторинг healthchecks.io + Slack-сповіщення.
• Тестування відновлення раз на місяць.
• Документація: як запустити, як відновити, контакти підтримки.

Порівняння: саморобний backup vs професійне налаштування

Чому варто довірити налаштування нам?

5+ років досвіду, 50+ проектів з бекапами, сертифікати AWS і Linux. Гарантуємо, що ваші дані можна буде відновити за 15 хвилин. У нас є ліцензія на ПЗ для моніторингу. Ми супроводжуємо кожен проект: відповідаємо на питання, оновлюємо скрипти при міграції. Зв'яжіться з нами для консультації та отримайте безкоштовну оцінку поточної схеми резервування.

Строки орієнтовно

Від 1 до 3 днів залежно від складності. Вартість розраховується індивідуально. Замовте налаштування backup — убезпечте свій бізнес від втрати даних.