Бекапи хостингу: 12 запитань, які врятують вас від цифрової катастрофи
Уявіть: ви прокидаєтесь о сьомій ранку, відкриваєте сайт - а там порожнеча. Білий екран. Ні контенту, ні бази даних, ні тих 200 статей, які ви писали два роки. Звертаєтесь до хостера, а він каже: «Ми не зберігаємо резервні копії на вашому тарифі». Ця ситуація - не фантастика. Щомісяця тисячі власників сайтів по всьому світу переживають саме це. І більшість із них ніколи не ставили собі правильних запитань про бекапи. Давайте це виправимо прямо зараз.
Що таке бекап хостингу і чому це не «щось десь автоматичне»
Перше і найнебезпечніше припущення - «мій хостер точно робить бекапи». Можливо. А можливо, і ні. Або робить, але зберігає їх на тому ж сервері, де ваш сайт. Це як тримати запасний ключ від квартири під килимком - формально він є, практично він безкорисний.
Бекап (резервна копія) - це повний знімок вашого сайту: файли, база даних, налаштування, електронна пошта, SSL-сертифікати. Все, що потрібно для відновлення проєкту з нуля. Але є нюанс: не всі бекапи однакові.
- Повний бекап - копіює абсолютно все, важить багато, створюється довго
- Інкрементальний - зберігає тільки зміни після останнього повного бекапу, швидший і легший
- Диференціальний - щось середнє: копіює все, що змінилось з моменту останнього повного бекапу
- Бекап бази даних - окремо тільки MySQL/PostgreSQL, без файлів
Головне правило: якщо ви не перевіряли, як саме працює бекап на вашому хостингу - вважайте, що його не існує.
Хто відповідає за збереження моїх даних - я чи хостер?
Коротка відповідь: ви. Довга відповідь: все одно ви. Прочитайте умови обслуговування будь-якого хостинг-провайдера - 95% з них прямо пишуть, що не несуть відповідальності за втрату даних клієнта. Навіть якщо обіцяють автоматичні бекапи.
«Резервне копіювання - це не послуга хостера, а обов'язок власника сайту. Хостер може надавати інструменти, але фінальна відповідальність завжди лежить на клієнті.» - Документація WHM/cPanel, розділ Backup Configuration
Здивовані? Більшість людей - так. Ми звикли думати, що раз платимо за хостинг, то провайдер подбає про все. Але це те саме, що сподіватись, що орендодавець квартири застрахує ваші речі. Ні, він тримає в порядку стіни і дах. А ваші речі - ваша турбота.
Тому навіть якщо ваш хостер робить бекапи - завжди тримайте власну копію в окремому місці. Google Drive, Dropbox, окремий сервер - будь-що, що фізично не пов'язане з вашим хостингом.
Як часто потрібно робити бекапи і скільки копій зберігати
Залежить від того, як часто змінюється ваш сайт. Якщо у вас блог з одним постом на тиждень - щоденний бекап може бути надлишковим. А якщо інтернет-магазин з 500 замовленнями на день - навіть щогодинний може бути недостатнім.
| Тип сайту | Рекомендована частота | Мінімум копій | Де зберігати |
|---|---|---|---|
| Візитка, лендінг | 1 раз на тиждень | 3-4 | Хмара + локально |
| Блог (1-3 пости/тиждень) | Щодня | 7-14 | Хмара + віддалений сервер |
| Інтернет-магазин | Кожні 6-12 годин | 14-30 | 2 хмари + локально |
| SaaS / вебдодаток | Щогодини або частіше | 30+ | 3 різні локації |
| Форум, спільнота | Кожні 6 годин | 14-21 | Хмара + віддалений сервер |
Золоте правило бекапів називається 3-2-1: три копії, на двох різних носіях, одна - в іншому фізичному місці. Звучить параноїдально? Можливо. Але знаєте, як називають людей, які так роблять? Тих, у кого є сайт після аварії.
Що може піти не так навіть з бекапами
О, тут починається найцікавіше. Мати бекап і мати робочий бекап - це дві абсолютно різні історії. Я знаю випадок, коли компанія три роки автоматично бекапила сайт. А коли знадобилось відновитись - виявилось, що скрипт ламався на першій хвилині, і всі 1 100 копій були порожніми файлами розміром 0 байт.
Ось найпоширеніші проблеми:
- Бекап не включає базу даних. Файли є, а весь контент - ні. Це як зберегти коробку від телефону без самого телефону.
- Копії зберігаються на тому ж сервері. Сервер «помер» - і сайт, і бекапи зникли разом.
- Ніхто ніколи не перевіряв відновлення. Бекап виглядає нормально, але при розгортанні видає помилки.
- Зашифрований бекап без пароля. Так, буває. Хтось увімкнув шифрування і забув зберегти ключ.
- Застарілий бекап. Остання копія - тримісячної давності, а сайт з того часу змінився на 70%.
Щомісяця тестуйте відновлення. Розгорніть бекап на тестовому середовищі і переконайтесь, що все працює. 15 хвилин на перевірку можуть зекономити вам тижні роботи і тисячі гривень.
Як налаштувати автоматичні бекапи: інструменти і підходи
Добра новина - вам не потрібно бути системним адміністратором, щоб організувати надійне резервне копіювання. Більшість сучасних хостингів пропонують вбудовані рішення. Питання тільки в тому, чи достатньо їх.
Для WordPress найпопулярніші плагіни бекапу:
- UpdraftPlus - безкоштовна версія вміє відправляти копії в Google Drive, Dropbox, Amazon S3
- BlogVault - зберігає бекапи на власних серверах, не навантажує ваш хостинг
- All-in-One WP Migration - простий, як двері, ідеальний для міграцій і разових копій
- JetBackup - часто вбудований у cPanel хостерів, працює на рівні сервера
Для не-WordPress сайтів або VPS-серверів підхід інший. Тут вам знадобиться cron-завдання + скрипт, який створює архів файлів і дамп бази, а потім відправляє це кудись далеко. Класичний набір: mysqldump для бази + tar для файлів + rclone для відправки в хмару. Три команди в bash-скрипті - і ви захищені краще, ніж 80% сайтів в інтернеті.
А якщо катастрофа вже сталась - що робити
Паніка - природна реакція. Але вона не допоможе. Ось чіткий алгоритм дій, коли ваш сайт зник або зламаний:
- Не чіпайте нічого на сервері. Кожна ваша дія може перезаписати дані, які ще можна врятувати.
- Зв'яжіться з хостером негайно. Запитайте, чи є у них бекап - навіть якщо в тарифі це не зазначено. Іноді провайдери тримають аварійні копії «на всяк випадок».
- Перевірте всі місця, де могли зберігатись копії - хмарні диски, плагіни бекапу, email (деякі плагіни відправляють копії поштою), локальний комп'ютер.
- Подивіться Google Cache і Wayback Machine. Контент можна частково відновити звідти. Це не повноцінний бекап, але краще, ніж нічого.
- Після відновлення - негайно налаштуйте нормальну систему бекапів. Другий раз такого шоку ваші нерви можуть не витримати.
Окрема історія - зломи. Якщо сайт зламали, відновлювати бекап потрібно обережно. Може виявитись, що зловмисник сидів у системі тижнями, і навіть бекап двотижневої давності вже заражений. У таких випадках рекомендується відкатитись якомога далі назад і потім вручну перенести контент у чисту інсталяцію.
Скільки це коштує і чи можна безкоштовно
Можна. І потрібно починати саме з безкоштовних рішень, якщо бюджет обмежений. UpdraftPlus + Google Drive (15 ГБ безкоштовно) - це вже краще, ніж у 70% сайтів.
Але якщо ваш проєкт приносить гроші - інвестуйте в платне рішення. BlogVault коштує від $89 на рік. JetBackup зазвичай включений у тариф хостера. Власний скрипт + Amazon S3 обійдеться в $1-5 на місяць за зберігання.
Порівняйте це з вартістю втрати сайту. Середній інтернет-магазин на WordPress з 1 000 товарів відновити з нуля - це 200-500 годин роботи. Навіть якщо рахувати по мінімальній ставці фрілансера 300 грн/год, виходить 60 000 - 150 000 гривень. А бекап коштує кілька доларів на місяць. Математика тут безжалісна.
Бекап - це не витрата, а страховка. І як будь-яка страховка, вона здається непотрібною рівно до того моменту, коли стає найважливішою річчю у вашому житті.
Тож ось вам запитання на завершення: коли ви востаннє перевіряли, чи можна реально відновити ваш сайт з бекапу? Якщо відповідь «ніколи» або «не пам'ятаю» - закрийте цю статтю і зробіть це прямо зараз. Серйозно. Решта інтернету почекає.