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