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

Погане оновлення, зниклі замовлення, зламаний плагін або сервер, який не стартує, показують справжній склад копії. Часто в архіві є лише база даних із замовленнями та заявками, а завантажених фото і PDF немає. В іншій копії файли на місці, а замовлень немає. Копія може лежати на тому самому сервері, який уже не відкривається. Остання придатна копія буває тритижневої давнини, а пароль від сховища лишається в людини, яка пішла. Якщо відновлення ніхто не робив, на нього йде цілий день.

1. Що в копії є, а чого немає

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

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

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

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

2. Що записати до наступної поломки

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

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

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

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

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

3. Що робить спеціаліст за одну зустріч

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

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