Бекапи сайту: як мають працювати і як відновитись за годину

Коротка відповідь

Робоча схема для звичайного сайту виглядає так:

• Файли і база - разом і на одну мить часу. Дамп бази від вівторка з файлами від п'ятниці дає сайт, який частково не працює: у базі є посилання на те, чого в файлах ще немає.
• Щодня, автоматично. Плюс окрема копія руками перед кожним оновленням CMS, зміною теми чи правкою в .htaccess.
• Не на тому ж сервері. Копія поруч із сайтом гине разом із сайтом - і при відмові диска, і при зламі.
• Глибина - тижні, а не одна доба. Зараження чи криве оновлення помічають не того ж дня, а на третій-п'ятий. Якщо є копія тільки за вчора, вона вже зіпсована.
• Перевірена хоча б раз. Архів, з якого ніколи не відновлювали, - це припущення, а не бекап.

Відновлення звичайного сайту з готової копії - це 15-60 хвилин: знайти потрібний архів, розпакувати в окрему теку, повернути файли, залити дамп бази, перевірити. Довше за все триває імпорт великої бази, а не файли.

Копія в хмарі - це ще не бекап

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

Я на цьому обпікся сам у травні 2026 року: на одному з сайтів зник службовий плагін, а нічна синхронізація о третій ранку прибрала його і з хмарного диска. Врятував тільки кошик із тридцятиденним зберіганням видаленого. Після того випадку я переписав схему бекапів під версійне сховище, де попередні стани лежать окремо і не перезаписуються.

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

Що має входити в копію

Типова помилка - зберегти теку з темою WordPress і вважати, що сайт забекаплено. Ось із чого він складається насправді:

Окремо про базу: у магазині саме вона і є бізнесом. Файли ви за потреби зберете заново з дистрибутива CMS і теми, а замовлення, клієнтів і залишки - нізвідки. Тому база копіюється частіше за файли.

Як часто робити копії і скільки їх зберігати

Частота відповідає на питання «скільки даних я готовий втратити»: при копії раз на добу ви в найгіршому випадку втрачаєте день замовлень і публікацій. Глибина відповідає на інше - «як далеко назад я можу відкотитись». Друге на практиці важливіше, бо поломки рідко помічають одразу.

Головне - щоб обидва параметри були відомі вам заздалегідь, а не з'ясовувались у момент аварії.

Як бекапи влаштовані в мене

Розкажу механіку, бо «щоденні бекапи» в рекламі означає що завгодно - від версійного сховища до тижневого знімка «коли встигнемо».

• Два прогони на добу - о 00:00 і о 12:00. Окремо архів файлів, окремо дампи всіх баз.
• Сховище - на іншому сервері, не на тому, де живуть сайти. Веб-сервер ходить туди окремим обмеженим акаунтом.
• Версійне сховище з дедуплікацією (BorgBackup): кожен прогін зберігає лише те, що змінилось. Цифра з живого репозиторію на сьогодні: 543 ГБ сумарного обсягу всіх архівів займають на диску 13,5 ГБ.
• Шифрування на стороні сервера-джерела. Той, хто отримає фізичний доступ до дисків сховища, побачить нечитабельні блоки.
• Глибина - 14 щоденних плюс 4 щотижневих архіви, це приблизно шість тижнів історії.
• Дампи баз додатково їдуть у хмару і зберігаються там 30 днів - це та сама третя копія з правила 3-2-1.
• Щогодинний сторож. Якщо успішного прогону немає понад 26 годин, мені падає сповіщення в Telegram: тихо зламаний бекап - найгірший зі сценаріїв.
• Тест відновлення 1-го числа щомісяця о 05:00 автоматично, плюс раз на квартал я вручну підіймаю чийсь сайт у тимчасову теку і дивлюсь, чи він відкривається.

Тепер чесно про межі цієї схеми. Глибина не безмежна: якщо проблему помітили через два місяці, щоденної копії за той день уже немає - лишиться найближча щотижнева. Формулювання «відновлення в один клік» я теж не люблю: на практиці повертати треба один файл, одну теку чи одну таблицю, а не весь сайт станом на вчора, і робиться це вибірково. Тому відновлення я роблю разом із вами - напишіть у Telegram, і я підберу потрібний архів та поверну саме те, що зламалось. Щоденні офсайт-копії входять у всі тарифи без доплат - і в Старт за 142 грн/міс, і в Pro за 800 грн/міс.

Як зробити копію самому: DirectAdmin за 5 хвилин

Копії хостера - страховка від аварії на сервері. Своя копія - страховка від вас самих: від невдалого оновлення, видаленої сторінки, плагіна, який зламав верстку. Вона потрібна навіть тоді, коли хостер робить свої.

Через розділ резервних копій у панелі

У DirectAdmin відкрийте Create/Restore Backups у розділі «Додаткові можливості». Позначте домени, бази даних, поштові скриньки і завдання cron - і запустіть створення. Через кілька хвилин архів з'явиться в теці backups вашого домашнього каталогу. Якщо ви ще не освоїлись у панелі, почніть зі статті DirectAdmin: перші кроки після замовлення.

Далі важливий крок, який пропускають: завантажте архів собі та видаліть із сервера. Поки він лежить у домашній теці, він, по-перше, не рятує від відмови самого сервера, по-друге, їсть ваше місце в тарифі - а на Старті це 10 GB NVMe на все разом.

Тільки база - через phpMyAdmin

Якщо ви міняєте лише щось у контенті чи налаштуваннях CMS, часто достатньо дампа бази: phpMyAdmin → потрібна база → Export → Quick → формат SQL. Для бази на кілька сотень мегабайтів експорт через браузер зазвичай обривається - тут потрібен SSH або моя допомога, напишіть у підтримку, зроблю дамп на сервері.

Що не класти в архів

Кеш (wp-content/cache і аналоги), логи, node_modules і - окремим пунктом - старі архіви всередині public_html. Останнє трапляється регулярно: копія потрапляє в наступну копію, і за півроку архів важить більше за сам сайт.

Відновлення за годину: порядок дій

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

Крок 2. Визначити, коли поламалось. Дивіться дату зміни підозрілих файлів і error.log. Потрібна копія, зроблена до цього моменту, а не найсвіжіша.

Крок 3. Якщо це зараження - брати копію з запасом. Бекдор міг лежати на сайті тиждень до того, як себе проявив. Копія «за день до поломки» у цьому випадку вже містить його.

Крок 4. Розпакувати в окрему теку, а не поверх сайту. Наприклад, у restore поруч із public_html. Розпакування «як є» поверх робочого сайту - найчастіша причина того, що після відновлення стало гірше, ніж було.

Крок 5. Повертати вибірково. Порівняйте архів із тим, що на сайті, і перенесіть лише потрібне: теку теми, плагін, видалений файл. Повне перезаписування виправдане тільки тоді, коли сайт не працює цілком.

Крок 6. База - окремо і в останню чергу. Спершу зробіть дамп поточної бази (так, навіть якщо вона зіпсована), потім заливайте відновлену. І звіряйте: файли й база мають бути з одного дня.

Крок 7. Перевірити за списком. Головна, одна внутрішня сторінка, форма або кошик, вхід в адмінку, пошта, HTTPS без попереджень у браузері.

Скільки це триває насправді:

Цифри - з реальних відновлень на NVMe-дисках. Якщо ви переїжджаєте на інший сервер, механіка та сама, але додаються DNS і конфіги - це окрема покрокова стаття про перенесення WordPress на новий хостинг.

Чому бекап не рятує: типові причини

• Копія на тому ж сервері. Диск відмовив або акаунт зламали - немає ні сайту, ні копії.
• Файли без бази. Сайт повертається, але порожній: контент жив у MySQL.
• Глибина в одну добу. Проблему помітили на п'ятий день - відкочуватись нікуди.
• Копію зроблено вже після зараження. Сайт повертається разом із бекдором, і через два дні все повторюється.
• Архів ніхто не відкривав. Всередині може бути порожня тека, обірваний дамп або лише тема без uploads.
• Втрачений пароль від шифрованого архіву. Копія фізично є, прочитати її неможливо. Ключі зберігайте поза сервером.

Чек-лист: перевірте свої бекапи за 10 хвилин

1. Дізнайтесь, де лежать копії вашого сайту і хто їх робить - ви, хостер чи ніхто.
2. Відкрийте останній архів і подивіться, що всередині: мають бути і файли, і дамп бази.
3. Перевірте дату найсвіжішої копії. Якщо їй більше доби - схема не працює.
4. З'ясуйте глибину: скільки копій зберігається і за який період можна відкотитись.
5. Переконайтесь, що хоча б одна копія лежить не на сервері з сайтом.
6. Зробіть тест: поверніть один файл з архіву в тимчасову теку і відкрийте його.
7. Випишіть в одне місце поза сервером: доступи до панелі, бази і сховища копій.
8. Поставте нагадування повторити цю перевірку раз на квартал.

Якщо на другому чи третьому пункті стало незатишно - напишіть мені у Telegram: подивлюсь ваш випадок, що копіюється, чого бракує і чи можна з тих архівів відновитись.

Підсумок

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

З мого боку на всіх тарифах однаково: копії двічі на добу о 00:00 і 12:00, шифроване версійне сховище на окремому сервері, шість тижнів історії, дампи баз додатково в хмару на 30 днів, щогодинний контроль свіжості й щомісячний тест відновлення. Плюс DirectAdmin, де ви в будь-який момент робите власну копію, безкоштовний SSL Let's Encrypt, PHP 8.3 і дата-центр у Франції. Доступність заявлена на рівні 99.9%, а не «сто відсотків» - такого не буває ні в кого.

Тарифи відрізняються лише потужністю: Старт - 1 ядро, 2 GB RAM і 10 GB NVMe за 142 грн/міс, Оптимал - 2 ядра і 20 GB за 229 грн/міс, Бізнес - 3 ядра і 30 GB за 350 грн/міс, Pro - 4 ядра і 100 GB за 800 грн/міс. Ціни за річної оплати, помісячно Старт виходить 479 грн/міс. Усі плани поруч - на сторінці тарифів хостингу, а оформити Старт - кілька хвилин.

І остання порада: перевірте свої бекапи сьогодні, а не тоді, коли вони знадобляться. Різниця між «сайт лежав годину» і «сайт довелося робити заново» - майже завжди саме в цій перевірці.