Стратегія резервного копіювання сайту, яка справді працює

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

Почніть із правила 3-2-1: три копії даних, на двох різних типах сховищ, одна з них — поза основним майданчиком. Для сайту першою копією вважається сам робочий сайт, другою — резервні копії хостера, третьою — архів, який ви завантажуєте у сховище під своїм контролем. Потім складіть список усього, що потрібно для повного відновлення. Файли сайту, завантаження й бази даних очевидні. Менш очевидні поштові скриньки, завдання cron, налаштування PHP, правила .htaccess або nginx, API-ключі та файли оточення, а також експорт DNS-зони: відновлювати сорок записів з пам'яті під час збою довго, і легко помилитися.

Частота копіювання випливає з двох запитань. Скільки роботи ви можете дозволити собі втратити? Це цільова точка відновлення, RPO. Як довго сайт може не працювати, поки ви його відновлюєте? Це цільовий час відновлення, RTO. Сайту-візитці, який змінюється раз на місяць, вистачить щоденної копії. Магазину, який приймає замовлення цілий день, — ні: кожна година між копіями означає годину замовлень, які доведеться вносити вручну. Термін зберігання важливий не менше за частоту: проблеми часто помічають за кілька днів, тож тримайте кілька щоденних копій, пару щотижневих і принаймні один щомісячний знімок.

Резервні копії хостера необхідні, але недостатні. На віртуальному хостингу WebHostFlow кожен сайт і кожну базу даних щоночі копіюємо на окрему інфраструктуру, зберігаємо 14 днів, а відновити їх можна з панелі керування — це покриває більшість випадковостей за кілька кліків. Але ці копії лежать у того самого провайдера і в тому самому акаунті. Якщо проблема в суперечці щодо оплати, викраденому паролі чи помилці в самому акаунті, потрібна копія, до якої ніхто інший не дотягнеться. Регулярно завантажуйте повний архів і зберігайте його окремо — наприклад, у зашифрованому хмарному сховищі або на диску в офісі.

Бази даних потребують особливої уваги. Копіювання «сирих» файлів працюючого сервера MySQL або PostgreSQL може дати копію, яка виглядає повною, але не запускається, бо дані змінювалися просто під час копіювання. Використовуйте нормальний дамп: mysqldump з параметром --single-transaction для таблиць InnoDB або pg_dump для PostgreSQL — обидва дають узгоджений знімок без блокування сайту. Стисніть дамп, додайте до назви дату й час і перевірте, чи не підозріло малий файл. Дамп нульового розміру, який пів року щоночі «успішно» створювався, — напрочуд часта знахідка.

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

Простий щомісячний чек-лист тримає все це під контролем. Переконайтеся, що останні автоматичні копії завершилися й мають правдоподібний розмір. Завантажте свіжу зовнішню копію файлів, баз даних і пошти. Експортуйте DNS-зону й запишіть зміни в конфігурації. Відновіть одну копію в тестове місце й перевірте, що сторінки, вхід і форми працюють. Видаліть зовнішні копії, старші за ваш термін зберігання. Це займає менше години й перетворює резервне копіювання з надії на процедуру. У WebHostFlow половину роботи на боці хостингу — на віртуальному та преміум-хостингу — беремо на себе ми, а на вас залишаються зовнішня копія й перевірка.