Бекапи на хостингу: чому ваша резервна копія може виявитись порожньою обіцянкою

Уявіть: п'ятниця, вечір, ви нарешті закрили ноутбук і пішли відпочивати. А в суботу вранці - порожній сайт. База даних зникла. Контент за три роки - випарувався. Ви заходите в панель хостингу, тиснете кнопку «Відновити з бекапу» і бачите напис, від якого холоне кров: «Остання резервна копія - 4 місяці тому. Розмір: 0 байт». Це не сценарій фільму жахів. Це реальна ситуація, яку я особисто спостерігав у клієнта з інтернет-магазином на 12 000 товарних позицій. Він втратив все. І знаєте, що найгірше? Він був впевнений, що бекапи працюють.

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

Чому «автоматичний бекап від хостера» - це ілюзія безпеки

Більшість хостинг-провайдерів пишуть на лендингу великими літерами: «Щоденні автоматичні бекапи включено!». І ви розслабляєтесь. Логіка проста: раз хостер обіцяє - значить все під контролем. Але давайте заглянемо в деталі.

Автоматичний бекап хостера - це страхова сітка з дірками розміром з вантажівку. Ось чому:

• Більшість shared-хостингів зберігають бекапи на тому самому фізичному сервері, де живе ваш сайт. Сервер згорів - згоріли і бекапи.
• Частота копіювання часто не щоденна, а раз на тиждень або навіть рідше - залежить від тарифу.
• Розмір бекапу обмежений. Якщо ваш сайт «потовстішав» понад ліміт - копія просто не створюється. Без жодного сповіщення.
• Відновлення часто доступне тільки через підтримку. А підтримка відповідає від 2 до 48 годин.

Я одного разу зателефонував у підтримку українського хостера і попросив показати список моїх бекапів. Знаєте, що мені відповіли? «У нас бекапи робляться, але ми не гарантуємо їхню цілісність і актуальність». Ось так. Без гарантій.

Сім помилок з бекапами, які вбивають сайти щодня

За 15 років роботи з веб-проєктами я зібрав колекцію бекап-катастроф. Ось найтиповіші помилки, які повторюються знову і знову:

1. Ніколи не перевіряти бекап на відновлення. Ви робите копію щодня. Чудово. Але ви хоч раз пробували з неї відновитись? 43% бекапів виявляються пошкодженими або неповними при спробі розгортання - це статистика від Veeam за 2024 рік.
2. Зберігати копії в одному місці. Бекап на тому самому сервері - це як тримати запасний ключ від квартири під килимком. Всі знають, де він лежить.
3. Ігнорувати базу даних. Файли сайту скопійовано, а MySQL-дамп - ні. Результат: у вас є оболонка сайту без єдиного запису, товару чи коментаря.
4. Не мати розкладу ротації. 30 бекапів за 30 днів - і раптом диск переповнений. Нові копії не створюються. Тиша.
5. Робити бекап під час пікового навантаження. Копіювання великої бази о 14:00, коли на сайті 500 відвідувачів? Привіт, timeout і пошкоджений дамп.
6. Покладатися тільки на хостера. Це як довірити всі свої гроші одному банку в країні, де немає системи гарантування вкладів.
7. Не шифрувати бекапи. Резервна копія - це повний зліпок вашого сайту: паролі, персональні дані клієнтів, ключі API. Без шифрування це подарунок для хакера.

«Бекап, який ви не тестували - це не бекап. Це надія. А надія - погана стратегія в IT.» - Томас Лімончеллі, автор книги «Практика системного адміністрування»

Правило 3-2-1: золотий стандарт, про який всі чули, але ніхто не виконує

Правило просте як двері, але дисципліна його виконання вимагає залізної волі.

3 копії ваших даних. 2 різних типи носіїв. 1 копія - поза межами вашого основного дата-центру.

Як це виглядає на практиці для типового сайту на WordPress або OpenCart?

Зверніть увагу: третя копія - це ваш «план Б на випадок апокаліпсису». Навіть якщо AWS впаде разом із вашим хостером (а таке бувало - згадайте інцидент OVH у 2021, коли фізично згорів дата-центр у Страсбурзі), у вас залишиться локальна копія.

Вартість такого підходу? Backblaze B2 коштує $0.005 за GB на місяць. Для сайту розміром 10 GB це $0.05 - п'ять центів. Менше, ніж чашка кави з автомата. А втрата даних для інтернет-магазину з оборотом 100 000 грн на місяць - це катастрофа на десятки тисяч.

Інструменти, які реально працюють: від плагінів до CLI-магії

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

Для WordPress:

• UpdraftPlus - найпопулярніший плагін. Безкоштовна версія вміє відправляти бекапи на Google Drive, Dropbox, S3. Налаштовується за 5 хвилин.
• BlogVault - платний, але з інкрементальними бекапами. Копіює тільки зміни, тому не навантажує сервер.
• WP-CLI + cron + rclone - для тих, хто не боїться терміналу. Команда wp db export зберігає базу, rclone sync відправляє все в хмару.

Для VPS/виділених серверів:

• restic - сучасна утиліта з дедуплікацією і шифруванням «з коробки».
• borgbackup - ще один потужний інструмент, який стискає дані і зберігає лише різницю між версіями.
• Bacula / Amanda - enterprise-рішення для складних інфраструктур.

Ключовий момент: яким би інструментом ви не користувалися, поставте собі нагадування в календар - раз на місяць тестувати відновлення. Просто розгорніть бекап на тестовому середовищі і переконайтесь, що все працює. Це займає 15-30 хвилин, але одного дня збереже вам тижні роботи.

Скільки часу у вас є: RPO і RTO простою мовою

Є два терміни, які звучать як абревіатури з NASA, але насправді критично важливі для кожного власника сайту.

RPO (Recovery Point Objective) - скільки даних ви готові втратити? Якщо бекап робиться раз на добу, то у найгіршому випадку ви втратите роботу за 24 години. Для блогу це терпимо. Для магазину з 200 замовленнями на день - ні.

RTO (Recovery Time Objective) - як швидко ви зможете відновити сайт? 5 хвилин? Година? Доба?

Визначте свої RPO і RTO до того, як щось трапиться. Це як план евакуації з будівлі - його малюють до пожежі, а не під час.

Темна сторона бекапів: що може піти не так навіть у параноїків

Ви все налаштували. Три копії, шифрування, щоденне тестування. Можна розслабитись? Не зовсім.

Є кілька сценаріїв, до яких варто підготуватися:

• Ransomware, що шифрує бекапи. Якщо зловмисник отримав доступ до сервера, він може зашифрувати не тільки сайт, а й локальні копії. Рішення - immutable backups (незмінні бекапи) в S3 з Object Lock.
• Тиха деградація даних. Файли бекапу на диску можуть пошкодитися через bit rot - фізичну деградацію носія. Рішення - контрольні суми і періодична верифікація.
• Людський фактор. Хтось із команди випадково видалив cron-задачу. Або змінив пароль від хмарного сховища і забув оновити скрипт. Бекапи тихо перестали працюватися два місяці тому. Рішення - моніторинг і алерти.

Налаштуйте простий alert: якщо бекап не з'явився у сховищі протягом 25 годин - вам приходить SMS або повідомлення в Telegram. Для цього достатньо скрипта на 10 рядків або безкоштовного акаунта в Healthchecks.io.

Ваш бекап - це ваша машина часу

Резервна копія - це єдина технологія, яка дозволяє вам подорожувати у часі. Серйозно. Зламали сайт учора? Відкотіться на позавчора. Оновлення плагіна поклало все? Поверніться на версію до оновлення. Але ця машина часу працює тільки якщо ви її заправили паливом, перевірили двигун і маєте запасний ключ.

Запитайте себе просто зараз: коли ви востаннє перевіряли, чи працює ваш бекап? Якщо відповідь «ніколи» або «не пам'ятаю» - закрийте цю статтю і зробіть це прямо зараз. Все інше може зачекати. А от ваші дані чекати не будуть.