Ни один бизнес не может гарантировать работу без инцидентов. В жизни всегда есть неизвестная переменная: устройства ломаются, сотрудники ошибаются и удаляют данные, киберпреступники шифруют информацию на дисках и требуют выкуп. И все же, как минимум, застраховаться от полной потери данных можно. Резервное копирование, или бэкап (backup) — первый и самый важный шаг, чтобы было, из чего восстановить систему случае сбоя и атаки.
Разберем, как устроен бэкап, какие виды резервных копий существуют и как использовать правило 3-2-1, которое стало золотым стандартом отрасли.
В двух словах: что такое резервное копирование, RTO и RPO
Резервное копирование (backup) — это процесс создания дублирующих копий информации и их сохранения на отдельном носителе или в удаленном хранилище. Именно из резервной копии происходит восстановление данных при утрате оригинала.
Проще говоря, вы делаете «запасной экземпляр» важных файлов, баз данных, конфигураций серверов и виртуальных машин, чтобы при любой непредвиденной ситуации использовать его и вернуть работоспособность ИТ-инфраструктуры.
Важно понимать разницу между резервным копированием и смежными понятиями.
Синхронизация (например, через облачные диски) — это процесс, а именно копирование изменений в реальном времени — и если файл повредился, битая версия моментально окажется во всех копиях.
Архивация — это перенос данных на долгосрочное хранение и удаление их с основного диска. Это защищает от того, что данные будут утрачены из-за сбоев, но не спасет от вируса-шифровальщика или пользовательских действий.
Только создание полноценного бэкапа решает задачу восстановления конкретного состояния данных на конкретный момент времени.
С точки зрения бизнеса резервное копирование — это часть более широкой дисциплины Disaster Recovery (аварийное восстановление), где ключевыми метриками выступают:
RPO (Recovery Point Objective) — целевая точка восстановления данных. Или, как еще говорят, объем потерянных данных, измеряемый временем. Например: при RPO = 4 часа копии будут создаваться не реже одного раза в 4 часа. И значит, при сбое или атаке вы гарантированно используете свежие данные, которые были сохранены не позже 4 часов назад.
RTO (Recovery Time Objective) — целевое время восстановления данных, или допустимое время простоя, за которое необходимо полностью восстановить сервисы. Например, при RTO = 1 час ИТ-инфраструктура должна полностью восстановиться после сбоя не позже, чем через 60 минут.
Чем критичнее данные, тем меньше эти значения и тем серьезнее требования к системе резервного копирования и хранилищу.
Зачем нужно резервное копирование и от чего оно защищает
Не стоит думать, что утрата данных — это редкость. Каждая компания, работающая с цифровой информацией, постоянно находится в зоне риска. Угрозы можно условно разделить на несколько групп, и бэкап закрывает большинство из них.
Категория угроз
Примеры
Вероятность
Технические сбои
Отказ дисков HDD/SSD, повреждение RAID, сбой контроллера, других устройств
Пожар, затопление, кража диска или сервера, отключение питания
Низкая, но критичная
Особенно остро стоит проблема программ-вымогателей. По данным Positive Technologies, более 70% успешных кибератак происходят с использованием вредоносного ПО на устройствах компании. Вот основные типы ВПО, которые команда PT определяет как наиболее распространенные:
программы-ransomware — 49%;
ПО для удаленного доступа — 33%;
шпионское ПО, которое записывает нажатие клавиш и т.д. — 22%.
Это необязательно нелегальные программы: доля легального ПО для атак растет. Злоумышленники постоянно совершенствуют инструменты, в их арсенале много средств, которые не так просто распознать. А средний выкуп за расшифровку корпоративных файлов превышает несколько миллионов рублей, при этом гарантий восстановления никто не дает.
В таких случаях облачный бэкап реально спасает. Компания с актуальным изолированным бэкапом просто разворачивает все заново из резервной копии в хранилище. И можно думать о том, как защититься от дальнейших атак.
Кроме того, создание DR-стратегии и резервное копирование решают такие бизнес-задачи:
непрерывная деятельность бизнеса и сохранение лояльности клиентов;
выполнение регуляторных требований (в некоторых отраслях);
защиту репутации бренда;
сохранение интеллектуальной собственности;
возможность отката после неудачных обновлений или миграций.
Как часто нужно делать резервные копии?
Универсального ответа на этот вопрос не существует — частота резервного копирования всегда определяется индивидуально под конкретный бизнес. Подход «одна периодичность для всех» здесь не работает: то, что избыточно для небольшой бухгалтерии, окажется катастрофически недостаточным для интернет-магазина с тысячами транзакций в час. Чтобы определить оптимальный график, нужно честно ответить на несколько ключевых вопросов: насколько критичны данные для операционной деятельности, сколько стоит сам процесс резервного копирования и — главное — сколько будет стоить для компании потеря информации при реальной аварии.
Отталкивайтесь от RPO — цели точки восстановления
Частота создания копий напрямую вытекает из RPO, о котором мы писали выше. Это метрика из плоскости бизнеса, и определять ее должно руководство компании. Логика простая: ИТ-специалисты предоставляют технологии и инструменты, но решение о приемлемом уровне риска принимает бизнес.
Чтобы понять ваш RPO, решите, какой объем данных компания готова потерять без критических последствий?
Допустимая потеря данных
Рекомендуемая частота резервного копирования
Типичные сценарии
До недели
Не реже одного раза в неделю
Архивы, справочная информация, редко изменяемые документы
До суток
Ежедневно (обычно ночью)
Корпоративные файловые серверы, CRM с умеренной активностью
До часа
Ежечасно или чаще
E-commerce, биллинг, финансовые операции
Близко к нулю
Непрерывная репликация (CDP)
Банковские транзакции, биржевые системы, критичные SaaS
Не менее важно определить RTO (Recovery Time Objective), то есть время, за которое нужно вернуться к работе после инцидента. Представьте ситуацию: вы делаете почасовые инкрементальные копии и полный бэкап по воскресеньям. В пятницу вечером происходит сбой диска. Формально вы потеряете максимум час данных, но восстановление потребует развернуть воскресный полный бэкап и последовательно применить почти неделю инкрементов — а это часы, а порой и сутки простоя.
Именно RTO определяет архитектуру хранения, выбор методов резервного копирования и периодичность создания полных копий. Чем амбициознее цели — короче RPO и RTO, — тем дороже обойдется система. Это объективная закономерность: моментальное восстановление с нулевыми потерями требует дублирующей облачной инфраструктуры, быстрых хранилищ и продвинутого ПО.
Практические рекомендации по графику
В большинстве компаний оптимальной оказывается комбинированная схема: ежедневные инкрементальные копии + еженедельные или ежемесячные полные.
Сами задания резервного копирования планируйте на часы минимальной нагрузки — как правило, это ночь, — чтобы не влиять на производительность боевых систем.
Параллельно с выбором частоты решите еще два вопроса: какие копии вы храните локально для быстрого восстановления, а какие отправляете во внеофисное или облачное хранилище, чтобы точно обезопасить себя от событий, которые связаны с физическим повреждением. Это напрямую связано с правилом 3-2-1, о котором мы скажем ниже.
Александр Будкин, ИТ-директор OXYGEN:
«Важные, но неочевидные моменты: автоматизируйте процесс настолько, насколько это возможно, обязательно документируйте регламент и регулярно тестируйте восстановление. Резервная копия, которую ни разу не разворачивали, — это не бэкап, а всего лишь предположение о бэкапе (или обещание бэкапа). Доверяй, но проверяй! Только успешный тест восстановления из хранилища подтверждает, что выбранная частота и стратегия действительно работают».
В OXYGEN мы поможем вам с созданием Disaster Recovery Plan и целевыми RTO/RPO, найдем баланс между безопасностью и ИТ-бюджетом и предложим самую оптимальную стратегию резервного копирования, включая облачное хранение. А также обязательно построим график тестирования вашего DR-сценария, чтобы вы были уверены в работоспособности.
Как работает backup: создание копий, хранение и восстановление данных
Процесс резервного копирования состоит из нескольких последовательных этапов, каждый из которых критичен для итогового результата.
Этап 1. Определение объектов копирования. Администратор формирует перечень того, что подлежит защите: файловые серверы, базы данных, виртуальные машины, почтовые системы, конфигурации сетевого оборудования, исходный код, пользовательские рабочие места.
Этап 2. Выбор политики и расписания. Определяются частота, тип копий, глубина хранения (retention), окна резервного копирования — временные интервалы, когда нагрузка на систему минимальна.
Этап 3. Создание копии. Специализированное ПО считывает данные с источника, при необходимости применяет дедупликацию (исключение дублирующихся блоков) и компрессию, затем передает их в хранилище. Современные решения используют технологии снапшотов и CBT (Changed Block Tracking), которые позволяют копировать только измененные блоки данных.
Этап 4. Хранение. Копии размещаются на локальных СХД, ленточных библиотеках, NAS, в облачных репозиториях или комбинированных хранилищах. Применяется шифрование на стороне источника и/или хранилища.
Этап 5. Верификация. Без регулярной проверки целостности и тестового восстановления бэкап превращается в иллюзию защиты. Хорошие системы автоматически запускают проверочные восстановления в изолированной среде.
Этап 6. Восстановление. При необходимости данные разворачиваются обратно — целиком, частично (granular recovery — отдельные файлы, письма, записи БД) или в виде запуска виртуальной машины напрямую из бэкапа (Instant Recovery).
Виды резервного копирования: полное, инкрементальное, дифференциальное и облачное
Выбор типа копии напрямую влияет на скорость бэкапа, объем хранилища и время восстановления.
Полное копирование (Full Backup). Создается полный дубликат всех выбранных данных и файлов. Самый надежный и простой для восстановления вариант, но требует максимум места и времени.
Инкрементальное копирование (Incremental). Сохраняются только изменения, произошедшие с момента последнего бэкапа любого типа. Экономит дисковое пространство и сетевой трафик, но восстановление требует последовательного применения всей цепочки копий.
Дифференциальное копирование (Differential). Сохраняются изменения, произошедшие с момента последнего полного бэкапа. Размер копий растет день ото дня, но восстановление быстрее, чем у инкрементального.
Синтетическое полное (Synthetic Full). Система объединяет последний полный бэкап и последующие инкременты в новую полную копию без обращения к источнику. Это снижает нагрузку на продуктивные системы.
Зеркальное копирование (Mirror). Создание точной копии данных и файлов без сжатия и версионности. Быстрое восстановление, но нет защиты от логических ошибок.
Облачное копирование (Cloud Backup). Данные передаются и хранятся в удаленном облачном репозитории провайдера. Может быть как самостоятельным решением, так и второй/третьей копией в гибридной схеме с локальными дисками. Удобный вариант — резервное копирование как сервис, когда облачный провайдер берет на себя инфраструктуру, лицензии, мониторинг и SLA.
Правило 3-2-1 резервного копирования
Это проверенная временем формула, которая стала фундаментом любой серьезной backup-стратегии. Расшифровывается она следующим образом:
3 — должно существовать минимум три копии данных (оригинал плюс две резервные).
2 — копии хранятся минимум на двух разных типах носителей и устройств (например, дисковый массив и объектное хранилище).
1 — минимум одна копия находится географически удаленно (off-site), вне основной площадки.
В таком сценарии каждый элемент закрывает определенный класс рисков. Несколько копий защищают от случайного повреждения одной из них. Разные носители — от одновременного отказа однотипного оборудования. Удаленная копия — от физической катастрофы на основной площадке и уничтожения файлов с ваших устройств.
Схема реализации правила 3-2-1 для среднего бизнеса:
Основной диск + внешний HDD + облачная площадка.
Чем поможет OXYGEN
У нас есть широкий набор сервисов для организации системы резервного копирования и хранения данных и файлов. Подбор решения зависит от разных факторов, которые мы обсуждаем индивидуально: какой объем данных, типы рабочих нагрузок, бюджет, требования к RTO/RPO.
Backup as a Service — защитите данные от риска утраты и обеспечьте быстрое восстановление системы. Мы предоставляем отдельную enterprise-консоль для управления вашими резервными копиями, где можно легко настраивать правила cloud-бэкапов под любые задачи компании. Облачные решения OXYGEN совместимы с популярными платформами виртуализации, поэтому подберем именно то, что нужно вам. Среди наших преимуществ — высокая скорость резервирования и гарантии по SLA.
Идеально для реализации правила 3-2-1 — разместите резервные копии критичных систем на нашей удаленной площадке, в защищенном ЦОДе Tier III. Мы используем сеть 10GbE, чтобы вы могли сверхбыстро загружать резервные копии, скорость канала до серверов Veeam Cloud Connect не ограничена. У вас будет доступ к вашим резервным копиям в любой момент, без сложной настройки VPN или дополнительных ресурсов — прямо из консоли Veeam.
Больше, чем резервное копирование — настоящая стратегия защиты ваших данных в зависимости от их критичности. Disaster Recovery позволяет минимизировать время простоя и оперативно восстановить ключевые бизнес-процессы. Это гарантирует, что ваши клиенты будут получать услуги без задержек. Можем реализовать любой сценарий, включая самый амбициозный для достижения RTO/RPO = 0.
Для большинства компаний среднего и крупного бизнеса сервисная модель оказывается выгоднее: не нужно инвестировать в железо и диски, нанимать узких специалистов, продлевать лицензии. Мы гарантируем доступность и сохранность файлов, обеспечиваем соответствие хранения требованиям регуляторов, а вы гибко управляете расходами на ИТ-инфраструктуру.
