Всем привет.
Недавние статьи на Хабре Импортозамещение на практике. Часть 1. Варианты и Не долго музыка играла… или как ОС Эльбрус так и не стала свободной не оставили меня равнодушным. Я решил поизучать этот вопрос в ключе задачи резервного копирования. Тем более, что в этой статье продукты Veeam Software упоминаются, а значит, вопрос может быть актуальным именно в ключе импортозамещения.
первоисточник изображения
Первым делом я решил скачать ОС «Эльбрус», а точнее — только доступный дистрибутив для архитектуры x86_64, посмотреть, как он устроен, и попробовать поставить на него Veeam Agent for Linux. Желающих узнать, что из этого получилось, прошу под кат.
Итак, маленькое отступление, а то вдруг кто-то не знает. «Эльбрус» — это такой процессор с довольно специфичной системой команд. Помимо него, есть программное обеспечение ОС «Эльбрус». И — вопреки распространенному заблуждению — для работы ОС «Эльбрус» не обязательно иметь аппаратный комплекс на базе процессора Эльбрус. Есть «PDK «Эльбрус» для x86» — собственно, он и появился в открытом доступе в виде установочного диска. Кстати, там есть сноска «PDK — platform development kit, набор разработчика» — отлично, значит, там есть как минимум компилятор.
Ещё одно маленькое вынужденное отступление. Дело в том, что я когда-то имел дело и с отечественным ПО, таким как «МСВС» и ОСРВ «Багет». Был опыт по работе и с отечественной элементной базой, в том числе и с процессором от МЦСТ. Поэтому со всей ответственностью могу сказать, что есть в этой области определённая специфика и, как раз её я постараюсь в статье не касаться. Когда ну прям очень захочется — буду ставить тэг [TBD]. Так что постараемся обойтись без откровенного троллинга и банальных стонов. В конце концов российскую оборонку и госструктуры нужно понять. Страна большая — бюджетмал.. [TBD].
Нулевой этап — качаем. Примечательно, что новость о том, что ОС «Эльбрус» стал доступной, вызвала резонанс, да такой, что сервер раздачи лёг. [TBD] Спасибо Yandex и тому инженеру, который догадался переложить его туда. Так что скорость закачки радует.
Первый этап — установка. Ставил я на первый попавшийся свободный для бесплатного использования гипервизор. Выделил два ядра, пару гигов ОЗУ, 32 Мб на видео (там ведь будет графический интерфейс, подумал я). Дисочек как обычно — 32 Гб.
Запустил инсталляцию. Инструкцией по установке я не пользовался, так что прокомментировать её не смогу. Интерфейс установки TUI — сурово-минималистический.
Ну и отлично, без мышки, значит, обойдёмся.
Со следующим окном я справился со второй попытки. Почему бы при инсталляции с диска не выбрать по умолчанию устройство sr0 [TBD]?
Выбираем источник CD-ROM, едем дальше.
Выбирая часовой пояс, я неожиданно понял, что система использует процесс загрузки init, и работаю я из TTY0.
ОК, значит отнесём «Эльбрус» к сообществу староверов[TBD]. В принципе, это хорошо: не нужно просить исходники, чтобы посмотреть, как отрабатывает процесс загрузки, так как всё на скриптах.
Остальное почти неважно: ставим всё и соглашаемся. Попутно узнаём, что ядро используется 3.14.79-13.84. Хм, а в Debian 7 было 3.2 [TBD].
Далее выбираем разбиение диска на разделы по умолчанию и… Видим предупреждение:
Мда, как-то плохо автоматическая разметка справилась с диском в 32 гига. Диск менять я не стал, прошёл квест с ручной разметкой диска в стиле «всё в одном». Пришлось ставить ext3, так как /boot не мог быть в ext4.
Система встала без происшествий.
Второй этап — поиск альтернатив.
Покопавшись с содержимым второго диска, я понял, что это репозитарий с доп. пакетами. А глянув в /etc/apt/sources.list, сообразил, что монтировать его нужно в /mnt/cdrom. Зато /etc/os-release я не нашёл. Но есть /etc/mcst-version с содержимым 3.0-rc36. 3.0 — это, наверное, версия — вроде сходится, а вот rc36? В общем, распознать этот дистрибутив классическим путём стороннему ПО скорее всего не удастся.
В рутовом разделе в глаза бросается директория /mcst, а там с замиранием сердца я обнаружил /mcst/backup. То есть средство для резервного копирования есть, причём встроенное в систему! «Отлично», — подумал я, — «Посмотрим как это работает!»
Оказалось, что есть bash-скрипт /mcst/bin/backup размером в 4Kб, который обеспечивает копирование файлов. По умолчанию — в директорию /mcst/backup. В исходнике я ожидал увидеть команду rsync, но в дефолтной конфигурации его нет. Скрипт выполняет просто копирование файлов. Команда выглядит как-то так:
Хотя, может я чего не понял? Может, кто в комментах сможет пояснить: как этот скрипт обеспечивает безопасное и надёжное резервирование данных? [TBD]
rsync, кстати, есть в доп. репозитарии. Версия 3.1.3. Я думаю, использование rsync — это всё-же лучшая альтернатива приложению /mcst/bin/backup.
Далее я решил поставить свеженький Veeam Agent for Linux. Кто-то спросит: «А при чём тут Veeam и импортозамещение?» Да, в реестре его нет, но он сертифицирован ФСТЭК, а значит, при отсутствии альтернатив его можно использовать. Уделив минут пятнадцать на альтернативы из реестра, мне удалось найти 3 ссылки по слову «backup» (ни одной, относящейся к моему вопросу, на слово «резерв»). Глубоким анализом этих программ я не занимался — потому не буду пытаться судить, насколько они подходят для резервного копирования машин под ОС Linux. Кому надо — сам сделает вывод и поделится им в комментах.
Этап третий — установка Veeam Agent for Linux.
Итак, Veeam Agent for Linux состоит из двух пакетов: модуля ядра veeamsnap (кстати, исходник тут) и проприетарного user-space кода в виде пакета veeam.
С установкой модуля ядра возникла одна маленькая проблема — отсутствие пакета dkms. Это такой сервис, который позволяет собирать модули ядра из исходников. Как правило, он есть на всех deb дистрибутивах. Пришлось его скачать из стороннего deb репозитария. Одно порадовало — пакет не зависит от архитектуры, так что встал как родной. Почему его не внесли в список доступных пакетов, точнее, не разработали [TBD]? Возможно, предполагается, что никто не должен собирать и запускать всякие не МЦСТ модули ядра. Тут правда есть неувязочка — так как linux-headers есть. То есть, модуль, при желании, можно собрать руками и запускать при старте машины скриптом. Я думаю частых обновлений от МЦСТ ждать не стоит [TBD].
«OK, модуль встал — самое сложное позади», — подумал я… Пакет veeam для deb репозитария есть для платформы amd64, а у ОС «Эльбрус» платформа x86_64 [TBD]. Разница, конечно, только в названии, но эта разница делает практически все пакеты из сторонних deb репозитариев несовместимыми с ОС «Эльбрус». Устраняется это досадное недоразумение элементарно: достаточно разобрать пакет, поправить информацию об архитектуре и собрать обратно. Как это сделать нагуглилось моментально.
Другая проблема — зависимости. Нужные файлы вроде есть, а вот пакетов нет. Сложилось впечатление, что имена пакетов отличаются он «импортных аналогов». Возможно, библиотеки по-другому объединены в пакеты. Я не стал глубоко вдаваться в подробности, убрал почти все зависимости, и установка пошла.
Следом всплыли проблемы с кодом старта сервиса. Не оказалось скрипта /lib/init/vars.sh. Почему-то «Эльбрус» обходится без него, так что уберём и мы. Далее пришлось заменить функцию вывода сообщений: не оказалось функций log_daemon_msg и log_end_msg. Покопавшись в файле /lib/lsb/init-functions, я нашёл функцию log_success_msg — нам сгодится для экспериментов. Кстати, в файле /lib/lsb/init-functions строка "# Source SuSE`s rc functions" в начале файла [TBD].
После такой вот грубой обработки пакета напильником бэкап entire-machine на NFS-шару успешно запустился. Маунт бэкапа тоже прошёл успешно. Так что, я полагаю, для резервного копирования машины с PDK «Эльбрус», скачанной за «просто так» без всяких обязательств, Veeam Agent for Linux точно подойдёт. Даже после всех доработок напильником.
Конечно, формально дистрибутив ОС «Эльбрус» не поддерживается, так как не входит в перечень поддерживаемых. Кроме того, Veeam Agent for Linux на нём не тестировался отделом QA, так что тех. поддержки нет (по крайней мере на момент публикации статьи).
Надеюсь, статья будет полезной тем, кто пытается реализовать приказ №334 от 29.06.2017. Мои вам… [TBD].
Недавние статьи на Хабре Импортозамещение на практике. Часть 1. Варианты и Не долго музыка играла… или как ОС Эльбрус так и не стала свободной не оставили меня равнодушным. Я решил поизучать этот вопрос в ключе задачи резервного копирования. Тем более, что в этой статье продукты Veeam Software упоминаются, а значит, вопрос может быть актуальным именно в ключе импортозамещения.
первоисточник изображения
Первым делом я решил скачать ОС «Эльбрус», а точнее — только доступный дистрибутив для архитектуры x86_64, посмотреть, как он устроен, и попробовать поставить на него Veeam Agent for Linux. Желающих узнать, что из этого получилось, прошу под кат.
Итак, маленькое отступление, а то вдруг кто-то не знает. «Эльбрус» — это такой процессор с довольно специфичной системой команд. Помимо него, есть программное обеспечение ОС «Эльбрус». И — вопреки распространенному заблуждению — для работы ОС «Эльбрус» не обязательно иметь аппаратный комплекс на базе процессора Эльбрус. Есть «PDK «Эльбрус» для x86» — собственно, он и появился в открытом доступе в виде установочного диска. Кстати, там есть сноска «PDK — platform development kit, набор разработчика» — отлично, значит, там есть как минимум компилятор.
Ещё одно маленькое вынужденное отступление. Дело в том, что я когда-то имел дело и с отечественным ПО, таким как «МСВС» и ОСРВ «Багет». Был опыт по работе и с отечественной элементной базой, в том числе и с процессором от МЦСТ. Поэтому со всей ответственностью могу сказать, что есть в этой области определённая специфика и, как раз её я постараюсь в статье не касаться. Когда ну прям очень захочется — буду ставить тэг [TBD]. Так что постараемся обойтись без откровенного троллинга и банальных стонов. В конце концов российскую оборонку и госструктуры нужно понять. Страна большая — бюджет
Нулевой этап — качаем. Примечательно, что новость о том, что ОС «Эльбрус» стал доступной, вызвала резонанс, да такой, что сервер раздачи лёг. [TBD] Спасибо Yandex и тому инженеру, который догадался переложить его туда. Так что скорость закачки радует.
Первый этап — установка. Ставил я на первый попавшийся свободный для бесплатного использования гипервизор. Выделил два ядра, пару гигов ОЗУ, 32 Мб на видео (там ведь будет графический интерфейс, подумал я). Дисочек как обычно — 32 Гб.
Запустил инсталляцию. Инструкцией по установке я не пользовался, так что прокомментировать её не смогу. Интерфейс установки TUI — сурово-минималистический.
Ну и отлично, без мышки, значит, обойдёмся.
Со следующим окном я справился со второй попытки. Почему бы при инсталляции с диска не выбрать по умолчанию устройство sr0 [TBD]?
Выбираем источник CD-ROM, едем дальше.
Выбирая часовой пояс, я неожиданно понял, что система использует процесс загрузки init, и работаю я из TTY0.
ОК, значит отнесём «Эльбрус» к сообществу староверов[TBD]. В принципе, это хорошо: не нужно просить исходники, чтобы посмотреть, как отрабатывает процесс загрузки, так как всё на скриптах.
Остальное почти неважно: ставим всё и соглашаемся. Попутно узнаём, что ядро используется 3.14.79-13.84. Хм, а в Debian 7 было 3.2 [TBD].
Далее выбираем разбиение диска на разделы по умолчанию и… Видим предупреждение:
Мда, как-то плохо автоматическая разметка справилась с диском в 32 гига. Диск менять я не стал, прошёл квест с ручной разметкой диска в стиле «всё в одном». Пришлось ставить ext3, так как /boot не мог быть в ext4.
Система встала без происшествий.
Второй этап — поиск альтернатив.
Покопавшись с содержимым второго диска, я понял, что это репозитарий с доп. пакетами. А глянув в /etc/apt/sources.list, сообразил, что монтировать его нужно в /mnt/cdrom. Зато /etc/os-release я не нашёл. Но есть /etc/mcst-version с содержимым 3.0-rc36. 3.0 — это, наверное, версия — вроде сходится, а вот rc36? В общем, распознать этот дистрибутив классическим путём стороннему ПО скорее всего не удастся.
В рутовом разделе в глаза бросается директория /mcst, а там с замиранием сердца я обнаружил /mcst/backup. То есть средство для резервного копирования есть, причём встроенное в систему! «Отлично», — подумал я, — «Посмотрим как это работает!»
Оказалось, что есть bash-скрипт /mcst/bin/backup размером в 4Kб, который обеспечивает копирование файлов. По умолчанию — в директорию /mcst/backup. В исходнике я ожидал увидеть команду rsync, но в дефолтной конфигурации его нет. Скрипт выполняет просто копирование файлов. Команда выглядит как-то так:
cp -rpdx <file backup> <file>
Целиком файл /mcst/bin/backup тут
Сразу предупреждаю, что для полного понимания одного этого скрипта недостаточно. Он тянет функции из /mcst/bin/source, который представляет собой что-то типа библиотеки функций. Его я приводить не стал (44KB).
#!/bin/bash
unalias -a
set +vx
source $(dirname $0)/source
[[ $? != 0 ]] && exit 1
OPTIONS="hvcdrRil:L:"
usage()
{
echo "Usage: $PROG_NAME [-$OPTIONS] [backup]"
echo " h - this help"
echo " v vv vvv - verbose, very verbose, extremly verbose"
echo " c - create backup"
echo " d - diffs backup and system"
echo " r - recovery system"
echo " R - remove backup"
echo " i - prompt before backup removing"
echo " l list - additional backup files list"
echo " L list - global backup files list"
echo " backup - backup directory, default /mcst/backup/backup"
}
init_prog()
{
typeset flg=0
while getopts $OPTIONS opt
do
case $opt in
h ) usage; exit 0;;
v ) (( verbose = verbose + 1 )); set_verbose;;
c ) flg=1; c_flg=1;;
d ) flg=1; d_flg=1;;
r ) flg=1; r_flg=1;;
R ) flg=1; R_flg=1;;
i ) i_flg=1;;
l ) l_flg=1; list_arg="$list_arg $OPTARG";;
L ) L_flg=1; LIST_arg="$LIST_arg $OPTARG";;
* ) usage "Invalid option"; exit 1;;
esac
done
set_verbose
check_su
init_variables
shift $((OPTIND-1))
if (( $# > 1 ))
then
echo_fatal "invalid arguments number, exp 0|1, act $#"
exit 1
fi
[[ $# = 1 ]] && BACKUP=$1
echo "Backup directory is $BACKUP"
if [[ $L_flg = 1 ]]
then
backup_list="$LIST_arg"
elif [[ $c_flg != 1 && $R_flg != 1 ]]
then
get_output_cmd "cat $BACKUP/$BACKUP_LIST_NAME"
backup_list="$output_cmd"
else
get_output_cmd "get_backup_list"
backup_list="$output_cmd"
fi
if [[ $l_flg = 1 ]]
then
backup_list="$backup_list $list_arg"
fi
if [[ $flg = 0 ]]
then
if [[ -d $BACKUP ]]
then
ls -laR $BACKUP
else
echo_info "Cannot access $BACKUP"
fi
echo "backup_list=$backup_list"
exit 0
fi
### echo "Backup list: $backup_list"
}
create_file()
{
typeset f=$1 fr=$2
typeset fb
[[ -z $fr ]] && fr=$f
fb=${f#/}
fb=$BACKUP/$fb
xcmd="rm -rf $fb"
set_cmd "$xcmd"
run_cmd
xcmd="mkdir -p $fb"
set_cmd "$xcmd"
run_cmd
if [[ -a $fr ]]
then
xcmd="cp -rpdx $fr $fb/file"
set_cmd "$xcmd"
run_cmd
xcmd="touch $fb/create"
set_cmd "$xcmd"
run_cmd
else
xcmd="touch $fb/delete"
set_cmd "$xcmd"
run_cmd
fi
}
diff_file()
{
typeset f=$1
typeset fb
fb=${f#/}
fb=$BACKUP/$fb
if [[ -f $fb/delete ]]
then
echo_info "$f absent"
elif [[ -f $fb/create ]]
then
# echo "state: create $f"
if [[ ! -a $f ]]
then
echo_info "cannot access $f"
else
xcmd="diff -r $f $fb/file"
echo "$xcmd"
set_cmd "$xcmd" "" "0 1 2"
run_cmd
fi
else
echo_fatal "wrong $f backup"
exit 1
fi
}
recovery_file()
{
typeset f=$1
typeset fb
fb=${f#/}
fb=$BACKUP/$fb
if [[ ! -a $fb ]]
then
echo_fatal "cannot access $fb"
exit 1
fi
xcmd="rm -rf $f"
set_cmd "$xcmd"
run_cmd
if [[ -f $fb/delete ]]
then
:
elif [[ -f $fb/create ]]
then
xcmd="cp -rpdx $fb/file $f"
set_cmd "$xcmd"
run_cmd
else
echo_fatal "wrong $fb backup"
exit 1
fi
}
remove_backup()
{
echo "Remove backup"
if [[ ! -d $BACKUP ]]
then
echo_info "Cannot access $BACKUP"
return
fi
if [[ ! -f $BACKUP/$BACKUP_LIST_NAME ]]
then
echo_fatal "$BACKUP_LIST_NAME absent, remove backup manually"
exit 0
fi
answer=
if [[ $i_flg = 1 ]]
then
echo -n "Remove $BACKUP directory (yes/...)?"
read answer
else
answer=yes
fi
if [[ $answer = yes ]]
then
xcmd="rm -rf $BACKUP"
set_cmd "$xcmd"
run_cmd
fi
}
recovery_backup()
{
echo "Recovery system from $BACKUP"
for f in $backup_list
do
get_output_cmd "get_mount_point $f"
mnt=$output_cmd
get_output_cmd "is_ro_mounted $mnt"
mnt=$output_cmd
if [[ ! -z $mnt ]]
then
remount_rw_fs $mnt
fi
recovery_file $f
if [[ ! -z $mnt ]]
then
remount_ro_fs $mnt
fi
done
echo "The system is ready, reboot the system manually"
}
create_backup()
{
echo "Create backup"
xcmd="mkdir -pm0777 $BACKUP"
set_cmd "$xcmd"
run_cmd
for v in $backup_list
do
f=${v%%:*}
backup_list2="$backup_list2 $f"
fr=${v#*:}
create_file $f $fr
done
echo "$backup_list2" >$BACKUP/$BACKUP_LIST_NAME
}
diff_backup()
{
echo "Diffs system and backup"
if [[ ! -d $BACKUP ]]
then
echo_fatal "cannot access $BACKUP"
exit 1
fi
for f in $backup_list
do
diff_file $f
done
}
main()
{
typeset f mnt mnt_list answer
if [[ $R_flg = 1 ]]
then
remove_backup
fi
if [[ $r_flg = 1 ]]
then
recovery_backup
fi
if [[ $c_flg = 1 ]]
then
create_backup
fi
if [[ $d_flg = 1 ]]
then
diff_backup
fi
}
init_prog "$@"
main
exit 0
Хотя, может я чего не понял? Может, кто в комментах сможет пояснить: как этот скрипт обеспечивает безопасное и надёжное резервирование данных? [TBD]
rsync, кстати, есть в доп. репозитарии. Версия 3.1.3. Я думаю, использование rsync — это всё-же лучшая альтернатива приложению /mcst/bin/backup.
Далее я решил поставить свеженький Veeam Agent for Linux. Кто-то спросит: «А при чём тут Veeam и импортозамещение?» Да, в реестре его нет, но он сертифицирован ФСТЭК, а значит, при отсутствии альтернатив его можно использовать. Уделив минут пятнадцать на альтернативы из реестра, мне удалось найти 3 ссылки по слову «backup» (ни одной, относящейся к моему вопросу, на слово «резерв»). Глубоким анализом этих программ я не занимался — потому не буду пытаться судить, насколько они подходят для резервного копирования машин под ОС Linux. Кому надо — сам сделает вывод и поделится им в комментах.
Этап третий — установка Veeam Agent for Linux.
Итак, Veeam Agent for Linux состоит из двух пакетов: модуля ядра veeamsnap (кстати, исходник тут) и проприетарного user-space кода в виде пакета veeam.
С установкой модуля ядра возникла одна маленькая проблема — отсутствие пакета dkms. Это такой сервис, который позволяет собирать модули ядра из исходников. Как правило, он есть на всех deb дистрибутивах. Пришлось его скачать из стороннего deb репозитария. Одно порадовало — пакет не зависит от архитектуры, так что встал как родной. Почему его не внесли в список доступных пакетов, точнее, не разработали [TBD]? Возможно, предполагается, что никто не должен собирать и запускать всякие не МЦСТ модули ядра. Тут правда есть неувязочка — так как linux-headers есть. То есть, модуль, при желании, можно собрать руками и запускать при старте машины скриптом. Я думаю частых обновлений от МЦСТ ждать не стоит [TBD].
«OK, модуль встал — самое сложное позади», — подумал я… Пакет veeam для deb репозитария есть для платформы amd64, а у ОС «Эльбрус» платформа x86_64 [TBD]. Разница, конечно, только в названии, но эта разница делает практически все пакеты из сторонних deb репозитариев несовместимыми с ОС «Эльбрус». Устраняется это досадное недоразумение элементарно: достаточно разобрать пакет, поправить информацию об архитектуре и собрать обратно. Как это сделать нагуглилось моментально.
mkdir tmp
dpkg-deb -R original.deb tmp
# edit DEBIAN/postinst
dpkg-deb -b tmp fixed.deb
Другая проблема — зависимости. Нужные файлы вроде есть, а вот пакетов нет. Сложилось впечатление, что имена пакетов отличаются он «импортных аналогов». Возможно, библиотеки по-другому объединены в пакеты. Я не стал глубоко вдаваться в подробности, убрал почти все зависимости, и установка пошла.
Следом всплыли проблемы с кодом старта сервиса. Не оказалось скрипта /lib/init/vars.sh. Почему-то «Эльбрус» обходится без него, так что уберём и мы. Далее пришлось заменить функцию вывода сообщений: не оказалось функций log_daemon_msg и log_end_msg. Покопавшись в файле /lib/lsb/init-functions, я нашёл функцию log_success_msg — нам сгодится для экспериментов. Кстати, в файле /lib/lsb/init-functions строка "# Source SuSE`s rc functions" в начале файла [TBD].
После такой вот грубой обработки пакета напильником бэкап entire-machine на NFS-шару успешно запустился. Маунт бэкапа тоже прошёл успешно. Так что, я полагаю, для резервного копирования машины с PDK «Эльбрус», скачанной за «просто так» без всяких обязательств, Veeam Agent for Linux точно подойдёт. Даже после всех доработок напильником.
Конечно, формально дистрибутив ОС «Эльбрус» не поддерживается, так как не входит в перечень поддерживаемых. Кроме того, Veeam Agent for Linux на нём не тестировался отделом QA, так что тех. поддержки нет (по крайней мере на момент публикации статьи).
Надеюсь, статья будет полезной тем, кто пытается реализовать приказ №334 от 29.06.2017. Мои вам… [TBD].
Комментарии (10)
shalm
22.04.2019 18:56-2Подождать немного, потянуть время и импортозамещение рассосётся, а этот бесценный опыт, описанный в статье, станет ненужным.
oller
22.04.2019 19:50+3Время идёт уже долго, пояса затягивают сильнее и альтернатив не много. Ещё 10 лет назад мне рассказывали как репы подключали к альту, смотрите ка он жив ....
OpenA
24.04.2019 12:24+2> Помимо него, есть программное обеспечение ОС «Эльбрус». И — вопреки распространенному заблуждению — для работы ОС «Эльбрус» не обязательно иметь аппаратный комплекс на базе процессора Эльбрус. Есть «PDK «Эльбрус» для x86» — собственно, он и появился в открытом доступе в виде установочного диска. Кстати, там есть сноска «PDK — platform development kit, набор разработчика» — отлично, значит, там есть как минимум компилятор.
Спасибо что озвучили мои мысли, а то дико подгорало от того что люди из тех двух статей не понимают с чем имеют дело, несут ахинею про «стребовать исходники как велит гпл» похоже вообще не осознавая что им спокойно вывалят исходники для x86 со всем остальным, ни закрытых либ ни компиляторов ни даже порта на e2k там не будет
iborzenkov
И вы туда-же? Тошнит уже от этого эльбруса и наклейки этикеточек.
CodeImp Автор
Подобного комментария я ждал. Самого когда-то укачивало от отечественных разработок. Однако, реальность такова, что работать приходится не с тем с чем хочется, а с тем что дают.
oller
Очень не хватает veam для проксмокс с инкрементальным копированием. Вариант ставить агентов лишает смысла всю затею.
Dorlas
Не сказал бы, что использование агентов Veeam (заметьте, бесплатных), так уж неудобно — все зависит от решаемых задач резервирования.
Если у Вас есть виртуалки с Domain Controllers — то разместите их на разных хостах и делайте полный бекап 1 раз в месяц какой то одной. Чаще обычно смысла нет никакого. В самой же AD включите RecycleBin. Тут Агента достаточно, нет смысла большого в бекапе на уровне гипервизора.
Если виртуалки — это файловые сервера — то тоже, Агент справится и отлично. Если все шары на доп-диске (например, D:) — то даже бесплатного за глаза хватит.
Если виртуалки — это сервера приложений — то можно пойти на компромисс и бекапить только важные данные (БД) — и опять, вероятно Агента хватит.
PS: Понимаю, что хочется как в VBR — бекапим все сразу и не паримся. Но VBR все таки изначально для коммерческих систем разрабатывался. Портирование на ProxMox денег особо не принесет.
Loxmatiymamont
Но, Петька, есть нюанс (с)
С последним апдейтом Veeam CE даёт все возможности платного приложения, просто на ограниченное количество машин.
Dorlas
Не совсем так — Veeam VBR CE == Veeam Standard (с ограничением на 10 VM).
А есть еще Enterprise и Enterprise Plus — там фишек больше.
До выхода Community Edition многие использовали бесплатный VBR + PowerShell скрипты для автоматизации (но до CE это конечно не дотягивало — так как не было инкрементов).
Вообще Veeam молодцы — чуть ли не единственный коммерческий продукт, у которого есть полноценное бесплатное решение для резервного копирования (как для виртуализации, так и для физики). Хороший ход, позволяющий вытеснить в SOHO-сегменте других конкурентов (расширить степень присутствия и повысить узнаваемость бренда). У SOHO обычно денег нет (либо сильно экономят) — так пусть вместо пиратских версий юзают бесплатные.
Вообще работа с KVM у Veeam идет — уже есть поддержка Nutanix AHV.
Возможно руки дойдут и до ProxMox — но нужно понимать, как эти вложения монетизировать…