У корпоративному ІТ вже давно існує проста формула, яка відділяє керовану аварію від катастрофи з багатомільйонними втратами. Канал IBM Technology нагадує про правило резервного копіювання 3‑2‑1 і доповнює його сучасними вимогами — незмінністю копій, тестуванням відновлення та шифруванням.
Чому резервні копії досі питання виживання бізнесу
Дані стали «кровоносною системою» сучасного бізнесу: це й історія операцій, і майбутні аналітичні моделі, і «секретний соус» продукту. Втрата цих масивів через збій обладнання, людську помилку, стихійне лихо або ransomware перетворює звичайний інцидент на екзистенційну загрозу для компанії.
Практика показує: навіть ті організації, які роблять бекапи, часто провалюються в ключовий момент — копії виявляються пошкодженими, зашифрованими разом із продакшеном або фізично знищеними разом з основним дата-центром. Класичне правило 3‑2‑1 покликане мінімізувати ці ризики.
Класика жанру: три копії, два носії, одна — поза майданчиком
3: три копії даних
Базова логіка проста:
- 1 основна (продакшен) копія;
- щонайменше 2 незалежні резервні копії.
Мати лише один бекап — майже так само ризиковано, як не мати жодного: при відмові сховища чи помилці конфігурації «єдиний» бекап дуже швидко перетворюється на нуль. Додаткова копія прибирає цей одиночний вузол відмови й робить стратегію стійкішою до збоїв конкретного пристрою або системи.
2: два різні типи носіїв
Друга умова — зберігати копії на двох різних типах медіа або технологій зберігання. Наприклад:
- продакшен на SSD,
- бекап №1 — на HDD (локальне або NAS‑сховище),
- бекап №2 — у хмарі.
Це важливо, бо апаратні проблеми часто мають «серійний» характер: дефектна партія SSD чи помилка прошивки може одночасно вивести з ладу цілу групу дисків. Рознесення копій по різних технологіях та постачальниках знижує ймовірність одночасної відмови до прийнятного мінімуму.
1: щонайменше одна копія — поза основним майданчиком
Третій елемент — географічне рознесення. Якщо всі копії знаходяться в одному дата-центрі (або навіть в одному місті), то пожежа, повінь, землетрус чи масштабне відключення електроенергії знищують або роблять недоступними все одразу.
Ключові моменти:
- одна з копій має бути фізично винесена в інший регіон;
- «через річку» — не завжди достатньо: у випадку великої бурі чи блекауту цілком може постраждати вся агломерація.
Розподіл, наприклад, між східним і західним узбережжям США (умовно — Нью-Йорк і Аризона) куди надійніший, ніж офіс у центрі міста і «резервний сайт» у передмісті.
Нові вимоги: незмінність, тестування та шифрування
Правило 3‑2‑1 добре вирішує класичні проблеми апаратних збоїв і стихійних лих. Але сучасні загрози, насамперед ransomware, змушують додавати нові цифри до цієї формули.
Ще одна «1»: незмінна або ізольована копія
Одна з копій має бути або:
- immutable (незмінна), або
- air‑gapped (ізольована «повітряним зазором»).
Незмінний бекап працює як «діод» для даних: запис у один бік, читання — без обмежень, але перезапис існуючих блоків заборонено. Нові версії додаються як нові записи, а не замінюють старі.
Перевага:
- навіть якщо продакшен або онлайн‑копії будуть зашифровані ransomware, незмінний бекап залишиться недоторканим.
Air‑gap‑копія — це сховище, яке фізично від’єднали від мережі після створення знімка. Плюс — максимальна ізоляція; мінус — копія неминуче застаріває, бо не оновлюється в режимі реального часу.
Багато компаній називають свої системи «air‑gapped», хоча між ними і продакшеном зберігається мережевий зв’язок. У строгому сенсі air‑gap означає повну фізичну розв’язку.
«0» помилок: тестувати відновлення, а не лише бекап
Частий сценарій: організація роками дисципліновано робить резервні копії, але жодного разу не пробувала відновитися з них у повному обсязі. Поки не трапиться справжня аварія, система відновлення залишається «теоретично працездатною».
Наслідок — у момент катастрофи виявляється:
- частина архівів пошкоджена,
- частина — не читається через зміни у форматі,
- частина — не охоплює критичні сервіси.
Тому до формули 3‑2‑1 логічно додати ще одну вимогу: регулярне тестування сценаріїв відновлення, з перевіркою цілісності й актуальності даних.
Шифрування як обов’язковий шар захисту
Ще один горизонтальний принцип — шифрувати всі резервні копії. Без цього фізичне викрадення носія або компрометація хмарного сховища миттєво перетворюється на витік чутливих даних.
Шифрування бекапів:
- захищає від несанкціонованого доступу до вмісту;
- доповнює ідею відсутності одиночних точок відмови, зменшуючи ризик «людського фактора» на стороні інфраструктури.
Скільки «дев’яток» доступності ви готові оплатити
Резервне копіювання й відновлення тісно пов’язані з питанням доступності сервісів. Бізнес зазвичай формулює запит як «24/7/365», але кожна додаткова «9» в SLA має ціну.
Типові орієнтири:
- 99% (дві дев’ятки) — близько 3 днів простою на рік; для критичних сервісів це вже неприпустимо.
- 99,9% (три дев’ятки) — приблизно 8 годин простою; один повноцінний робочий день.
- 99,99% (чотири дев’ятки) — близько 52 хвилин простою.
- 99,999% (п’ять дев’яток) — орієнтовно 5 хвилин недоступності на рік.
Що вища ціль за доступністю, то:
- дорожчі інфраструктура і процеси;
- складніші архітектурні рішення потрібні;
- більші вимоги до якості резервування та швидкості відновлення.
Головне усвідомлення: повністю уникнути відмов неможливо. Завдання ІТ‑команди — зробити так, щоб інцидент не переростав у катастрофу, а відновлення було контрольованим й передбачуваним процесом. Грамотно реалізоване правило 3‑2‑1 з доповненнями у вигляді immutable‑копій, тестування та шифрування — один із найефективніших інструментів на цьому шляху.
Джерело
YouTube — 3‑2‑1 Backup Rule Explained: Protect Your Data from Disaster