Потеря данных приводит к тем же последствиям, что и отказ питания — остановке бизнеса.
Но если питание восстанавливается часами, данные без бэкапа не восстанавливаются вообще. Ransomware зашифровал сервера → нет бэкапа → выбор между выкупом и банкротством. Разбираемся, как строить систему резервного копирования.
Главная ошибка резервного копирования
Типичный сценарий: «Делаем бэкап раз в день на ту же систему хранения. Этого достаточно.» Проблема: единая точка отказа.
Что происходит на практике:
Ransomware проникла в сеть ↓ Зашифровала рабочие данные ↓ Зашифровала бэкапы (они в той же сети) ↓ Восстановиться невозможно
Правильный подход: изолированные копии на разных носителях в разных локациях.
Типы резервных копий
Полный бэкап (Full)
Копируются все данные целиком.
- Преимущества: простое восстановление (одна копия), не требует других бэкапов
- Недостатки: длительное время создания, большой объём хранилища, высокая нагрузка на сеть
Применение: еженедельно или ежемесячно в комбинации с инкрементальными.
Инкрементальный бэкап (Incremental)
Копируются только изменения с момента последнего бэкапа (любого типа).
Схема инкрементального бэкапа:
Понедельник: Full ↓ Вторник: изменения с понедельника (Incr1) ↓ Среда: изменения со вторника (Incr2) ↓ Четверг: изменения со среды (Incr3)
Восстановление: Full + Incr1 + Incr2 + Incr3 (все копии по цепочке)
- Преимущества: быстрое создание, минимальный объём, низкая нагрузка
- Недостатки: сложное восстановление (нужна вся цепочка), потеря одного звена = невозможность восстановления
Дифференциальный бэкап (Differential)
Копируются изменения с момента последнего полного бэкапа.
Схема дифференциального бэкапа:
Понедельник: Full ↓ Вторник: изменения с понедельника (Diff1) ↓ Среда: изменения с понедельника (Diff2) ↓ Четверг: изменения с понедельника (Diff3)
Восстановление: Full + последний Diff
- Преимущества: простое восстановление (Full + один Diff), быстрее полного бэкапа
- Недостатки: объём растёт к концу недели, медленнее инкрементального
Сравнение типов бэкапов
| Тип | Скорость создания | Объём | Восстановление | Применение |
|---|---|---|---|---|
| Full | медленно | большой | простое | еженедельно |
| Incremental | быстро | минимальный | сложное | ежедневно |
| Differential | средне | растущий | среднее | 2-3 раза в неделю |
Оптимальная стратегия: Full еженедельно + Incremental ежедневно.
Правило 3-2-1 резервного копирования
Методология защиты данных от любых сценариев потери.
Правило 3-2-1:
- 3 копии данных (рабочая + 2 бэкапа)
- 2 разных типа носителей (диск + лента / другой сервер)
- 1 копия за пределами площадки (удалённая локация)
Логика правила: 3 копии защищают от отказа носителя, 2 типа носителей защищают от отказа технологии, 1 удалённая копия защищает от локальной катастрофы.
Сценарии защиты
| Сценарий | Защита |
|---|---|
| Отказ диска | вторая локальная копия |
| Пожар в ЦОД | удалённая копия |
| Ransomware | оффлайн-копия (отключённая от сети) |
| Ошибка администратора | любая копия |
Без правила 3-2-1 всегда есть сценарий полной потери данных.
RPO и RTO — ключевые метрики
RPO (Recovery Point Objective) — допустимая потеря данных. Показывает: сколько данных можно потерять при аварии. Пример: бэкап раз в сутки → RPO = 24 часа, бэкап каждый час → RPO = 1 час, синхронная репликация → RPO ≈ 0. Вопрос бизнесу: «Сколько часов работы можно потерять?»
RTO (Recovery Time Objective) — время восстановления. Показывает: через сколько сервис заработает после аварии. Пример: восстановление из ленты → RTO = 8-12 часов, восстановление из диска → RTO = 2-4 часа, переключение на реплику → RTO = 5-10 минут. Вопрос бизнесу: «Сколько времени простоя допустимо?»
Зависимость стоимости от RPO/RTO
| RPO/RTO | Технология | Стоимость |
|---|---|---|
| 24 ч / 12 ч | ленточный бэкап | низкая |
| 6 ч / 4 ч | дисковый бэкап | средняя |
| 1 ч / 30 мин | снапшоты + репликация | высокая |
| 0 / 5 мин | синхронная репликация + кластер | очень высокая |
Чем жёстче требования — тем дороже решение.
Локальное vs удалённое хранение
Локальное хранение: бэкап на том же сервере / СХД / в том же ЦОД. Преимущества: быстрое восстановление, низкая latency, не требует канала связи. Недостатки: уязвимо для локальных катастроф (пожар, затопление), уязвимо для ransomware в той же сети, не соответствует правилу 3-2-1. Применение: первая копия для быстрого восстановления.
Удалённое хранение: бэкап на другой площадке (другой ЦОД, другой город). Преимущества: защита от локальных катастроф, защита от ransomware (если изолировано), соответствие правилу 3-2-1. Недостатки: медленное восстановление, требует канала связи, сложность синхронизации. Применение: вторая копия для катастрофоустойчивости.
Оптимальная схема: локальная + удалённая копии.
Защита от ransomware
Современные вымогатели шифруют не только данные, но и бэкапы.
Сценарий атаки ransomware:
Проникновение в сеть ↓ Распространение по инфраструктуре ↓ Обнаружение бэкап-серверов ↓ Шифрование бэкапов ↓ Шифрование рабочих данных ↓ Требование выкупа
Без защищённых бэкапов восстановление невозможно.
Методы защиты бэкапов
| Метод | Защита |
|---|---|
| Оффлайн-копии (air gap) | отключены от сети |
| Иммутабельность (immutable) | невозможно изменить/удалить |
| Отдельная сеть хранения | изолирована от основной |
| WORM-носители | однократная запись |
| MFA для доступа | защита учётных записей |
Критично: хотя бы одна копия должна быть недоступна из основной сети.
Автоматизация резервного копирования
Ручное резервное копирование — гарантия проблем.
Что автоматизировать:
- Расписание бэкапов
- Ротацию копий (удаление старых)
- Проверку целостности
- Оповещения об ошибках
- Репликацию на удалённую площадку
Правило: если процесс не автоматизирован, он будет забыт.
Проверка восстановления
Главная ошибка: делать бэкапы, но не проверять восстановление. Статистика: 40% бэкапов невозможно восстановить из-за ошибок.
Сценарий без проверки:
Делаем бэкапы годами ↓ Произошла авария ↓ Попытка восстановления ↓ Бэкапы повреждены / несовместимы / неполные ↓ Потеря данных
Правильный подход: ежемесячная проверка восстановления в тестовой среде.
Хранение бэкапов
Носители для резервного копирования.
| Носитель | Скорость | Объём | Стоимость $/ТБ | Применение |
|---|---|---|---|---|
| HDD | средняя | большой | низкая | дисковый бэкап |
| Лента (LTO) | низкая | очень большой | минимальная | архивное хранение |
| SSD | высокая | средний | высокая | быстрое восстановление |
Лента (LTO) — стандарт для долгосрочного хранения больших объёмов.
Типовая инфраструктура бэкапа
| Уровень | Технология | RPO | RTO |
|---|---|---|---|
| Первый (быстрый) | снапшоты на СХД | 1-4 ч | 30 мин |
| Второй (локальный) | дисковый бэкап | 24 ч | 4 ч |
| Третий (удалённый) | репликация в DR | 24 ч | 8 ч |
| Четвёртый (архив) | ленточное хранение | 7-30 дней | 1-2 дня |
Многоуровневая защита обеспечивает восстановление в любом сценарии.
Резервное копирование — не страховка, а необходимость. Ключевые принципы: правило 3-2-1 (3 копии, 2 носителя, 1 удалённая), защита от ransomware (оффлайн-копии), автоматизация процесса, регулярная проверка восстановления.
Критичные метрики: RPO — допустимая потеря данных, RTO — время восстановления. Главная ошибка: хранить все копии в одной локации/сети. Правильная стратегия: локальная копия для скорости + удалённая для надёжности + оффлайн для защиты от ransomware.
Частые вопросы
Какой тип бэкапа использовать ежедневно?
Инкрементальный — копирует только изменения, быстро создаётся, занимает минимум места. Полный бэкап делать еженедельно. Для восстановления нужны: последний Full + все Incremental по цепочке.
Как защитить бэкапы от ransomware?
Критично: хотя бы одна копия оффлайн (air gap — отключена от сети). Дополнительно: иммутабельные копии (нельзя изменить), отдельная сеть хранения, MFA для доступа. Ransomware шифрует всё доступное в сети.
Как часто проверять восстановление?
Минимум раз в месяц в тестовой среде. Без проверки 40% бэкапов оказываются повреждёнными при попытке восстановления. Проверка должна быть автоматизирована и логироваться.