Helo semua.
Artikel terkini mengenai HabrΓ© ΠΈ tidak meninggalkan saya acuh tak acuh. Saya memutuskan untuk mengkaji isu ini dalam konteks tugas sandaran. Lebih-lebih lagi, dalam Produk Perisian Veeam disebut, yang bermaksud bahawa isu itu mungkin berkaitan secara khusus dalam konteks penggantian import.
![Sandaran Linux daripada Veeam pada OS Elbrus. Penggantian import ['?' | '.' | '!']](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Pertama sekali, saya memutuskan untuk memuat turun OS Elbrus, atau sebaliknya, hanya pengedaran yang tersedia untuk seni bina x86_64, lihat cara ia berfungsi, dan cuba pasang Ejen Veeam untuk Linux padanya. Jika anda ingin tahu apa yang keluar dari ini, sila lihat kucing.
Jadi, penyimpangan kecil, sekiranya ada yang tidak tahu. "Elbrus" adalah seperti itu dengan sistem arahan yang agak khusus. Selain itu, terdapat perisian Elbrus OS. Dan - bertentangan dengan kepercayaan popular - untuk mengendalikan OS Elbrus, tidak perlu mempunyai sistem perkakasan berdasarkan pemproses Elbrus. Terdapat "PDK "Elbrus" untuk x86" - sebenarnya, ia muncul dalam domain awam dalam bentuk cakera pemasangan. Ngomong-ngomong, terdapat nota kaki "PDK - kit pembangunan platform, kit pembangun" - bagus, ini bermakna terdapat sekurang-kurangnya pengkompil di sana.
Satu lagi pengunduran paksa kecil. Hakikatnya ialah saya pernah berurusan dengan perisian domestik, seperti MSVS dan Baguette RTOS. Saya mempunyai pengalaman bekerja dengan komponen domestik, termasuk pemproses daripada MCST. Oleh itu, saya boleh mengatakan dengan penuh tanggungjawab bahawa terdapat kekhususan tertentu dalam bidang ini dan saya akan cuba untuk tidak menyentuhnya dalam artikel. Apabila saya benar-benar mahu, saya akan meletakkan tag [TBD]. Oleh itu, kami akan cuba melakukannya tanpa mengeluh dan mengerang. Akhirnya, industri pertahanan Rusia dan agensi kerajaan perlu difahami. Negara besar - bajet kecil.. [TBD].
Tahap sifar - muat turun. Perlu diperhatikan bahawa berita bahawa Elbrus OS telah tersedia menyebabkan resonans, sehinggakan pelayan pengedaran turun. [TBD] Terima kasih kepada Yandex dan jurutera yang terfikir untuk memindahkannya ke sana. Jadi kelajuan muat turun adalah baik.
Peringkat pertama - pemasangan. Saya memasangnya pada hypervisor pertama yang tersedia untuk kegunaan percuma. Saya memperuntukkan dua teras, beberapa pertunjukan RAM, 32 MB untuk video (akan ada antara muka grafik, saya fikir). Cakera adalah seperti biasa - 32 GB.
Saya memulakan pemasangan. Saya tidak menggunakan arahan pemasangan, jadi saya tidak boleh mengulas mengenainya. Antara muka pemasangan TUI sangat minimalis.
Baiklah, kita boleh lakukan tanpa tetikus.
Saya berjaya tetingkap seterusnya pada percubaan kedua. Mengapa tidak pilih peranti lalai sr0 [TBD] semasa memasang dari cakera?
Pilih sumber CD-ROM dan teruskan.
Semasa memilih zon waktu, saya tiba-tiba menyedari bahawa sistem menggunakan proses but init, dan saya bekerja dari TTY0.
OK, kemudian mari kita klasifikasikan "Elbrus" sebagai komuniti [TBD]. Pada dasarnya, ini bagus: anda tidak perlu meminta kod sumber untuk melihat cara proses muat turun berfungsi, kerana semuanya adalah skrip.
Selebihnya hampir tidak penting: kami meletakkan segala-galanya dan bersetuju. Sepanjang perjalanan, kami mendapati bahawa kernel digunakan 3.14.79-13.84. Hmm, Debian 7 mempunyai 3.2 [TBD].
Seterusnya, pilih pembahagian cakera lalai dan... Kami melihat amaran:
Hmm, entah bagaimana pembahagian automatik tidak berfungsi dengan baik dengan cakera 32 gig. Saya tidak menukar cakera; Saya menyelesaikan pencarian dengan pembahagian cakera manual dalam gaya "semua-dalam-satu". Saya terpaksa memasang ext3, kerana /boot tidak boleh berada dalam ext4.
Sistem itu muncul tanpa insiden.
Peringkat kedua - mencari alternatif.
Selepas menyelongkar kandungan cakera kedua, saya menyedari bahawa ini adalah repositori dengan tambahan. dalam pakej. Dan melihat /etc/apt/sources.list, saya menyedari bahawa ia perlu dipasang dalam /mnt/cdrom. Tetapi saya tidak menjumpai /etc/os-release. Tetapi terdapat /etc/mcst-version dengan kandungan 3.0-rc36. 3.0 mungkin versi - nampaknya sesuai, tetapi rc36? Secara umum, perisian pihak ketiga berkemungkinan besar tidak akan dapat mengenali pengedaran ini dengan cara klasik.
Dalam partition root, direktori /mcst menarik perhatian saya, dan di sana, dengan hati yang tenggelam, saya menemui /mcst/backup. Iaitu, terdapat alat sandaran, dan ia terbina dalam sistem! βHebat,β saya fikir, βMari kita lihat cara ini berfungsi!β
Ternyata terdapat skrip bash 4Kb /mcst/bin/backup yang menyediakan penyalinan fail. Secara lalai - ke direktori /mcst/backup. Dalam kod sumber saya menjangkakan untuk melihat arahan rsync, tetapi ia tidak dalam konfigurasi lalai. Skrip hanya menyalin fail. Perintah kelihatan seperti ini:
cp -rpdx <file backup> <file>
Keseluruhan fail /mcst/bin/backup ada di siniSaya memberi amaran kepada anda dengan segera bahawa skrip ini sahaja tidak mencukupi untuk difahami sepenuhnya. Ia menarik fungsi daripada /mcst/bin/source, iaitu sesuatu seperti perpustakaan fungsi. Saya tidak memasukkannya (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
Walaupun, mungkin saya tidak memahami sesuatu? Mungkin seseorang boleh menerangkan dalam ulasan: bagaimanakah skrip ini memastikan sandaran data yang selamat dan boleh dipercayai? [TBD]
rsync, dengan cara ini, disertakan dalam add-on. repositori. Versi 3.1.3. Saya fikir menggunakan rsync masih merupakan alternatif yang lebih baik kepada aplikasi /mcst/bin/backup.
Seterusnya, saya memutuskan untuk meletakkan yang baru Ejen Veeam untuk Linux. Seseorang akan bertanya: "Apakah kaitan Veeam dan penggantian import dengannya?" Ya, ia tidak ada dalam daftar, tetapi ia diperakui oleh FSTEC, yang bermaksud bahawa jika tiada alternatif ia boleh digunakan. Menghabiskan lima belas minit untuk alternatif daripada , saya dapat mencari 3 pautan untuk perkataan "sandaran" (tiada yang berkaitan dengan soalan saya untuk perkataan "rizab"). Saya belum membuat analisis mendalam tentang program ini, jadi saya tidak akan cuba menilai sejauh mana ia sesuai untuk menyandarkan mesin yang menjalankan Linux. Sesiapa yang memerlukannya akan membuat kesimpulan sendiri dan berkongsi dalam komen.
peringkat ketiga β pemasangan Ejen Veeam untuk Linux.
Jadi, Ejen Veeam untuk Linux terdiri daripada dua pakej: modul kernel veeamsnap (by the way, ) dan kod ruang pengguna proprietari dalam bentuk pakej veeam.
Terdapat satu masalah kecil dengan memasang modul kernel - pakej dkms yang hilang. Ini adalah perkhidmatan yang membolehkan anda membina modul kernel daripada sumber. Sebagai peraturan, ia tersedia pada semua pengedaran deb. Saya terpaksa memuat turunnya dari repositori deb pihak ketiga. Satu perkara yang menggembirakan saya ialah pakej itu tidak bergantung pada seni bina, jadi ia sesuai seperti yang asli. Mengapakah ia tidak disertakan dalam senarai pakej yang tersedia, atau sebaliknya, tidak dibangunkan [TBD]? Mungkin diandaikan bahawa tiada siapa yang harus membina dan menjalankan mana-mana modul kernel bukan MCST. Benar-benar terdapat percanggahan di sini - kerana terdapat pengepala linux. Iaitu, modul, jika dikehendaki, boleh dipasang dengan tangan dan dilancarkan oleh skrip apabila mesin dimulakan. Saya fikir anda tidak sepatutnya mengharapkan kemas kini yang kerap daripada MCST [TBD].
"OK, modul telah dipasang - bahagian yang paling sukar telah berakhir," saya fikir... Pakej veeam untuk repositori deb adalah untuk platform amd64, dan OS Elbrus mempunyai platform x86_64 [TBD]. Perbezaannya, sudah tentu, hanya pada nama, tetapi perbezaan ini menjadikan hampir semua pakej dari repositori deb pihak ketiga tidak serasi dengan OS Elbrus. Salah faham yang menjengkelkan ini boleh dihapuskan dengan mudah: cuma buka pakej, betulkan maklumat tentang seni bina dan susun semula. Bagaimana hendak melakukannya serta merta.
mkdir tmp
dpkg-deb -R original.deb tmp
# edit DEBIAN/postinst
dpkg-deb -b tmp fixed.deb
Masalah lain ialah kebergantungan. Fail yang diperlukan nampaknya ada di sana, tetapi pakej tidak ada. Tanggapan adalah bahawa nama pakej berbeza daripada "analog yang diimport" mereka. Mungkin perpustakaan dibungkus secara berbeza. Saya tidak terlalu terperinci, mengalih keluar hampir semua kebergantungan, dan pemasangan diteruskan.
Kemudian masalah muncul dengan kod permulaan perkhidmatan. Skrip /lib/init/vars.sh tiada. Atas sebab tertentu, Elbrus berjaya tanpanya, jadi kami akan mengalih keluarnya juga. Seterusnya, kami terpaksa menggantikan fungsi output mesej: fungsi log_daemon_msg dan log_end_msg telah tiada. Selepas membelek-belek dalam fail /lib/lsb/init-functions, saya menjumpai fungsi log_success_msg - ia sesuai untuk kita untuk eksperimen. Ngomong-ngomong, dalam fail /lib/lsb/init-functions baris β# Source SuSE`s rc functionsβ berada pada permulaan fail [TBD].
Selepas pemprosesan kasar pakej dengan fail, sandaran keseluruhan mesin pada bahagian NFS telah berjaya dilancarkan. Lekapan sandaran juga berjaya. Jadi, saya percaya bahawa untuk membuat sandaran mesin dengan Elbrus PDK, dimuat turun "sama seperti itu" tanpa sebarang kewajipan, Ejen Veeam untuk Linux pastinya sesuai. Walaupun selepas semua pengubahsuaian dengan fail.
Sudah tentu, kit pengedaran OS Elbrus tidak disokong secara rasmi, kerana ia tidak termasuk dalam senarai yang disokong. Di samping itu, Ejen Veeam untuk Linux tidak diuji ke atasnya oleh jabatan QA, jadi mereka. tiada sokongan (sekurang-kurangnya pada masa penerbitan artikel).
Saya harap artikel itu berguna kepada mereka yang cuba melaksanakan perintah No 334 pada 29.06.2017 Jun XNUMX. Milik saya kepada awak... [TBD].
Sumber: www.habr.com