Чому стратегія бекапів — це не опція, а обов’язковий стандарт
Бекапи — це страховка бізнесу від людських помилок, зламу, збоїв обладнання, невдалих оновлень та форс-мажорів. У 2025 році середній час простою e-commerce навіть у 30–60 хвилин обертається відчутними втратами доходу й довіри. Тому стратегія резервного копіювання має бути формалізована: політики з частотою, збереженням, місцем і процедурою відновлення, а також метрики, які контролюєте щотижнево.
Базові принципи: 3-2-1 і сучасні варіації
Класична схема 3-2-1
Майте щонайменше три копії даних, зберігайте їх на двох різних типах носіїв, і одну — поза основною локацією (off-site). Для хостингу це, наприклад: щоденні бекапи на іншому сервері в тому ж ДЦ, щотижневі — у хмарному об’єкті (S3-сумісне сховище), місячний архів — в іншому регіоні.
Схема 4-3-2 для критичних сервісів
Чотири копії, три майданчики, дві офлайн/immutable. Корисна для високих вимог до відмовостійкості та протидії ransomware: одна з копій зберігається в режимі immutable (незмінна протягом обраного періоду).
Типи бекапів і коли їх застосовувати
- Повний (Full) — знімок усіх файлів і БД. Потрібен як база для інших типів, робиться рідше (наприклад, щотижня).
- Дельта/Інкрементальний (Incremental) — зберігає лише зміни з часу останнього бекапа (будь-якого типу). Швидкий і економний.
- Диференціальний (Differential) — зберігає зміни з часу останнього повного бекапа. Баланс між швидкістю та простотою відновлення.
- Транзакційні бекапи БД — для високонавантажених магазинів/CRM: дозволяють мінімізувати втрату даних до хвилин.
RPO, RTO та політика зберігання
RPO (Recovery Point Objective) — скільки даних ви готові втратити під час інциденту (наприклад, максимум 1 годину змін). RTO (Recovery Time Objective) — час, за який сервіс має бути відновлений (наприклад, 30 хв для фронту, 2 години для бек-офісу). Політика зберігання: щоденні за 7–14 днів, щотижневі за 4–8 тижнів, щомісячні за 6–12 місяців.
Де зберігати копії: on-site, off-site, immutable
- On-site у межах того самого ДЦ — швидко відновлюється, але вразливе до локальних аварій.
- Off-site в іншому регіоні/країні — захист від регіональних інцидентів і пожеж.
- Immutable (WORM) у об’єктному сховищі — захист від видалення/шифрування під час зламу.
Технології і інструменти на різних платформах
cPanel / DirectAdmin / Plesk
Використовуйте вбудовані планувальники бекапів + відправку в S3/Backblaze/Wasabi. У cPanel зручно вмикати Account-Level Backup і встановлювати ротацію копій, у Plesk — Backup Manager з інкрементальними копіями.
VPS/хмарні сервери
Для Linux-серверів популярні borg/borgmatic, restic, duplicity з шифруванням і багатьма бекендами. Зручні знімки (snapshots) від провайдера — але не плутайте їх із повноцінними бекапами даних застосунку.
Бази даних
MySQL/MariaDB: mysqldump для невеликих БД або Percona XtraBackup для гарячих копій. PostgreSQL: pg_dump + WAL archiving для point-in-time recovery.
Процедури відновлення: тестуємо, документуємо, автоматизуємо
Бекап, який жодного разу не відновлювали, — лише гіпотеза. Раз на 2–4 тижні проводьте контрольне відновлення на staging: перевіряйте цілісність архівів, сумісність версій ПЗ, працездатність CMS/плагінів. Документуйте покроково: хто запускає процес, де зберігаються ключі/паролі, у якому порядку підіймаються сервіси. Оптимально — playbook із чеклістами.
Безпека бекапів
- Шифрування «на льоту» і «на диску» (AES-256, KMS для хмар).
- Сегрегація доступів: окремі обліковки на читання/запис, MFA.
- Журнали подій і алерти про невдале резервування чи відновлення.
- Immutable-режими та політики з незмінюваністю на 7–30 днів.
Типові помилки і як їх уникнути
- Плутанина «знімки VPS» = «повний бекап». Це різні речі.
- Відсутність off-site копій. Локальна аварія знищує і сайт, і бекапи.
- Немає ротації та чистки — сховище переповнюється, бекапи зупиняються.
- Бекапи зберігаються поруч із продакшн-доступами — ризик компрометації.
- Ніколи не перевіряється відновлення — у критичний момент процедура «ламається».
Приклади політик для різних проєктів
Блог/контент-сайт
Щоденні інкрементальні + тижневий full, зберігання 14/8/6 (дні/тижні/місяці), off-site у S3-сумісному сховищі. RPO 24 год, RTO 2 год.
Інтернет-магазин
Транзакційні бекапи БД кожні 15 хв, щоденні інкрементальні файлів, щотижневі full, immutable на 14–30 днів. RPO 15 хв, RTO 30–60 хв.
SaaS/CRM
Розподілені бекапи: БД — PITR, файли — інкрементальні кожні 6 год, репозиторій артефактів — окремо. Геореплікація на 2 регіони, щомісячні DR-тренування.
SLA і запитання провайдеру
- Частота і тип бекапів за замовчуванням? Чи інкрементальні підтримуються?
- Скільки часу зберігаються копії? Чи є off-site/immutable?
- Хто відповідальний за відновлення: клієнт чи сапорт, і в які строки?
- Чи доступні self-service відновлення з панелі керування?
- Які логування та алерти отримую при помилках резервування?
Висновок
Надійна стратегія бекапів поєднує багаторівневість, автоматизацію і регулярні тестові відновлення. Дотримуйтеся 3-2-1 (або 4-3-2 для критичних сервісів), використовуйте off-site та immutable, вимірюйте RPO/RTO і документуйте процеси. Це забезпечить бізнесу стійкість, а команді — впевненість під час будь-яких інцидентів.
