Как настроить автоматическое резервное копирование базы данных без потери данных?
Мы часто сталкиваемся с ситуацией, когда владелец сайта уверен, что бэкапы есть, но при реальной аварии выясняется: копия хранится на том же сервере, файлы битые или вообще отсутствуют. Потеря базы данных — потеря бизнеса. Например, недавно к нам обратился интернет-магазин: жёсткий диск вышел из строя, а единственный 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. На одном проекте это спасло от потери данных: оказалось, что скрипт долгое время создавал пустые архивы из-за ошибки в конфигурации.
Параметры резервного копирования: частота, ротация, шифрование
| Параметр | Рекомендуемое значение | Комментарий |
|---|---|---|
| Частота | Ежедневно + WAL каждые 6 часов | Для high-load проектов — hourly |
| Хранение локально | 7 дней | Используем find с -mtime |
| Хранение в облаке | 30 дней (S3 Standard-IA) | Для архива — Glacier (90 дней) |
| Шифрование | GPG с ключом 4096 бит | AES-256 также доступен |
| Тестирование | Ежемесячно | Healthchecks.io + Telegram |
Наш процесс работы
- Анализ: определяем критичность данных, нагрузку, бюджет.
- Проектирование: выбираем стратегию 3-2-1, расписание, шифрование.
- Реализация: пишем скрипты, настраиваем cron, подключаем облачное хранилище.
- Тестирование: автоматическое восстановление на тестовую БД, сверка целостности.
- Мониторинг: алерты в Slack/Telegram, дашборд статусов.
- Документация: передаём вам инструкцию и доступы.
Что входит в работу
- Скрипты бэкапа для PostgreSQL/MySQL (адаптация под вашу среду).
- Настройка ротации (локально 7 дней, в S3 30 дней).
- Шифрование архивов (GPG/AES-256).
- Мониторинг healthchecks.io + Slack-уведомления.
- Тестирование восстановления раз в месяц.
- Документация: как запустить, как восстановить, контакты поддержки.
Сравнение: самодельный backup vs профессиональная настройка
| Критерий | Самодельный скрипт | Наша настройка |
|---|---|---|
| Автоматизация | Часто забывают обновлять | Cron + мониторинг |
| Ротация | Ручная чистка | Автоматическая, с настраиваемым сроком |
| Шифрование | Редко | Всегда, с GPG |
| Проверка | Никогда | Ежемесячно, с отчётом |
| Восстановление | Вручную | Скрипт в 1 команду |
| Оповещения | Нет | Slack/Telegram |
Кейс из практики: восстановление после сбоя
Клиент — интернет-магазин с PostgreSQL. Однажды ночью произошёл сбой RAID-массива. Благодаря настроенному бэкапу с ротацией 7/30 дней, мы восстановили базу на новый сервер за 20 минут. Потери данных — 0. Без backup простой составил бы минимум 2 дня, а упущенная выручка — около $15 000.
Почему стоит доверить настройку нам?
5+ лет опыта, 50+ проектов с бэкапами, сертификаты AWS и Linux. Гарантируем, что ваши данные можно будет восстановить за 15 минут. У нас есть лицензия на ПО для мониторинга. Мы сопровождаем каждый проект: отвечаем на вопросы, обновляем скрипты при миграции. Свяжитесь с нами для консультации и получите бесплатную оценку текущей схемы резервирования.
Сроки ориентировочно
От 1 до 3 дней в зависимости от сложности. Стоимость рассчитывается индивидуально. Закажите настройку backup — обезопасьте свой бизнес от потери данных.