Бекапи й аварійне відновлення: що перевірити до того, як знадобиться

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

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

Бекапи тепер мішень, а не лише страхувальна сітка

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

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

Правило, оновлене

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

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

Два числа, які вирішують усе інше

До вибору інструментів визначте дві речі в бізнесових, а не технічних термінах.

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

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

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

Що насправді треба бекапити

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

• База й завантаження, очевидно, і разом: база, відновлена проти невідповідної теки медіа, дає сайт із побитими картинками.
• Конфігурація, що живе поза кодом. Налаштування сервера, правила редиректів, cron-завдання, змінні середовища. Саме через них відновлений сайт зазвичай поводиться дивно.
• DNS-записи. Їх рідко бекаплять, іноді втрачають, а сайт, до якого не достукатися, лежить незалежно від того, чи він працює.
• Пошта, якщо вона на хостингу. Скриньки часто поза межами бекапу й нерідко є найціннішими даними компанії.
• Дані в сторонніх сервісах. Заявки з форм, записи CRM, платформи відгуків. Ваш бекап не включає чужу систему, а їхній експорт і є вашим бекапом.
• Доступи, щоб цим скористатися. Ідеальний бекап із паролем відновлення, який зберігається лише на зашифрованому ноутбуці, — відомий і цілком уникний збій.

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

Строк зберігання й незручне питання про видалення

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

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

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

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

Навчальне відновлення за дві години

Це вся стаття в одній вправі, і майже ніхто її не робить. Забронюйте дві години, попередьте кого треба й проведіть.

1. Візьміть дату, а не останній бекап. Відновіть копію тритижневої давності. Реальні інциденти виявляють пізно, і найновіша копія часто вже скомпрометована.
2. Відновлюйте не на продакшен. Стейджинг або локальне середовище. Мета — довести, що копія робоча, а не зламати робочий сайт.
3. Заміряйте час. Від рішення до працюючого сайту. Це число і є вашим справжнім часом відновлення, і воно буде більшим за те, що в договорі.
4. Скористайтеся сайтом. Увійдіть, зробіть тестове замовлення, надішліть форму, перевірте медіа, перевірте, що заплановані завдання виконуються. Головна, що відкрилася, — це не відновлений сайт.
5. Запишіть, чого бракувало. Завжди чогось бракує. Зазвичай доступів, конфігураційного файлу або сторонньої інтеграції, яку треба підключити наново.

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

Де саме кусає WordPress

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

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

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

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

Інструкція, яку ніхто не пише до інциденту

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

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

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

Хто саме відповідає за бекап

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

Розвʼязується це одним реченням у договорі й трьома перевірками.

1. Назвіть відповідального поіменно, а не роллю. «Підрядник забезпечує резервне копіювання» не працює, коли підрядник змінюється.
2. Запитайте, де лежить копія і хто має до неї доступ. Якщо відповідь містить лише назву хостингу, у вас одна копія, а не три.
3. Попросіть показати останнє успішне відновлення. Не звіт про бекап — саме відновлення: дату, тривалість і те, що перевіряли після нього.

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

Коротко

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