Комментарии 7
Наш «Кибер Бэкап» является программой-инструментом, и, смею заметить, инструментом неплохим.
Исключительно в сравнении с рубекапом. Акронисом был - акронисом остался.
потом делаем полную резервную копию машины и ставим её на восстановление на втором шасси,
ИИИИ (бадабумс) получаем одинаковые маки и GUID. Потому что sysprep надо было делать - а это надо делать или ансимблом или вмварью, причем там тоде вызов сиспреп
Выход есть: делаем резервную копию машины и восстанавливаем её на новое железо. Свежие ОС семейства Windows имеют собственные средства адаптации к таким ситуациям
Иии получаем синий экран, потому что другой контроллер, и нет там "средств адаптации", если руками предварительно ничего не сделать. Или опять сиспреп.
Делаем всё то же самое, что в прошлый раз, но не для одного АРМа, а для всего отдела, и
2024 год, у кого-то баре метал такой что нужна миграция ?
Наша гипотетическая компания уже дорастает до смелых попыток: в виртуализацию решено переносить и серверы
вм миграшн тулзам лет - 15 ? 20 ?
Можно опять же завести «нулёвые» машины, и пусть белые воротнички к ним привыкают, неча тут капризничать, а можно уже полученные ранее бэкапы рабочих мест развернуть на другой платформе виртуализации, и
И получить геморрой, потому что сетевые карты не те.
Исключительно в сравнении с рубекапом. Акронисом был - акронисом остался.
Тут какое-то противоречие мысли из текста вы видите?
получаем одинаковые маки и GUID
Нет не получаем, абзац про тиражирование на железном шасси.
Иии получаем синий экран
Или не получаем, если всё делаем корректно по мануалу и с использованием нужного инструментария.
2024 год, у кого-то баре метал такой что нужна миграция ?
Вы удивитесь...
вм миграшн тулзам лет - 15 ? 20 ?
Опять же, вы удивитесь количеству сценариев, где одни решения работают, а другие нет.
И получить геморрой, потому что сетевые карты не те.
Или не получить геморрой, потому что всё сделали по мануалу, а не абы как.
Ваши замечания в целом, конечно, справедливы. Для случая, когда миграцией занимается админ-недоучка, по старой админской привычке не читавший мануал перед тем, как начинать что-то делать. И с синдромом утёнка - есть только тот вариант, с которым этот админ знаком лично, а остальные решения не существуют.
Но мы верим, что нашим продуктом пользуются в том числе разумные люди, профессионалы, умеющие выбирать инструмент под задачу и умеющие его корректно применять, сообразно инструкциям и рекомендациям. Инструмент есть, он работает, полно рабочих сценариев - это мы знаем из ежедневной практики и статистики, а значит, кто-то смог успешно решить какие-то свои ИТ-задачи при помощи нашего продукта, а значит, он стал чуточку счастлив, а если счастливы пользователи - счастливы и мы.
После ухода "главного конкурента" (в том же ценовом диапазоне, с близким функционалом) с российского рынка, стали пользоваться Кибер Бэкапом, и сразу столкнулись с "досадными особенностями":
LAN-free backup для VMWare работает только если "Storage node" находится внутри того же кластера vSphere, то есть, если в роли агента резервного копирования с локальным хранилищем используется физический сервер, имеющий доступ к тем же томам, на которых размещаются ВМки, забрать снэпшоты он не может - на данный момент пришлось запихивать агента внутрь кластера виртуализации и презентовать ему (не спрашивайте, как - это отдельный квест, тянущий на небольшую статью) по FC SAS-дисковые полки из резервного ДЦ.
"Динамические группы" для планов резервного копирования есть, но позволяют делать отбор только по очень ограниченному набору признаков, наиболее гибким из которых является "name", но для виртуальной среды это весьма неудобно - например, если имеется кластер на несколько сотен ВМ, часть из которых создаются для тестов, часть работают в боевую, часть являются "файлопомойками", часть обслуживает высоконагруженные БД, часть в домене, часть в DMZ, и т.д., организовать вменяемый план резервного копирования возможно только вручную (у упомянутого "конкурента" можно было группировать машины в различные планы по тэгам - например, пока не проставили тэг "full backup", или "system volume only", ВМ не копируется, а с тэгом, помещается в соответствующий план).
Пару раз возникала неприятная ситуация - при сохранении файлов с сетевого ресурса на LTO-библиотеку, задача зависала, и "отваливалась" по "not responding" более, чем через сутки простоя; да, данная задача в принципе, выполнялась несколько суток из-за объёма данных, но как-то работа с библиотеками выглядит недоделанной, или недодокументированной (не смог найти, как возвращать ленты по истечении срока хранения в пул свободных, да и в остальном больше пришлось "методом тыка" искать решение, нежели по документации).
А так - решение рабочее, пусть и не без странностей.
P.S.: да, по первым двум пунктам пришлось общаться с поддержкой, а по первому, так вообще вести длинную переписку "на американском форуме" (местная поддержка внятного решения не предложила), по третьему - молча страдать, благо задача не высокоприоритетная.
Да, нам есть куда стремиться, на самом деле.
Однако, хотелось бы вас попросить всё-таки не страдать молча, а писать к нам в техническую поддержку. Мы правда стараемся помочь. чем можем, и правда обновляем приоритеты запрашиваемого функционала, чтобы те фича-реквесты, по которым обращаются чаще, можно было подвинуть в очереди на разработку.
В любом случае, спасибо вам за внимание к нашему продукту, оно очень ценно для нас.
хотелось бы вас попросить всё-таки не страдать молча, а писать к нам в техническую поддержку
Ну, когда возникают действительно насущные вопросы, обращаюсь - не сомневайтесь ;-) Но "холодный бэкап" в нашем случае отнюдь не первостепенная задача, так что, раз получилось реализовать хоть как-то - уже хорошо. Вот, когда (если?) решим все острые вопросы, вернёмся и к решению менее насущных проблем. Именно для нас сейчас куда интереснее развитие функционала динамических групп - по ним FR есть, а пока придумываем алгоритмы группировки "по префиксам названия ВМ".
Спасибо большое за ваши комментарии, как раз в проработке у нас тема с тегами для динамических групп. Подскажите, а вы уже попробовали какие-то отечественные платформы виртуализации или пока на VMWare?
У нас на VMWare лицензия бессрочная, поэтому пока сидим на нём. В данный момент несколько сотрудников проходят курсы по "отечественному proxmox" - впечатления двойственные... по крайней мере, "бой" в ближайшее время перемещать не планируем, но "пуркуа бы и не па?", как говорится - я с ним игрался "ещё в мохнатые времена", тогда он был "не очень", но уверен, что за прошедшие годы сильно вырос - возможно, "тест" и "препрод" будем пробовать переместить (обновления VMWare, как-никак, недоступны).
в проработке у нас тема с тегами для динамических групп
К слову, почему именно тэги? Ради совместимости с ушедшим с рынка конкурентом? (вижу только такой стимул) Просто заметил, что работа с "Custom attributes" уже как-то реализована (туда КБ, как минимум, пишет время и результат последнего бэкапа) - если проще (быстрее) реализовать этот путь, пользователи (как минимум, мы) будут только рады - перетащить "тэги" в "атрибуты" можно простейшим скриптом...
Кибер Бэкап как мультитул для различных ИТ-задач