Резервное копирование относится к базовым процессам обеспечения устойчивости информационных систем. Организации хранят данные на физических серверах, виртуальных машинах, в базах данных, файловых хранилищах и прикладных системах. Отказ оборудования, программная ошибка, некорректное обновление, случайное удаление информации или нарушение работы инфраструктуры способны привести к потере данных и остановке сервисов. Поэтому резервная копия рассматривается не просто как дополнительный экземпляр файла, а как часть заранее спроектированной системы восстановления.
Российские системы резервного копирования применяются в корпоративных дата-центрах, государственных информационных системах, инфраструктуре предприятий, образовательных и медицинских организаций, а также у операторов различных ИТ-сервисов. Их задача заключается в автоматизации создания, хранения, контроля и восстановления резервных копий с учётом особенностей отечественной программной и аппаратной инфраструктуры.
Выбор конкретной платформы зависит от состава информационных систем, объёма данных, требований к срокам восстановления и допустимому объёму потерь. Универсальной схемы, одинаково подходящей небольшому офису и крупному дата-центру, не существует.
Что представляет собой система резервного копирования
Система резервного копирования - это программный комплекс, который организует создание копий информационных ресурсов по заданным правилам. Она может работать с файлами, каталогами, операционными системами, виртуальными машинами, базами данных и другими объектами.
В простейшем варианте резервирование заключается в переносе данных с основного носителя на другой диск. В корпоративной среде этого недостаточно. Необходимо учитывать расписание, версионность, автоматическое удаление устаревших копий, контроль свободного пространства, права пользователей, шифрование, журналирование и возможность восстановления.
Поэтому специализированная система обычно включает управляющий сервер, компоненты взаимодействия с защищаемыми системами и одно или несколько хранилищ. Администратор задаёт правила, определяет источники данных и контролирует результаты выполнения заданий через централизованный интерфейс.
Одной из важных функций становится каталог резервных копий. Он позволяет установить, когда создавалась конкретная версия, к какому серверу она относится и какие данные могут быть восстановлены.
Почему резервная копия должна находиться отдельно
Копирование файла в другую папку на том же диске нельзя считать полноценным резервированием. При физическом отказе накопителя будут потеряны одновременно оригинал и копия.
Аналогичная ситуация возникает, если рабочая информационная система и все резервные данные размещаются на одном дисковом массиве. Сбой контроллера, повреждение файловой системы или другая проблема общего уровня способна затронуть обе части.
Поэтому резервные данные желательно физически или логически отделять от основных. Для этого используются выделенные серверы, системы хранения, объектные хранилища и другие специализированные ресурсы.
В некоторых инфраструктурах создаётся дополнительная копия на другой площадке. Географическое разделение защищает от событий, затрагивающих целый дата-центр или серверное помещение.
Чем критичнее информация, тем важнее исключать единые точки отказа.
Полное резервное копирование
При полном копировании система сохраняет весь выбранный набор данных. Это может быть файловый каталог, база данных или виртуальная машина в зависимости от используемой технологии.
Преимущество полной копии заключается в сравнительно понятной структуре восстановления. Для возврата данных требуется основной резервный набор, не зависящий от большой последовательности предыдущих операций.
Недостатком является значительный объём. Если предприятие хранит десятки терабайт информации, ежедневное создание полной копии может потребовать много времени, сетевой пропускной способности и дискового пространства.
Поэтому полные копии нередко создаются с определённой периодичностью, а между ними сохраняются только изменения.
Конкретный график зависит от размера данных и допустимого резервного окна - времени, в течение которого операция может выполняться без критичного влияния на производственные системы.
Инкрементальная схема
Инкрементальное резервирование позволяет копировать информацию, которая изменилась после предыдущего соответствующего задания.
Например, в понедельник создаётся полный экземпляр файлового сервера. Во вторник система сохраняет только произошедшие после него изменения, а в среду - новые изменения после вторничного задания.
Основное преимущество заключается в сокращении объёма передаваемых данных. Чем меньше информации изменяется между операциями, тем заметнее экономия пространства и времени.
Однако цепочка становится более сложной. Для восстановления состояния на определённую дату могут потребоваться полная копия и несколько последующих инкрементов.
Поэтому необходимо следить за целостностью всей последовательности и регулярно проводить тестовое восстановление.
Дифференциальное резервирование
При дифференциальной схеме сохраняются все изменения относительно последней полной копии.
Если полный экземпляр был создан в воскресенье, копия среды содержит изменения за один день, вторничная - за два дня и так далее. После следующего полного резервирования цикл начинается заново.
Такой вариант занимает больше места, чем последовательность небольших инкрементов, но может упростить восстановление, поскольку требуется меньше элементов цепочки.
Выбор между полной, инкрементальной и дифференциальной схемой определяется архитектурой системы. Различные ресурсы в одной организации могут резервироваться по разным правилам.
Автоматизация резервного копирования
Один из основных принципов корпоративного резервирования - минимальная зависимость от ручных действий.
Администратор определяет расписание, после чего система самостоятельно запускает задания. Например, файловые ресурсы могут копироваться ночью, базы данных - несколько раз в сутки, а отдельные критичные ресурсы - значительно чаще.
Автоматизация снижает риск ситуации, когда сотрудник забыл вручную создать копию. Однако она не означает, что резервирование можно полностью оставить без наблюдения.
Необходимо отслеживать завершение заданий, появление ошибок и доступность хранилищ. Если ежедневное копирование несколько недель завершается с ошибкой, а уведомления никто не контролирует, наличие самой системы не обеспечивает защиту данных.
Поэтому автоматизация и мониторинг должны работать совместно.
Политики и расписания
При большом количестве серверов удобнее использовать не отдельные настройки для каждого объекта, а политики.
Политика определяет тип резервирования, расписание, срок хранения и другие параметры. Затем она назначается определённой группе ресурсов.
Например, критичные серверы могут иметь одну политику, тестовая инфраструктура - другую, а архивные файловые данные - третью.
Такой подход помогает стандартизировать процессы. Новый сервер можно отнести к нужной категории, после чего он получает предусмотренную для неё схему защиты.
Политики следует периодически пересматривать. Информационная система, которая несколько лет назад была вспомогательной, со временем может превратиться в важный бизнес-сервис.
Резервирование файловых систем
Файловый уровень остаётся одним из наиболее распространённых объектов защиты. Это пользовательские документы, общие сетевые каталоги, конфигурационные файлы и рабочие данные приложений.
При настройке задания определяется, какие каталоги необходимо включать и что можно исключить. Кэши, временные файлы и автоматически генерируемые данные иногда нет смысла переносить в резервное хранилище.
Однако исключения необходимо задавать осторожно. Если важный каталог ошибочно не вошёл в задание, проблема обнаружится только при попытке восстановления.
Для файловых серверов также полезна возможность восстанавливать отдельный файл или папку без возврата всего массива данных.
Это актуально в случае случайного удаления пользователем одного документа.
Резервное копирование баз данных
Базы данных требуют специального подхода. Простое копирование файлов работающей СУБД может не обеспечить логически согласованного состояния.
Во время операции в базу продолжают поступать изменения, поэтому специализированные системы взаимодействуют с механизмами самой СУБД либо используют поддерживаемые методы создания согласованных копий.
При проектировании учитывается частота транзакций и максимальная допустимая потеря информации.
Для системы, данные в которой меняются раз в несколько дней, может быть достаточной редкая копия. Для активно используемой бизнес-базы аналогичная схема создаёт неприемлемый риск.
Также необходимо учитывать порядок восстановления: иногда сначала разворачивается базовая копия, а затем применяются журналы или дополнительные наборы изменений.
Защита виртуальных машин
Виртуальная инфраструктура позволяет резервировать данные на уровне целой виртуальной машины.
В этом случае объектом защиты становится не отдельный документ, а виртуальный сервер с его дисками и конфигурацией. Такой способ удобен при необходимости восстановить всю систему после серьёзного сбоя.
При этом файловое и виртуальное резервирование могут применяться одновременно. Копия всей ВМ используется после масштабного отказа, а файловая - когда нужно вернуть один документ.
При выборе российской системы резервного копирования важно заранее проверить совместимость с используемой платформой виртуализации и её конкретной версией.
Одинаковое слово "поддержка" может подразумевать разный набор функций, поэтому следует уточнять доступность полного восстановления, отдельных дисков, файлов и других необходимых операций.
Физические серверы
Не вся инфраструктура виртуализирована. Физические серверы продолжают применяться для высоконагруженных баз данных, специализированных вычислений и систем, связанных с аппаратным оборудованием.
Их резервирование может включать файловые данные, приложения и системные настройки.
При полном отказе физического сервера необходимо учитывать не только возврат информации. Потребуется подготовить новое оборудование, установить операционную систему и восстановить необходимые компоненты.
Поэтому документация по аварийному восстановлению должна описывать весь процесс, а не только операцию получения файлов из архива.
Срок хранения резервных копий
Резервное хранилище имеет ограниченный объём, поэтому невозможно бесконечно сохранять каждую созданную версию.
Для этого используется политика хранения. Например, ежедневные копии могут храниться определённое количество дней, недельные - несколько месяцев, а отдельные архивные экземпляры - дольше.
Необходимая глубина зависит от того, насколько быстро обнаруживаются проблемы.
Ошибочное изменение базы может стать заметно спустя несколько дней. Если за это время все старые точки уже удалены, восстановить корректное состояние будет сложнее.
При наличии нормативных требований к сохранности документов сроки резервирования необходимо согласовывать с правилами хранения соответствующей информации.
RPO - допустимый объём потери данных
В архитектуре резервного копирования используется показатель Recovery Point Objective - RPO.
Он показывает, за какой период организация допускает потерю изменений после серьёзного сбоя.
Предположим, резервная копия создаётся ежедневно в 02:00, а авария произошла вечером. Если дополнительных механизмов нет, изменения за рабочий день могут отсутствовать в последней копии.
Для одних систем такая ситуация допустима, для других неприемлема.
Поэтому частота резервирования должна определяться не удобством администратора, а требованиями бизнеса к сохранности информации.
Чем меньше RPO, тем чаще необходимо фиксировать состояние системы.
RTO - время возврата сервиса
Второй показатель - Recovery Time Objective, или RTO. Он характеризует допустимую продолжительность восстановления.
Можно иметь актуальную резервную копию, но потратить сутки на её возврат из-за недостаточной производительности хранилища или сложной процедуры развёртывания.
Поэтому при проектировании необходимо измерять не только скорость создания бэкапа.
Если сервис должен вернуться в работу через час после аварии, инфраструктура должна физически обеспечивать такое восстановление.
Для наиболее критичных систем резервирование дополняют кластеризацией, репликацией и другими механизмами высокой доступности.
Бэкап и высокая доступность
Резервное копирование и отказоустойчивость решают разные задачи.
Кластер может быстро переключить сервис на другой сервер при аппаратном отказе, но не защитит от логической ошибки, которая мгновенно распространилась на все узлы.
Резервная копия позволяет вернуться к предыдущему состоянию, но её восстановление может занимать значительное время.
Поэтому в критичных информационных системах эти подходы обычно применяют совместно.
Реплика также не всегда является резервной копией. Если пользователь удалил данные и это удаление автоматически повторилось на втором узле, оба экземпляра окажутся одинаково неполными.
Проверка созданных копий
Одна из наиболее серьёзных ошибок - считать успешный статус задания достаточным доказательством работоспособности резервирования.
Файл может физически существовать, но это ещё не гарантирует успешное восстановление приложения или базы.
Поэтому необходимо проводить проверки целостности и тестовые восстановления.
Для теста выбирается копия, разворачивается в отдельной среде и проверяется работоспособность данных.
Такая процедура позволяет обнаружить проблемы в цепочке резервирования до настоящей аварии.
Периодичность проверок зависит от критичности системы. Чем выше последствия потери информации, тем важнее подтверждать восстановимость на практике.
Хранилище резервных данных
Требования к хранилищу отличаются от характеристик рабочей системы.
Для продуктивной базы может быть важна минимальная задержка, тогда как для архива резервов главным параметром становится большая ёмкость. Но процесс восстановления, напротив, требует достаточной скорости чтения.
При проектировании оценивают объём исходных данных, ежедневный прирост, срок хранения и ожидаемую степень сокращения объёма за счёт различных методов оптимизации.
Необходимо оставлять резерв свободного пространства. Если система постоянно работает практически на предельной ёмкости, любое увеличение объёма исходных данных способно нарушить график резервирования.
Дедупликация
Одни и те же данные могут многократно встречаться в разных резервных копиях. Дедупликация позволяет обнаруживать повторяющиеся блоки и не хранить их несколько раз.
Это особенно заметно в виртуальной инфраструктуре. Десятки виртуальных машин могут содержать одинаковые системные файлы операционной системы.
Однако эффективность дедупликации нельзя заранее считать фиксированной. Она зависит от структуры информации.
Уже сжатые архивы, видео и некоторые форматы резервных данных содержат меньше повторяющихся блоков, поэтому экономия может быть небольшой.
При расчёте ёмкости безопаснее использовать результаты испытаний на реальном наборе данных.
Сжатие данных
Сжатие также применяется для уменьшения занимаемого пространства.
Эффективность зависит от типа содержимого. Текстовые документы и некоторые базы способны хорошо сжиматься, тогда как фотографии, видео и архивы уже используют собственные алгоритмы компрессии.
Сжатие требует вычислительных ресурсов. Поэтому при проектировании нужно учитывать баланс между экономией пространства и нагрузкой на серверы резервного копирования.
В больших инфраструктурах недостаточная вычислительная производительность способна увеличить резервное окно.
Шифрование резервных копий
Резервное хранилище часто содержит полную копию корпоративной информации, включая конфиденциальные документы и базы.
Поэтому доступ к нему должен контролироваться не менее строго, чем доступ к продуктивным системам.
Одним из способов дополнительной защиты является шифрование. При его использовании необходимо отдельно организовать безопасное хранение ключей.
Если ключ утерян, физически исправная резервная копия может стать недоступной.
Недопустима и обратная ситуация, когда ключ хранится рядом с копиями без необходимых ограничений доступа.
Защита от программ-вымогателей
Современная политика резервирования должна учитывать сценарии, при которых вредоносная программа пытается удалить или зашифровать не только рабочие данные, но и доступные резервные копии.
Для снижения этого риска резервную инфраструктуру изолируют от пользовательского сегмента, разграничивают административные полномочия и используют отдельные учётные записи.
Часть копий может храниться в формате, исключающем изменение после записи в течение определённого времени, если такую возможность предоставляет используемая инфраструктура.
Полезен и принцип разделения: одна авария или одна скомпрометированная учётная запись не должна давать возможность уничтожить все поколения резервных данных.
Правило нескольких копий
В практике резервирования применяется принцип хранения нескольких экземпляров информации на различных носителях или площадках.
Его смысл состоит в том, что одна техническая проблема не должна одновременно уничтожить все доступные версии.
Например, основные данные находятся в продуктивном хранилище, резервная копия - на выделенной системе, а дополнительный экземпляр - на другой площадке.
Количество и схема размещения зависят от рисков организации.
Для небольшой некритичной системы подобная архитектура может быть избыточной, но для значимых данных географическое разделение существенно снижает вероятность полной потери.
Российское программное обеспечение и совместимость
При выборе российской системы резервного копирования организации часто учитывают возможность работы с отечественными операционными системами, платформами виртуализации и СУБД.
Однако термин "российская система" сам по себе не подтверждает совместимость с конкретным программным стеком.
Перед внедрением необходимо проверить матрицу поддерживаемых продуктов, причём важны точные версии. После обновления операционной системы или гипервизора совместимость также желательно перепроверять.
Если для организации имеет значение наличие продукта в реестре российского программного обеспечения или выполнение дополнительных нормативных требований, соответствующие сведения следует проверять по официальным источникам на момент выбора.
Мониторинг резервирования
Даже полностью автоматическая система требует постоянного контроля.
Администратор должен видеть количество успешных и неудачных заданий, объём созданных копий, свободное место и продолжительность операций.
Рост времени резервирования может служить ранним признаком проблем с сетью или системой хранения.
Также полезно контролировать объекты, которые давно не создавали успешную копию. В большой инфраструктуре один сервер легко потерять среди сотен заданий.
Для критических ошибок настраиваются уведомления, чтобы специалисты получали информацию без необходимости постоянно открывать административный интерфейс.
Разграничение административного доступа
Система резервного копирования предоставляет доступ к большим объёмам информации и поэтому относится к критичным элементам инфраструктуры.
Не каждому администратору нужны одинаковые полномочия. Один сотрудник может контролировать задания, другому требуется выполнять восстановление, а изменение глобальных настроек доступно ограниченной группе специалистов.
Разграничение ролей уменьшает последствия случайной ошибки и снижает риск злоупотребления учётной записью.
Операции желательно журналировать, чтобы можно было установить, кто изменил политику, удалил копию или запустил восстановление.
Масштабирование системы
По мере роста организации увеличивается и количество резервируемых ресурсов.
К существующим файловым серверам добавляются виртуальные машины, новые базы, филиалы и дополнительные приложения.
Архитектура должна позволять увеличивать производительность без полного пересмотра всей системы.
Масштабирование может включать добавление серверов резервного копирования, новых хранилищ и расширение сетевой инфраструктуры.
При этом узким местом нередко становится не программная платформа, а сеть или производительность дисковой подсистемы.
Поэтому тестирование необходимо проводить на объёмах, сопоставимых с предполагаемой промышленной эксплуатацией.
Резервное копирование в распределённой инфраструктуре
Если организация имеет несколько филиалов, копирование всех данных через один канал связи может оказаться неэффективным.
В этом случае рассматриваются распределённые схемы. Часть операций выполняется на региональной площадке, а необходимые копии затем передаются в центральное или дополнительное хранилище.
При проектировании учитывается пропускная способность каналов и время передачи данных.
Особенно важно это для площадок с нестабильной связью. Кратковременный разрыв соединения не должен автоматически приводить к потере всей резервной цепочки.
План аварийного восстановления
Российская система резервного копирования является техническим инструментом, но сама по себе не заменяет план Disaster Recovery.
Организация должна знать последовательность восстановления инфраструктуры.
Например, после серьёзной аварии может потребоваться сначала вернуть сетевые сервисы и систему идентификации, затем базы данных и только после них прикладные системы.
Также заранее определяются ответственные сотрудники и порядок взаимодействия между подразделениями.
Хороший план желательно периодически отрабатывать на учебном сценарии. Во время реального инцидента времени на изучение процедур обычно значительно меньше.
Что учитывать перед внедрением
Первым этапом становится инвентаризация. Нужно составить перечень серверов, виртуальных машин, баз, файловых ресурсов и приложений.
Затем определяется критичность каждого объекта и требования RPO и RTO.
После этого рассчитываются объём резервного хранилища и пропускная способность сети.
Следует также проверить совместимость системы с используемыми платформами, определить правила доступа и разработать политику хранения.
Перед переносом всей инфраструктуры в новую систему полезен пилотный проект. Он позволяет проверить реальные скорости, особенности настройки и восстановление тестовых данных.
Только после успешной проверки можно постепенно включать остальные информационные ресурсы.
Типичные ошибки при организации резервного копирования
Одна из распространённых ошибок - хранение единственной резервной копии рядом с исходными данными.
Вторая - отсутствие контроля заданий. Система установлена, но ошибки месяцами остаются незамеченными.
Третья - отсутствие практической проверки восстановления.
Также встречается ситуация, когда организация резервирует старые серверы, но забывает включать в политику новые системы.
Ещё одна проблема заключается в одинаковом подходе ко всем данным. Критичная производственная база и временный тестовый сервер обычно требуют разных схем резервирования.
Наконец, нельзя забывать об обновлении документации. Сведения о том, что и как восстанавливать, должны соответствовать фактической инфраструктуре.
Заключение
Российская система резервного копирования представляет собой программную основу для автоматизированной защиты данных физических и виртуальных серверов, файловых ресурсов, баз данных и других компонентов ИТ-инфраструктуры. Её задача заключается не только в создании копий, но и в управлении расписаниями, сроками хранения, восстановлением, доступом и контролем выполнения операций.
Полные, инкрементальные и дифференциальные схемы позволяют выбирать баланс между объёмом резервного хранилища и сложностью восстановления. Для критичных информационных систем дополнительно учитываются показатели RPO и RTO, определяющие допустимую потерю данных и продолжительность простоя.
Надёжность резервирования зависит от всей архитектуры. Копии следует отделять от исходных ресурсов, контролировать их целостность и периодически выполнять тестовое восстановление. Важную роль играют разграничение административного доступа, защита самого резервного хранилища и наличие нескольких поколений данных.
При выборе российского решения необходимо оценивать совместимость с используемыми операционными системами, СУБД, виртуализацией и системами хранения. Если организация предъявляет требования к происхождению программного обеспечения или его реестровому статусу, соответствующие сведения проверяются отдельно по официальным источникам.
Главным показателем эффективности резервного копирования остаётся не число созданных архивов, а способность восстановить нужную информацию в установленный срок. Поэтому система резервного копирования должна рассматриваться как часть общей стратегии устойчивости ИТ-инфраструктуры вместе с мониторингом, информационной безопасностью, высокой доступностью и планом аварийного восстановления.