Як налаштувати автоматичний бекап за правилом 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 — менше 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/

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

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. Гарантуємо відновлення з бекапу. Замовте консультацію — ми підберемо оптимальну стратегію для вашого проекту. Хочете убезпечити свій проект? Зв'яжіться з нами — оцінимо інфраструктуру за один день і запропонуємо оптимальну стратегію.

Технічна підтримка сайту: оновлення, моніторинг, SLA

Сайт на Laravel 8 з PHP 7.4. PHP 7.4 більше не підтримується, Laravel 8 — теж не отримує оновлень безпеки. Хостинг-провайдер попередив про обов'язкове оновлення PHP до 8.1 — після оновлення два плагіни та одна бібліотека зламалися, сайт упав. Ми регулярно стикаємося з такими сценаріями: проект без регулярного ТО перетворює кожне оновлення середовища на аварію.

Цей кейс — не виняток, а правило. Комерційні сайти втрачають конверсію через повільне завантаження, вразливості, недоступність. Ми беремо на себе моніторинг, оновлення залежностей, бекапи та SLA — щоб ви займалися бізнесом, а не сервером.

Без системної підтримки кожне оновлення середовища стає сюрпризом: ламаються залежності, падає продуктивність, з'являються діри безпеки. Технічна підтримка сайту — це страховка від таких сюрпризів та гарантія стабільної роботи.

Що реально входить у технічну підтримку сайту?

Підтримка — не «відповісти на дзвінок, коли щось зламалося». Це систематичне запобігання поломкам.

Оновлення залежностей. Composer packages, npm packages, CMS або фреймворк. composer audit та npm audit показують відомі вразливості. Dependabot або Renovate створюють автоматичні PR — завдання підтримки перевірити, що оновлення не зламало staging, і змержити.

Оновлення бувають: patch (1.2.3 → 1.2.4, тільки bugfix, безпечно), minor (1.2.0 → 1.3.0, нові фічі зі зворотною сумісністю, зазвичай безпечно), major (1.x → 2.x, ламаючі зміни, вимагають тестування). Ігнорувати оновлення 6+ місяців — накопичити техборг: розрив більший, роботи більше.

WordPress — окрема розмова. Популярність платформи робить її головною ціллю атак. Застарілі плагіни — вектор №1 зломів. Регулярні оновлення ядра, плагінів, тем + правильні дозволи файлової системи + WAF — необхідний мінімум. Наш досвід показує, що автоматичні оновлення WordPress Core без тестового середовища — ризик, який ми не допускаємо.

Як моніторинг запобігає простоям?

Uptime моніторинг. Базовий HTTP-чек раз на хвилину. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Алерт у Telegram або Slack при падінні — і сповіщення при відновленні. Якщо сайт недоступний 10 хвилин у робочий час — прямий збиток.

Продуктивність. TTFB, LCP, INP — відстежуємо через Google Search Console (реальні користувачі, CrUX) та синтетичний моніторинг (Lighthouse CI, SpeedCurve). Деградація часто поступова — без моніторингу ви помічаєте через місяць, коли LCP вже 5s.

Помилки додатку. Sentry — стандарт для відстеження JavaScript та PHP/Python помилок у реальному часі. Кожен необроблений виняток із трасуванням стеку, контекстом запиту, версією браузера. Особливо важливо для помилок, які користувачі не повідомляють — вони просто йдуть.

База даних. Зростання об'єму, повільні запити (MySQL slow query log, pg_stat_statements для PostgreSQL), розмір індексів. Таблиця без VACUUM у PostgreSQL розростається до гігабайт через dead tuples. Рутинне обслуговування БД — частина підтримки.

Дисковий простір та логи. logrotate налаштований? /var/log/nginx росте без обмежень і заповнює диск — класика. Автоматична ротація + алерт при disk > 80%.

Чому бекапи без перевірки — ілюзія?

Бекап без перевірки відновлення — не бекап, а ілюзія безпеки. Бачили випадки, коли mysqldump створював файл 0 байт через помилку прав, а ніхто не перевіряв вміст місяцями. Ми гарантуємо, що всі копії працездатні.

Схема бекапів:

• Щоденний інкрементальний бекап бази даних + медіафайли
• Щотижневий повний бекап
• Зберігання: мінімум 3 копії, 2 різних медіа, 1 offsite (S3, Backblaze B2)
• Автоматична перевірка цілісності (pg_restore --list, mysqldump verify)
• Тестове відновлення раз на квартал в ізольоване середовище

Retention політика: 7 щоденних, 4 щотижневих, 3 щомісячних. S3 Lifecycle rules автоматизують видалення.

SLA: що це означає на практиці

SLA (Service-Level Agreement) Wikipedia — конкретні зобов'язання щодо часу реакції та відновлення:

SLA має сенс тільки за наявності моніторингу — інакше про проблеми дізнаються від користувачів, а не від систем. Неробоча кнопка у формі може непомітно вбивати конверсію тижнями.

Процес оновлення контенту

Розробник не повинен бути в ланцюжку для правки тексту на сторінці. CMS зі зручним редактором, розмежування прав (редактор править контент, не чіпає код), історія змін. Для Laravel-проектів — Nova, Filament, або headless CMS (Strapi, Contentful) залежно від складності.

Preview перед публікацією, staged rollout для важливих змін. Якщо редактори працюють напряму з prod — це ризик.

Типові ситуації, які вирішуємо

Злом сайту: аналіз вектора атаки, очищення, посилення безпеки (WAF, fail2ban, обмеження прав файлової системи). Відновлення з бекапу займає години, а не дні — якщо бекапи налаштовані правильно. Регулярна підтримка запобігає таким інцидентам.

Падіння продуктивності після оновлення: feature flag + можливість швидкого rollback. Canary деплой — оновлюємо 5% трафіку, дивимось метрики, потім 100%.

Що входить у пакет підтримки (deliverables)

При укладенні договору ви отримуєте:

• Документація: схема інфраструктури, доступи, процедури відновлення
• Моніторинг: uptime, продуктивність, помилки, логи — налаштований з першого дня
• Резервне копіювання: щоденні/щотижневі копії з перевіркою
• Оновлення залежностей: щомісячний аудит та оновлення з тестуванням
• SLA-реагування: за пріоритетами з таблиці вище
• Звіти: щотижневі дашборди, щомісячний огляд, квартальний техплан
• Підтримка редагування контенту: навчання редакторів, налаштування прав

Зв'яжіться з нами, щоб підібрати відповідний план та отримати первинний аудит стану вашого проекту.

Як ми працюємо: етапи

1. Онбординг (3–5 днів): аудит поточного стану, налаштування моніторингу та бекапів, документування інфраструктури.
2. Регулярний ритм: щотижневий звіт за метриками, щомісячний огляд оновлень, квартальний технічний аудит.
3. Реагування: за SLA, з фіксацією причини та часу вирішення.
4. Розвиток: за вашим запитом — новий функціонал, оптимізація, рефакторинг.

Ми працюємо з 2016 року, підтримуємо понад 50 проектів від лендінгів до маркетплейсів.

Строки та вартість

Налаштування моніторингу та бекапів: 3–5 днів. Регулярна підтримка — ongoing контракт з фіксованим об'ємом годин на місяць або абонемент. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — оцінимо ваш проект за 1–2 дні.

Порівняння: моніторинг з автоматичним алертингом vs ручна перевірка

Автоматичний моніторинг Better Uptime в 10 разів швидше реагує на збої, ніж ручна перевірка.