вот вы говорите, что нету запросов про командлет get, но кто в таком исполнении использует «Limit processed per storage snapsho to»? приходится делать делать задания на каждый лун отдельно и шедулить After this job (хотя вы же сами не рекомендуете так шедулить).
Скажите, почему у вас есть коммандлет Set-VBRJobAdvancedBackupOptions, но нету соттветствующего Get-* — иногда приходится перепроверять настройки десятков заданий и это геморно.
Настройки задания РК — Storage — Advanced — Integration — Limit processed per storage snapsho to == какая польза от этой фичи? Мне, например, интереснее такая схема — в задании на закладке Virtual Mashines выбраны датасторы (LUN-ы) с ВМ (к примеру на каждом датасторе по 15 ВМ), тот самый лимит, например 10, берет 10 ВМ с первого датастора, делает им снапшот (потом снапшот луна...) и бэкапит их, далее берет следующие 10 ВМ (5 с первого датастора и 5 со второго) и так далее. А сейчас у вас получается, что делается снапшет 10 ВМ на каждом датасторе (шторм снапшотов по всем лунам задания), а уже следующим этапом пяти ВМ. В общем, интересно чтобы ВМ бэкапились по очереди, как без storage snapshots.
Там описываются варианты схожие с моим и с утилитой из «лабы».
У File Copy, по моему мнению, не хватает функциональности сжатия, дедупликации и инкремента.
Здравствуйте! С наступившим НГ.
У меня маленькое рац.предложение, возможно вы его сможете реализовать:
улучшить функционал «File Copy Job» (интересно для бэкапа writable volumes от vmware app volumes) — на датасторе есть папка с .vmdk файлами персональных слоев пользователей (writable volumes), хотелось бы бэкапить эту папку со сжатием и инкрементами (файлы активных пользователей, если таковые есть на момент задачи, пропускать).
Я в курсе про утилиту labs.vmware.com/flings/app-volumes-backup-utility, но она мне не очень нравится, возможно такой вариант окажется лучше.
Еще хотелось бы, чтобы при восстановлении файлов .vmdk на датастор можно было выбирать тип thin, thick.
спасибо :)
не всегда хороший вариант:
1. восстанавливает только точку полного бэкапа (инкрементальные недоступны);
2. распаковываются файлы ВМ сначала локально, потом их надо выгрузить на сторадж (две операции, для большой ВМ накладно);
3. для большой ВМ может быть быстрее быстро развернуть с нуля новый сервер, импортировать .vbk (.vbm) и быстро запустить Instant VM Recovery (или полное восстановление в одну операцию).
В такой ситуации достаточно иметь во втором ЦОДе второй сервер, на котором будет смонтирован тот же репозиторий. Если навернется перый ЦОД или первый бэкап-сервер, то что-бы экстренно восстановить что-то достаточно импортировать .vbk на втором сервере и восстановить данные. Для дальнейшей работы (пока не будет восстановлен первый) на втором сервере можно накатить бэкап конфигурации VeeamConfigBackup.
Мне вот линуксовый сервер/прокси интересен исходя из экономии Win-лицензии и т.к. у нас на хостах имеются свободные* локальные сторажи, то на них созданы ВМ с линуксом, которые через iSCSI отдают эти свободные* пространства бэкап-серверу под бэкап-копи-репозитории. Так вот неплохо было бы этим ВМ дать еще роль прокси.
Разница замечена и на полных бэкапах и на инкрементах. Больший размер файлов на ReFS заметил уже давно, поначалу разница была небольшой — до 5%, но после последнего обновления (9.5.0.1038) бэкапы на ReFS прибавили в размере. Пробовал форматировать репозиторий (с размером блока 4к и 64к) — без изменений.
Если Fail, то (по умолчанию) будет еще 3 попытки с интервалом 10 минут повторить задачу и только после этого таки запустится следующая задача. Только что простой 30 минут.
ИМХО шедулер не достаточно гибкий, и даже PS-скриптами не всё можно обыграть.
Хотелки:
1.Периодичность Active full и Syntetic full бэкапов вынести из «Advanced» закладки Storage, например, в закладку Virtual mashines задачи бэкапа.
2.На закладке задачи Virtual mashines возможность настройки последовательности с условием а) пока не закончилась текущая очередь — следующую не начинать б) следующую очередь начинать только когда освободятся ресурсы от выполнения текущей очереди. Например (а): очередь формируется из ВМ размещенных на ЛУНе (функция storage snaphots используется), ЛУНов в задании несколько, сценарий — бэкапятся ВМ с ЛУНа 1 (снапшеты ВМ, снапшет ЛУНа, удаление снапшетов ВМ, бэкап, удаление снапшета ЛУНа) и только после окончания бэкапа ВМ с ЛУНа 1 начинается очередь ВМ с ЛУНа 2,…
3.Имея много задач по бэкапу с разными настройками хотелось бы видеть эти «настройки» в табличном виде на заглавной странице Jobs или с помощью PS-скрипта
А есть что-нибудь подобное для установки на железо?
или возможно ли девиртуализировать перенести апплианс на железо?
Интересует не распределенное виртуальное хранилище между несколькими хостами, а именно создание «хранилки» на базе одного сервера. Типа FreeNAS только от более именитых производителей (EMC, HP, ...)
и че? где быстрое резервное копирование?!?
реклама голого сервера, не более того.
есть у Harbor одна проблемка - при перезагрузке не всегда или не все контейнеры стартуют, приходится ручками подталкивать.
или службой:
cat > /etc/systemd/system/harbor.service <<-EOF
[Unit]
Description=Harbor
After=docker.service systemd-networkd.service systemd-resolved.service
Requires=docker.service
Documentation=https://goharbor.io/docs/
[Service]
Type=simple
Restart=on-failure
RestartSec=5
ExecStart=/usr/local/bin/docker compose -f /harbor/docker-compose.yml up
ExecStop=/usr/local/bin/docker compose -f /harbor/docker-compose.yml down
[Install]
WantedBy=multi-user.target
EOF
systemctl enable harbor.service
Настройки задания РК — Storage — Advanced — Integration — Limit processed per storage snapsho to == какая польза от этой фичи? Мне, например, интереснее такая схема — в задании на закладке Virtual Mashines выбраны датасторы (LUN-ы) с ВМ (к примеру на каждом датасторе по 15 ВМ), тот самый лимит, например 10, берет 10 ВМ с первого датастора, делает им снапшот (потом снапшот луна...) и бэкапит их, далее берет следующие 10 ВМ (5 с первого датастора и 5 со второго) и так далее. А сейчас у вас получается, что делается снапшет 10 ВМ на каждом датасторе (шторм снапшотов по всем лунам задания), а уже следующим этапом пяти ВМ. В общем, интересно чтобы ВМ бэкапились по очереди, как без storage snapshots.
У File Copy, по моему мнению, не хватает функциональности сжатия, дедупликации и инкремента.
У меня маленькое рац.предложение, возможно вы его сможете реализовать:
улучшить функционал «File Copy Job» (интересно для бэкапа writable volumes от vmware app volumes) — на датасторе есть папка с .vmdk файлами персональных слоев пользователей (writable volumes), хотелось бы бэкапить эту папку со сжатием и инкрементами (файлы активных пользователей, если таковые есть на момент задачи, пропускать).
Я в курсе про утилиту labs.vmware.com/flings/app-volumes-backup-utility, но она мне не очень нравится, возможно такой вариант окажется лучше.
Еще хотелось бы, чтобы при восстановлении файлов .vmdk на датастор можно было выбирать тип thin, thick.
спасибо :)
1. восстанавливает только точку полного бэкапа (инкрементальные недоступны);
2. распаковываются файлы ВМ сначала локально, потом их надо выгрузить на сторадж (две операции, для большой ВМ накладно);
3. для большой ВМ может быть быстрее быстро развернуть с нуля новый сервер, импортировать .vbk (.vbm) и быстро запустить Instant VM Recovery (или полное восстановление в одну операцию).
Мне вот линуксовый сервер/прокси интересен исходя из экономии Win-лицензии и т.к. у нас на хостах имеются свободные* локальные сторажи, то на них созданы ВМ с линуксом, которые через iSCSI отдают эти свободные* пространства бэкап-серверу под бэкап-копи-репозитории. Так вот неплохо было бы этим ВМ дать еще роль прокси.
Лучше бы сделали серверную часть на линуксе или хотя-бы проксю на линуксе.
Хотелки:
1.Периодичность Active full и Syntetic full бэкапов вынести из «Advanced» закладки Storage, например, в закладку Virtual mashines задачи бэкапа.
2.На закладке задачи Virtual mashines возможность настройки последовательности с условием а) пока не закончилась текущая очередь — следующую не начинать б) следующую очередь начинать только когда освободятся ресурсы от выполнения текущей очереди. Например (а): очередь формируется из ВМ размещенных на ЛУНе (функция storage snaphots используется), ЛУНов в задании несколько, сценарий — бэкапятся ВМ с ЛУНа 1 (снапшеты ВМ, снапшет ЛУНа, удаление снапшетов ВМ, бэкап, удаление снапшета ЛУНа) и только после окончания бэкапа ВМ с ЛУНа 1 начинается очередь ВМ с ЛУНа 2,…
3.Имея много задач по бэкапу с разными настройками хотелось бы видеть эти «настройки» в табличном виде на заглавной странице Jobs или с помощью PS-скрипта
или возможно ли
девиртуализироватьперенести апплианс на железо?Интересует не распределенное виртуальное хранилище между несколькими хостами, а именно создание «хранилки» на базе одного сервера. Типа FreeNAS только от более именитых производителей (EMC, HP, ...)