Сценарий 2. Малый и средний бизнес

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

С точки зрения инфраструктуры, определим малый и средний бизнес как компанию, в которой есть:

• от нескольких десятков до сотни физических серверов, несколько серверов на ОС Linux

• одна платформа виртуализации (гипервизор), обычно в 2-х хостовом кластере с 100-200 виртуальных машин

• бизнес-приложения, требующие возможности гранулярного восстановления

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

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

Рекомендуется устанавливать сервер управления на Windows Server 2012 R2 или более поздние версии сервера Microsoft, хотя возможна установка и на более ранние версии Windows (Кибер Бэкап 16 поддерживает Windows Server и другие серверные редакции версий 2003-2019) или на ОС Linux.

Аппаратные требования

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

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

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

Использование Microsoft SQL Server в качестве базы данных для сервера управления рекомендуется для окружений с 900+ агентами/виртуальными машинами. 

Устанавливаемые компоненты

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

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

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

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

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

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

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

На каждую защищаемую машину в соответствии с развернутыми на машине приложениями устанавливаются агенты защиты. При установке агента на ОС семейства Linux, обязательно нужно установить компонент "Инструмент создания загрузочного носителя" (Bootable Media Builder). Этот компонент позволит запускать удаленное восстановление машины на уровне дисков и всей машины. Сам загрузочный носитель создавать не нужно, достаточно наличие этого компонента в системе. На хосты виртуализации устанавливаются агенты для  резервного копирования виртуальных машин на уровне гипервизора (резервное копирование без использования агентов)..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что защищать

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

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

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

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

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

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

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

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

Расписание

Наиболее типичным узким местом для операций резервного копирования является пропускная способность сети: в подсегменте сети без его перегрузки может одновременно выполнятся ограниченное число операций резервного копирования. Так же не стоит забывать про производительность хранилища резервных копий, так как на него будет одновременно записываться несколько резервных копий создавая нагрузку по профилю близкую к «случайной записи». Таким образом, расписание выполнения операций резервного копирования должно быть сбалансировано между требованиями по выполнению метрики RPO (recovery point objective), общим объемом защищаемых данных и пропускной способностью сети. В типовой организации малого и среднего бизнеса с парой десятков машин, несколькими терабайтами защищаемых данных и ежедневным инкрементным бэкапом, никаких специальных действий предпринимать не нужно. Но, если в вашей компании больше машин, нагруженная сеть или вы не можете организовать резервное копирование с помощью простой схемы, рекомендуется распределить защищаемые машины по нескольким группам. Каждая группа должна содержать определенное количество агентов чтобы операция резервного копирования завершилась в заданный промежуток времени.

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

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

Для каждого типа объектов резервного копирования должна быть составлена своя схема резервного копирования и определена ее "важность". На одной машине может находится одновременно несколько объектов с разной важностью. Например сама ОС, которую достаточно копировать раз в день и база данных, которую нужно копировать каждые 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% «про запас» - это позволит учесть рост размера копии с течением времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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

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

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

Отключение восстановления файлов из резервных копий дисков

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

Эти дополнительные файлы расположены:

• В ОС Windows 7 и более поздних версиях: %PROGRAMDATA%\Acronis\BackupAndRecovery\TapeLocation

• В ОС Linux: /var/lib/Acronis/BackupAndRecovery/TapeLocation

Пространство, занимаемое этими дополнительными файлами, зависит от количества файлов в соответствующей резервной копии. Для полной резервной копии диска, содержащего примерно 20 000 файлов (обычное резервное копирование диска рабочей станции), дополнительные файлы занимают около 150 МБ. Одна полная резервная копия сервера, содержащего 250 000 файлов, может создать около 700 МБ дополнительных файлов. Даже в небольших средах размер таких файлов быстро вырастет до десятков гигабайт. Рекомендуется отключать этот параметр, если он вам абсолютно не нужен, и в этом случае убедитесь, что размер узла хранения соответствует этим дополнительным файлам.

Наборы лент

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

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