Резервне копіювання сайту: як налаштувати бекапи та відновлення у 2026 році

Резервна копія потрібна не для звіту «бекап створено», а для швидкого повернення сайту до роботи. Якщо архів пошкоджений, зберігається поруч із сайтом або ніхто не знає, як його відновити, він майже не зменшує ризик. Надійна система охоплює файли, базу даних, налаштування, зовнішнє сховище, контроль результату й регулярний тест відновлення.

Коротка відповідь

Для більшості бізнес-сайтів варто налаштувати автоматичні щоденні копії файлів і бази даних, зберігати одну копію поза основним сервером та перевіряти сповіщення про помилки. Для інтернет-магазину або сервісу з частими замовленнями база може копіюватися кожні 15–60 хвилин. Частоту визначають не типом CMS, а тим, скільки нових даних бізнес готовий втратити.

Практична основа — правило 3-2-1: три копії важливих даних, два різні типи або середовища зберігання й одна копія поза основною локацією. CISA рекомендує не лише створювати, а й захищати та тестувати резервні копії.

Що саме потрібно копіювати

Сайт — це не один каталог із зображеннями. Для повного відновлення потрібен узгоджений набір компонентів.

• Файли сайту: код, тема, плагіни, завантажені зображення, документи та інші медіафайли.
• База даних: сторінки, товари, замовлення, користувачі, налаштування CMS і частина даних інтеграцій.
• Конфігурація: версія PHP, змінні середовища, правила вебсервера, cron-завдання та параметри кешування.
• DNS і SSL: перелік актуальних записів домену, порядок випуску сертифіката та доступ до реєстратора.
• Пошта: скриньки й листи, якщо вони працюють на тому самому хостинг-акаунті.
• Інтеграції: ключові налаштування CRM, оплати, доставки, аналітики та вебхуків без зберігання секретів у відкритому документі.

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

RPO і RTO: дві цифри до вибору сервісу

Перед налаштуванням розкладу визначте два показники. Google Cloud пояснює, що RPO — максимально прийнятний період втрати даних, а RTO — максимально прийнятний час недоступності системи.

Наприклад, якщо RPO магазину становить 30 хвилин, щоденної копії бази недостатньо: після збою можна втратити майже добу замовлень. Якщо RTO дорівнює двом годинам, завантаження великого архіву з повільного сховища та ручне налаштування сервера можуть не вкластися в цю ціль.

Тип сайту	Орієнтовний RPO	Орієнтовний RTO	Практичний розклад
Лендінг, що рідко змінюється	24 години	4–8 годин	Щоденна копія та копія перед змінами
Корпоративний сайт або блог	12–24 години	2–4 години	Щоденно, з довшим зберіганням тижневих копій
Інтернет-магазин	15–60 хвилин для БД	1–2 години	Часті копії БД, щоденні файли, копія перед оновленням
Онлайн-сервіс або особистий кабінет	За бізнес-вимогою, інколи хвилини	За SLA	Реплікація, журнали транзакцій і окремий план аварійного відновлення

Це стартові орієнтири, а не універсальний стандарт. Чим менші RPO та RTO, тим складніша й дорожча інфраструктура.

Як працює правило 3-2-1 для сайту

У простому варіанті першою копією є робочий сайт. Друга — автоматичний бекап у сховищі хостингу. Третя — зашифрована копія в незалежному хмарному сховищі або на іншому сервері.

Важливо, щоб зовнішня копія не залежала від того самого акаунта й диска. Якщо робочий сайт і всі архіви лежать на одному сервері, збій накопичувача, видалення акаунта або компрометація доступу може зачепити їх одночасно. CISA також радить мати захищені офлайн-копії та регулярно перевіряти процедуру відновлення у своєму керівництві з протидії ransomware.

Якою має бути політика зберігання

Один останній архів не захищає від помилки, яку помітили через тиждень. Для типового сайту можна почати з такої ротації:

• 7 щоденних копій;
• 4–5 тижневих копій;
• 6–12 місячних копій для важливих проєктів;
• окрема копія перед оновленням CMS, модуля, дизайну або великим імпортом.

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

Тестове відновлення перевіряє не лише архів, а й роботу всього сайту та інтеграцій.

Автоматизація: що має відбуватися без участі людини

Ручний бекап корисний перед конкретною зміною, але не замінює розклад. Надійний процес автоматично:

1. Створює копії файлів і бази з потрібною частотою.
2. Шифрує архів під час зберігання та передачі.
3. Відправляє копію в незалежне сховище.
4. Перевіряє завершення завдання, розмір архіву й контрольну суму.
5. Видаляє застарілі копії за політикою ротації.
6. Надсилає сповіщення про помилку відповідальній людині.

Сповіщення лише про успіх недостатньо. Потрібен контроль відсутності результату: якщо завдання взагалі не запустилося, система також повинна подати сигнал.

Чому бекап хостингу не знімає відповідальність із власника

Автоматичні копії провайдера — сильний перший рівень, але потрібно письмово з’ясувати умови:

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

Під час вибору хостингу перевіряйте не лише наявність слова «backup», а всю політику. Власна зовнішня копія зберігає можливість відновитися навіть після конфлікту доступів або перенесення сайту на інший хостинг.

Зона відповідальності	Хостинг-провайдер	Власник сайту або технічна команда
Робота серверної платформи	Підтримує інфраструктуру за умовами тарифу	Контролює, чи тариф відповідає RPO/RTO
Автоматичні копії провайдера	Створює та зберігає за своєю політикою	Перевіряє політику, строки та доступність відновлення
Незалежна зовнішня копія	Може не надавати	Налаштовує окремо та захищає доступ
Працездатність сайту після відновлення	Зазвичай відповідає лише за сервер	Перевіряє CMS, форми, оплату, CRM та інтеграції
План і тест відновлення	Надає інструменти або підтримку	Визначає відповідальних, проводить тест і фіксує результат

Як правильно тестувати відновлення

Архів вважається робочим лише після успішного відновлення. NIST включає тестування до повного циклу планування безперервності, а Google Cloud радить перевіряти не тільки дані, а й увесь стек застосунку.

Тест краще проводити на ізольованому технічному домені або staging-середовищі, не поверх робочого сайту.

1. Оберіть конкретну копію й зафіксуйте час початку.
2. Розгорніть файли, базу даних і потрібну конфігурацію.
3. Перевірте головні сторінки, авторизацію, пошук і мобільну версію.
4. Для магазину зробіть тестове замовлення, перевірте кошик, оплату, листи, склад і CRM.
5. Переконайтеся, що форми, вебхуки, cron і аналітика працюють.
6. Проскануйте журнали на помилки та виміряйте фактичний час відновлення.
7. Запишіть результат, проблему, відповідального й потрібні зміни до інструкції.

Проводьте такий тест щонайменше раз на квартал для активного бізнес-сайту, а також після значної зміни інфраструктури. Частоту можна підвищити, якщо простій має високу ціну.

Типові помилки

• Копії зберігаються на тому самому сервері. Один інцидент може знищити і сайт, і архіви.
• Копіюється лише база або лише файли. Відновлений комплект виявляється неповним.
• Немає історії версій. Пошкодження потрапляє в останню копію, а старішої чистої версії немає.
• Ніхто не читає сповіщення. Помилка триває місяцями, поки бекап не знадобиться.
• Відновлення ніколи не тестували. Інструкція застаріла, доступи втрачені або архів пошкоджений.
• Паролі до сайту й сховища однакові. Компрометація одного акаунта відкриває обидва середовища.
• У бекапі немає конфігурації та доступів. Дані є, але швидко запустити сайт неможливо.

План налаштування за один робочий день

Крок 1. Інвентаризація

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

Крок 2. Цілі відновлення

Узгодьте допустиму втрату даних (RPO) і допустимий простій (RTO). Не вимагайте «нуль втрат і нуль хвилин» без оцінки вартості.

Крок 3. Два незалежні маршрути

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

Крок 4. Моніторинг і відповідальність

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

Крок 5. Контрольне відновлення

Розгорніть копію на staging, пройдіть чекліст і порівняйте фактичний час із RTO. Після тесту виправте процес, а не лише архів.

Чекліст для власника сайту

• Чи копіюються одночасно файли, база та важлива конфігурація?
• Чи є копія поза основним сервером і окремим акаунтом?
• Який RPO та RTO встановлено для сайту?
• Скільки щоденних, тижневих і місячних версій зберігається?
• Хто отримує повідомлення про помилку?
• Коли востаннє виконувалося повне тестове відновлення?
• Чи перевірялися форми, кошик, оплата, пошта, CRM і cron після відновлення?
• Чи захищене сховище шифруванням, унікальним паролем і MFA?
• Чи існує актуальна інструкція та резервний відповідальний?

Висновок

Надійний бекап — це не архів, а перевірена здатність повернути сайт до роботи в межах визначених RPO й RTO. Найкращий базовий підхід для малого та середнього бізнесу: автоматизація, правило 3-2-1, незалежне сховище, історія версій, сповіщення й регулярне тестове відновлення.

BB STUDIO може перевірити поточну схему копіювання, налаштувати незалежні резервні копії та провести контрольне відновлення. Дізнайтеся більше про хостинг із щоденними бекапами або напишіть нам, щоб отримати технічний план для вашого сайту.

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

Як часто робити резервну копію сайту?

Частота залежить від допустимої втрати даних. Для статичного лендінгу часто достатньо щоденної копії та копії перед змінами. Для магазину база може потребувати копіювання кожні 15–60 хвилин, а файли — щодня.

Чи достатньо автоматичних бекапів хостингу?

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

Чи потрібно копіювати сайт перед оновленням WordPress?

Так. Документація WordPress нагадує про автоматичні планові копії. Перед оновленням ядра, теми або плагіна додаткова ручна точка відновлення зменшує ризик.

Чим резервна копія відрізняється від snapshot?

Snapshot швидко фіксує стан диска або сервера й зручний для оперативного повернення. Але якщо він зберігається в тій самій інфраструктурі, то не замінює незалежний offsite-бекап.

Як зрозуміти, що бекап справді працює?

Відновити його на тестовому середовищі, перевірити весь сайт та виміряти час. Сам факт створення архіву не доводить, що дані повні й придатні до використання.

---

Підготовлено командою BB STUDIO. Матеріал базується на практиці хостингу, технічної підтримки та відновлення бізнес-сайтів, а також на офіційних рекомендаціях CISA, NIST, WordPress і Google Cloud.