Як налаштувати автоматичний бекап за правилом 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 — менше 5 рублів на місяць, тоді як втрата даних може коштувати мільйони. Це вкладення, яке окупається при першій же аварії. Наприклад, щомісячні витрати на зберігання 50 ГБ бекапів — близько 25 рублів. А відновлення даних після збою може коштувати сотні тисяч рублів. Економія очевидна.
Які дані бекапимо в першу чергу
База даних — головне джерело змін. Для автоматичного бекапу сайту на 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/ Етапи налаштування бекапу
- Оцінка обсягу даних: визначаємо розмір БД, файлів та їх темп зростання.
- Вибір стратегії: частота бекапів, глибина зберігання, класи S3.
- Написання скриптів: pg_dump, rsync, aws cli.
- Налаштування crontab: для БД — кожні 6 годин, для файлів — раз на добу.
- Налаштування S3 Lifecycle: автоматична ротація та видалення старих копій.
- Тестове відновлення: імітація збою та перевірка 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, виконано тестове відновлення, налаштований моніторинг з алертами, та передана документація клієнту.
Самописний скрипт чи готовий плагін: що обрати?
| Критерій | Самописний bash-скрипт | Готовий сервіс (UpdraftPlus, BlogVault) |
|---|---|---|
| Гнучкість | Повний контроль | Обмежений налаштуваннями |
| Вартість | Тільки витрати S3 | Щомісячна підписка |
| Час налаштування | 2–4 години | 30 хвилин |
| Відновлення | Будь-яка частина даних | Тільки повний restore |
Самописний скрипт виправданий при кастомних сценаріях: ротація, декілька БД, інтеграція з моніторингом. Для простих сайтів готові плагіни швидше, але ми рекомендуємо гібридний підхід.
Рекомендована політика зберігання
| Тип бекапу | Інтервал | Термін зберігання | Клас S3 |
|---|---|---|---|
| База даних (daily) | 6 годин | 7 днів | STANDARD |
| База даних (weekly) | 1 тиждень | 30 днів | STANDARD_IA |
| База даних (monthly) | 1 місяць | 90 днів | GLACIER |
| Файли (daily) | 1 день | 30 днів | STANDARD_IA |
| Файли (monthly) | 1 місяць | 12 місяців | GLACIER_DEEP_ARCHIVE |
Як налаштувати Lifecycle Policy через AWS CLI
Виконайте команду: `aws s3api put-bucket-lifecycle-configuration --bucket my-backups --lifecycle-configuration file://lifecycle.json`Наші інженери сертифіковані AWS та PostgreSQL. Гарантуємо відновлення з бекапу. Замовте консультацію — ми підберемо оптимальну стратегію для вашого проекту. Хочете убезпечити свій проект? Зв'яжіться з нами — оцінимо інфраструктуру за один день і запропонуємо оптимальну стратегію.







