Резервное копирование: что это такое и как защитить резервные копии

Что такое резервное копирование

Резервное копирование — это процесс создания копий данных для их восстановления после потери или повреждения оригинала. В ИТ-среде такой процесс часто называют backup, а саму копию — бэкапом.

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

Резервная копия отличается от обычной копии файла. Например, сотрудник может скопировать документ на другой диск. Такая операция создает дополнительный экземпляр, но сама по себе не формирует полноценную систему защиты данных.

Корпоративная система резервного копирования обычно работает по заданным правилам: контролирует расписание, сроки хранения, версии и доступ к копиям, а также фиксирует ошибки и результаты заданий.

Еще одно важное свойство — возможность восстановить данные на нужный момент времени. Это особенно важно для баз данных и виртуальных машин.

Если файл повредили сегодня, наличие только его поврежденной копии не поможет. Нужна более ранняя версия, которая содержит корректные данные.

Поэтому резервное копирование — это не просто дублирование информации, а управляемый процесс, связанный с жизненным циклом данных.

Зачем нужно резервное копирование

Главная задача резервного копирования — вернуть данные и рабочие системы после инцидента. Причины потери информации могут быть разными.

Один из распространенных сценариев — человеческая ошибка. Сотрудник может удалить папку, изменить важную таблицу или перезаписать документ.

Сбои оборудования также представляют угрозу. Может выйти из строя накопитель, сервер или система хранения, а иногда проблема затрагивает сразу несколько компонентов.

Ошибки программного обеспечения способны повредить данные без физического отказа оборудования. Например, неудачное обновление может нарушить работу базы данных или приложения.

Отдельный риск — кибератаки. Программа-вымогатель может зашифровать рабочие файлы, серверы и доступные резервные копии. Злоумышленник также может попытаться удалить бэкапы перед основной фазой атаки.

Нельзя исключать и физические аварии: пожар, затопление, перебои электропитания и другие происшествия могут вывести площадку из строя.

Для бизнеса последствия измеряются не только стоимостью утраченных данных. Не менее критична длительность простоя.

Без резервных копий компания может потерять доступ к CRM, бухгалтерской системе или производственным сервисам. Восстановление вручную может занять много времени или оказаться невозможным.

Грамотно построенная система резервного копирования сокращает период восстановления и делает последствия инцидента более прогнозируемыми.

Резервное копирование и информационная безопасность

В информационной безопасности резервное копирование связано прежде всего с доступностью данных. Даже после серьезного инцидента организация должна иметь возможность вернуть критичные сервисы в работу.

При этом резервное копирование нельзя рассматривать только как операционную задачу ИТ-службы. Оно является одним из элементов киберустойчивости — способности организации продолжать работу и восстанавливаться после атаки.

Резервные копии особенно важны при атаках программ-вымогателей, но их наличие само по себе не гарантирует успешного восстановления.

Если злоумышленник получил административные права, он может удалить доступные бэкапы. Другой вариант — зашифровать хранилище вместе с основной инфраструктурой.

Проблема может возникнуть и без действий атакующего. Копии иногда создаются с ошибками или содержат уже поврежденные данные.

Поэтому безопасное резервное копирование строится вокруг трех задач: создать копию, сохранить ее и убедиться, что из нее можно восстановить данные.

Последний этап особенно важен: успешное создание резервной копии еще не подтверждает возможность восстановления.

Какие бывают виды резервного копирования

На практике чаще всего используют три базовых метода: полное, инкрементальное и дифференциальное резервное копирование.

Полное резервное копирование

При полном резервном копировании система каждый раз сохраняет весь выбранный набор данных.

Такой подход упрощает восстановление: обычно достаточно одной полной копии.

Недостаток — большой объем данных. Полное резервное копирование требует больше места и создает повышенную нагрузку на сеть и хранилище.

Поэтому ежедневное полное копирование больших систем может требовать значительных ресурсов.

Инкрементальное резервное копирование

Инкрементальное резервное копирование сохраняет только изменения, появившиеся после предыдущего резервного копирования.

Например, в воскресенье создается полная копия. В понедельник система сохраняет изменения за один день, а во вторник — изменения после понедельничного резервного копирования.

Такой подход уменьшает объем каждой операции и сокращает окно резервного копирования.

Однако восстановление усложняется: системе может потребоваться полная копия и вся цепочка последующих инкрементов.

Повреждение одного элемента цепочки способно затруднить восстановление.

Дифференциальное резервное копирование

Дифференциальное резервное копирование сохраняет изменения после последней полной копии.

Если полная копия создана в воскресенье, понедельничная копия содержит изменения за понедельник. Во вторник сохраняются изменения уже за два дня.

Объем дифференциальной копии постепенно растет до следующего полного резервного копирования.

Восстановление обычно проще, чем при классической инкрементальной схеме: нужны последняя полная и актуальная дифференциальная копии.

В реальной инфраструктуре методы часто комбинируют. Выбор зависит от объема данных, окна резервного копирования и требований к восстановлению.

Где хранят резервные копии

Хранилище резервных копий должно соответствовать рискам и задачам компании.

Самый простой вариант — локальная система хранения. Она обеспечивает быстрый доступ к данным и удобна для оперативного восстановления.

Однако локальное хранилище может пострадать вместе с основной инфраструктурой, например при атаке, физической аварии или компрометации учетной записи.

Поэтому часть копий часто переносят на отдельную площадку — например, в другой офис или центр обработки данных (ЦОД).

Другой вариант — облачное хранилище. Оно позволяет географически отделить копии от основной инфраструктуры.

Но использование облака само по себе не решает задачу защиты. Необходимо учитывать права доступа, модель ответственности и безопасность учетных записей.

В некоторых инфраструктурах используют ленточные носители. Они могут применяться для длительного хранения больших объемов данных.

Особое место занимают изолированные копии. Offline-копия физически или логически недоступна основной инфраструктуре большую часть времени.

Air gap подразумевает разделение среды хранения и рабочей сети. Степень изоляции зависит от конкретной архитектуры.

Еще один вариант — immutable backup, то есть неизменяемая резервная копия. После записи ее нельзя изменить или удалить в течение заданного срока.

Неизменяемость снижает риск уничтожения бэкапов при компрометации административной учетной записи, если механизм реализован независимо от скомпрометированной среды управления.

Правило 3-2-1 и его современные варианты

Правило 3-2-1 — один из распространенных принципов организации резервного копирования.

Классическая схема предполагает:

• иметь минимум три экземпляра данных;
• хранить их минимум на двух разных типах носителей или систем;
• держать минимум одну копию вне основной площадки.

Основные рабочие данные считаются первым экземпляром. Две дополнительные копии создают необходимый запас.

Смысл правила не столько в самих цифрах, сколько в снижении риска единой точки отказа.

Например, две копии на одном сервере почти не дают дополнительной защиты: отказ сервера может сделать недоступными обе.

С развитием киберугроз, в том числе ransomware, появились расширенные варианты этого принципа.

Один из них — правило 3-2-1-1-0. Первые три цифры сохраняют прежнее значение.

Дополнительная единица обычно означает наличие изолированной или неизменяемой копии, а ноль — отсутствие ошибок после проверки резервных данных и восстановления.

Встречаются и другие варианты правила. Важнее конкретной формулы принцип независимости копий.

Критичная резервная копия должна оставаться доступной для восстановления даже при компрометации основной инфраструктуры.

Что такое RPO и RTO

При проектировании системы резервного копирования важно определить два показателя.

RPO — Recovery Point Objective, или целевая точка восстановления. Показатель определяет максимально допустимый объем потери данных, выраженный через период времени.

Проще говоря, RPO отвечает на вопрос: за какой период организация допускает потерю изменений?

Предположим, RPO бухгалтерской системы равен одному часу. Это означает, что после инцидента необходимо иметь возможность восстановить состояние данных с потерей не более часа изменений.

Если резервная копия создается раз в сутки и других механизмов защиты данных нет, такое требование выполнить не получится.

RTO — Recovery Time Objective, или целевое время восстановления. Этот показатель определяет допустимое время восстановления сервиса после инцидента.

Например, если RTO равен четырем часам, сервис должен быть восстановлен в пределах этого периода.

RPO и RTO связаны, но описывают разные требования.

RPO относится к допустимой потере данных, RTO — ко времени восстановления.

Чем жестче эти требования, тем больше ресурсов может потребоваться для построения соответствующей архитектуры.

Низкий RPO требует более частого сохранения изменений или других механизмов защиты данных. Низкий RTO требует быстрого доступа к резервным копиям и достаточных ресурсов для восстановления.

Поэтому RPO и RTO целесообразно определять отдельно для разных систем и сервисов.

Критичная платежная система и архив старых документов могут иметь разные требования к восстановлению.

Такой подход позволяет распределять ресурсы с учетом критичности систем.

Основные угрозы для резервных копий

Резервная копия сама является ценным активом. В некоторых сценариях злоумышленник может атаковать инфраструктуру резервного копирования до воздействия на основные системы.

Один из рисков — компрометация административной учетной записи. Получив высокие привилегии, атакующий может попытаться удалить задания и резервные копии.

Другой риск — ransomware. Программа-вымогатель может зашифровать сетевые хранилища, которые постоянно доступны из основной инфраструктуры.

Опасны и ошибки конфигурации. Например, организация считает, что резервирует все виртуальные машины, но часть новых систем не добавлена в задания.

Существует и риск неполного или поврежденного резервного копирования. Задание может формально завершиться успешно, однако данные окажутся непригодными для восстановления.

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

Поэтому инфраструктуру резервного копирования необходимо рассматривать как отдельный защищаемый контур.

Как защитить резервные копии

Первый принцип — разделять рабочую инфраструктуру и инфраструктуру резервного копирования.

Если администратор основной среды автоматически получает полный доступ к резервным копиям, компрометация его учетной записи может затронуть и резервный контур.

Для управления системой резервного копирования следует использовать отдельные учетные записи, а права выдавать по принципу минимальных привилегий.

Для привилегированного доступа целесообразно применять MFA — Multi-Factor Authentication, или многофакторную аутентификацию.

Она снижает риск использования учетной записи только на основании похищенного пароля.

Административные консоли не должны быть доступны из любой части корпоративной сети. Доступ можно ограничить выделенными сегментами и управляющими станциями.

Данные следует защищать при передаче и хранении. Если применяется шифрование, отдельно нужно продумать управление и резервирование ключей.

Для критичных данных можно использовать неизменяемые хранилища. Они не позволяют изменить или удалить записанные данные в течение установленного срока.

При этом неизменяемость не заменяет другие меры защиты. Ошибочно созданная или уже поврежденная резервная копия также может оказаться неизменяемой.

Поэтому необходимы мониторинг, контроль целостности и тестирование восстановления.

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

Журналы управления системой резервного копирования желательно передавать во внешнюю систему мониторинга. Это снижает риск одновременного уничтожения резервных копий и следов действий в той же системе.

Почему важно проверять восстановление

Успешное резервное копирование и успешное восстановление — не одно и то же.

Система может каждую ночь показывать успешный статус задания, но это не гарантирует, что данные действительно можно использовать.

Например, файл мог скопироваться без ошибок, хотя приложение записало его в некорректном состоянии.

В другом случае все копии могут зависеть от ключа шифрования, который был утрачен.

Еще один сценарий — слишком медленное восстановление. Формально данные доступны, но восстановление нескольких десятков терабайт может занять несколько дней.

Если RTO системы составляет четыре часа, такая схема не соответствует установленному требованию.

Поэтому восстановление нужно регулярно тестировать.

Для критичных систем можно проводить учебные аварийные восстановления: команда берет резервную копию и разворачивает систему в изолированной среде.

Так проверяют не только сами данные, но также инструкции, зависимости и готовность сотрудников.

В рамках процессов Disaster Recovery проводят комплексные тесты восстановления ИТ-среды после крупной аварии или киберинцидента.

Такие проверки помогают выявить зависимости, которые трудно заметить при анализе документации.

Например, приложение может успешно восстановиться, но не работать без DNS, службы каталогов или внешней базы данных.

Резервное копирование, репликация и архивирование: в чем разница

Эти подходы решают смежные задачи, поэтому их иногда путают.

Резервное копирование создает точки восстановления. Его главная задача — вернуть данные после потери или повреждения.

Репликация поддерживает копию данных или системы на другом сервере или площадке и применяется в том числе для повышения доступности.

Однако репликация сама по себе не всегда защищает от логических ошибок.

Если сотрудник удалил данные, изменение может попасть и на реплику. То же возможно при повреждении или шифровании данных.

Поэтому репликация не заменяет резервное копирование.

Архивирование предназначено прежде всего для длительного хранения данных, которые редко используются в текущей работе.

Архив может понадобиться для хранения истории, выполнения внутренних требований или длительного хранения документов.

В одной инфраструктуре все три подхода могут использоваться одновременно.

Типичные ошибки при организации резервного копирования

Одна из наиболее опасных ошибок — хранить все резервные копии рядом с рабочими данными. В таком случае одна авария или атака может затронуть всю инфраструктуру.

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

К другим распространенным ошибкам относятся:

• отсутствие изолированной или immutable-копии для критичных данных;
• отсутствие заданных RPO и RTO;
• новые сервисы не включаются в задания резервного копирования;
• ошибки заданий не контролируются;
• сроки хранения выбираются без учета требований бизнеса;
• восстановление проверяется только после реальной аварии.

Отдельная ошибка — считать количество копий главным показателем надежности.

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

Поэтому важно оценивать не только количество копий, но и архитектуру хранения и доступа.

Как построить систему резервного копирования в компании

Работу стоит начинать не с покупки хранилища, а с инвентаризации.

Сначала нужно определить, какие системы и данные существуют в инфраструктуре, а затем оценить их роль в бизнес-процессах.

Не все данные требуют одинакового уровня защиты.

Для критичных систем необходимо определить RPO и RTO. После этого можно выбирать частоту и метод резервного копирования, сроки хранения и тип хранилища.

Следующий шаг — спроектировать распределение копий.

Часть данных можно хранить локально для быстрого восстановления. Еще одну копию следует вынести за пределы основной площадки.

Для наиболее критичных систем стоит предусмотреть дополнительный изолированный или неизменяемый уровень хранения.

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

Отдельный процесс — мониторинг заданий.

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

Последний обязательный этап — проверка восстановления.

Для разных классов систем можно установить отдельный график тестов. Частота проверки должна учитывать критичность сервиса, требования к восстановлению и особенности инфраструктуры.

Чек-лист: каким должно быть надежное резервное копирование

Систему резервного копирования можно оценить по нескольким базовым признакам.

Проверьте, выполняются ли следующие условия:

• существуют несколько независимых копий критичных данных;
• копии логически или географически разделены;
• есть изолированная или immutable-копия;
• административный доступ отделен от основной инфраструктуры;
• для привилегированного доступа используется MFA;
• данные защищены при передаче и хранении;
• ошибки заданий резервного копирования контролируются;
• целостность копий регулярно проверяется;
• восстановление периодически тестируется;
• существует документированный порядок действий при аварии.

Если несколько пунктов отсутствуют, сама система резервного копирования может выполнять задания корректно, однако общий процесс восстановления останется уязвимым.

Если компания пересматривает систему резервного копирования, стоит начать с оценки текущей архитектуры: определить требования к RPO и RTO, проверить защиту административного доступа, изоляцию копий и готовность к восстановлению.

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

FAQ

Как часто нужно делать резервные копии?

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

Где лучше хранить резервные копии?

Не следует хранить все копии на одной площадке и в одном контуре доступа. Часть можно держать локально для быстрого восстановления, а другую — отдельно от основной инфраструктуры. Для критичных данных стоит предусмотреть изолированную или immutable-копию.

Защищает ли резервное копирование от программ-вымогателей?

Резервное копирование помогает восстановиться после атаки программы-вымогателя, если сами копии защищены от удаления и изменения. Если злоумышленник имеет к ним доступ, резервные данные также могут быть уничтожены или зашифрованы.

Чем репликация отличается от резервного копирования?

Репликация поддерживает актуальную копию данных или системы и помогает повышать доступность. Резервное копирование сохраняет точки восстановления. Ошибка, удаление или повреждение данных могут попасть на реплику, поэтому репликация не заменяет резервную копию.

Нужно ли тестировать восстановление, если резервное копирование всегда завершается успешно?

Да. Успешное выполнение задания подтверждает создание копии, но не гарантирует, что данные пригодны для восстановления. Реальную готовность системы подтверждает только тестовое восстановление.