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

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

Ми часто стикаємося з ситуацією, коли власник сайту впевнений, що бекапи є, але при реальній аварії з'ясовується: копія зберігається на тому ж сервері, файли биті або взагалі відсутні. Втрата бази даних — втрата бізнесу. Наприклад, нещодавно до нас звернувся інтернет-магазин: жорсткий диск вийшов з ладу, а єдиний 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 — убезпечте свій бізнес від втрати даних.