Уявіть ранок, коли сайт не відкривається, у CRM порожньо, а на пошту прийшов лист із вимогою викупу за ваші ж дані. У цей момент вирішується не «чи є у вас резервна копія», а зовсім інше питання: чи є у вас план відновлення після збою — покроковий, перевірений, доступний людині, яка о шостій ранку тремтячими руками намагається повернути бізнес до життя. Резервна копія без плану — це запчастина без інструкції зі збірки. Ця стаття про те, як скласти такий план заздалегідь, поки все ще працює.
Більшість власників малого й середнього бізнесу згадують про відновлення вже під час аварії. Тоді з’ясовується найгірше: копії або немає, або вона тижневої давнини, або лежить на тому ж сервері, що й «упав», або її ніхто ніколи не пробував розгорнути назад. Ми працюємо із системами клієнтів з 2018 року й бачимо цей сценарій регулярно. Хороша новина: підготовка коштує в рази менше за один день простою, і зробити її можна спокійно, без пожежі.
Чому «у нас є бекап» — це ще не захист
«Бекап є» — найнебезпечніша фраза в бізнесі. Бо за нею зазвичай ховається кілька непомічених пасток.
Перша: копія лежить поруч із оригіналом. Якщо шифрувальник чи збій диска накрив сервер — він накрив і копію на тому ж сервері. Робоча схема — щонайменше три копії, на двох різних носіях, одна з яких фізично чи логічно відокремлена (офлайн або в іншому місці).
Друга: копію ніхто не перевіряв. Резервна копія, яку жодного разу не розгортали назад, — це припущення, а не факт. Дуже часто виявляється, що архів пошкоджений, у ньому бракує бази даних, або відновлення потребує пароля, який знав звільнений рік тому адміністратор.
Третя: застаріла глибина. Якщо копія робиться раз на тиждень, то в найгіршому випадку ви втрачаєте тиждень замовлень, документів і листування. Для інтернет-магазину чи сервісу це вже не «незручність», а прямий фінансовий збиток і зіпсовані стосунки з клієнтами.
План відновлення після збою починається саме тут — не з технології, а з чесної відповіді на питання: скільки даних ми готові втратити і як швидко мусимо повернутися.
Два числа, з яких усе починається
Перш ніж щось налаштовувати, визначте для кожної важливої системи два орієнтири.
Перший — скільки часу бізнес витримає простій. Годину? День? Для когось відключення сайту на три години — дрібниця, для когось — зрив постачань і штрафи. Це число диктує, наскільки швидким і автоматизованим має бути відновлення.
Друге — скільки даних припустимо втратити. Якщо ви приймаєте замовлення щохвилини, копія раз на добу означає до доби втрачених продажів. Тоді потрібне частіше, а часом безперервне резервування.
Ці два числа — не технічна забаганка, а бізнес-рішення власника. Саме вони визначають, який план вам справді потрібен, і вберігають від двох крайнощів: платити за надлишкову «космічну» надійність там, де вистачить простого, або економити там, де кожна година простою коштує реальних грошей.
Що має бути в плані, окрім даних
Дані — лише половина справи. Бізнес складається не тільки з файлів, а з доступів і знань, які зазвичай живуть у голові однієї людини. Повноцінний план відновлення після збою фіксує:
- Доступи. Де і як зберігаються паролі, ключі, доступи до домену, пошти, платіжних систем. Якщо все це знав один підрядник — у вас не бізнес, а заручник. Доступи мають бути в захищеному сховищі, а не в чиємусь блокноті.
- Домен і пошта. Часто найдовше відновлюється не сайт, а керування доменом та корпоративною поштою. Зафіксуйте, де вони зареєстровані й хто має до них доступ.
- Порядок дій. Простий документ: що робимо в першу чергу, кому телефонуємо, звідки беремо копію, як перевіряємо, що все повернулось. Написаний людською мовою, а не технічним жаргоном.
- Контакти. Хто відповідає за відновлення, хто його підстраховує, як зв’язатися, якщо звична пошта недоступна.
Цей документ має лежати там, куди ви дістанетесь, навіть коли основна система лежить, — не всередині неї самої.
Окремий випадок: відновлення після злому
Збій обладнання й злом — різні сценарії, і план мусить враховувати обидва. Після злому просто «розгорнути останню копію» недостатньо: якщо зловмисник був у системі кілька днів, свіжа копія вже може містити його закладку. Тому план відновлення після збою внаслідок атаки додатково передбачає: визначити, коли саме почалося вторгнення, обрати завідомо «чисту» копію до цієї дати, змінити всі паролі й ключі, і лише потім повертати систему в роботу. Без цього ви ризикуєте відновитися прямо в руки того, хто вас зламав. Саме тому офлайн-копія, до якої зловмисник не мав доступу, — не розкіш, а страховка.
Як перевірити, що план справді працює
План, який ніхто не репетирував, — це надія, а не гарантія. Раз на певний період варто провести навчальне відновлення: узяти копію й розгорнути її на окремому середовищі, не чіпаючи бойову систему. Така репетиція майже завжди показує щось несподіване — забутий крок, відсутній доступ, копію, яка розгортається не за п’ять хвилин, а за півдня.
Важлива деталь із досвіду: тренуватися треба на окремій копії, ніколи — на живих даних. Мета репетиції — знайти проблему в спокійній обстановці, а не створити другу аварію поверх першої. Після кожної такої перевірки план уточнюється, і з часом відновлення з лякливої невідомості перетворюється на рутинну процедуру на кілька годин.
З чого почати вже сьогодні
Не обов’язково будувати все одразу. Розумний перший крок — інвентаризація: перелічіть системи, від яких залежить бізнес, і для кожної чесно дайте відповідь — де копія, коли її востаннє перевіряли, хто має доступи. Уже цей список зазвичай відкриває дві-три діри, які варто закрити негайно.
Далі — відокремити копію від оригіналу, узгодити глибину й частоту з тими двома числами, і записати порядок дій простими словами. Це фундамент, на якому відновлення перестає залежати від однієї людини та її пам’яті.
Ми в LPF від 2018 року вибудовуємо й супроводжуємо такі системи на власній інфраструктурі — від резервування до перевірених сценаріїв відновлення. Якщо хочете спокійно оцінити, наскільки ваш бізнес готовий до збою, почніть із короткої розмови: ми разом складемо перелік ризиків і покажемо, з чого почати. Краще один спокійний день підготовки зараз, ніж один панічний ранок потім.