Коротка відповідь
Бекап на Meridaro — це повна щоденна копія файлів сайту й баз даних, яка автоматично вивантажується на окреме сховище, фізично відокремлене від сервера, де працює сайт. Це входить у кожен тариф, включно зі «Стартом», і не потребує додаткового налаштування з боку клієнта.
Чому копія «на тому ж диску» — це не бекап
Найпоширеніша ілюзія безпеки: на сервері є папка backups/, куди щодня складається архів. Технічно копія є. Але вона не рятує від жодного з найчастіших сценаріїв втрати даних:
- Відмова диска — фізична поломка знищує і сайт, і копію одночасно, бо вони на одному носії.
- Шифрувальник (ransomware) чи злом — якщо зловмисник отримав доступ до файлової системи, він бачить і бекапи теж і може їх видалити чи зашифрувати разом з оригіналом.
- Людська помилка — випадкове видалення директорії одним рухом прибирає і сайт, і «підстраховку».
Правило, яке варто запам'ятати: якщо копія лежить там само, де оригінал, — це не бекап, а ілюзія бекапу. Справжня копія має бути на окремому фізичному носії чи сервері.
Як це влаштовано на Meridaro
Щоночі скрипт бекапів знімає повну копію: файли сайту (включно з завантаженими зображеннями й документами) і окремо — дамп бази даних MySQL. Обидва компоненти вивантажуються по мережі на окремий сервер зберігання, який не має публічного доступу ззовні й не пов'язаний із виробничим сервером спільним диском чи спільною точкою відмови.
Зберігається кілька останніх щоденних копій за принципом ротації — це дозволяє відкотитися не тільки до «вчора», а й на кілька днів назад, якщо проблему (наприклад, зламаний плагін чи невдале оновлення) помітили не одразу.
Що саме можна відновити
| Сценарій | Що відновлюємо |
|---|---|
| Зламали сайт, дефейс чи вірус у файлах | Файли + база з копії до зараження |
| Невдале оновлення плагіна/теми WordPress | Тільки файли, база лишається поточною |
| Помилка в товарах/замовленнях інтернет-магазину | Тільки база даних окремим файлом |
| Випадково видалили один файл чи зображення | Окремий файл з копії, без повного відкату |
Тобто відновлення не завжди означає «відкотити все й втратити свіжі замовлення». Часто можна дістати саме той шматок, який потрібен — окрему таблицю бази чи окремий файл, — а решту лишити як є.
Скільки часу займає відновлення
Чесна відповідь: у межах кількох годин, а не хвилин чи секунд. Процес не повністю автоматичний — адміністратор піднімає потрібну копію, перевіряє її цілісність (щоб не «полагодити» сайт зіпсованою копією) і тільки після цього повертає сайт у роботу. Для великих баз даних інтернет-магазинів це може займати довше, ніж для сайту-візитки.
Якщо потрібен план дій на випадок будь-якого збою — не тільки для відновлення з бекапа, а загалом — дивіться аварійне відновлення сайту: план дій до того, як щось трапилось.
Чи можна замовити бекап «на вимогу»
Так — перед ризикованою операцією (велике оновлення, зміна теми, міграція) можна запросити позаплановий знімок через тікет у підтримку, окремо від автоматичного нічного розкладу. Це особливо корисно перед переносом інтернет-магазину на новий хостинг чи будь-якою міграцією.
Що записується в лог бекапу і навіщо на нього дивитися
Кожен цикл резервного копіювання лишає технічний лог — час старту й завершення, обсяг скопійованих даних, статус завершення (успішно чи з помилкою). Для звичайного власника сайту читати ці логи щодня не потрібно, але корисно знати, що вони існують і що підтримка хостингу може за запитом підтвердити: так, останній бекап пройшов успішно такого-то числа, ось обсяг файлів і бази. Це перетворює абстрактне "у нас є бекапи" на перевірюваний факт із конкретною датою й результатом.
Тестове відновлення: перевірка, яку рідко хто робить
Найнадійніший спосіб дізнатися, чи справді працюють бекапи, — не читати про них, а хоча б раз спробувати відновлення на практиці, у тестовому середовищі. Багато компаній роками платять за резервне копіювання, жодного разу не перевіривши, що копія дійсно розгортається без помилок. Раз на кілька місяців має сенс написати в підтримку й попросити розгорнути останній бекап на тестовому піддомені — це коштує невеликих зусиль і дає впевненість, яку неможливо отримати інакше, ніж фактичною перевіркою.
Різниця між бекапом хостингу і бекапом самої CMS
Деякі власники сайтів додатково використовують плагіни резервного копіювання на рівні CMS (наприклад, окремі бекап-плагіни для WordPress), що вивантажують копії у хмарне сховище (Google Drive, Dropbox). Це не суперечить бекапам на рівні хостингу, а доповнює їх — два незалежні джерела копій підвищують шанси, що хоча б одне спрацює у критичний момент. Головне — стежити, щоб обидва механізми справді працювали, а не покладатися на один із них, вважаючи, що другий "теж десь є".
А що з бекапом самої пошти?
Поштові скриньки на домені резервуються в межах того самого щоденного циклу, що й файли сайту. Якщо ви переносите сайт і пошту одночасно, варто заздалегідь ознайомитися з нюансами: як не втратити пошту при переносі сайту на новий хостинг.
Що відбувається, якщо власний бекап-скрипт сайту конфліктує з бекапом хостингу
Деякі CMS чи плагіни намагаються самостійно робити знімки бази даних "про всяк випадок" прямо на диску сайту. Якщо такий локальний архів росте безконтрольно (а це трапляється, коли про нього забувають), він може непомітно з'їдати дисковий простір тарифу, ніяк не покращуючи реальну безпеку (бо лежить на тому самому диску, як обговорювалося вище). Гарна практика — покладатися на офіційний механізм бекапів хостингу як на основний, а локальні плагіни резервного копіювання використовувати ощадливо, з обмеженою кількістю копій, що зберігаються, або взагалі вимикати, якщо вони дублюють те, що й так надійно робить хостинг.
Повна vs інкрементна копія: що технічно відбувається щоночі
Існує два поширені підходи до резервного копіювання. Повна копія — щоразу знімається весь обсяг даних наново; просто й надійно, але вимагає більше місця для зберігання й довше виконується на великих сайтах. Інкрементна копія — після першої повної копії наступні знімки фіксують лише зміни з попереднього разу, що суттєво економить і місце, і час, але робить процес відновлення трохи складнішим (потрібно послідовно застосувати кілька інкрементів).
На практиці для сайтів малого й середнього розміру різниця для кінцевого користувача непомітна — головне, щоб сам процес був автоматичним, регулярним і перевіреним, а не те, яким саме технічним методом він реалізований усередині. Важливіше — принцип зберігання поза сервером, про який ідеться вище, і те, що копія дійсно придатна до відновлення, а не просто існує формально.
Типова помилка: думати, що "бекап" і "версійність CMS" — одне й те саме
Деякі CMS, зокрема WordPress з певними плагінами, мають вбудовану систему версій — наприклад, історію редагувань окремих записів. Це зручно для відкату одного тексту статті, але це не бекап у повному розумінні: він не рятує від видаленої бази даних, зламаного сервера чи випадково видаленої директорії з зображеннями. Повноцінний бекап на рівні хостингу і версійність контенту на рівні CMS — це різні механізми для різних сценаріїв, і покладатися варто на обидва, а не тільки на один із них.
Скільки місця реально займають бекапи і чи це обмежує сайт
Резервні копії зберігаються на окремому сховищі, не на тому ж диску, де працює сайт, — тож обсяг бекапів не витрачає дисковий простір, виділений під сам тариф. Клієнту не потрібно самостійно стежити за місцем під архіви чи вручну видаляти старі копії — ротація (заміна найстаріших копій новими) відбувається автоматично на боці хостингу.