Бекапи на хостингу: хто насправді відповідає за ваші дані і що робити, коли все зникло
Уявіть: понеділок, 9 ранку, кава ще не допита, а ваш сайт - порожній. База даних зникла. Файли - теж. Ви телефонуєте в техпідтримку хостингу, а вам відповідають: «Бекапи? Це ваша відповідальність, ми ж написали в умовах обслуговування на сторінці 47». І ось ви сидите, дивитесь у монітор і розумієте, що два роки контенту, замовлень, клієнтської історії просто випарувалися. Звучить як фільм жахів? Це реальність, з якою стикаються десятки бізнесів щомісяця. Давайте розберемось, як не стати одним із них.
Хто винен, коли бекап не спрацював
Ось найпоширеніший міф: «Хостинг-провайдер робить бекапи, тож мені нема про що хвилюватися». Це приблизно як вірити, що ваш орендодавець автоматично страхує все ваше майно в квартирі. Спойлер - ні.
Більшість хостинг-провайдерів дійсно створюють резервні копії, але роблять це для себе, а не для вас. Їхні бекапи потрібні на випадок аварії всього сервера, а не для відновлення вашого конкретного файлу, який ви випадково видалили вчора ввечері.
Що зазвичай написано в угоді про обслуговування дрібним шрифтом:
- Провайдер створює бекапи «за можливості» без гарантій повноти та актуальності
- Відновлення з бекапу провайдера - платна послуга (від $5 до $50 за запит)
- Глибина зберігання - часто лише 1-3 дні, що безглуздо, якщо проблему помітили через тиждень
- Провайдер не несе відповідальності за втрату даних навіть через свою ж аварію
Відчуваєте різницю? Бекап існує, але він - не ваш рятувальний круг. Він - рятувальний круг сервера.

Три рівні захисту, які повинен мати кожен сайт
Пам'ятаєте правило 3-2-1? Ні, це не код від сейфа. Це золотий стандарт резервного копіювання, який використовують навіть NASA та великі банки. Суть проста:
- 3 копії ваших даних (оригінал + 2 бекапи)
- 2 різних носія зберігання (наприклад, сервер хостингу + хмарне сховище)
- 1 копія за межами основної локації (географічно віддалений дата-центр або інший сервіс)
Здається складно? Насправді - ні. Для середнього WordPress-сайту це виглядає так: автоматичний щоденний бекап плагіном (UpdraftPlus, BlogVault або BackupBuddy), копія летить у Google Drive або Amazon S3, і раз на тиждень ви вручну завантажуєте архів на свій комп'ютер. Все. 15 хвилин налаштування - і ви спите спокійно.
«Бекап, який ви ніколи не тестували на відновлення - це не бекап. Це ілюзія безпеки.» - Томас Лімончеллі, автор книги «The Practice of System and Network Administration»
І ця цитата б'є в саму суть. Скільки з вас хоча б раз перевіряли, чи можна реально розгорнути сайт із того архіву, що лежить десь у хмарі? Якщо відповідь «ніколи» - у вас не бекап, а ZIP-файл з надією.
Що саме бекапити і як часто
Не всі дані однакові. Статичні сторінки сайту-візитки змінюються раз на місяць. Інтернет-магазин з десятками замовлень щодня - зовсім інша історія. Тому частота бекапів повинна відповідати швидкості змін на сайті.
| Тип сайту | Що бекапити | Рекомендована частота | Мінімальна глибина зберігання |
|---|---|---|---|
| Сайт-візитка | Файли + БД | Раз на тиждень | 30 днів |
| Блог (5-10 постів/місяць) | Файли + БД | Щодня | 14 днів |
| Інтернет-магазин | БД кожні 6 годин, файли щодня | Кожні 6-24 години | 30 днів |
| SaaS-платформа | БД в реальному часі, файли щодня | Неперервна реплікація | 60-90 днів |
| Форум/спільнота | БД + медіа-файли | Кожні 12 годин | 21 день |
Зверніть увагу: база даних і файли - це дві різні речі. Файли (теми, плагіни, зображення) змінюються рідше. База даних (замовлення, коментарі, записи) - постійно. Тому для магазину або платформи має сенс бекапити БД частіше, ніж файлову систему.
І ще один нюанс, про який забувають навіть досвідчені адміни: конфігураційні файли сервера. Налаштування nginx, .htaccess, php.ini, cron-таблиці - все це теж частина вашої інфраструктури. Втратити їх - як втратити рецепт страви, яку ви готували ідеально, але ніколи не записували.

Інструменти: від безкоштовних плагінів до enterprise-рішень
Добра новина - інструментів для бекапів більше, ніж сортів кави у вашій улюбленій кав'ярні. Погана новина - вибрати потрібний так само складно.
Для shared-хостингу найпростіший шлях - плагіни CMS. UpdraftPlus (безкоштовна версія) закриває потреби 80% WordPress-сайтів. Він вміє відправляти копії в Dropbox, Google Drive, Amazon S3 за розкладом. Налаштування займає 10 хвилин.
Для VPS і виділених серверів варто дивитись на серверні рішення:
- Restic - безкоштовний, швидкий, з дедуплікацією (зберігає тільки зміни, а не повну копію щоразу)
- BorgBackup - схожий на Restic, але з трохи іншою філософією шифрування
- Bacula / Bareos - enterprise-рівень для складних інфраструктур з десятками серверів
- Acronis Cyber Protect - комерційне рішення з вебінтерфейсом і захистом від ransomware
Принциповий момент: не зберігайте бекапи на тому ж сервері, де працює сайт. Це як ховати запасний ключ від квартири під килимком біля дверей. Якщо сервер зламають або диск помре - ви втратите і сайт, і його копію одночасно.
Відновлення: момент істини, до якого ніхто не готовий
Знаєте, що спільного між бекапами і вогнегасниками? Усі знають, що вони потрібні, але ніхто не перевіряє, чи вони працюють. Поки не загориться.
Ось алгоритм, який варто запустити хоча б раз на квартал:
- Завантажте свій останній бекап на локальний комп'ютер або тестовий сервер
- Розгорніть його в ізольованому середовищі (локальний XAMPP, Docker-контейнер або тестовий піддомен)
- Перевірте: чи відкриваються сторінки, чи працює адмінка, чи на місці замовлення та контент
- Засікіть час відновлення - це ваш RTO (Recovery Time Objective), і ви повинні знати цю цифру
- Запишіть результат і дату перевірки
Середній час повного відновлення WordPress-сайту з бекапу - від 15 хвилин до 2 годин, залежно від розміру бази та кількості файлів. Для інтернет-магазину на Magento або кастомному фреймворку - може бути 4-8 годин. Знати цю цифру заздалегідь - критично. Бо коли сайт лежить, кожна хвилина - це втрачені гроші та довіра.

Що запитати у хостинг-провайдера прямо зараз
Замість того, щоб чекати катастрофи, відкрийте тікет у свого провайдера і задайте ці конкретні питання. Запишіть відповіді. Серйозно - запишіть, бо потім будете дякувати собі.
- Як часто ви створюєте бекапи моїх даних і де вони зберігаються фізично?
- Яка максимальна глибина відновлення (за скільки днів назад можна «відкотитися»)?
- Чи включено відновлення з бекапу в мій тариф або це платна послуга?
- Чи зберігаються бекапи в іншому дата-центрі, відмінному від основного сервера?
- Яка ваша відповідальність у разі втрати моїх даних згідно з SLA?
Якщо на будь-яке з цих питань відповідь вас не влаштовує - це не привід бігти від провайдера. Це привід взяти бекапи у свої руки і перестати покладатись на чужі обіцянки.
Ось проста математика. Середній інтернет-магазин в Україні генерує 50-200 замовлень на день. Кожне замовлення - умовно 500-2000 грн. День простою - це від 25 000 до 400 000 грн прямих втрат. Плюс репутація, позиції в Google, нервові клітини. А тепер порівняйте це з вартістю бекап-рішення: від 0 грн (безкоштовні плагіни) до $10-30 на місяць за хмарне сховище. Рівняння, яке не потребує калькулятора.
Залишається одне питання, яке я хочу вам поставити: коли ви востаннє перевіряли, чи ваш бекап справді працює? Якщо ви зараз невпевнено відвели погляд від екрана - ви знаєте, що робити сьогодні ввечері. Не завтра. Сьогодні.