Развертываем Кибер Бэкап самостоятельно. Часть 3

Сценарий 3. Крупная компания

В предыдущей части мы привели рекомендации по установке и использованию нашего продукта в компаниях малого и среднего бизнеса. Сегодня мы, Дмитрий Ермолаев и Алексей Федоров, затронем вопросы установки и использования Кибер Бэкапа в крупных компаниях.

Примечание: если вы читаете не с начала, рекомендуем познакомиться с описанием компонентов Кибер Бэкапа в первой части цикла.

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

Подготовка к развертыванию

Требования к ОС для крупных компаний

Для сред, где в основном используется ОС Windows, мы рекомендуем устанавливать сервер управления на Windows Server 2012 R2 или более поздние версии. Также можно использовать машины с более ранними версиями Windows или с ОС Linux. 

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

ОС Linux

Кибер Бэкап поддерживает следующие версии ОС Linux: Red Hat Enterprise Linux 5.x+, Ubuntu 9.10+, Fedora 9+, SUSE Linux Enterprise Server 11+, Debian 5+, CentOS 6.x+, Linux 6.x+, и другие ОС на ядре 2.6.23+. Также поддерживаются российские ОС: Альт Сервер, Альт Рабочая станция, Альт СП, РЕД ОС, Astra Linux Common Edition релиз «Орел», Astra Linux Special Edition релиз «Воронеж», Astra Linux Special Edition релиз «Смоленск», РОСА «КОБАЛЬТ», ROSA Enterprise Desktop. Полный список поддерживаемых ОС можно посмотреть в базе совместимостей.

База данных сервера управления

По умолчанию для хранения своих данных сервер управления использует СУБД SQLite - и на платформе Windows и на Linux. Возможностей этой СУБД вполне достаточно для большинства компаний малого и среднего бизнеса. Но для задач крупного бизнеса необходимо использовать более надежное и безопасное решение. Для ОС Windows рекомендуем использовать Microsoft SQL Server – для крупных организаций подойдут все издания кроме SQL Express. В ОС Linux используйте PostgreSQL. В следующих версиях Кибер Бэкапа планируется реализовать поддержку использования PostgreSQL в качестве базы данных сервера управления.

Рекомендации по использованию СУБД Microsoft SQL Server

Ниже приведены две конфигурации, поддерживающие использование до 10 000 агентов с хранением данных сервера управления в Microsoft SQL Server. Выберите ту, которая наиболее подходит вашим требованиям

Требования к оборудованию

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

Аппаратные требования к централизованным компонентам управления повышаются с увеличением числа защищаемых устройств, особенно в средах с более чем 200 агентами. Так как сервер управления не слишком требователен к процессору и памяти, ключевым критерием для крупных компаний будет пропускная способность канала ввода/вывода подсистемы хранения, используемой различными базами данных сервисов сервера управления. Это связано с тем, что синхронизация агентов в крупных средах порождает большое количество конкурирующих запросов к базам сервера управления. При работе со стандартной базой SQLite это порождает большое количество (от сотен до тысяч) операций ввода/вывода в секунду (IOPS), которые могут привести к возникновению «заторов» при использовании стандартных жестких дисков. Мы рекомендуем использовать диски с высокой пропускной способностью для сервера управления, такие как SSD.

Ниже приведены две конфигурации для сервера управления, поддерживающие использование до 5 000 агентов.

Для создания планов резервного копирования рекомендуется добавлять в план не более 500 объектов резервного копирования (физические/виртуальные машины), а каждый план запускать не чаще чем раз в 15 мин.

Используемые порты

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

Оптимизация после развертывания продукта

Хранение журнала активностей

По умолчанию активности хранятся в течение 90 дней. В крупных средах с тысячами машин журнал активностей может стать слишком большим, что приведет к задержкам в его использовании. Мы рекомендуем уменьшить срок хранения до 30 дней. Для этого:

1. Откройте на редактирование файл task_manager.yaml;

2. Этот файл располагается:

   • в ОС Windows в папке %Program Files%\Acronis\TaskManager\

   • в ОС Linux в папке /var/lib/Acronis/TaskManager/

3. В разделе «database» в подразделе «shards» найдите строки

   • - connection-string: sqlite://task-manager.sqlite

   • days-to-keep: 90

4. Измените значение «90» на «30»;

5. Сохраните изменения и перезапустите сервис сервера управления (Acronis Service Manager Service).

Также см. статью в базе знаний.

Данные об использовании хранилищ

Панель использования хранилищ показывает данные, которые обновляются каждые 5 минут. Если вы планируете добавить более 2000 защищаемых объектов и, если вы используете локальное или сетевое хранилище, мы рекомендуем понизить частоту обновлений, например, обновлять данные каждый час. Для этого:

1. Откройте на редактирование файл collector.yml;

2. Этот файл располагается

   • в ОС Windows в папке %ProgramData%\Acronis\MonitoringCollector

   • в ОС Linux в папке /var/lib/Acronis/MonitoringCollector/

3. В строке «vaults_collection_interval» измените значение параметра с 300 на 3600:

   • vaults_collection_interval: 3600

4. Сохраните изменения и перезапустите сервис сервера управления (Acronis Service Manager Service).

Примечание: Не изменяйте значения параметров activities_collection_interval, alerts_collection_interval и flush_intervalтак как эти настройки не связаны с числом защищаемых объектов.

Компоненты и установка

Компоненты управления

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

Компоненты для удаленной установки (только для сервера управления на ОС Windows)

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

Агенты защиты

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

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

• в настоящее время нет способа импортировать или экспортировать конфигурацию сервера управления;

• в настоящее время нет способа запуска сервера управления в кластере;

  • Примечание: в новой версии Кибер Бэкапа, которая выйдет в конце года, сервер управления сможет работать в отказоустойчивом кластере, развернутом в одном или нескольких ЦОД. Подробнее об этом напишем в обзоре Кибер Бэкапа 16.5.

• защита сервера управления потребует лицензии, соответствующей операционной системе, на которой установлен сервер управления.

Потребуется установить следующие компоненты, но не обязательно "рядом" с сервером управления.

• Мастер создания загрузочных носителей;

• СУБД Microsoft SQL Server для сред с более чем 900 агентов.

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

Узел хранения

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

Сервис каталогизации

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

Агенты защиты

Агенты защиты должны быть установлены на все объекты, которые подлежат защите. Установка агентов каждого типа подробно описана в Руководстве пользователя. 

Физические машины

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

Виртуальные среды

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

Обработка Off-host

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

• Репликация резервных копий;

• Валидация резервных копий;

• Очистка хранилищ резервных копий;

• Преобразование резервной копии в ВМ;

• Репликация ВМ;

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

Рекомендуемая процедура установки Кибер Бэкапа

Ниже приведены рекомендации по установке в крупные среды:

1. При установке в ОС Linux, сначала установите все необходимые пакеты;

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

3. Если требуется, установить узел хранения или сервис каталогизации на серверы, связанные с инфраструктурой хранения данных и зарегистрировать эти компоненты в сервере управления;

4. Создать учетные записи пользователей и отделов организации;

5. Создать группы объектов защиты;

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

7. Сконфигурировать хранилища резервных копий;

   1. установить отдельного агента на сервер, используемый для хранения данных или максимально близко с ним (с т.з. топологии сети). Этот агент будет использоваться для off-host обработки данных - очистки, валидации, репликации и пр.

8. Настроить планы защиты и применить их к группам;

9. Создать планы обработки данных off-host;

10. Создать отделы, группы и пользователей. 

Подробно процедура установки описана в Руководстве пользователя.

Рекомендации по планам резервного копирования

Что защищать

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

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

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

Выбор места хранения резервных копий

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

• Хранить все резервные копии на защищаемой машине или рядом (с точки зрения топологии) с агентом.

  • Например, резервную копию диска C:\ можно хранить на диске D:\ или внешнем USB-устройстве. У таких сценариев нет каких-либо особых рекомендаций. Преимуществом такого сценария будет снижение нагрузки на сеть, но потребуется чуть больше администрирования. 

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

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

• Хранить резервные копии централизованно (рекомендуемый вариант).

  • Для крупных сред это потребует использования нескольких сегментов сети, каждый из которых имеет собственное хранилище и/или достаточную пропускную способность для соединения с хранилищем. Подробнее об этом - ниже, в разделе "Хранилища".

  • При централизованном хранении резервных копий все задания по обработке данных - валидация, репликация и пр. должны выполняться выделенным под эти задачи агентом, связанным с хранилищем. Рекомендованным решением для централизованного хранения резервных копий, будет использование общих папок SMB/NFS и файловых систем xfs и NTFS с размером кластера 64к. Подробнее см. статью в базе знаний.

Расписание

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

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

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

Для каждого типа объектов резервного копирования должна быть составлена своя схема резервного копирования и определена ее "важность". На одной машине может находиться одновременно несколько объектов с разной важностью. Например, сама ОС, которую достаточно копировать раз в день, и база данных, копируемая каждые 3 часа. Для этого создаются отдельные планы, которые не должны пересекаться по времени.

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

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

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

Срок хранения резервных копий

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

Если вы используете централизованное хранилище резервных копий с большим объемом, настоятельно рекомендуем отключить правила хранения резервных копий в плане защиты - укажите что резервные копии нужно хранить бесконечно. Это связано с тем, что задачи по очистке, указанные в плане защиты будут выполняться каждым агентом по завершении операции резервного копирования, что приведет к дополнительной нагрузке и на агентов и на сеть когда сотни агентов будут выполнять задачи по очистке хранилища. Вместо этого, установите отдельного агента на машину с хранилищем резервных копий (или максимально близко к ней в сети) и создайте специальный план очистки. Такой план будет выполняться одним агентом по собственному расписанию с минимальной нагрузкой на сеть.

Репликация, преобразование и валидация резервных копий

По аналогии с задачей очистки хранилищ, не включайте операции репликации или валидации в план защиты, размещающий резервные копии в централизованном хранилище. Вместо этого всегда создавайте отдельные мини-планы, выполняющие операции репликации и валидации вне хоста (off-host) в периоды низкой нагрузки на ресурсы. Агент, назначенный для выполнения таких операций, должен быть установлен максимально близко (с точки зрения топологии) к хранилищу или прямо на машину с хранилищем резервных копий. 

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

Число ресурсов на один план защиты

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

Другие рекомендации

Уведомления и отчеты

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

Отключите все уведомления, не связанные с вашей средой

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

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

Настройте уведомления для отдельных предупреждений

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

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

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

Обработка ошибок и повтор выполнения операций

При возникновении исправимой ошибки Кибер Бэкап повторно пытается выполнить неудачную операцию (например, сеть становится недоступной). По умолчанию выполняется 30 повторных попыток с 30-секундными интервалами (15 минут). Это не критично для небольших заданий резервного копирования, но может существенно повлиять на окна резервного копирования, если вы параллельно выполняете резервное копирование больших групп машин. Это значение можно уменьшить до 10 повторных попыток с 30-секундными интервалами.

Формат файла резервной копии

По возможности, всегда используйте формат архива версии 12 (еще называется Archive3). Этот формат резервной копии используется для быстрого резервного копирования и восстановления. Каждая цепочка резервных копий (полного или дифференциального копирования, и всех зависящих от них инкрементных резервных копий) сохраняется в один файл TIBX. Более подробно см. статью «Tibx или не tib».

Активная защита

Служба "Активная защита" (Active Protection) обеспечивает защиту компьютера от вредоносных программ, таких как вирусы-вымогатели и программы майнинга криптовалют. Вирусы-вымогатели шифруют файлы и требуют платы от пользователя за ключ расшифровки. Программы майнинга криптовалют запускают математические вычисления в фоновом режиме, тем самым повышая нагрузку на вычислительные ресурсы и увеличивая сетевой трафик. Помимо защиты от вредоносных программ, "Активная защита" предотвращает неавторизованные изменения собственных процессов, записей реестра, исполняемых и конфигурационных файлов и резервных копий, расположенных в локальных папках.

Активная защита работает на машинах под управлением ОС Windows 7 и более поздних версий и ОС Windows Server 2008 R2 и более поздних версий. На машине должен быть установлен агент для Windows. "Активная защита" — это отдельный модуль в плане защиты. Рекомендуется включить активную защиту на всех машинах, где использование ресурсов процессора не критично. Активная защита обычно использует несколько процентов ресурсов процессора во время анализа файлов.

Защита сервера управления

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

Хранилища

Рекомендации по хранению

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

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

• размера полной копии;

• среднего размера инкрементной копии;

• длины необходимой цепочки копий.

К этим данным добавляем 20% «про запас» - это позволит учесть рост размера копии с течением времени.

Дедупликация

Дедупликация в Кибер Бэкапе всегда происходит в источнике - вычисление хэша выполняется агентом, а данные, уже содержащиеся в резервной копии, не пересылаются повторно по сети. Это отличный способ уменьшить как требования к хранилищу, так и пропускную способность сети, особенно если вы создаете резервные копии похожих машин. 

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

Дедупликация и репликация

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

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

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

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

Ленточные устройства

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

Список протестированных и поддерживаемых ленточных устройств можно посмотреть в базе совместимостей (необходимо включить фильтр "Категории совместимости" - "Ленточные устройства") или в документе. Чтобы проверить совместимость ваших собственных ленточных устройств, используйте инструмент совместимости лент. 

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

Если источник резервной копии медленный и скорость записи на ленты не соответствует минимальному значению допустимому ее стандартом LTO см. статью в базе знаний, то запись останавливается до загрузки данных в буфер. После этого запись на ленты продолжится, до момента пока буфер снова не станет пуст. Этот процесс старт/стоп занимает очень большое количество времени, по этому его следует избегать. Используйте в таких сценариях несколько агентов, которые будет записывать свои данные одновременно на одну ленту, через механизм мультиплексирования. В обратном сценарии, когда источник очень быстрый, а ленты медленные, используйте мультистриминг (с несколькими потоками), когда один агент записывает данные сразу на несколько лент.  Об управлении лентами см. в документации по продукту. 

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

Узел хранения для лент

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

База данных управления лентами

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

Путь к базе данных по умолчанию:

• Windows7, Server2008 и более поздние версии Windows: %PROGRAMDATA%\Acronis\BackupAndRecovery\ARSM\Database

• Linux: /var/lib/Acronis/BackupAndRecovery/ARSM/Database

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

Чтобы переместить базу данных в ОС Windows

• Остановите службу управления съемными носителями;

• Переместите все файлы из папки по умолчанию в новую папку;

• Найдите раздел реестра HKEY_LOCAL_MACHINE\SOFTWARE\Acronis\ARSM\Settings;

• Укажите новый путь расположения в значении реестра ArsmDmlDbProtocol. Строка может содержать до 32765 символов.;

• Запустите службу управления съемными носителями.

Чтобы переместить базу данных в ОС Linux

• Остановите службу acronis_rsm;

• Переместите все файлы из папки по умолчанию в новую папку;

• Откройте файл конфигурации /etc/Acronis/ARSM.config в текстовом редакторе;

• Найдите строку <value name="ArsmDmlDbProtocol" type="TString">;

• Измените путь под этой строкой;

• Сохраните файл;

• Запустите службу acronis_rsm.

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

Для восстановления данных резервных копий с ленточных накопителей используется папка Tape Location, в которой содержатся кэш и мета файлы сохраненных данных. А также файловые системы дисков с поддержкой файлового восстановления. Эти данные занимают около 0,01% от данных, занятых на лентах и на больших библиотеках могут достигать размера в сотни гигабайт. Поэтому заранее предусмотрите необходимый размер хранилища на узле хранения с подключенными лентами. Подробнее см. статью в базе знаний.

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

Наборы лент

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

Кибер Инфраструктура

Крупные компании, заинтересованные в создании надежного хранилища для резервных копий, могут воспользоваться нашим продуктом Кибер Инфраструктура. Кибер Инфраструктура позволяет быстро и легко преобразовать стандартное оборудование в универсальную, масштабируемую, защищенную гиперконвергентную инфраструктуру, которая объединяет виртуализацию и хранилища любых видов данных - блочных, файловых, объектных и резервных копий. Входящий в состав продукта шлюз резервных копий (ABGW) позволяет использовать Кибер Инфраструктуру совместно Кибер Бэкапом, сводя к минимуму количество технологий, необходимых для хранения резервных копий, и обеспечивает дополнительные улучшения в плане производительности.

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