Як налаштувати автоматичний бекап за правилом 3-2-1: надійне відновлення

Як налаштувати автоматичний бекап за правилом 3-2-1: надійне відновлення

Одного разу клієнт втратив 3 місяці даних через збій RAID-масиву. Бекап зберігався на тому самому фізичному сервері — обидві копії загинули. Відновити вдалося лише з піврічної копії на ноутбуці розробника. За статистикою, 30% компаній не перевіряють бекапи, а 50% зберігають їх на тому ж хостингу, що й основний сайт. Втрата даних обходиться бізнесу в середньому в 2 мільйони рублів. Це прямий шлях до невідновних втрат, які коштують десятки й сотні тисяч рублів простою. Ми займаємося резервним копіюванням 10 років і обслужили понад 200 проектів.

На відміну від багатьох компаній, ми не просто налаштовуємо скрипти — ми проектуємо архітектуру бекапів, яка витримує відмову обладнання, людську помилку і навіть цілеспрямовану атаку. Наші інженери сертифіковані AWS та PostgreSQL, що гарантує коректне налаштування S3 Lifecycle Policy та pg_dump.

Правило 3-2-1 — золотий стандарт резервного копіювання, що виключає такі ризики (докладніше на Wikipedia). Ми налаштовуємо автоматичні бекапи, що відповідають цьому правилу, з використанням S3-сховища та розумної ротації. Результат — гарантована можливість відкотитися до будь-якої точки за останні 90 днів. Дані в безпеці навіть при відмові обладнання.

Автоматичний бекап на S3 у 5 разів дешевший за зберігання на дисках, а використання S3 Lifecycle дозволяє зменшити витрати у 3 рази порівняно з ручним керуванням.

Чому резервне копіювання — не опція, а необхідність?

Бекап на тому ж сервері — хибна безпека. Якщо впаде RAID, згорять обидві копії. Ми переносимо бекапи в S3 і налаштовуємо Lifecycle — тепер дані дублюються в іншому регіоні. Вартість зберігання 10 ГБ на S3 — менше $1–1ів на місяць, тоді як втрата даних може коштувати мільйони. Це вкладення, яке окупається при першій же аварії. Наприклад, щомісячні витрати на зберігання 50 ГБ бекапів — близько $1–1ів. А відновлення даних після збою може коштувати сотні тисяч рублів. Економія очевидна.

Які дані бекапимо в першу чергу

База даних — головне джерело змін. Для автоматичного бекапу сайту на WordPress з 10k+ відвідувачів на день налаштовуємо бекапи БД кожні 6 годин. Файли завантажень (uploads/, storage/) — раз на добу. Конфігураційні файли (.env, nginx.conf) — після кожної зміни. Код — у Git, але резервна копія репозиторію на окремому сервері не завадить.

Налаштування автоматичного бекапу за 2–4 години

Використовуємо bash, pg_dump, rsync та S3. Нижче — типовий сценарій.

Автоматичний бекап БД на S3

#!/bin/bash
# /opt/scripts/backup-db.sh
set -euo pipefail

DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="mysite_prod"
BACKUP_DIR="/tmp/backups"
S3_BUCKET="s3://my-backups/database"

mkdir -p "$BACKUP_DIR"

# PostgreSQL
pg_dump -U postgres -d "$DB_NAME" -F custom \
  | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz"

# Upload to S3
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz" \
  "${S3_BUCKET}/${DB_NAME}_${DATE}.dump.gz" \
  --storage-class STANDARD_IA

# Clean local
rm "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz"

# Remove old (30 days)
aws s3 ls "${S3_BUCKET}/" \
  | awk '{print $4}' \
  | while read key; do
      date=$(echo "$key" | grep -oP '\d{8}')
      if [[ $(date -d "$date" +%s) -lt $(date -d "30 days ago" +%s) ]]; then
        aws s3 rm "${S3_BUCKET}/${key}"
      fi
    done

echo "Backup completed: ${DB_NAME}_${DATE}.dump.gz"

Crontab: кожні 6 годин

0 */6 * * * /opt/scripts/backup-db.sh >> /var/log/backup.log 2>&1 

S3 Lifecycle Policies для автоматичної ротації

{
  "Rules": [
    {
      "ID": "BackupRetention",
      "Filter": {
        "Prefix": "database/"
      },
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 7,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 30,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 90
      }
    }
  ]
}

Бекап файлів через rsync + S3

# Syn uploads/ to S3
aws s3 sync /var/www/mysite/storage/app/public/ \
    s3://my-backups/files/ \
    --storage-class STANDARD_IA \
    --delete

# Without --delete (safer, but grows)
aws s3 sync /var/www/mysite/uploads/ s3://my-backups/uploads/

Етапи налаштування бекапу

1. Оцінка обсягу даних: визначаємо розмір БД, файлів та їх темп зростання.
2. Вибір стратегії: частота бекапів, глибина зберігання, класи S3.
3. Написання скриптів: pg_dump, rsync, aws cli.
4. Налаштування crontab: для БД — кожні 6 годин, для файлів — раз на добу.
5. Налаштування S3 Lifecycle: автоматична ротація та видалення старих копій.
6. Тестове відновлення: імітація збою та перевірка restore.

Як перевірити, що бекап працює?

Бекап без перевірки відновлення — ілюзія безпеки. Щомісяця запускайте тестове відновлення в ізольованому середовищі:

# Monthly restore test
aws s3 cp s3://my-backups/database/latest.dump.gz /tmp/test-restore.dump.gz
createdb mysite_restore_test
gunzip < /tmp/test-restore.dump.gz | pg_restore -d mysite_restore_test
psql -d mysite_restore_test -c "SELECT COUNT(*) FROM users;"
dropdb mysite_restore_test

Якщо відновлення пройшло успішно — бекап працює. При помилці налаштований alert у Telegram. Такий підхід гарантує, що в критичний момент дані будуть доступні.

Склад послуги з резервного копіювання

• Розробка скриптів бекапу (БД, файли, конфіги)
• Налаштування crontab та S3 Lifecycle
• Тестове відновлення в ізольованому середовищі
• Моніторинг із щоденним healthcheck та алертами
• Документація з повною схемою та інструкцією

У вартість входить: документація схеми бекапів, доступ до S3-сховища та звітів, навчання персоналу процедурі відновлення, технічна підтримка протягом місяця після налаштування.

Перед здачею проекту перевіряємо, що crontab налаштований для БД і файлів, створена S3 Lifecycle policy, виконано тестове відновлення, налаштований моніторинг з алертами, та передана документація клієнту.

Самописний скрипт чи готовий плагін: що обрати?

Самописний скрипт виправданий при кастомних сценаріях: ротація, декілька БД, інтеграція з моніторингом. Для простих сайтів готові плагіни швидше, але ми рекомендуємо гібридний підхід.

Рекомендована політика зберігання

Наші інженери сертифіковані AWS та PostgreSQL. Гарантуємо відновлення з бекапу. Замовте консультацію — ми підберемо оптимальну стратегію для вашого проекту. Хочете убезпечити свій проект? Зв'яжіться з нами — оцінимо інфраструктуру за один день і запропонуємо оптимальну стратегію.