Серьезные инциденты случаются со всеми, даже с глобальными игроками. Чего стоил один только прошлогодний сбой у Toyota! Тогда переполнение дискового пространства и сбой в СУБД стали причиной остановки всех заводов компании в Японии. А недавно произошла хакерская атака на СДЭК. В таких ситуациях остается надеяться только на бэкапы.
Не удивительно, что мы часто получаем запросы от клиентов о том, как организовать корпоративное резервное копирование. Их интересует, что именно бэкапить, как часто это делать, где хранить резервные копии, какие регламенты нужны и как лучше организовать резервное копирование на предприятии. Особенно много таких запросов стало поступать в последнее время. Поэтому я решил написать серию статей о том, как устроено резервное копирование, как его организовать и защитить. Моя цель — рассказать о best practice и структурировать эти знания. Бэкапы — обширная тема, которая включает множество нюансов, так что я начну с архитектуры и буду постепенно углубляться в детали.
Я — Алексей Зотов, руководитель направления ИТ-инфраструктуры в К2Тех. У меня более чем 15-летний опыт в сфере резервного копирования. С командой я собственными руками саппортил больше сотни заказчиков: проектировал, внедрял, оказывал техподдержку, ездил настраивать архитектуру в Штатах и Европе, получил десятки сертификатов по основным продуктам из верхнего угла квадрата Gartner и не только. В общем, на рынке уже не первый день. А средний стаж моей команды экспертов — от 7-8 лет.
Но все это не означает, что со мной нельзя спорить в комментах. У многих есть свое видение архитектуры, и я это покажу далее в статье. Я открыт к обсуждению и готов рассмотреть различные подходы к решению задач безопасного резервного копирования. Тем более, универсального подхода не существует. Я постараюсь описать общие принципы, хотя, конечно, многое зависит от конкретного продукта.
Основы резервного копирования
Бэкап в корпоративном секторе — это вам не простое хранение фоток в облаке. Здесь применяются специализированные методики и оборудование, множественные копии, защищенная и отказоустойчивая архитектура, а сам процесс резервного копирования обычно строго регулируется и регламентируется.
Начнем с основ: в зависимости от поставленных задач используются различные типы резервного копирования: полные и инкрементальные (дифференциальные и кумулятивные).
Полная копия — это точная копия всех исходных данных. Она создает полный снимок на момент копирования.
Инкрементальные копии сохраняют изменения с момента последнего бэкапа любого типа. Например, если полная копия создана в воскресенье, то в понедельник будут скопированы изменения с воскресенья, во вторник — с понедельника, в среду — со вторника и так далее до следующей полной копии.
Кумулятивные копии, в свою очередь, накапливают все изменения с момента последней полной копии. То есть, если полная копия создана в воскресенье, то в понедельник будут скопированы изменения с воскресенья, во вторник — с воскресенья, в среду — снова с воскресенья, и так до следующей полной копии.
Существует понятие синтетической резервной копии, когда к полной копии добавляются несколько инкрементальных. Потом, в определенный момент происходит слияние — полная копия обновляется при помощи инкрементальных бэкапов и цикл создания инкрементальных бэкапов стартует по новой, но в качестве основной используется уже обновленная копия.
Синтетика востребована при бэкапе больших файловых шар и виртуальных машин. В первом случае фулл бэкап — это долго и сложно, а схема с инкрементальными копиями становится лишь временным решением, так как слишком длинная цепочка создает проблемы с восстановлением.
Во втором случае синтетические бэкапы позволяют снизить нагрузку на платформу виртуализации, которую создает регулярное полное резервное копирование. Дополнительный плюс здесь в том, что разные фичи вроде восстановления отдельных объектов из виртуалки или мгновенного запуска нормально работают с синтетическими копиями. Конечно, существуют еще и снэпшоты томов на системах хранения данных (СХД). Их тоже можно использовать для снижения нагрузки на платформу, но синтетика представляется более универсальной. Она работает в большинстве случаев.
Все эти схемы резервного копирования можно реализовать при помощи специальных продуктов — систем резервного копирования (СРК). Раньше топ-3 популярных производителей СРК составляли Veritas, Veeam и Commvault. Также на рынке присутствовали решения от западных вендоров оборудования — Dell EMC, IBM, HPE (Microfocus). Но на сегодняшний день все эти западные компании официально покинули российский рынок и их продукты для резервного копирования более недоступны. А буквально недавно — в марте 2024-го — Veeam Software начала блокировать доступ к своим службам для пользователей, находящихся на территории России. Ограничения затронули все виды продуктов и услуг Veeam.
Сейчас в сегменте СРК у нас представлены российские разработки:
-
Кибер Бэкап
-
RuBackup
-
Береста
Также доступны китайские продукты — Vinchin и AISHU. Причем в отличие от AISHU, Vinchin гораздо больше открыт к диалогу с пользователями из России, каналы техподдержки у них отстроены значительно лучше. Также на российский рынок пытались зайти NAKIVO и Rubrik, но без особого успеха. Они либо недоступны совсем, либо с доступом возникают сложности.
Итого: сейчас у нас в доступе пять продуктов (три российских и два китайских)
Тем не менее у всех перечисленных решений свои особенности, так что неудивительно, что в этой области даже крупные компании до сих пор допускают ошибки.
На самом деле, основные правила резервного копирования уже были сформулированы авторами Хабры и ничуть не устарели спустя 10 лет после публикации. Разве что для их реализации используются другие продукты (да и то не всегда). Вместо того чтобы повторять прописные истины, перейдем к тому, как их нарушают!
Частые ошибки резервного копирования: чек-лист
Понятно, что главная проблема у всех одна — невозможность восстановить данные в нужный момент. Но до такой катастрофы нужно еще дойти. К этому может привести целый ворох различных ошибок. Из нашего опыта можем выделить наиболее распространенные проблемы (проверьте себя):
1. Не проверены резервные копии
Зачастую клиенты настраивают систему резервного копирования, но не проверяют возможность восстановления данных. Мы сталкивались с десятками кейсов, когда процесс восстановления не отработан. Или, например, записана кассета, которая лежала где-то несколько лет, и только в час X оказалось, что с ней что-то не так. За все это время никто ни разу не проверил носитель и не провел тестовое восстановление.
Или другая распространенная ситуация: тщательно копируется база данных, но админы забывают о фронтенде, который отображает данные из этой БД.
Сложные информационные системы состоят из множества компонентов, и все они нужны для полного восстановления, но нет-нет и один или несколько из них остаются без резервной копии.
Основная причина — отсутствие культуры и регламента тестового восстановления. Это самая распространенная ошибка среди наших клиентов, кроме нескольких десятков крупнейших предприятий в России.
Казалось бы, проблему можно решить при помощи автоматизации — сделать так, чтобы софт сам проверял восстанавливаемость резервных копий, однако, это не дает гарантий. Полный аппрув восстанавливаемости можно получить только когда DBA и прикладники зашли на восстановленную систему и проверили все лично.
2. Отсутствие документирования
Классическая проблема, которая особенно болезненна для средних или небольших компаний. В таких организациях редко происходит смена внутреннего персонала, и часто отсутствует документация по системе резервного копирования. Нигде не зафиксировано, что именно копируется, куда сохраняются данные и какие технологии используются. Соответственно, нет документации и по восстановлению данных.
И вот сотрудник, отвечавший за бэкапы, уходит, и никто уже точно не знает, как настроена система, куда бэкапится встроенная база данных и что делают самописные скрипты. Ситуация осложняется тем, что иногда может пройти несколько месяцев или даже лет, прежде чем возникнет необходимость в восстановлении этих данных.
В итоге однажды новый сотрудник получает уведомление о необходимости восстановления конкретной резервной копии, но не знает, к какому серверу подключаться и какую консоль запускать. В результате теряется время.
По нашим оценкам, эта проблема сейчас актуальна для 80% компаний среднего бизнеса. Крупные российские компании уже в основном привыкли документировать свои процессы.
Для них нормой стало наличие четких инструкций по восстановлению каждого компонента системы. В такой ситуации даже дежурный оператор, ранее не занимавшийся этой задачей, сможет провести восстановление в критический момент.
У небольших компаний, конечно, может не хватать ресурсов и времени на создание подробной документации. Однако если вы серьезно относитесь к резервному копированию, стоит стремиться к такому уровню организации процесса.
3. Нет регламента постановки системы на бэкап
Часто возникает ситуация, когда новые информационные системы не включаются в процесс резервного копирования просто потому, что об этом забывают. Или наоборот: во время регламентных работ резервное копирование отключают, а после их завершения забывают включить обратно. Причина — отсутствие четкого регламента.
Это может показаться неправдоподобным. «Как такое возможно? Я никогда не забываю о резервном копировании своего компьютера!» — напишут в комментариях. Однако в корпоративной среде это происходит регулярно из-за несистемного подхода. В лучшем случае в компании используют шаблон/форму, которую нужно заполнить и отправить ответственному. Но этого недостаточно.
Исключение составляют крупные компании с выделенной командой по резервному копированию. Это характерно для финансового сектора, нефтегазовой отрасли, металлургии и других крупных компаний. У остальных мы постоянно исправляем подобные ошибки.
Три основных компонента системы резервного копирования и их защита
Начнем с плохой новости: бэкапам нужны бэкапы. Других способов значительно повысить шансы сохранения данных человечество еще не придумало.
Давайте рассмотрим структуру классической трехуровневой системы резервного копирования. Она состоит из трех основных компонентов:
Управляющий сервер (мастер-сервер, бэкап сервер и т.д.) отвечает за логику работы СРК в целом, хранит настройки ПО и базу данных резервных копий. Он раздает серверам передачи данных команды: «копируй», «восстанавливай», делай резервное копирование определенных сегментов и так далее.
Сервера передачи данных (медиа-сервер, медиа-агент и т.д.) физически подключены к устройствам хранения данных, таким как ленточные или виртуальные библиотеки или дисковые массивы. Их основная функция — запись резервируемых данных на эти устройства. Они могут записывать как данные с физического сервера, на котором они работают, или обслуживать запросы на запись от обычных (сетевых) клиентов. Медиа-серверы используют различные протоколы, в зависимости от типа подключения устройств хранения. Это может быть SAN, LAN, iSCSI, прямое подключение и так далее.
Клиенты (агенты) — участники резервного копирования, которые не имеют непосредственного подключения к накопительным устройствам и поэтому передают данные для резервирования по LAN на один или несколько управляющих серверов.
В некоторых случаях используются архитектуры, где клиенты напрямую взаимодействуют с устройствами хранения. Раньше для этого применялись специальные плагины и протоколы, однако сейчас такие решения стали доступнее. Например, в качестве устройства хранения можно использовать классическую CIFS/NFS шару. Клиенты могут напрямую записывать туда резервные копии.
Что надо бэкапить и как?
В системах резервного копирования выделяют несколько типов защищаемых типов данных и агентов.
-
Обычный файловый бэкап
Он предполагает сохранение и восстановление отдельных файлов. Основная сложность в том, что их может быть очень много. Шары по 30, 40, 50 терабайт, набитые мелкими файлами — довольно распространенное явление.
Для оптимизации резервного копирования большого числа мелких файлов по-хорошему нужно использовать несколько потоков. Очень полезны синтетика, снэпшоты, block-level бэкапы, однако возможности отечественного софта в этом плане пока еще ограничены.
-
Резервное копирование баз данных, приложений и платформ виртуализации
Хотя базы данных и приложения тоже состоят из файлов, их резервное копирование требует особого подхода. Данные нужно сохранять и восстанавливать в формате, совместимом с конкретным приложением или базой данных.
Типичный пример — почта. Можно создать резервную копию всей почтовой базы данных, но часто требуется более гибкий подход. Например, восстановление отдельных писем, конкретных почтовых ящиков, календарей или заметок. Оптимальное решение позволяет восстанавливать каждый компонент по отдельности.
Если мы говорим про СУБД, то иногда нужно вернуть не всю базу данных, а только транзакционные логи или некоторые таблицы. Для этого под каждую базу, как правило, существует специализированный агент.
Отдельная история — платформы виртуализации. Когда хочется забэкапить виртуальную машину в целом. И иметь возможность восстановить ее туда же, или восстановить в другой кластер, на другую площадку. Можно восстанавливать отдельные файлы из виртуальной машины или конвертировать их. Этот процесс называется virtual-to-virtual восстановлением. Например, мы создаем резервную копию системы в VMware, а восстанавливаем в zVirt или наоборот.
-
Резервное копирование файловых шар
Системы хранения данных с file share также требуют создания резервных копий. Мы всегда выделяли этот процесс отдельно и сейчас наблюдаем возрождение спроса на подобное резервное копирование.
Для этой задачи применяются специальные протоколы. Наиболее распространенный — NDMP (Network Data Management Protocol). Он обеспечивает сохранение и восстановление данных в формате, совместимом с СХД.
Защита сервера управления резервным копированием
Сервер управления является ключевым элементом системы резервного копирования. В разных системах он может называться по-разному: primary-сервер, где-то мастер-сервер или commserve, где-то узел управления, нетворк сервер и т. д.
Независимо от названия он, как правило, содержит базу данных с полной конфигурацией системы резервного копирования, управляет политиками резервного копирования, хранит расписания и ведет историческую информацию о выполненных операциях резервного копирования и восстановления. Поэтому сервер управления становится критической точкой отказа, и его нужно защищать.
1. Повышение безопасности сервера
Первостепенное значение имеет повышение безопасности сервера, особенно в контексте защиты от вирусов и программ-шифровальщиков. Напрашивающимся решением будет использование Linux: RHEL, ALMA, CentOS или Астра и РедОС, если рассматривать российские решения. В сравнении с Windows они менее подвержены типовым атакам. К тому же позволяют достаточно просто ограничить удаленный доступ root-пользователю или активировать вход по ssh-ключу.
2. Дублирование
Корпоративные заказчики редко ограничиваются одним центром обработки данных.
Типичная практика предполагает использование двух ЦОДов, например, одного частного и одного коммерческого.
В такой конфигурации второй резервный сервер обычно находится в режиме ожидания (standby). Он выключен и не активен до тех пор, пока не возникнет необходимость. Этот сервер становится актуальным в случае проблем на основной площадке. Тогда проводится определенный набор действий: перенаправление доменного имени, изменение IP-адреса, запуск необходимых сервисов, подключение базы данных и другие операции. Это можно делать вручную или автоматически при помощи кластерного ПО.
3. Виртуальные машины
В последнее время заказчики все чаще обращаются к использованию виртуальных машин для размещения управляющих серверов. Этот подход позволяет переложить все сложности по переключению между площадками и отказоустойчивости на платформу виртуализации. Это существенно снижает нагрузку на персонал и снижает риск человеческих ошибок при выполнении критических операций. Минус здесь в зависимости от платформы виртуализации. Если она недоступна, ложится и система резервного копирования.
4. Бэкап сервера управления
Резервное копирование — ключевой инструмент защиты данных. Многие решения для резервного копирования имеют встроенную функцию сохранения собственной базы данных. Если сервер выходит из строя, его можно быстро восстановить: переустановить программное обеспечение и загрузить сохраненную базу данных из резервной копии.
Современные подходы часто сочетают несколько методов защиты. Например, используют Linux, резервное копирование встроенной базы данных и различные технологии отказоустойчивости (кластеризацию, виртуализацию, репликацию). Организации, уделяющие особое внимание сохранности данных, применяют все эти методы одновременно.
Защита медиа-серверов в системах резервного копирования
Уровнем ниже в архитектуре систем резервного копирования располагаются серверы передачи данных (медиа-серверы, медиа-агенты, узлы хранения и т.д.). Эти компоненты принимают данные от конечных пользователей и сохраняют их на подключенных устройствах хранения.
Основной метод повышения их отказоустойчивости — установка нескольких медиа-серверов на площадку. Такой подход позволяет быстро переключиться на резервный сервер и обеспечивает непрерывность процесса резервного копирования.
У нас в практике были истории, когда отказывал медиа-сервер и данные, которые к нему относились, нельзя было восстановить, пока его не починят. Однако восстановление работоспособности медиа-сервера — сравнительно простая задача, ведь там нет собственных БД. Достаточно подготовить другой сервер: установить операционную систему, компоненты медиа-сервера, подключить устройство хранения, все это переконфигурировать и можно спокойно продолжать работу. Все это требует усилий, но как правило, проходит безболезненно для компании.
Как организовать безопасную систему резервного копирования в компании с несколькими филиалами и ЦОДами
Потребуются следующие ингредиенты:
-
Дисковые хранилища для оперативного резервного копирования;
-
Ленты для долгосрочного хранения;
-
Минимум два ЦОДа.
Управляющий сервер должен быть продублирован, кластеризован для обеспечения отказоустойчивости. Медиа-серверы также нуждаются в дублировании. Каждая площадка должна быть оснащена дисковыми и ленточными хранилищами. Бэкапы изначально записываются в пределах своей “локальной” площадки.
Оптимальная схема работы предполагает, что после записи данных клиентом на медиа-сервер и устройства хранения одного ЦОД копия автоматически реплицируется на вторую удаленную площадку. Там данные сохраняются дополнительно. В результате создаются две копии всех данных на двух разных площадках, что обеспечивает минимально допустимый уровень защищенности информации. В то же время наиболее надежный подход — хранить еще и третью отчуждаемую копию. Это могут быть, например, хранящиеся в сейфе кассеты или дисковая полка с «золотым образом» всех систем, которую обесточивают и физически отключают от всех сетей. Можно использовать и объектное S3-хранилище, но защита данных в облаке — это отдельная тема для рассказа.
При наличии филиалов организация резервного копирования может варьироваться в зависимости от их масштаба и качества каналов связи:
-
Для небольших филиалов с хорошими каналами связи подходит централизованный подход. В этом случае филиалы функционируют как обычные клиенты, отправляя свои резервные копии в централизованную инфраструктуру.
-
Крупные филиалы требуют развертывания собственной системы резервного копирования. Такая система выполняет локальное резервное копирование, но при этом отправляет дополнительные копии (например, «золотые») в центральный ЦОД.
Преимущество второго подхода в том, что при некритичных проблемах филиал может быстро восстановить данные локально. В случае серьезных инцидентов есть возможность получить резервные копии из центрального ЦОДа. Это обеспечивает оптимальный баланс между производительностью и безопасностью данных.
Сложные архитектуры бэкапа — хорошо или плохо?
В свое время в Штатах я спорил об этом с одним инженером, который работал в business-critical support (BCS) в вендоре. Его позиция заключалась в том, что отказоустойчивые кластеры для управляющего сервера избыточны. По его мнению, восстановление встроенной базы данных из резервной копии или переразвертывание сервера происходит быстрее, чем настройка сложных кластерных конфигураций.
Эта дискуссия актуальна и сегодня. Одним специалистам нравится сложность и многослойность, а другие убеждены, что нужно сокращать число возможных точек отказа.
Одной из наиболее сложных архитектур в нашей практике был кластер для Veritas NetBackup поверх реплицируемых СХД. В случае сбоя было необходимо сперва поднять кластер, и лишь затем восстановить встроенную базу. Без проработанной документации это было, мягко говоря, нетривиальной задачкой, на которую ушла уйма драгоценного времени.
Этот пример иллюстрирует важность соблюдения баланса в архитектуре систем. Чрезмерное усложнение системы резервного копирования и избыточное дублирование компонентов могут привести к неожиданным проблемам. В некоторых случаях это делает невозможным удаленное восстановление данных при серьезных сбоях, таких как логическое удаление базы данных. В моей практике был такой кейс, когда пришлось посреди ночи вылетать из Москвы на площадку к заказчику в Тюмень, чтобы на месте поднять такую сильно закластеризованную базу данных. Сильный аргумент в пользу упрощения конфигураций (привет американскому инженеру BCS!).
Дополнительные сложности возникают и при работе с нестандартными системами или неподдерживаемыми компонентами, для которых отсутствуют готовые агенты резервного копирования. В таких случаях приходится разрабатывать и внедрять собственные скрипты. Это не только усложняет систему, но и создает дополнительные точки отказа. Результатом становится чрезвычайно сложная конфигурация, в которой крайне трудно разобраться стороннему специалисту.
В идеале при создании резервных копий важно использовать простые и эффективные, минимально достаточные технологии. Обычно восстановление из бэкапа — небыстрый процесс, особенно для большого объема данных. Единственный интервал, на который мы можем повлиять — время от появления запроса на восстановление до запуска этого процесса. В идеальных условиях на это уходит 15-30 минут, но в сложных ситуациях восстановление может сильно затягиваться. Порой можно разбираться часами, а то и днями, и это неправильно. Система резервного копирования должна быть выстроена так, чтобы в критический момент не нужно было разбираться, как она работает и что делать.
Если восстановление системы занимает больше получаса даже при наличии инструкции, пора действовать. Необходимо упростить систему, вложиться в инфраструктуру и повысить производительность.
В следующей статье я расскажу, как это сделать. Обсудим с вами выбор носителей для резервных копий, типы бэкапов, оптимальные сроки их хранения. Затем планирую затронуть тему защиты резервных копий от целенаправленных атак и программ-шифровальщиков, чье количество растет в последнее время, а также влияние защиты на производительность.
Я буду рад услышать ваше мнение о том, какие аспекты резервного копирования вас интересуют больше всего. Ваши отзывы помогут мне сделать следующую статью максимально полезной.
И для бесед о бэкапе я всегда доступен по адресу: alzotov@k2.tech
Автор: Алексей Зотов
