Всім привіт.
Нещодавні статті на хабрі и не залишили мене байдужим. Я вирішив вивчати це питання в ключі завдання резервного копіювання. Тим більше, що в продукти Veeam Software згадуються, отже, питання може бути актуальним саме у ключі імпортозаміщення.
![Linux Backup від Veeam на ОС "Ельбрус". Імпортозаміщення ['?' | '.' | '!']](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Насамперед я вирішив завантажити ОС «Ельбрус», а точніше — лише доступний дистрибутив для архітектури 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, але дефолтної конфігурації його немає. Скрипт виконує просто копіювання файлів. Команда виглядає якось так:
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, модуль встав - найскладніше позаду", - подумав я. Різниця, звичайно, тільки в назві, але ця різниця робить практично всі пакети зі сторонніх 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].
Джерело: habr.com