Сайт зламався. Коли ти востаннє перевіряв резервну копію?

У вівторок о 8:50 тобі пише менеджер: «Сайт показує білу сторінку». За пів години з’ясовується, що вночі оновився плагін, і тепер не відкривається ні каталог, ні адмінка. Ти спокійно відповідаєш: «Нічого, у нас же бекапи». І тут починається найцікавіше.

Хто їх робить? Хостинг. Добре, а за яку дату остання? Треба подивитися. Хто вміє відновлювати? Здається, Олег, підрядник. Олег у відпустці. Коли відновлення закінчиться, з’ясується ще одна дрібниця: копія зроблена о третій ночі, а замовлення за вчорашній вечір у неї не потрапили.

Ситуація дуже типова: власник щиро вважає, що копії є, і формально він правий. Але фраза «бекапи є» відповідає лише на одне питання з чотирьох. Три інші звучать так: що саме ми втратимо, скільки часу сайт не працюватиме і хто натисне кнопку.

Далі я веду одну умовну історію: інтернет-магазин запчастин для сільгосптехніки. Каталог на кілька тисяч позицій, замовлення від фермерських господарств, двоє менеджерів, сайт на WordPress із WooCommerce. Історія вигадана, але кожна її проблема цілком побутова.

Коли сайт лежить, тебе цікавить не сам факт існування архіву. Тобі треба знати дві цифри.

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

Скільки часу сайт може не працювати. Це час відновлення. Він складається з того, скільки шукатимеш доступи, скільки триватиме саме відновлення і скільки перевірятимеш результат. Хостинг може обіцяти відновлення «в один клік», але клік ще треба комусь зробити, і цей хтось має мати доступ.

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

Візьми свій звичайний день і подивися, що змінюється на сайті між двома копіями.

У магазину запчастин за день буває, наприклад, 30 замовлень, а менеджер увечері оновлює ціни з таблиці постачальника. Копія о третій ночі. Збій о 16:00. Між ними тринадцять годин: вчорашні вечірні замовлення, сьогоднішні ранкові, оновлені ціни, два нові оптові клієнти з особистими знижками.

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

Документація WordPress пропонує орієнтир: для невеликих сайтів, де мало змін, копію робити раз на тиждень, для активних сайтів щодня, а також завжди перед оновленням (WordPress: Backups). Для магазину з постійними замовленнями «щодня» часто замало, тому базу даних варто копіювати частіше, ніж файли. Файли (теми, плагіни, фото товарів) змінюються рідко. Замовлення живуть саме в базі.

Що зробити: спитай у того, хто веде сайт, о котрій годині робиться копія бази і як часто. Порівняй відповідь із тим, скільки замовлень чи заявок ти готовий відновлювати руками.

Для типового сайту на WordPress потрібні дві частини: файли й база даних. Офіційна документація окремо пояснює, що копія файлів не містить бази, бо база зберігається в окремій системі (WordPress: Backups, інструкція з копії бази).

Але навіть повний архів «файли плюс база» часто не містить того, без чого бізнес не запрацює. Пройдися цим списком:

• Пошта. Скриньки на хостингу зазвичай живуть окремо від сайту. Британський центр кібербезпеки NCSC прямо називає пошту, рахунки, контакти й дані клієнтів серед того, що бізнесу треба копіювати разом із сайтом (NCSC: Backing up your data).
• DNS-записи домену. Якщо їх змінили або видалили, сайт і пошта перестануть знаходитися, хоча самі цілі. Достатньо скриншота чи експорту записів, збереженого окремо.
• Налаштування сервера. Правила переадресації, паролі на службові розділи, обмеження доступу часто лежать не в WordPress, а в конфігурації сервера.
• Ключі інтеграцій. Платіжний сервіс, доставка, синхронізація зі складом чи обліковою програмою. Після відновлення їх іноді доводиться підключати заново, і краще заздалегідь знати, де взяти ці дані.
• Файли поза сайтом. Фото товарів можуть лежати в окремому хмарному сховищі, а форми заявок у сторонньому сервісі.
• Завдання за розкладом. Нічне оновлення цін, вивантаження в маркетплейс, нагадування клієнтам.

У нашому умовному магазині саме на цьому пункті і з’явився перший сюрприз. Фото товарів роками вантажили в окреме сховище, і в архів сайту вони не входили. Відновлений каталог виглядав як вітрина після інвентаризації: назви на місці, ціни на місці, замість картинок сірі квадрати.

Копія на тому самому хостингу, що й сайт, нагадує запасний ключ, приклеєний скотчем до тих самих дверей. Поки двері на місці, дуже зручно.

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

WordPress радить тримати кілька свіжих копій у різних місцях: на хостингу, у хмарному сховищі й локально (WordPress: Backups). NCSC додає дві важливі деталі: зовнішній диск не повинен бути постійно підключений до комп’ютера, бо деякі віруси дістають і його, а хмарне сховище з копіями варто захистити двоетапною перевіркою входу (NCSC).

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

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

Про це питання майже не думають, а воно вирішує, чи врятує тебе копія після зламу.

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

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

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

WordPress у матеріалі про зламані сайти радить спитати хостинг, як саме він зберігає копії, і заздалегідь планувати їх як частину безперервної роботи бізнесу (WordPress: FAQ My site was hacked). Додам від себе: постав це питання до того, як щось сталося. Відповідь «зберігаємо три дні» чесніше почути на спокійну голову.

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

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

Тому до копій є кілька вимог безпеки:

1. Не тримати архіви в публічній папці сайту, звідки їх може завантажити будь-хто, хто вгадав назву файлу. А назви на кшталт backup_new_2_ok.zip вгадуються краще, ніж здається.
2. Шифрувати копії, які лежать поза хостингом, і зберігати пароль до шифрування так, щоб його знайшли двоє людей, а не одна.
3. Обмежити, хто може завантажити копію. Підряднику для роботи вона потрібна, стажеру з SMM навряд.
4. Видаляти старі копії за правилом, а не тоді, коли закінчилося місце на диску.

Якщо сайт нещодавно переїжджав, після переїзду варто окремо перевірити, що службові файли закриті. Про інші пастки переїзду є окремий розбір «Новий сайт запустили. А Google досі шукає старий».

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

Ось як цю тривогу провів наш умовний магазин.

Підготовка. Обрали дату, коли замовлень мало. Підрядник створив окремий піддомен для тесту, закрив його паролем і заборонив індексацію, щоб тестова копія не з’явилася в Google і не відбирала відвідувачів у живого сайту.

Старт секундоміра. Секундомір запустили не тоді, коли почалося відновлення, а тоді, коли власник сказав: «Уявімо, що сайт упав». Бо в справжній аварії перші хвилини теж ідуть не на роботу, а на пошук доступів.

Відновлення. Взяли останню копію файлів і бази з того місця, де вона зберігається поза хостингом. Розгорнули на тестовому піддомені.

Перевірка. Пройшли сайт як покупець і як менеджер:

• головна, каталог, пошук, кілька карток товарів із фото;
• ціни відповідають даті копії;
• вхід в адмінку працює;
• оформлення замовлення доходить до кроку оплати в тестовому режимі, без справжніх списань;
• форма зворотного зв’язку надсилає лист на тестову адресу.

Перед перевіркою важливо вимкнути на тестовій копії розсилки й листи клієнтам. Інакше відновлена база дуже сумлінно надішле фермерам нагадування про кошики, які вони кинули ще навесні.

Протокол. Записали чотири речі: дату копії, загальний час від «упав» до «працює», що не відновилося і хто що робив.

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

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

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

Якщо збій стався о 16:00, а копія з 3:00 ночі, то відновлення бази поверх поточної затре все, що з’явилося між ними, навіть якщо ці дані фізично ще є на сервері. Тому перед відновленням зроби три речі:

1. Збережи поточний стан, навіть зламаний. Копія бази в момент аварії може містити ті самі тринадцять годин замовлень. Сайт може не відкриватися, а база при цьому цілком жива.
2. Вивантаж або випиши нові замовлення. З адмінки, якщо вона працює, або з повідомлень на пошті й кабінету платіжного сервісу.
3. Відновлюй спочатку в тестову копію, якщо дозволяє час, і лише потім переноси на живий сайт.

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

І ще одна звичка, яка рятує найчастіше: свіжа копія безпосередньо перед будь-яким оновленням. WordPress радить саме це (WordPress: Backups). Нічне автоматичне оновлення без свіжої копії перед ним виглядає як сміливий експеримент, у якому піддослідний ти.

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

На цій сторінці:

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

Якщо після читання цього списку ти розумієш, що половина доступів досі в підрядника, почни з нашої перевірки доступів у статті «Підрядник зник. Що залишилося від твого сайту?». Без доступів план відновлення лишається гарним побажанням.

Цей лист можна скопіювати й відправити тому, хто зараз веде твій сайт. Відповіді на нього дадуть приблизно ту саму картину, що й навчальна тривога, тільки без секундоміра.

Якщо на сьомому питанні запала тиша, це теж відповідь.

Не треба перебудовувати все одразу. Ось короткий порядок:

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

Якщо хочеш, щоб це подивився хтось збоку, ми можемо перевірити твій сайт, копії й доступи. А якщо сайт треба переробити так, щоб копіювання й відновлення в ньому були передбачені з самого початку, про це наша сторінка сайтів і e-commerce.