О технических средствах резервного копирования и восстановления информации сказано уже очень много, поэтому в этой статье мы рассмотрим создание бекапов больше с точки зрения организации этого процесса. Эффективные системы резервного копирования информации подразумевают, в первую очередь, грамотную стратегию, организационные решения и политики сохранения данных.
Основными тенденциями на 2017-2019 годы мы видим следующие виды резервного копирования:
- копирование в облако с любых устройств по принципу “подписки” за каждый гигабайт данных с помощью облачных сервисов, которые через предустановленный в систему агент “заливают” копии в облако . Пример тому – Commvault
- копирование в облако с помощью Veaam и подобных продуктов (Acronis/Symantec/HP Data Protector). Требует подготовки провайдера, настройки коннектора между облаком провайдера и “наземной” виртуальной средой.
- копирование “инхаус” с помощью софтовых решений от производителей NAS систем или выделенных хранилищ корпоративного сектора
- распределенный бекап с помощью встроенных в ОС Windows Server решений
Задачи резервного копирования в организации
Резервное копирование информации чаще всего преследует две цели:
6.8 Устройство резервного копирования, скрипты и задания агента для MS SQL Server
- сохранить данные для максимально быстрого восстановления (disaster recovery), если с ИТ-системой компании произошла авария, ее атаковал вирус и т.д. У таких резервных копий сравнительно небольшой период хранения (чаще всего сутки или двое, потом они перезаписываются более новыми), к данным можно получить доступ очень быстро. Копируются пользовательские и бизнес-данные, а также настройки ОС, прикладного ПО и вся информация, необходимая для восстановления работоспособности системы
- создать долговременный архив сведений о деятельности компании, к которому можно обратиться при необходимости получить данные за прошедшие периоды. Такие архивы хранятся долго (месяцы и годы), скорость доступа к ним не особенно важна – обычно не страшно, если получение данных займет несколько дней. Хранятся только бизнес-данные и данные пользователей, нет необходимости хранить какую-либо системную информацию.
Например, в копии для быстрого восстановления системы вам может быть доступна только последняя, актуальная версия какого-либо документа, а в архиве могут храниться все его прошлые версии.
Эти две цели вполне можно совмещать, вести и долговременный архив, и делать «слепки» системы для аварийного восстановления, особенно если данных немного и ИТ-инфраструктура компании несложная. Но следует четко разграничивать: что и с какими целями вы делаете, какие используете ресурсы для каждой задачи, где и как долго будут храниться эти резервные копии, исходя из требований бизнеса.
При аварии можно восстанавливать систему на «голое железо», т.е. резервировать и затем поднимать из резервной копии ОС со всем настройками, пользовательские приложения и данные. Однако такие копии сложнее создавать, они требуют больше места для хранения и в некоторых случаях конфигурация аппаратной части должна быть полностью идентична той, с которой снималась копия, иначе такое восстановление не получится. Поэтому иногда целесообразнее переустановить ОС заново и затем уже восстанавливать данные бизнес-приложений. При выборе политик снятия, хранения копий и восстановления данных из них, стоит учитывать особенности работы и доступные ресурсы каждой конкретной компании, универсальных рекомендаций тут не бывает.
Создание резервных копий при помощи агентов
Резервное копирование VS Избыточное резервирование
Чтобы оборудование продолжало работать, даже если какой-то отдельный компонент откажет, в него вносится определенная избыточность – «лишние» компоненты или вычислительные ресурсы, которые в обычном рабочем режиме могут показаться ненужными.
Пример избыточного резервирования:
- кластерная архитектура, где при выходе узла из строя его функции берут на себя другие узлы
- RAID-массив, в котором отказ одного из дисков не является критичным для системы в целом, информация сохранится
- «зеркальный» сервер, на который постоянно выполняется репликация данных с основного и на который переключаются сервисы компании, если основной сервер потерял работоспособность.
Такая избыточность повышает надежность системы, однако она не заменяет резервное копирование. Ни RAID-массив, ни кластер никак не обезопасит данные от действия вируса, удаления из-за ошибки пользователя или нарушения файловой системы, так как данные будут затронуты все равно по всей системе, не останется неповрежденной копии для восстановления. К тому же, ни одно из приведенных средств не решит полноценно задачу вести долговременный архив данных компании.
Распорядок резервного копирования
Сам по себе процесс резервного копирования ощутимо нагружает сервер, информация с которого копируется, вплоть до отказа определенных сервисов и недоступности для пользователей. К тому же очень желательно, чтобы в данные не вносились изменения в тот момент, когда они копируются – это может вызвать различные коллизии.
Лучше не копировать данные «на ходу», а создавать резервные копии, когда систему никто не использует или нагрузка минимальна. Для компаний со стандартным рабочим днем имеет смысл делать бэкапы ночью или на выходных, для круглосуточных сервисов стоит выбрать время, когда активность пользователей минимальна.
Виды резервного копирования в организации
Существуют разные технологии резервного копирования, которые отличаются затратами средств и времени:
- полное резервное копирование – выбранные данные копируются целиком. Самый надежный способ, но требует наибольшего количества ресурсов, места для хранения данных и времени копирования, поэтому в чистом виде применяется редко, обычно комбинируется с другими видами (например, первый раз с системы снимается полная копия, а потом резервируются только внесенные изменения). Позволяет восстановить утраченные данные с нуля быстрее всех остальных видов копирования.
- инкрементное копирование – записываются только те данные, которые были изменены со времени прошлого бэкапа. Для таких копий требуется значительно меньше памяти, чем при полном копировании, и снимаются они значительно быстрее. Разумеется, при таком подходе необходимо периодически делать и полную резервную копию, при любой аварии систему восстанавливают из такой копии, а затем накатывают на нее все последующие инкрементные копии в хронологическом порядке. Важный момент: инкрементное копирование восстанавливает удаленные файлы и все предыдущие версии файлов, которые изменялись, так что при восстановлении следует предусмотреть дополнительное дисковое пространство на этот случай.
- дифференциальное резервное копирование – похоже на инкрементное, т.е. копируются только изменения, сделанные с момента последнего полного копирования. Отличие в том, что в каждую последующую копию сохраняются изменения из предыдущей и добавляются новые. Получается, что для восстановления после аварии понадобится только полная копия и последняя из дифференциальных, что значительно сокращает время восстановления. Минусами, по сравнению с инкрементным копированием, являются большой объем копий (иногда сравнимый с полным копированием) и большее время копирования.
Чтобы выбрать подходящий для каждого конкретного случая вид копирования, следует предварительно оценить, как минимум, сколько места доступно для хранения резервных копий, сколько времени получится выделить на «окно бэкапа» без ущерба для бизнес-процессов.
Топология резервного копирования
По своей топологии схемы резервного копирования также различаются.
- Децентрализованная схема. Её суть в том, что на каждом сервере и рабочей станции может быть собственное ПО для резервного копирования, работающее независимо от других узлов сети. Все данные выгружаются на какой-либо общий сетевой ресурс, откуда потом попадают в архив или восстанавливаются, при необходимости. Достоинства схемы в том, что она чрезвычайно простая, легко реализуется и обычно не требует дополнительного ПО, копирование выполняется штатными средствами операционной системы или СУБД. Есть и недостатки – сложно установить общую политику резервного копирования и защиты информации, общее для всех программ расписание бэкапов, настраивать и мониторить деятельность каждой из программ придется отдельно, что усложняет администрирование. Поэтому децентрализованная схема резервного копирования подойдет либо для небольшой и несложной сети, либо для случаев, когда централизованную схему невозможно организовать в силу каких-либо ограничений.
- Централизованная схема – для ее реализации необходимо специализированное клиент-серверное ПО. Серверная часть устанавливается на сервер резервного копирования и централизованно управляет установленными у пользователей программными агентами, которые собирают, копируют информацию о системе или восстанавливают ее из копии. В таком варианте легко настраивать общие политики создания резервных копий, расписание бэкапов, все участники могут работать согласно с общей для компании инструкцией по резервному копированию информации.
- Централизованная схема резервного копирования без программ-агентов – упрощенный вариант предыдущей схемы, когда серверная часть использует только существующие службы и сервисы (например, собирает данные из специально назначенных общих папок Windows). Схема не очень надежная, в ней есть известная проблема, когда открытые в текущий момент для редактирования файлы не попадают в резервную копию и при сбое системы могут быть утрачены. Поэтому применять ее стоит только на небольших сетях и при условии высокой пользовательской дисциплины.
- Смешанная схема – сочетание централизованной и децентрализованной. Программы-агенты устанавливаются только на некоторых серверах сети, от остальных устройств данные на эти сервера отправляют их локальные программы, каждая своими средствами. А уже с этих серверов накопленную информацию программы-агенты централизованно соберут, обработают и отправят в общее хранилище.
Место хранения резервных копий
Чтобы еще больше обезопасить информацию от возможной потери, желательно физически хранить резервные копии отдельно от основного оборудования, на котором развернута рабочая система. При этом необходимо обеспечить возможность быстро получить эти копии, если действительно возникнет такой случай, когда данные необходимо восстанавливать.
Наиболее популярный метод – хранить резервные копии в облаке в дата-центре (собственном или арендовать у провайдера), отправляя туда данные и получая их обратно по защищенному VPN-туннелю. Скорость передачи данных в таком случае ограничивается пропускной способностью канала, но большие объемы данных можно сжимать, используя алгоритмы сжатия или дедупликацию.
Также можно записывать данные на съемные физические носители, которые будут храниться за пределами офиса или здания компании. Плюсом данного подхода является его простота, минусами – необходимость организовать логистику перемещения физических носителей для перезаписи копий, для восстановления данных из копии, а также безопасное хранение данных (шифрование данных, договора о неразглашении с сотрудниками).
Организационные моменты и человеческий фактор
Кроме сугубо технических моментов, в организации резервного копирования информации важен и организационный аспект. Необходимо разработать положение о резервном копировании информации и добиться его выполнения всеми задействованными сотрудниками. В частности, в таком положении должно быть следующее:
- регулярность копирования, резервное копирование по расписанию и перед важными изменениями в системе
- перепроверка бэкапов – необходимо периодически проверять, действительно ли получается восстановить работоспособную базу или систему из резервной копии
- документирование процедур восстановления, на случай, если восстанавливать систему придется другому администратору. Естественно, доступ к такой документации должен быть ограничен
- определение условий, при которых система считается неработоспособной и необходимо начать процедуру восстановления
Информация опубликована на основании нашего сайта
Источник: dzen.ru
О Резервном копировании информации в организации
О технических средствах резервного копирования и восстановления информации сказано уже очень много, поэтому в этой статье мы рассмотрим создание бекапов больше с точки зрения организации этого процесса. Эффективные системы резервного копирования информации подразумевают, в первую очередь, грамотную стратегию, организационные решения и политики сохранения данных.
Основными тенденциями на 2017-2019 годы мы видим следующие виды резервного копирования:
- копирование в облако с любых устройств по принципу “подписки” за каждый гигабайт данных с помощью облачных сервисов, которые через предустановленный в систему агент “заливают” копии в облако . Пример тому — Commvault;
- копирование в облако с помощью Veaam и подобных продуктов (Acronis/Symantec/HP Data Protector). Требует подготовки провайдера, настройки коннектора между облаком провайдера и “наземной” виртуальной средой;
- копирование “инхаус” с помощью софтовых решений от производителей NAS систем или выделенных хранилищ корпоративного сектора;
- распределенный бекап с помощью встроенных в ОС Windows Server решений.
Задачи резервного копирования в организации
Резервное копирование информации чаще всего преследует две цели:
- сохранить данные для максимально быстрого восстановления (disaster recovery), если с ИТ-системой компании произошла авария, ее атаковал вирус и т.д. У таких резервных копий сравнительно небольшой период хранения (чаще всего сутки или двое, потом они перезаписываются более новыми), к данным можно получить доступ очень быстро. Копируются пользовательские и бизнес-данные, а также настройки ОС, прикладного ПО и вся информация, необходимая для восстановления работоспособности системы;
- создать долговременный архив сведений о деятельности компании, к которому можно обратиться при необходимости получить данные за прошедшие периоды. Такие архивы хранятся долго (месяцы и годы), скорость доступа к ним не особенно важна – обычно не страшно, если получение данных займет несколько дней. Хранятся только бизнес-данные и данные пользователей, нет необходимости хранить какую-либо системную информацию.
Например, в копии для быстрого восстановления системы вам может быть доступна только последняя, актуальная версия какого-либо документа, а в архиве могут храниться все его прошлые версии.
Эти две цели вполне можно совмещать, вести и долговременный архив, и делать «слепки» системы для аварийного восстановления, особенно если данных немного и ИТ-инфраструктура компании несложная. Но следует четко разграничивать: что и с какими целями вы делаете, какие используете ресурсы для каждой задачи, где и как долго будут храниться эти резервные копии, исходя из требований бизнеса.
При аварии можно восстанавливать систему на «голое железо», т.е. резервировать и затем поднимать из резервной копии ОС со всем настройками, пользовательские приложения и данные. Однако такие копии сложнее создавать, они требуют больше места для хранения и в некоторых случаях конфигурация аппаратной части должна быть полностью идентична той, с которой снималась копия, иначе такое восстановление не получится. Поэтому иногда целесообразнее переустановить ОС заново и затем уже восстанавливать данные бизнес-приложений. При выборе политик снятия, хранения копий и восстановления данных из них, стоит учитывать особенности работы и доступные ресурсы каждой конкретной компании, универсальных рекомендаций тут не бывает.
Резервное копирование VS Избыточное резервирование
Чтобы оборудование продолжало работать, даже если какой-то отдельный компонент откажет, в него вносится определенная избыточность – «лишние» компоненты или вычислительные ресурсы, которые в обычном рабочем режиме могут показаться ненужными.
Пример избыточного резервирования:
- кластерная архитектура, где при выходе узла из строя его функции берут на себя другие узлы;
- RAID-массив, в котором отказ одного из дисков не является критичным для системы в целом, информация сохранится;
- «зеркальный» сервер, на который постоянно выполняется репликация данных с основного и на который переключаются сервисы компании, если основной сервер потерял работоспособность.
Такая избыточность повышает надежность системы, однако она не заменяет резервное копирование. Ни RAID-массив, ни кластер никак не обезопасит данные от действия вируса, удаления из-за ошибки пользователя или нарушения файловой системы, так как данные будут затронуты все равно по всей системе, не останется неповрежденной копии для восстановления. К тому же, ни одно из приведенных средств не решит полноценно задачу вести долговременный архив данных компании.
Распорядок резервного копирования
Сам по себе процесс резервного копирования ощутимо нагружает сервер, информация с которого копируется, вплоть до отказа определенных сервисов и недоступности для пользователей. К тому же очень желательно, чтобы в данные не вносились изменения в тот момент, когда они копируются – это может вызвать различные коллизии.
Лучше не копировать данные «на ходу», а создавать резервные копии, когда систему никто не использует или нагрузка минимальна. Для компаний со стандартным рабочим днем имеет смысл делать бэкапы ночью или на выходных, для круглосуточных сервисов стоит выбрать время, когда активность пользователей минимальна.
Виды резервного копирования в организации
Существуют разные технологии резервного копирования, которые отличаются затратами средств и времени:
- полное резервное копирование – выбранные данные копируются целиком. Самый надежный способ, но требует наибольшего количества ресурсов, места для хранения данных и времени копирования, поэтому в чистом виде применяется редко, обычно комбинируется с другими видами (например, первый раз с системы снимается полная копия, а потом резервируются только внесенные изменения). Позволяет восстановить утраченные данные с нуля быстрее всех остальных видов копирования;
- инкрементное копирование – записываются только те данные, которые были изменены со времени прошлого бэкапа. Для таких копий требуется значительно меньше памяти, чем при полном копировании, и снимаются они значительно быстрее. Разумеется, при таком подходе необходимо периодически делать и полную резервную копию, при любой аварии систему восстанавливают из такой копии, а затем накатывают на нее все последующие инкрементные копии в хронологическом порядке. Важный момент: инкрементное копирование восстанавливает удаленные файлы и все предыдущие версии файлов, которые изменялись, так что при восстановлении следует предусмотреть дополнительное дисковое пространство на этот случай;
- дифференциальное резервное копирование – похоже на инкрементное, т.е. копируются только изменения, сделанные с момента последнего полного копирования. Отличие в том, что в каждую последующую копию сохраняются изменения из предыдущей и добавляются новые. Получается, что для восстановления после аварии понадобится только полная копия и последняя из дифференциальных, что значительно сокращает время восстановления. Минусами, по сравнению с инкрементным копированием, являются большой объем копий (иногда сравнимый с полным копированием) и большее время копирования.
Чтобы выбрать подходящий для каждого конкретного случая вид копирования, следует предварительно оценить, как минимум, сколько места доступно для хранения резервных копий, сколько времени получится выделить на «окно бэкапа» без ущерба для бизнес-процессов.
Топология резервного копирования
По своей топологии схемы резервного копирования также различаются.
- Децентрализованная схема. Её суть в том, что на каждом сервере и рабочей станции может быть собственное ПО для резервного копирования, работающее независимо от других узлов сети. Все данные выгружаются на какой-либо общий сетевой ресурс, откуда потом попадают в архив или восстанавливаются, при необходимости. Достоинства схемы в том, что она чрезвычайно простая, легко реализуется и обычно не требует дополнительного ПО, копирование выполняется штатными средствами операционной системы или СУБД. Есть и недостатки – сложно установить общую политику резервного копирования и защиты информации, общее для всех программ расписание бэкапов, настраивать и мониторить деятельность каждой из программ придется отдельно, что усложняет администрирование. Поэтому децентрализованная схема резервного копирования подойдет либо для небольшой и несложной сети, либо для случаев, когда централизованную схему невозможно организовать в силу каких-либо ограничений;
- Централизованная схема – для ее реализации необходимо специализированное клиент-серверное ПО. Серверная часть устанавливается на сервер резервного копирования и централизованно управляет установленными у пользователей программными агентами, которые собирают, копируют информацию о системе или восстанавливают ее из копии. В таком варианте легко настраивать общие политики создания резервных копий, расписание бэкапов, все участники могут работать согласно с общей для компании инструкцией по резервному копированию информации;
- Централизованная схема резервного копирования без программ-агентов – упрощенный вариант предыдущей схемы, когда серверная часть использует только существующие службы и сервисы (например, собирает данные из специально назначенных общих папок Windows). Схема не очень надежная, в ней есть известная проблема, когда открытые в текущий момент для редактирования файлы не попадают в резервную копию и при сбое системы могут быть утрачены. Поэтому применять ее стоит только на небольших сетях и при условии высокой пользовательской дисциплины;
- Смешанная схема – сочетание централизованной и децентрализованной. Программы-агенты устанавливаются только на некоторых серверах сети, от остальных устройств данные на эти сервера отправляют их локальные программы, каждая своими средствами. А уже с этих серверов накопленную информацию программы-агенты централизованно соберут, обработают и отправят в общее хранилище.
Место хранения резервных копий
Чтобы еще больше обезопасить информацию от возможной потери, желательно физически хранить резервные копии отдельно от основного оборудования, на котором развернута рабочая система. При этом необходимо обеспечить возможность быстро получить эти копии, если действительно возникнет такой случай, когда данные необходимо восстанавливать.
Наиболее популярный метод – хранить резервные копии в облаке в дата-центре (собственном или арендовать у провайдера), отправляя туда данные и получая их обратно по защищенному VPN-туннелю. Скорость передачи данных в таком случае ограничивается пропускной способностью канала, но большие объемы данных можно сжимать, используя алгоритмы сжатия или дедупликацию.
Также можно записывать данные на съемные физические носители, которые будут храниться за пределами офиса или здания компании. Плюсом данного подхода является его простота, минусами – необходимость организовать логистику перемещения физических носителей для перезаписи копий, для восстановления данных из копии, а также безопасное хранение данных (шифрование данных, договора о неразглашении с сотрудниками).
Организационные моменты и человеческий фактор
Кроме сугубо технических моментов, в организации резервного копирования информации важен и организационный аспект. Необходимо разработать положение о резервном копировании информации и добиться его выполнения всеми задействованными сотрудниками. В частности, в таком положении должно быть следующее:
- регулярность копирования, резервное копирование по расписанию и перед важными изменениями в системе;
- перепроверка бэкапов – необходимо периодически проверять, действительно ли получается восстановить работоспособную базу или систему из резервной копии;
- документирование процедур восстановления, на случай, если восстанавливать систему придется другому администратору. Естественно, доступ к такой документации должен быть ограничен;
- определение условий, при которых система считается неработоспособной и необходимо начать процедуру восстановления.
Присоединяйтесь к нам, чтобы каждую неделю получать полезные и рабочие материалы для улучшения вашего бизнеса.
Кейсы и стратегии от экспертов рынка.
При администрировании сети часто возникает необходимость в настройке DNS, но что это такое, зачем используется и как выглядит?
Ответа на самые часто задаваемые вопросы о защите персональных данных в соответствии с Федеральным законом №152-ФЗ: о хранении ПДн в облаках, исполнение требований надзорных органов, нейтрализация угроз и т.д.
При администрировании серверов нередко возникают проблемы с жёсткими дисками и другим «железом». В настоящей статье мы расскажем, как может быть повышена скорость чтения и записи данных, снижены риски потери данных.
Восстановление серверов и данных на сервере в СПб. Восстановление работоспособности сервера при сбоях и после вирусов (в т.ч. вирусов шифровальщиков), грамотная настройка бэкапа и архивация данных на сервере
Услуги обеспечения защиты и информационной безопасности баз данных и модулей 1С:Предприятие 7.7 и 8, настройка защиты сервера 1С. Защита информации в 1С от сбоев, взлома, копирования на программном и аппаратном уровнях для обеспечения отказоустойчивости бизнеса
Услуги по настройке резервного копирования баз 1С 8.2, 8.3 в том числе автоматического, по расписанию или при выходе. Архивация и бэкап базы 1С средствами 1С, Windows Server, специализированными утилитами.
Настроим и обеспечим резервное копирование сервера, файловой системы, баз данных (в том числе 1С), документов, файлов, почты организации. Услуга “Резервное копирование и восстановление данных” гарантирует, что любая ценная для вас информация будет надежно защищена от удаления или повреждения.
Источник: integrus.ru
Так с агентом или без?
Привет, Хабр! Сегодня я хочу рассказать о том, как решаются вопросы резервного копирования в случаях работы с агентами или без них. В этом посте мы обсудим, какие преимущества даёт безагентная СРК (на примере Кибер Бэкап), поговорим о том, как она работает, а также рассмотрим ситуации, когда Илюха Курякин (см. «Агенты А.Н.К.Л.» ) всё-таки нужен.
Когда СРК защищает отдельно взятый компьютер, всё работает достаточно просто — специальная служба следит за изменениями вашей файловой системы и согласно заданным правилам создает резервные копии в выбранном месте. Резервные копии могут передаваться по локальной сети или в облако, сохраняются на внешние накопители, а также в сетевые СХД и программно-определяемые хранилища (например, в Кибер Инфраструктуру — и эта тема заслуживает отдельного поста), в том числе и по схеме 3-2-1. В подобных случаях никакого дополнительного агента не требуется — все компоненты устанавливаются вместе и работают как единый комплекс ПО.
Но при развертывании системы резервного копирования в организации, где необходимо защитить десятки (а может и сотни) физических и виртуальных серверов и рабочих станций, обычно на каждый защищаемый объект устанавливается агент, который отвечает за выполнение задач резервного копирования. Агенты могут работать в различных режимах, создавать локальные или сетевые резервные копии. Управление агентами происходит из центральной консоли Кибер Бэкап.
Существуют различные механизмы развертывания агентов. Их можно устанавливать вручную на каждую машину (например, если количество серверов и рабочих станций невелико и практически не меняется) или через групповые политики — для этого можно настроить установку агентов на новые рабочие места, вычислительные узлы или серверы.
Схема без агентов
Когда речь идет о виртуальных машинах, можно поступить иначе. Напомним, что нам доступен гипервизор — управляющее ПО с которым мы можем общаться напрямую и поручать ему создание резервных копий и восстановление данных.
Это становится возможным за счет использования API гипервизоров, через которые сервер резервного копирования может передавать команды/задачи.
Простейшая схема такого резервного копирования выглядит следующим образом:
- Кибер Бэкап посылает запрос на создание моментального снимка ВМ;
- Гипервизор создает снапшот и передаёт путь к нему Кибер Бэкапу;
- Кибер Бэкап перерабатывает получившийся файл в резервную копию формата Кибер Бэкап (или ее инкрементное обновление) и помещает в хранилище резервных копий.
Восстановление происходит по той же простой схеме. Например, если требуется восстановление ВМ целиком, выполняются следующие шаги:
- Кибер Бэкап получает запрос на восстановление определённой ВМ от администратора;
- Кибер Бэкап копирует образ ВМ на нужный носитель;
- Кибер Бэкап даёт гипервизору команду создать новую ВМ из образа.
Конечно, в реальных сценариях при работе с гипервизором учитывается множество дополнительных факторов — проблемы доступа к различным видам хранилищ, механика перемещения данных и формирование инкрементной резервной копии, гарантии сохранения работоспособности ВМ во время сбора снапшотов и так далее.
За все эти операции отвечает виртуальное устройство, которое устанавливается в кластере для взаимодействия с СРК. Такой “безагентный бэкап” (хотя формально, виртуальное устройство тоже можно называть “агентом”) решает широкий круг задач. Бэкап без агентов оказывается выгодным как с точки зрения распределения ресурсов, так и для пользователей ВМ и задач, которые на этих ВМ выполняются:
Работает быстрее — используется ресурс гипервизора, а не отдельно взятой виртуальной машины. Это позволяет достаточно быстро выполнить бэкап даже большого объема данных.
Не мешает пользователям — использует не только ресурсы ВМ, на которой в этот момент вы как раз пытаетесь запустить важную рабочую задачу, но и опирается на ресурсы сети, вычислительные возможности и хранилище кластера в целом.
Разгружает админов — не требуется настройка для каждой отдельно взятой виртуальной машины. Можно обеспечить защиту всего кластера с заданными параметрами RTO и RPO — для этого нужно просто установить единые политики резервного копирования и аварийного восстановления. Настройки будут актуальны как для существующих, так и для новых виртуальных машин.
Что же делать агенту?
После сказанного выше может показаться что агенты уже и не нужны. Но в случае с Кибер Бэкапом это не так. Все дело в том, что большинство развертываний нашего решения происходит на различных инфраструктурах, а агенты устанавливается на физические серверы и рабочие станции.
Помимо этого, агенты бывают полезны и в системах виртуализации. Агентный бэкап позволяет особенно тщательно защищать наиболее критичные ресурсы в кластере — об этом рассказывали на Хабре коллеги, которые активно используют Кибер Бэкап в своих проектах.
Например, если у вас в виртуальной среде или облаке работает важная СУБД, к ней можно добавить агента, который будет обеспечивать резервное копирование ценных для бизнеса данных с минимальным разумным интервалом (обычно — это раз в 15 минут, хотя можно и меньше) и это никак не противоречит наличию безагентного бэкапа для кластера в целом или для какой-то его части.
Режимы с агентом (agent-based) и без него (agent-less) часто комбинируют, когда снимок ВМ выполняется один раз в день, а агент внутри машины создает резервную копию важных данных (например, данных приложений 1С) раз в час, причем в режиме файлов.
Для Кибер Бэкап такая схема является совершенно нормальной. Её настройка и управление происходит из той же самой консоли.
При настройке плана резервного копирования вы можете выбрать схему защиты определенных виртуальных машин, резервные копии которых создаются без агентов, а также определить периодичность и метод сохранения данных поддерживаемых приложений, если внутри ВМ уже установлен агент Кибер Бэкап.
Поддержка гипервизоров
Если честно, нам, как разработчикам, было бы проще, если бы все использовали агентов — они работают одинаково на любых платформах как физических, так и виртуальных. Но именно безагентный бэкап (а точнее комбинация агентного и безагентного) позволяет создать сервис резервного копирования на уровне облака или системы виртуализации, а значит — лучше защитить данные разного типа.
Проекты интеграции с гипервизорами идут долго и требуют глубокого погружения. Мы уже рассказывали, с какими сложностями пришлось столкнуться при включении безагентного резервного копирования для платформы ECP Veil. Однако, судя по отзывам заказчиков, такая возможность оказывается действительно востребованной, и сейчас мы поддерживаем безагентный бэкап для таких гипервизоров, как Кибер Инфраструктура, ECP VeiL, zVirt, ROSA Virtualization, РЕД Виртуализация, Hyper-V, VMware, и ряда других.
Источник: habr.com