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

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

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Як налаштувати автоматичний бекап за правилом 3-2-1: надійне відновлення
Простий
від 4 годин до 2 днів

Наші компетенції:

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1418
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1285
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    983
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1242
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    983
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    997

Як налаштувати автоматичний бекап за правилом 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, виконано тестове відновлення, налаштований моніторинг з алертами, та передана документація клієнту.

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

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