Veeam backup replication v10 резервное копирование nas и файловых шар
Этой статьёй я хочу дать старт небольшому циклу, который будет посвящён новому функционалу в Veeam Backup & Replication V10, который мы так долго уже ждём. На момент публикации данной статьи дата релиза GA всё ещё неизвестна, но я побывал на Veeam Vanguard Summit 2019, где появилось довольно много подробностей о 10-й версии продукта и теперь у меня есть большое количество материалов, которыми я мог бы с вами поделиться. Тем более, что всё это подкрепляется уже 2-й бета версией, которая уже доступна узкому кругу лиц.
Бекапа файловых шар действительно не хватало и это было очень частым запросом. Конечно были варианты, каким образом бекапить файловые шары при помощи Veeam, один из таких способов при помощи Linux Agent я уже описывал, но скажем честно — это грабли, а не решение.
Очень радует тот факт, что функционал не просто появился, он пришёл уже в довольно зрелом состоянии, предоставляет массу возможностей, которые призваны сделать резервное копирование как можно более быстрым, при этом делая процесс восстановления как можно более гибким.
10-я версия предлагает 2 варианта резервного копирования файловых шар:
- SMB v1, v2 и v3
- NFS v3 и v4.1
- «Управляемые» файловые сервера на базе Linux и Windows.
Начну с «управляемых» файловых серверов, т.к. этот вариант у нас фактически уже имелся и реализован практически также — при помощи агентов, установленных на файловых серверах под управлением Linux и Windows. Здесь компания Veeam немного отошла от своей основной идеи «делаем бекап всего, а вы уже сами решаете, что вы хотите из этого восстановить». Новые агенты для файлового бекапа, схожи по своей сути с хелперами, которые устанавливаются на виртуальные машины при application-aware. Они позволяют выполнить бекап отдельных дисков/разделов сервера, но при этом не позволяют сделать резервное копирование всего сервера и, соответственно, из такого бекапа можно восстановить только отдельные файлы. Именно этот вариант рекомендуется использовать, если ваш файловый сервер находится под управление одной из этих операционных систем. Если же вы хотите иметь возможность восстанавливать файловый сервер целиком, чтобы защититься от полного отказа, то ваш путь — полноценный Windows/Linux агент.
Но перейдём к более интересному — сетевые шары.
Одной из интересных особенностей на мой взгляд является использование снепшотов. Во-первых, для SMB3 можно использовать VSS снепшоты, а если вы используете СХД с поддержкой снепшотов, то можете использовать её снепшоты.
Да, вы можете забирать данные на прямую с шары, но в этом случае заблокированные (используемые пользователями в этот момент) файлы не смогут быть прочитаны и Veeam их просто проигнорирует при резервном копировании.
Для работы VSS снепшотов, единственным условием является поддержка SMB3 как со стороны самой файловой шары, так и со стороны Veeam Proxy, чтобы он мог шаре дать соответствующую команду.
И третий вариант — снепшоты СХД. На GitHub в репозитории VeeamHub уже есть примеры pre-job скриптов, которые делают снепшот (на примере NetApp FAS/AFF). При этом, Veeam корректно работает со снепшотом, вам не нужно указать путь именно до него, что позволяет в дальнейшем восстанавливать файлы в оригинальное место на шаре без дополнительных проблем.
Процесс и хранение
При первом бекапе вычисляется CRC-хэш для каждого файла и директории, при запуске следующего задания (инкрементного) происходит сравнение CRC-хэшей «по дереву», начиная с рутовой директории. Если хэш директории не изменялся — она просто пропускается, т.к. внутри ничего не менялось. Таким образом ищутся директории с изменённым хэшем и уже внутри этих директорий ищутся файлы с изменившимся хэшем. Для этих файлов снова вычисляется хэш, записывается их метадата и происходит бекап данного файла.
Хэши хранятся в Cache Repository. Cache Repository создаётся отдельный для каждой шары на этапе добавления каждой шары в VBR, желательно располагать на SSD, т.к. работа с метаданными требует хорошей скорости дисковой подсистемы. Если вы используете для хранения данных SOBR, то стоит учитывать, что Cache Repository не может располагаться на нём. Также у нас появилось несколько приятных вещей:
Для файлового бекапа Veeam ушёл от использования точек восстановления и перешёл к дням.
Мы можем хранить несколько версий файлов, если они изменялись, при этом для долгосрочного хранения этих файлов мы можем указать другой репозиторий. В том числе есть гибкие настройки по хранению файлов и в том числе поддерживается фильтрация по расширению файла.
Предполагается, что для долговременного хранения файлов будет использоваться иное хранилище, нежели основной репозиторий для бекапов, к примеру, это может быть более дешевая система хранения данных или облачное S3 хранилище.
Может быть использовано несколько прокси для бекапа одной шары в рамках одного задания.
Это позволяет лучше масштабировать систему и добиться максимальной скорости. В рамках одного задания разные прокси могут обрабатывать одну шару, разделяя между собой данные, но используя при этом один и тот же Cache Repository и Backup Repository. Возможность использовать Backup Repository несколькими прокси серверами появилась благодаря новому формату хранения данных для файлового бекапа. Native BLOB Storage вместо VBK и VIB. Данные хранятся в блобах, размер которых равен 64Мб.
Переход к новому формату хранения данные позволяет добиться ещё одной положительной возможности — данные одной сессии бекапа могут храниться на разных экстентах. То, чего невозможно добиться при бекапе виртуальных машин (по крайней мере на сегодняшний день), но что может потенциально дать дополнительный прирост производительности, если для SOBR вы используете разные системы хранения данных или шары с разных дисковых агрегатов.
При использовании SOBR для файлового бекапа на каждом экстенте хранится дополнительные набор (из двух копий) метаданных, что позволяет «потерять» до двух экстентов (независимо от того — 3 у вас или 20). Но это не отказоустойчивость на уровне самих данных, а только на уровне метаданных, что позволит при потере одного из экстентов перечитать все метаданные, чтобы составить карту данных, которые нам ещё доступны на живых экстентах, что бы этот бекап у нас был работоспособен.
Для корректной работы данного функционала требуется у задания включить Backup Health check. И для полной безопасности — запускать его ежедневно. Тогда при потере одного из экстентов мы сможем запустить Health check у джоба и перестроить метаданные, для запуска процесса восстановления. Нужно понимать, что при перестроении метаданных, из них удаляется информация о тех данных, что были на экстенте, который умер. Соответственно Health check можно запустить только вручную и только при полном понимании администратором, что данный экстент и данные на нём навсегда утеряны. Если же ваш экстент недоступен временно, этот функционал использовать нельзя, даже если экстент станет доступен, данные уже не будут подтянуты Veeam.
Прокси для файлового бекапа может быть только на Windows — это уточнение теперь необходимо, в связи с появлением Linux Virtual Proxy, но на нём подробнее остановлюсь в части про бекап виртуальных машин.
Восстановление
Конечно, для восстановления у нас есть Explorer, какой он был для файлового восстановления, но в нём добавилось несколько отличных вещей.
Одно важное замечание — если вы делаете файловый бекап Linux сервера при помощи нового “файлового” агента, то для восстановления файлом больше не требуется FLR, который необходимо было запускать в вашей виртуальной инфраструктуре и уже через него восстанавливать файлы. Благодаря этому новый эксплорер запускается за секунды и сразу же готов к работе.
Первый вариант восстановления — Entire File share
Здесь примечательно, что у нас появился не просто выбор точек, как это было реализовано раньше, а в стиле CDP (если кто-то видел презентацию Андрея Железко и Дмитрия Князева на VeeamON Forum Russia 2017). Хотя можно и вручную выбрать конкретную точку по календарю, если вам удобнее классический вариант. Самым же удобным является то, что у нас есть браузер файлов и мы можем посмотреть состав бекапа. Найти нужную копию (например, до того, как директорию обработал шифровальщик) и восстановиться на этот момент без всяких проблем. Есть возможность как восстанавливаться в оригинальное расположение файлов, так и в другую директорию и/или на другой сервер. При этом у нас имеется ряд дополнительных опций при восстановлении, если восстанавливаемый файл есть на нашей шаре:
- Skip restoring (keeps existing files)
- Replace older files only (use for restoring shares reverted to a snapshot)
- Replace newest files only (use to roll back unwanted contents changes)
- Restore anyway (overwrites existing files)
Так же при восстановлении могут быть восстановлены атрибуты доступа к файлам и директориям.
Второй вариант — Rollback to point in time
Самый простой вариант — откатываем всё что есть на рестор поинт, без дополнительных параметров.
И самый интересный и наиболее востребованный вариант — Files and Folders.
По умолчанию, нам предлагается в качестве восстановления использовать последнюю копию бекапа либо можно выбрать необходимый рестор поинт, но самое интересное, это вариант All time, где мы сможем увидеть все файлы, которые имеются в нашем бекапе и в том числе — все версии изменявшихся файлов, с возможностью восстановить именно необходимую копию файла. И видны те файлы, которые уже удалены с продуктивного хранилища вместе с указанием даты их удаления. Это удобно, когда вам нужно восстановить конкретный файл, который вы не знаете когда именно был удалён или изменён, а при наличии поиска по файлам это операция занимает минимальное количество времени.
И небольшая вишенка на торте — Veeam ONE, в который добавлены новые репорты для NAS бекапа:
- Backups on repository
- Backups on tape
некоторые старые репорты подверглись обновлению:
- Job history
- Backup infrastructure custom data
Алерты к нему же и обновлены:
- File backup job state
- File backup copy state
- File-to-tape jobs state
- Proxy connection
- Proxy performance
И самое интересное — лицензирование
И так, мы наконец-то получили недостающую часть звена в резервном копировании при помощи Veeam. Знаю, что было множество запросов на эту тему. Приятно, что реализация оказалась на довольно высоком уровне и интересными решениями. Поддержка снепшотов СХД (а поддерживаются все совместимые на сегодняшний день СХД и те, которые будут добавляться в дальнейшем при помощи Storage API) на мой взгляд просто отличная идея, как и новый формат хранения.
Мир сетевых хранилищ NAS изменился. Масштабируемость, которая стала возможна благодаря производственным устройствам NAS и использованию протоколов NFS и SMB, достигла новых уровней. Взрывной рост объемов данных NAS продолжается, как и потребность в защите неструктурированных данных от злонамеренных атак, использующих уязвимости этих устройств.
Простое и эффективное резервное копирование NAS обеспечивает защиту неструктурированных данных с помощью удобного подхода на основе мастера заданий и позволяет обрабатывать петабайты данных с максимальной скоростью.
Гибкие возможности хранения данных NAS отвечают требованиям защиты данных для различных NAS и файловых серверов благодаря встроенным возможностям гранулярного восстановления.
Надежная архитектура не только позволяет защищать большие объемы данных, но также обеспечивает согласованность и эффективность данных.
Принцип работы резервного копирования NAS от Veeam
Компоненты
Данные исходных общих сетевых ресурсов переносятся на целевые устройства с помощью файловых прокси-серверов. Файловые прокси-серверы ― это масштабируемые и программно-определяемые компоненты, которые обеспечивают перенос данных. Для их масштабирования не требуются выделенные устройства или новое оборудование.
Решающим преимуществом является функция отслеживания изменений файлов, которая позволяет контролировать размеры файлов в исходном хранилище. Данные хранятся в кэш-репозитории. Кэш-репозиторий отслеживает все объекты, измененные с момента создания предыдущей резервной копии. В результате резервное копирование выполняется очень быстро.
Отслеживание измененных файлов
Функция резервного копирования NAS поддерживает все те же репозитории, что и резервное копирование ВМ, в том числе масштабируемый репозиторий. При разработке резервного копирования NAS особое внимание было уделено защите неструктурированных данных. Технология позволяет переносить старые версии файлов в более экономичные хранилища, такие как устройства дедупликации или объектные хранилища. Эта методология обеспечивает возможность краткосрочного хранения данных в течение нескольких дней на производственной площадке.
Чтобы обеспечить соблюдение требований законодательства, можно использовать публичное облачное хранилище для долгосрочного хранения и архивирования данных. Резервное копирование NAS от Veeam также позволяет хранить копию данных NAS на удаленной площадке, с отдельным сроком хранения. Эту возможность можно использовать для послеаварийного восстановления неструктурированных данных.
With Veeam Backup & Replication you can easily back up and restore content of various NAS file shares. The solution can be flexibly scaled to reliably protect massive amounts of data, even for the largest of enterprise organizations.
To protect your NAS file shares, you can use your existing Veeam Backup & Replication infrastructure. Just configure the following components:
For system requirements for NAS backup components, see System Requirements .
To learn how NAS backup components interact during file share backup, see How File Share Backup Works .
A file share is a storage device or data source available to multiple hosts through a computer network.
For supported file shares, see Platform Support .
File share backup jobs in Veeam Backup & Replication can read data from the following sources:
- SMB (CIFS) path
- NFS path
- Path to the storage snapshot folder
- VSS snapshot
Mind the following limitations:
- Reading from VSS snapshots on SMB shares is available only under certain conditions, listed in this Veeam KB article .
- Reading from VSS snapshots on DFS shares is not supported.
To learn how to add NAS file shares to the backup infrastructure, see Adding File Share .
A backup proxy is an architecture component that sits between the file share and other components of the backup infrastructure. The backup proxy operates as a data mover that transfers data between the source file share and the backup repository. The backup proxy processes jobs and delivers backup and restore traffic.
You can assign the role of a backup proxy to any Windows-managed server added to your Veeam Backup & Replication infrastructure. By default, this role is assigned to the backup server. But this option is sufficient only for small installations where all components are located in the same network segment. For larger installations with larger workload, assign the role of a backup proxy to a dedicated server, as described in Adding Backup Proxy . After that, choose this backup proxy to process the backup traffic from file shares, as described in Adding NFS File Share and Adding SMB File Share .
To optimize performance of several concurrent tasks, you can use several backup proxies. In this case, Veeam Backup & Replication will distribute the backup or restore workload between available backup proxies on per-task basis, taking into account proxy connectivity and their current load. You can deploy backup proxies in the primary site or in remote sites. Mind that using a remote backup proxy may reduce backup performance and is not recommended. To minimize the network load during backup, locate the backup proxy closer to the source file share in the computer network: at the best they should be one hop away from each other.
A cache repository is a storage location where Veeam Backup & Replication keeps temporary metadata and uses it to reduce the load on the file share during the backup procedure. The cache repository keeps track of all objects that have changed between each backup session. This allows performing incremental backups from the file share super fast and very efficiently.
You can assign the role of a cache repository to a simple backup repository added to the Veeam Backup & Replication infrastructure. To assign this role, select the backup repository as a cache repository, as described in Specify File Share Processing Settings .
To minimize the network load during backup, locate the cache repository closer to the backup proxy in the computer network: at the best, they should be located on one machine.
A backup repository is a main storage location where Veeam Backup & Replication keeps all versions of backed up files for the configured period and metadata files. Backups stored in the backup repository can be used to quickly restore the entire file share to the state as of a specific restore point.
[Optional] If you want to retain specific files for a longer period of time, you can use cheaper devices for archive purposes. To enable file archiving, configure Veeam Backup & Replication to move backup files and metadata files from the backup repository to an archive repository . By default, usage of the archive repository is disabled and, after the retention period for the backup repository is over, backup files are deleted.
[Optional] If you want to store a copy of the file share backup in a different repository, you can configure a secondary repository where Veeam Backup & Replication will copy all backups created in the backup repository. The secondary repository can have its own retention policy and encryption settings. By default, no secondary repository is configured.
The table below describes which roles can be assigned to the different storage types.
Одной из главных новостей 10-й версии Veeam Backup & Replication, о которой информация появилась уже некоторое время назад, является Linux proxy. Многие давно этого ждали. Почему же он появился?
- Есть заказчики у которых в принципе нет Windows и они его не хотят
- Требуется лицензия на Windows proxy
- Сама ОС — «легче»
Из не совсем радостных вещей — пока только в режиме Hot-Add, т.е. физические серверы не поддерживаются. А вот из приятного (на мой взгляд) отказ от Virtual Disk Development Kit (VDDK) в пользу собственного кода. И это хорошо, потому что возникает множество сложностей при использовании VDDK, в том числе и проблемы с производительностью. У меня самого было несколько кейсов, связанных с VDDK. Отказ в пользу собственного кода даёт больше возможностей и вероятнее всего лучше это будет заметно на производительности. Я не отказал себе в удовольствии сравнить производительность Linux и Windows прокси серверов, правда в моём случае результат оказался не таким, как ожидалось.
Я создал прокси с 1 vCPU и 1Gb памяти, чтобы посмотреть — на какой из платформ при этом скорость будет лучше. Специально было взяты минимальные параметры, чтобы узким местом в системе оказался именно прокси-сервер. К моему удивлению, Linux показал себя хуже, чем Windows, хотя у моих коллег Vanguard’ов картина была обратной. Но я пока не ставлю 100% крест на Linux и продолжу тестирование уже на боевой инфраструктуре, когда сможем обновить наши сервера до 10-й версии, вероятнее всего там картина будет иной, т.к. я связываю такую картину с недостаточной производительностью моего тестового стенда с точки зрения дисковой подсистемы. Причём, если вы внимательно присмотритесь к скриншотам, то заметите, что при использовании Windows агента процесс упирается больше в источник, а не в сам прокси. Я вообще не понимаю, как Windows 2012 R2 может работать на 1 CPU и 1Gb памяти. В консоль его войти просто не возможно, всё очень тормозит. Но при этом же в качестве прокси работает быстрее, чем Linux. Здесь тоже стоит отметить, что новая версия агента всё ещё в бете и я так думаю, что она не последняя перед релизом, так что есть ещё время привести её в порядок и сделать как минимум не хуже, чем Windows.
Официально поддерживаемые ОС для прокси:
И конечно же нельзя было отказать себе в радости, чтобы не провести такой же тест, но уже между двумя разными версиями Linux — Centos 7 и Ubuntu 19.
А вот у Steven Onofaro, в его статье “VEEAM V10 – LINUX PROXIES HAVE ARRIVED” результаты получились совсем обратные и лучше себя показал как раз CentOS, а не Ubuntu, хотя версии одни и те же.
Компания не хочет связываться с аплайнсами и предоставлять уже готовые образы ОС для развёртывания. Вы можете взять наиболее приоритетный дистрибутив Linux для вашей компании и применять к нему ваши политики по безопасности и обновлениям. С одной стороны — это хорошо, с другой стороны, на мой взгляд развёртывание аплайнса можно было бы сделать более простым и быстрым. Но мою подобную идею с динамическим развёртыванием не оценили, хотя у Anthony Spiteri есть проект Otosukeru, который в этом поможет. Для всех любителей DevOps подойдёт как нельзя лучше. Вы можете использовать его в качестве Pre и Post скриптов, для автоматического развёртывания прокси на базе Linux, а по завершению заданий — удалить их. На мой взгляд это отличное решение.
XFS Fast Clone, думаю из названия уже будет понятно, о чём идёт речь. Собственно с появлением Linux proxy, его можно использовать и в качестве сервера-репозитория, пробрасывая сторадж внутрь VM.
Если кто-то не знаком с тем, что такое Fast Clone, небольшое объяснение: Fast Clone позволяет создавать синтетические полные резервные копии и резервные копии GFS без перемещения блоков данных. Вместо этого при создании синтетических полных бекапов, данные не копируются, а ссылаются на блоки данных, которые уже присутствуют на томе. Fast Clone увеличивает скорость создания и преобразования синтетических резервных копий, снижает требования к дисковому пространству и нагрузку на устройства хранения. Подробнее о том, как это уже работает на Windows с ReFS можно прочитать в статье «Использование возможностей ReFS в Veeam Backup & Replication 9.5».
Обязательным условием для работы FastClone является использование параметров reflink=1 и crc=1 и размер блока 4096
mkfs.xfs –b size=4096 -m reflink=1,crc=1 /dev/sdb1
Для сравнения я сделал несколько резервных копий на ReFS, и такое же количество и тип копий на XFS репозиторий — разницы во времени преобразования и итоговом размере резервной копии я не смог заметить.
Ещё один немало важный момент — Linux прокси по своим возможностям полностью идентичен Windows прокси, т.е. самое главное — поддержка application-aware processing есть, и самое главное, VIX для доступа к VM полностью работает.
В целом, нам осталось лишь дождаться, когда Linux начнёт поддерживаться на физических серверах, работа над этим уже ведётся, но сроки релиза или хотя бы Beta пока не оглашаются.
Veeam Backup & Replication V10 принесёт нам множество нового функционала, но не весь он такой большой, как бекап NAS или новый Linux прокси, поэтому писать по отдельной статье по каждой новой функции не имеет смысла и я решил объединить их в один большой материал. А интересного действительно много.
Уже объявлена дата Veeam V11 Launch Event — 24 февраля. Пока точно неизвестно — это день релиза или же будет громкий анонс, но в любом случае я рекомендую вам присоединиться к этому мероприятию.
В 10-й версии нам представили новую функциональность по бекапу файловых шар. Вещь полезная, но лично мне не нравилась реализация. Да, CFT самого Veeam был хорош, но те же снепшоты через скрипты не самое удобное решение. Было понятно, что функционал будет развиваться и сегодня у нас есть возможность оценить год проделанной работы в этом направлении.
Интеграция с СХД
В Veeam V11 появилась возможность более простой работы с NAS’ами. Если в 10-й версии приходилось настраивать интеграцию со снепшотами фактически руками при помощи скриптов, то теперь этот функционал уже есть из коробки, правда поддерживается пока только с массивами NetApp (Lenovo) на базе ONTAP и Dell EMC Isilon.
У нас появились новые галочки в мастере добавления СХД — их я уже показывал в предыдущей части «V11: агенты«, когда рассказывал про возможность использования снепшотов СХД при бекапе физического Windows сервера. Сегодня у меня развёрнут уже RC и этот мастер получил свой окончательный вид.
Block or file storage for VMware — это то, как мы использовали СХД до 11-й версии, делая снепшот луна, на котором располагалась vmfs.
Block storage for Microsoft Windows — для бекапа Windows агентом.
NAS filer — поддержка файлера.
После этого мы добавляем не просто файловую шару, как это было в 10 версии, а NAS.
Veeam уже имеет интеграцию с СХД, соответственно, знает для какого вольюма необходимо сделать снепшот, сам же делает export policy (для NFS) для себя и забирает данные. Именно такого подхода к бекапу файловых шар с СХД изначально и ждали от Veeam, а теперь остаётся дождаться только расширения списка поддерживаемых СХД, т. к. список NAS Devices состоит всего из двух СХД, что намного меньше, чем для блочного доступа.
При работе с Dell EMC Isilon есть возможность использовать его CFT (Change File Tracking), что конечно же крайне благоприятно влияет на скорость работы. Механизм CFT самого Veeam крайне неплохо справляется со своей задачей, но СХД делает это ещё лучше.
Instant File Share (SMB) Recovery
Veeam уже давно ставит своей основной задачей дать возможность как можно быстрее начать работать с данными в резервной копии в случае проблем с продуктивными системами. Вполне логично было ожидать появления Instant Recovery и для резервных копий шар.
Теперь, при наступлении каких-либо проблем с вашей продуктивной шарой, вы можете запустить Instant Recovery для неё и в кратчайшие сроки дать доступ к файлам вашим пользователям. Причём, если вы используете, например DFS, то это можно сделать вообще прозрачно для пользователей.
Файл бекапа из репозитория монтируется на прокси-сервер с ролью mount server и доступ к данным предоставляется через него. Если у вас несколько шар и к ним предполагается достаточно большое количество запросов, то можно гранулярно для каждой из шар указать разные mount прокси, чтобы распараллелить нагрузку на них.
Если по какой-то причине потеряны ACL, тогда они будут автоматически наследоваться от вышестоящей директории. Если вышестоящей директории нет, то их можно будет назначить в самом визарде при восстановлении.
Но, к сожалению, на сегодняшний день функциональность IR для файловых шар пока довольно сильно ограничена:
- Пока поддерживается только SMB
- Публикуемые шары находятся в режиме read-only
- Нет функционала «миграции в прод», т. е. после публикации шары нам необходимо будет отдельно запустить ещё и процесс восстановления данных
Что ещё интересного нам предлагают в 11-й версии:
- NAS бэкап и дедуп-аплайенсы. Улучшена производительность при бекапе файловых шар на дедуп-аплайнсы. В материалах приводятся примеры на базе HPE StoreOnce, думаю оно же будет справедливо и для DellEMC DataDomain, но на сегодняшний день у меня нет их в лабе, чтобы проверить самостоятельно. Увеличен размер blob-файла с 64Мб до 1Гб, что дало значительное увеличение скорости.
- Meta-extent. Теперь в составе SOBR может быть репозиторий с ролью meta-extent, т. е. предполагается быстрый репозиторий (SSD) для хранения мета-данных и более медленный репозиторий для самих данных. Естественно, этот механизм так же даёт прирост в скорости работы. Примеры снова приводятся на базе HPE StoreOnce, но я не вижу никаких ограничений в том, чтобы использовать эту же схему при бекапах на обычном сервере с дисками. По крайней мере технических ограничений по данному поводу нигде не описано.Но Meta-extent будет работать только при бекапе File share, другим типам джобов оно просто не требуется.
- На вкладке нотификации для File share job у нас появилась возможность создавать CSV файл, в котором будет содержаться список файлов с проблемами с атрибутами файлов или которые были по какой-то причине пропущены во время работы джобы.
- Естественно, для всего этого подвезли и новые PowerShell командлеты.
На сегодня у меня всё. Я думаю, что это была последняя статья из цикла по V11, т. к. до Launch Event осталось всего около 3 недель, RC уже есть и вряд ли вдруг появится что-то ещё новое до релиза. Так что ждём 24 февраля, надеемся, что это будет не просто презентация новой версии, а мы увидим релиз в этот же день. Так что не забывайте регистрироваться и до встречи!
Читайте также: