Бекапи на хостингу: чому ваша копія сайту - це брехня, і як зробити справжню
Уявіть: ви прокидаєтесь о сьомій ранку, берете каву, відкриваєте сайт - а там порожнеча. Біла сторінка. Або ще гірше - чужий контент. Ви тиснете кнопку "Відновити з бекапу" в панелі хостингу, і... нічого не відбувається. Бекап виявляється порожнім, застарілим або просто битим. Це не фантастика. Це щоденна реальність тисяч власників сайтів, які щиро вірили, що хостер подбає про їхні дані. Давайте розберемось, чому резервні копії на хостингу - одна з найнебезпечніших ілюзій для початківців, і як побудувати систему, яка справді врятує вас у критичний момент.
Бекап від хостера - це не ваш бекап
Ось факт, який більшість початківців ігнорує: бекап, який робить ваш хостинг-провайдер, існує насамперед для нього, а не для вас. Прочитайте умови використання будь-якого shared-хостингу. У 90% випадків ви знайдете рядок на кшталт: "Ми не гарантуємо збереження резервних копій і не несемо відповідальності за втрату даних".
Це як замок на скляних дверях - виглядає надійно, але розбивається від одного удару.
Чому так? Тому що хостер робить бекапи для швидкого відновлення всього сервера після аварії. Ваш окремий сайт - лише крихітна частка цього процесу. Якщо щось трапиться саме з вашим акаунтом - зламали, видалили файли, оновлення WordPress розтрощило базу даних - хостер може і не мати актуальної копії.
"Найдорожча помилка в IT - це вірити, що хтось інший відповідає за ваші дані. Бекап, який ви не перевіряли - це не бекап, а самообман." - Тоні Хсі, колишній CEO Zappos, після масштабної втрати даних у 2013 році.
Запитайте себе: коли востаннє ви особисто завантажували бекап свого сайту і пробували його відновити? Якщо відповідь - "ніколи", ласкаво просимо в клуб, де перебуває приблизно 73% власників малих сайтів (за даними опитування CodeGuard за 2024 рік).
Три типи бекапів, які варто розрізняти
Не всі резервні копії народжуються рівними. Перед тим як щось налаштовувати, розберіться, що саме ви зберігаєте.
- Повний бекап (Full backup) - копія абсолютно всього: файли, база даних, налаштування сервера, поштові скриньки. Важкий, повільний, але найнадійніший. Робіть його мінімум раз на тиждень.
- Інкрементальний бекап (Incremental) - зберігає лише те, що змінилось з моменту останнього повного бекапу. Швидкий, легкий, ідеальний для щоденного використання. Але без базового повного бекапу він безкорисний - як другий поверх без першого.
- Бекап бази даних (Database only) - окремий дамп MySQL або PostgreSQL. Критично важливий для сайтів на WordPress, Joomla, будь-якому CMS. Контент, коментарі, замовлення - все живе в базі. Файли можна перевстановити, а ось унікальні дані клієнтів - ні.
| Параметр | Повний бекап | Інкрементальний | Тільки база даних |
|---|---|---|---|
| Швидкість створення | Повільно (10-60 хв) | Швидко (1-5 хв) | Дуже швидко (секунди) |
| Розмір | Великий (1-50 ГБ) | Малий (50-500 МБ) | Мінімальний (1-200 МБ) |
| Відновлення | Повне, "з нуля" | Потребує базу + ланцюжок | Тільки контент і дані |
| Рекомендована частота | 1 раз на тиждень | Щодня | Кожні 6-12 годин |
| Найкраще для | Катастрофічні збої | Щоденний захист | Інтернет-магазини, блоги |
Золоте правило? Комбінуйте. Повний бекап у неділю, інкрементальні - кожен день, дамп бази - кожні 6 годин. Це не параноя. Це здоровий глузд.
Правило 3-2-1, яке рятує навіть від пожежі в дата-центрі
У березні 2021 року дата-центр OVH у Страсбурзі згорів. Буквально. Вогонь знищив тисячі серверів. Сайти, які зберігали бекапи на тому ж сервері, втратили все - і оригінал, і копію. Це як тримати запасні ключі від квартири всередині цієї ж квартири.
Правило 3-2-1 - ваш рятувальний жилет:
- 3 копії ваших даних (оригінал + 2 резервні)
- 2 різних типи носіїв (наприклад, сервер хостингу + хмарне сховище)
- 1 копія поза основним майданчиком (інший дата-центр, інший провайдер, інший континент)
Звучить складно? Насправді це простіше, ніж здається. Плагін UpdraftPlus для WordPress дозволяє автоматично відправляти бекапи в Google Drive, Dropbox або Amazon S3 за кілька кліків. Для більш серйозних проектів - rclone або restic через cron-завдання на сервері.
Ось конкретний сценарій для початківця з WordPress-сайтом:
- Встановіть UpdraftPlus (безкоштовна версія цілком достатня для старту).
- Налаштуйте повний бекап щонеділі в Google Drive.
- Увімкніть щоденний бекап бази даних у Dropbox.
- Раз на місяць вручну скачуйте повний бекап на свій комп'ютер або зовнішній диск.
- Раз на квартал - відновлюйте бекап на тестовому середовищі, щоб переконатись, що він робочий.
П'ять кроків. Тридцять хвилин на налаштування. І ви вже в безпечнішому становищі, ніж 80% сайтів у інтернеті.
Інструменти, які працюють, а не просто обіцяють
Давайте без теорії - конкретні назви, конкретні ситуації.
Для WordPress: UpdraftPlus, BlogVault (платний, але з автоматичним staging), WPvivid. BlogVault, до речі, зберігає бекапи на власних серверах - ви не витрачаєте місце на хостингу і не залежите від одного провайдера.
Для будь-якого сайту через SSH: rsync + cron - класика, яка не підводить. Один рядок у crontab, і ваші файли щоночі летять на віддалений сервер. Додайте mysqldump для бази - і маєте повноцінну систему.
Для тих, хто хоче "налаштувати і забути": BorgBackup або Restic. Обидва підтримують дедуплікацію (не копіюють файли, які не змінились), шифрування і стиснення. Restic ще й вміє писати напряму в S3-сумісне сховище.
Головне - не зберігайте бекапи лише на тому ж сервері, де живе сайт. Це найпоширеніша помилка новачків. Сервер впав - бекап впав разом з ним. Ваш хостер зламали - зламали і ваші копії.
Як перевірити, що ваш бекап - не порожня обіцянка
Знаєте, яка різниця між "у мене є бекап" і "я можу відновити сайт"? Приблизно така ж, як між "у мене є вогнегасник" і "я вмію ним користуватись". Тестування бекапів - це те, що відрізняє людей, які втрачають сайти, від тих, які їх рятують.
Мінімальна перевірка, яку варто робити хоча б раз на квартал:
- Скачайте бекап на локальний комп'ютер і розпакуйте - чи є всі файли?
- Імпортуйте дамп бази в локальний MySQL (через XAMPP, MAMP або Docker) - чи відкриваються таблиці?
- Підніміть сайт локально або на тестовому піддомені - чи працює він повністю?
- Перевірте зображення, CSS, функціонал форм - дрібниці, які часто "ламаються" при відновленні.
Якщо це звучить як зайва робота - згадайте про OVH. Або про хлопця з Нідерландів, який у 2022 році втратив інтернет-магазин з оборотом 15 000 євро на місяць, бо його "надійний бекап" виявився дампом порожньої бази. Він довіряв автоматичній системі, яку жодного разу не перевірив.
Бекап без тестування - це не бекап. Це файл, який займає місце на диску.
Скільки це коштує, і чому "безкоштовно" - нормально
Добра новина: надійна система резервного копіювання для невеликого сайту може коштувати рівно нуль. Google Drive дає 15 ГБ безкоштовно - цього вистачить на десятки бекапів типового блогу або невеликого магазину. UpdraftPlus у безкоштовній версії покриває 90% потреб. Rsync і cron - взагалі вбудовані в будь-який Linux-сервер.
Якщо ж ваш проект серйозніший - 5-10 доларів на місяць за Backblaze B2 (зберігання за $0.005/ГБ) або Wasabi дадуть вам терабайти простору з надійністю 99.999999999%. Одинадцять дев'яток. Це означає, що ймовірність втрати файлу - приблизно одна на мільярд.
Для порівняння: відновлення зламаного сайту без бекапу обійдеться в 200-2000 доларів (а іноді і більше), не рахуючи втраченого прибутку, трафіку та нервів. Математика тут проста, як двічі два.
Ось що мене дивує: люди готові платити 200 доларів за красиву тему WordPress, але не витрачають 30 хвилин на налаштування бекапів. Може, справа в тому, що красива тема - це видимий результат, а бекап - невидимий? Але ж парашут теж невидимий - поки не стрибнеш. Яка ваша стратегія резервного копіювання прямо зараз - план чи ілюзія?