Veeam disk imported что это
Veeam Backup: миленькие хитрости
В преддверии Нового года я подумал: а не сделать ли скромный, но очень полезный подарок нашим читателям, рассказав про функции, на которые системные администраторы-пользователи Veeam Backup & Replication обычно не обращают внимания, а про некоторые из них даже и не знают? Так родилась эта статья — о том, как использовать Veeam Backup нестандартным способом.
Начну, пожалуй, с известного многим VeeamZIP.
VeeamZIP
VeeamZIP — бесплатный инструмент для создания резервных копий.
В бесплатном Veeam Backup Free Edition возможно забэкапить только одну ВМ за один проход VeeamZIP, в платной же версии Veeam Backup & Replication у VeeamZIP нет никаких ограничений. В результате работы VeeamZIP получается файл, в котором находится полная копия забэкапленной ВМ. Запускается операция VeeamZIP вручную из интерфейса (на закладке Virtual Machines — см. скриншот ниже), командлетой PowerShell (Help, рассказ на хабре) или из vSphere Web Client (если установлен плагин с Veeam Backup Enterprise Manager).
Основное предназначение VeeamZIP: однократное создание независимой переносимой резервной копии.
Quick Migration
Возможность Quick Migration доступна в бесплатной версии. В платном Veeam Backup & Replication она применяется для миграции ВМ, после операции восстановления путем запуска непосредственно из резервной копии — Instant VM Recovery, в случае если, например, VMware Storage vMotion невозможен. Запустить эту операцию также можно со вкладки Virtual Machines.
Но ведь никто не запрещает использовать эту функцию для обычного переноса ВМ в рабочей среде! Спору нет, Storage vMotion хорош тем, что переносит диски ВМ без остановки их работы, но он негативно влияет на производительность основной СХД в момент переноса. А Quick Migration работает аналогично репликации в Veeam Backup & Replication, и влияние на СХД существенно меньше [помечу себе, что надо проверить, срабатывает ли при этой операции I/O Control], но при этом ВМ будет некоторое время недоступна (будет иметь место даунтайм на момент ввода ВМ в паузу, переноса посторонних блоков и вывода машины из паузы). Так что здесь у вас есть выбор: либо штатный ресурсоемкий svMotion без остановки, либо Veeam Quick Migration с меньшим влиянием на продуктив, но приостановкой в работе.
А вообще, закладка Virtual Machines — весьма полезный раздел.
Закладка Virtual Machines
Здесь вы легко можете находить нужные ВМ и, кликая по правой кнопке мыши, добавлять их в существующие задания или создавать с ними новые. Это зачастую проще и нагляднее, чем каждый раз открывать задание на редактирование и добавлять новые ВМ для бэкапа через его свойства.
Соскучились по FastSCP?
Кто помнит про Veeam FastSCP для VMware? Когда-то это был единственный хороший способ копировать данные на датасторы, например, если это ISO-шники или готовые ВМ, образы дисков. Консольный scp копировал очень медленно, а FastSCP был действительно быстрым и бесплатным. Затем его упразднили в пользу бесплатной редакции Veeam Backup. Но! Функция копирования был и остается в Veeam Backup & Replication.
Итак, идем в консоли на закладку Files (Вы её вообще открываете, скажите честно? Нет? Ну и зря!). Там мы сможем найти нужные файлы на любом из зарегистрированных в консоли Veeam серверов: VMware, Linux, Windows (включая хосты Hyper-V, конечно) — и копировать их куда угодно в пределах этих же зарегистрированных серверов через Copy-Paste или Drag’n’Drop. (Заметьте, и с Linux на Windows, и обратно тоже можно.)
Сам процесс копирования, если говорить про Windows/Linux, происходит изнутри ОС. Так что смело добавляйте физические хосты в консоль Veeam Backup & Replication, когда вам необходимо из/в них тоже что-то копировать.
Копирование происходит как есть, т. е. без сжатия и дедупликации. Хотите сжимать файлы для архивации? Наверное, тогда лучше всего подойдут ленты. У них есть встроенная архивация, а у Veeam Backup & Replication есть интеграция с лентами и свой тип задания File to Tape Job.
И еще про закладку Files
На этой закладке есть встроенный текстовый редактор!
И он понимает текстовые файлы в Unix формате:
Так что если вам нужно отредактировать vmx-файл (конфигурация ВМ на платформе VMware) или любой другой конфигурационный файл внутри Linux (да и Windows тоже), то можете смело воспользоваться этим инструментом. По команде «Сохранить» файл будет сохранен там же, откуда он и был открыт (то есть вовсе не надо копировать его себе на диск, чем-то редактировать и потом заливать обратно).
Трюки с vPower
Напомню тем, кто не знает, а тем, кто забыл — расскажу.
vPower — это технология Veeam, предназначенная для получения доступа к данным ВМ, находящихся в резервной копии, без необходимости полного извлечения (разархивирования и регидрации всех данных обратно). На ней построена возможность Veeam Instant VM Recovery для быстрого восстановления доступа к засбоившей ВМ, а также другие возможности, включая виртуальные лаборатории, восстановление файлов «других ОС» (не Windows) и т. д.
Для платформы VMware vSphere используется свой встроенный NFS-сервер (vPower NFS). Принцип его работы следующий. Veeam Backup & Replication регистрирует на хосте ESXi новое хранилище NFS. Затем при восстановлении ВМ извлекает из резервной копии мелкие файлы ВМ — vmx, nvram и другие. При этом вместо файлов дисков (vmdk) создаются файлы-ссылки на них. Далее Veeam Backup регистрирует ВМ в vSphere и дает команду на её загрузку (при включенной соответствующей опции). Когда гипервизор обращается к файлу-диску ВМ за блоком данных, Veeam Backup & Replication извлекает нужный блок из резервной копии и отдает его гипервизору. Так загружается и затем работает ВМ из резервной копии.
Что еще можно сделать с vPower NFS? Идем дальше!
Вот вам шара
Обычно добавление VeeamBackup NFS производится 1 раз на каждый хост ESXi при проведении вышеописанных операций. При повторных операциях перепроверяется, что данное подключение существует, и если вы вручную удалите это подключение (unmount datastore), Veeam Backup & Replication подключит его заново. (Эти диски Veeam Backup сам, по своей доброй воле не удаляет — чтобы сократить время при следующем процессе.) Отключать его, в принципе, не имеет большого смысла, а уж будучи подключенным, он может помочь в других делах. Так, его можно использовать как (внезапно!) NFS шару 🙂 Например, можно туда положить ISO-шник или мигрировать ВМ между хостами ESXi, не связанными общим хранилищем.
Удобно: перенастройте папку для vPower NFS на удобное, доступное для вас место на сервере репозитория (расположение по умолчанию — в %ProgramData% ).
Тогда в эту папку будет проще что-то положить со стороны Windows-машины. А можно и еще расшарить папку — для удобного доступа извне.(Вот тут возникла идея: проверить, как VMware Workstation будет работать с таким диском.)
Подключим NFS ко всем хостам — это можно сделать вручную, запустив процесс восстановления Instant VM Recovery на каждом хосте, а затем отменив восстановление (лично мне это не очень удобно, особенно при большом количестве хостов). Другой вариант — в консоли VMware на каждом хосте добавить NFS с данными сервера, как показано здесь (но это также делается вручную):
Можно сделать то же самое через командлет New-Datastore (из powercli). Например, вот так:
Ну, а если вы хотите удалить все NFS-датасторы, оставшиеся от Veeam Backup & Replication, то для этой цели есть скрипт.
И вместо заключения — предновогоднее пожелание
Иногда мы даже не задумываемся, что ПО, которым мы пользуемся каждый день, обладает возможностями, на которые мы не обращаем внимания — а они могут помочь нам в других, не совсем «своих» повседневных задачах.
Всем известно, что в системном администрировании большую часть времени отнимают рутинные задачи. Подумайте над тем, как автоматизировать их с помощью тех средств, которые у вас уже есть под рукой, и вы наверняка найдете, как использовать имеющиеся программы по их не совсем прямому назначению. Think, так сказать, different…
Политики хранения Veeam B&R — прочтите перед апгрейдом
Долгожданный релиз версии 11 нашего флагманского продукта заставил меня снова взяться за перо. Такова цена работы с активно развивающимся софтом – не успеваешь с чувством глубокого удовлетворения закрыть Word, как все написанное начинает устаревать и Сизиф вновь должен толкать свой камень в гору на общее благо.
За время моей работы в Veeam я пережил уже семь крупных апдейтов. Чтобы быть во всеоружии, еще до релиза по каждому я вел конспект, куда записывал все изменения и нововведения. Могу сказать, что по этой нехитрой метрике v.11 побил все рекорды, обогнав даже юбилейную десяточку. Уверен, о новых фичах будет сказано еще многое, а я же продолжу развивать тему этой серии и расскажу, какие изменения следует ожидать с точки зрения ретеншена.
Backup copy job
Если вы хорошо изучили принцип ретеншена в BCJ, то вас может ждать некоторое разочарование – v.11 сильно перекроила процесс в сторону единообразия с обычным заданием бэкапа. Если же вы не обеспокоились изучением этого замысловатого предмета, то все равно рекомендую прочитать первую часть этой серии постов, из солидарности к коллегам и потому что уже сказанное там в данной статье я повторять не буду.
Начну с простого. Что не изменилось:
Если архивирование методом GFS не включено, то изменений нет, задание все так же будет работать в бесконечно-инкрементальном режиме, и количество точек будет точно соответствовать установленному ретеншену.
Если используется режим периодической копии с опцией “Read entire point” (в режиме немедленной копии эта опция все также отсутствует), то фундаментальный принцип не изменится – задание продолжит работать в инкрементальном режиме с периодическими полными бэкапами в дни GFS.
Самые значительные изменения произошли с синтетическим GFS. Откроем настройки задания на уже известном нам шаге:
Как видите, меню претерпело сильные изменения. Хорошие новости в том, что оно вполне может быть вам уже знакомо – оно точь-в-точь повторяет аналогичное меню из настроек обычного задания. Унификация – пожалуй, главная идея изменений. Так проще разработчикам, клиентам и, самое главное – нам, техподдержке.
Разберем подробнее каждое изменение.
Расписание. Если в прошлой версии момент создания каждой точки устанавливался четко на определенный день, то теперь задание следует «интервальной» системе, уже знакомой по обычным заданиям.
С недельным бэкапом все просто – он создается точно в назначенный день (причем как при «активном», так и при «синтетическом» GFS, но об этом чуть позже).
Месячный GFS имеет только два варианта расписания: в первую неделю месяца и последнюю. Если у вас включен недельный интервал, то задание не будет создавать отдельную месячную точку GFS и просто даст 2 флага подходящей недельной точке.
Возьмем такой пример: задание запускается в первый раз в понедельник и настроено создавать недельные точки в пятницу и месячные точки в первую неделю месяца. В первый день будет создан VBK, который будет относиться к базовой цепочке и не будет иметь флагов GFS (в свойствах бэкап сета такая точка отмечается буквой R). В пятницу будет создан недельный GFS (W). Он же будет помечен месячным флагом (M), потому что он подходит по расписанию. В следующую неделю в пятницу будет создан недельный GFS и так далее.
Если же включен только месячный интервал, то GFS точка будет создаваться в первый день первой или последней недели месяца. Если этот день был пропущен – в следующий, и так далее до конца недели. Если была упущена вся неделя, то поезд ушел до следующего месяца.
Годовой GFS позволяет выбрать месяц, когда будет создана точка. Он также работает в связке с месячным интервалом. Если он включен, то подходящая точка получит сразу оба флага. Если нет, то годовая точка будет создана в первый день месяца с повтором попытки во второй день, и так далее до конца месяца.
Квартальные GFS точки. Их тут нет. Их не было в обычных заданиях, когда туда был добавлен GFS ретеншен, поэтому их нет и тут. Первопричина – почти полное отсутствие пользовательского интереса к квартальному GFS, поэтому смею надеяться, что особого негатива это решение не вызовет.
Единица счисления. Если раньше ретеншен исчислялся количеством точек, то теперь он исчисляется количеством недель, месяцев и лет для соответствующего интервала. Причина изменений – появление режима неизменяемости данных (immutability) для защищенных Linux репозиториев и объектных хранилищ. Изменения в них блокируются на определенное время, соответственно, удобнее, когда и ретеншен, и блокировка используют единую систему счисления.
Синтетический GFS. Еще одно важное изменение. Если раньше синтетический метод создавал GFS точку с солидным лагом (повторюсь, в первой части все расписано), то теперь она создается точно в день GFS. Таким образом, теперь и синтетический GFS использует старый-добрый инкрементальный метод с периодическим полным бэкапом. В установленный день задание скопирует инкрементальную точку, после чего синтезирует из нее полный бэкап. Если же инкрементальная точка по какой-то причине создана не будет, то задание использует наиболее близкую точку из имеющихся на репозитории. В предыдущей статье я также упоминал, что BCJ не учитывает в расчете ретеншена точки, помеченные флагами GFS. Теперь эту особенность убрали, так что все стало совсем-совсем как в обычном задании.
Рассмотрим пример. Задание хранит только недельные GFS точки, создает их каждый вторник, работает ежедневно и настроено хранить 8 точек в основной цепи. Ретеншен отработает, когда «активная» часть наберет 8 точек, включая GFS. При ретеншене будут удалены только инкременты, недельный GFS останется и будет удален отдельно когда истечет GFS ретеншен.
Миграция
Довольно сложный момент в этой истории – это переход от старого метода к новому после апгрейда. Разработчики постарались придумать правила, которые позволяют получить после апгрейда максимально схожие настройки. Но все же не будет лишним проверить результат и поправить, если что не так. В целом правила такие:
Месячный GFS
Расписание с первого понедельника месяца по воскресенье второй недели становится первой неделей месяца.
Расписание с 1 по 15 число месяца также становится первой неделей.
Расписание с третьего понедельника месяца по последнее воскресенье становится последней неделей.
Расписание с 16 по 31 число также становится последней неделей.
Иными словами, если день GFS выпадал на первую половину месяца, то он переносится на первую неделю. Если на вторую половину месяца – то на последнюю неделю.
Квартальный GFS
Квартальное расписание будет пересчитано на месячное по обменному курсу 1 квартальная точка = 3 месячных. Если до этого месячное расписание не использовалось, то оно будет включено. Если уже использовалось – то ретеншен будет увеличен до нужного количества. Конечно, такая математика приведет к увеличению потребления места, но бэкапов всегда лучше хранить больше, чем меньше.
Годовой и недельный GFS
Тут изменения минимальны. Настройки годового GFS становятся менее гранулярными, поэтому будет выставлен только соответствующий старому расписанию месяц. В недельном же никаких изменений не требуется.
На что обратить внимание
При апгрейде есть шанс потерять будущую GFS точку. Рассмотрим такой пример. Задание выставлено хранить 5 точек и создавать недельный GFS каждую среду синтетическим методом.
Такая цепочка может выглядеть так:
Есть какое-то количество недельных GFS точек и основная цепочка. До v.11 точки GFS создавались с лагом, т. е. в цепочке уже есть инкремент, который в будущем станет GFS точкой (механизм был расписан в первой части).
Переход на v.11 меняет режим работы, мерджи прекращаются. Задание продолжить создавать инкременты, а в следующую среду создаст GFS точку. Далее следует обычная логика ретеншена задания с периодическими полными бэкапами – когда будет создано 4 инкремента к новой точке, старая цепочка удаляется, вместе с потенциальной GFS точкой.
Если очень важно, чтобы все GFS точки были на месте, выход я вижу один – перед апгрейдом временно уменьшить ретеншен основной цепочки до минимума чтобы заставить задание смерджить инкременты и создать «висящие» GFS точки. Благо, такую операцию нужно провести только один раз.
Если у вас используется только годовой GFS. До v.11 вполне нормально было настроить задание хранить короткую основную цепочку и создавать только годовые GFS точки синтетическим методом. В v.11 это приведет к огромному накоплению инкрементов в основной цепочке, потому что это станет аналогичным созданию инкрементального задания с полным бэкапом раз в год. При запуске раз в день такое задание создаст 364 инкремента полному бэкапу + установленное ретеншеном количество точек, прежде чем старая часть цепочки сможет быть удалена.
Решение – держать хотя бы 1 недельную GFS точку. Количество точек в основной цепочке все равно несколько увеличится, но не так критично.
Будьте более внимательными к регулярной работе заданий. Как было сказано, ретеншен GFS точек теперь считается по времени, а не по количеству. В общем случае разницы нет: скажем, если недельные GFS точки создаются регулярно, то можно сказать, что мы храним 5 недельных точек или же что мы храним каждую недельную точку в течение 5 недель – конечный результат одинаковый. Но есть и отличие – что, если задание работает нерегулярно? В 11 версии хранение GFS точки не зависит от создания последующих точек. Прошел срок – и точка будет удалена, даже если новые точки не были созданы. Таким образом, ретеншен стал более предсказуемым, но и требует большей внимательности к работе задания.
Периодическая очистка GFS точек
Этот раздел продолжает тему GFS, но стоит несколько особняком, поэтому я решил его рассмотреть отдельно.
До v.11 при удалении задания бэкап сет переносился в категорию Disk (Imported). Сюда же помещались и настоящие импортированные бэкап сеты. Такое смешение было не очень интуитивным, поэтому в v.11 для бэкап сетов, потерявших свои родительские задания, были созданы отдельные разделы, помеченные как (Orphaned). На скриншоте ниже я попытался показать все многообразие категоризации бэкапов:
Как видите, их два – Disk (Orphaned) и Object Storage (Orphaned). С первым все ясно, во второй же попадают точки, выгруженные на объектное хранилище.
При чем же здесь GFS? А при том, что даже если бэкап сет попадает в (Orphaned) категорию, ретеншен для GFS точек не перестает работать. Для обычных точек – да. А вот если на полном бэкапе есть флаг GFS, то B&R сначала подождет, пока флаг будет снят после истечения срока хранения, потом проверит, есть ли завязанные на него инкременты. Если таких нет – то точка будет вычищена. Если вам нужно, чтобы бэкап сет оставался неизменным, вместо удаления задания кликните правой кнопкой по бэкап сету и выберите “Remove from configuration”. После этого кликните правой кнопкой по репозиторию и выберите “Rescan”. Бэкап сет будет импортирован и помещен под категорией (Imported).
Защищенный репозиторий Linux и режим неизменяемости (immutability)
Гонка вооружений в сфере защиты данных идет полным ходом: пока нехорошие люди в худи и темных очках пытаются не дать пользователям воспользоваться бэкапами, наши разработчики придумывают все новые способы эти бэкапы защитить.
Одной из новинок v.11 стал Linux репозиторий с повышенной защищенностью. Его фишка – возможность защитить цепочки от манипуляций любым способом, кроме разве что физического при помощи тяжелых предметов.
Я не буду подробно рассматривать устройство самого репозитория, скажу лишь, что он требует наличия постоянного транспортного агента на борту (при переходе на v.11 с предыдущей версии для его установки нужно прокликать через свойства репозитория). Кроме того, визард вам будет очень настойчиво рекомендовать использовать одноразовые реквизиты, которые будут использованы единожды для установки транспортного агента, а затем удалены.
Весь новый функционал сводится вот к этой настройке:
Время окончания неизменяемости можно посмотреть в свойствах бэкап сета в колонке Immutable until:
3 самые нижние точки относятся к закрытой цепочке. После создания нового VBK их дата окончания неизменяемости уже не обновляется, но и флаг снят не был. Затем идет новая цепочка, с уже несколько обновленной датой. Особняком стоит VBK с GFS флагом, у него свои правила.
Так как же «неизменяемость» влияет на работу ретеншена? Эту настройку следует учитывать, потому что неизменяемые точки не могу быть удалены по ретеншену. Возьмем пример, когда из-за настроек может возникнуть конфликт: задание работает каждый день с полным бэкапом в понедельник и настроено хранить 7 точек. Постоянным читателям не составит труда подсчитать, что цепочка достигнет 14 точек, после чего старая «подцепочка» будет удалена. Теперь добавим к этому неизменяемость в течение 10 дней.
Теперь, когда цепочка накопит 14 точек и пора уже будет применять ретеншен, в статистике задания появится безапелляционное сообщение:
Some backups cannot be deleted according to the retention policy, because they are immutable
В итоге ретеншен будет применен только после окончания неизменяемости для старой части, когда в сумме в цепочке будет уже 17 точек:
Вывод: при расчете ретеншена и вместимости репозитория, учитывайте, что Immutability может влиять на ретеншен в сторону удлинения цепочки.
Коротко об остальном
Прощай, трансформ! Как и ожидалось, в дивном новом мире не нашлось места для странной опции Transform into rollbacks. Расстались мягко: если она была включена до апгрейда, то так и останется. Но в новых заданиях вы ее не найдете. И к лучшему.
Catalyst copy. Фича появилась в v.10 и явной настройки ретеншена не имела – по умолчанию копии точек удалялись после удаления оригиналов из сорсного StoreOnce, если с момента создания точки прошел 21 день. Теперь эта настройка появилась в интерфейсе (см. ниже). При этом опцию можно отключить совсем, тогда копия цепочки будет соответствовать сорсу 1:1.
Портирование кода из обычного задания в BCJ привело к изменению в логике работы репозиториев с ротацией дисков. Раньше при использовании виндового репозитория BCJ держала независимую цепочку на каждом диске, и выставленный ретеншен считался для каждого диска (т. е. ретеншен 5 точек означал 5 точек на каждом диске). В v.11 цепочки все еще независимые, но ретеншен считается по всем дискам вместе (5 точек значит 5 точек на всех дисках). Если заметите, что при смене диска задание внезапно удаляет всю цепочку – это оно. Чтобы избежать потерь, выкрутите ретеншен повыше.
В v.10 тейповые задания считали, что BCJ — это бесконечно-инкрементальное задание, а значит, для него всегда нужно создавать виртуальный синтетический бэкап. В v.11 все работает согласно законам логики: если у BCJ выключен GFS, то это бесконечно-инкрементальная цепочка, и для нее копия на ленту будет создавать виртуальную синтетику. Если GFS включен, то включен и периодический полный бэкап, а значит, виртуальна синтетика создаваться не будет.
У BCJ теперь тоже есть ретеншен по дням. Минимальный ретеншен составляет 2 дня, но учтите, что минимальное количество точек в цепочке в любом случае будет равно 3.
Заключение
В прошлый раз я опрометчиво объявил, что о ретеншене мне сказать больше нечего. Не буду совершать ту же ошибку, хотя надеюсь отойти от этой темы хотя бы до следующей версии. Если у вас есть предложения, можете написать, чем можно заполнить этот промежуток времени. Если нет – то до встречи в v.12, где нам наверняка будет что обсудить.