Hallo almal.
Onlangse artikels oor Habré и het my nie onverskillig gelaat nie. Ek het besluit om hierdie kwessie in die konteks van die rugsteuntaak te bestudeer. Verder, in Veeam Sagteware-produkte word genoem, wat beteken dat die kwessie spesifiek in die konteks van invoervervanging relevant kan wees.
![Linux-rugsteun vanaf Veeam op Elbrus OS. Invoervervanging ['?' | '.' | '!']](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Eerstens het ek besluit om die Elbrus-bedryfstelsel af te laai, of liewer, slegs die beskikbare verspreiding vir die x86_64-argitektuur, kyk hoe dit werk, en probeer om Veeam Agent vir Linux daarop te installeer. As jy wil weet wat hieruit gekom het, sien kat asseblief.
Dus, 'n klein afwyking, ingeval iemand nie weet nie. "Elbrus" is so met 'n taamlik spesifieke bevelstelsel. Benewens dit, is daar Elbrus OS-sagteware. En - anders as wat algemeen aanvaar word - om die Elbrus-bedryfstelsel te bedryf, is dit nie nodig om 'n hardewarestelsel te hê wat op die Elbrus-verwerker gebaseer is nie. Daar is "PDK "Elbrus" vir x86" - in werklikheid het dit in die publieke domein verskyn in die vorm van 'n installasieskyf. Terloops, daar is 'n voetnoot "PDK - platformontwikkelingskit, ontwikkelaarstel" - wonderlik, dit beteken dat daar ten minste 'n samesteller daar is.
Nog 'n klein gedwonge terugtog. Die feit is dat ek eenkeer te doen gehad het met huishoudelike sagteware, soos MSVS en Baguette RTOS. Ek het ondervinding gehad om met huishoudelike komponente te werk, insluitend 'n verwerker van MCST. Daarom kan ek met volle verantwoordelikheid sê dat daar 'n sekere spesifisiteit op hierdie gebied is en ek sal probeer om dit nie in die artikel aan te raak nie. Wanneer ek regtig wil, sal ek die etiket [TBD] plaas. Ons sal dus probeer klaarkom sonder volstrekte trol en banale gekerm. Op die ou end moet die Russiese verdedigingsbedryf en regeringsagentskappe verstaan word. Groot land - klein begroting.. [TBD].
Zero stadium - Aflaai. Dit is opmerklik dat die nuus dat die Elbrus OS beskikbaar geword het 'n resonansie veroorsaak het, soveel so dat die verspreidingsbediener afgegaan het. [TBD] Dankie aan Yandex en die ingenieur wat gedink het om dit soontoe te skuif. Die aflaaispoed is dus goed.
Eerste stadium - installasie. Ek het dit geïnstalleer op die eerste hypervisor wat beskikbaar was vir gratis gebruik. Ek het twee kerns toegewys, 'n paar optredes RAM, 32 MB vir video (daar sal 'n grafiese koppelvlak wees, het ek gedink). Die skyf is soos gewoonlik - 32 GB.
Ek het die installasie begin. Ek het nie die installasie-instruksies gebruik nie, so ek kan nie daarop kommentaar lewer nie. Die TUI-installasie-koppelvlak is uiters minimalisties.
Wel, wonderlik, ons kan sonder 'n muis klaarkom.
Ek het die volgende venster met die tweede probeerslag reggekry. Waarom nie die verstektoestel sr0 [TBD] kies wanneer u vanaf skyf installeer nie?
Kies die CD-ROM-bron en gaan aan.
Terwyl ek die tydsone gekies het, het ek skielik besef dat die stelsel die init-opstartproses gebruik, en ek werk vanaf TTY0.
OK, dan klassifiseer ons "Elbrus" as 'n gemeenskap [TBD]. In beginsel is dit goed: jy hoef nie vir die bronkode te vra om te sien hoe die aflaaiproses werk nie, aangesien alles geskryf is.
Die res is amper onbelangrik: ons sit alles en stem saam. Langs die pad vind ons uit dat die kern 3.14.79-13.84 gebruik word. Hmm, Debian 7 het 3.2 [TBD] gehad.
Kies dan die verstekskyfpartisionering en ... Ons sien 'n waarskuwing:
Hmm, op een of ander manier het die outomatiese partisionering nie goed met 'n 32 gig-skyf hanteer nie. Ek het nie die skyf verander nie; Ek het die soeke voltooi met handmatige skyfpartisionering in die "alles-in-een"-styl. Ek moes ext3 installeer, aangesien /boot nie in ext4 kon wees nie.
Die stelsel het sonder voorval ontstaan.
Die tweede fase - soek na alternatiewe.
Nadat ek deur die inhoud van die tweede skyf gesoek het, het ek besef dat dit 'n bewaarplek is met bykomende. in pakkies. En kyk na /etc/apt/sources.list, ek het besef dat dit in /mnt/cdrom gemonteer moet word. Maar ek het nie /etc/os-release gevind nie. Maar daar is /etc/mcst-weergawe met die inhoud 3.0-rc36. 3.0 is waarskynlik die weergawe - dit lyk of dit pas, maar rc36? Oor die algemeen sal derdeparty-sagteware heel waarskynlik nie hierdie verspreiding op die klassieke manier kan herken nie.
In die root partisie vang die /mcst gids my oog, en daar, met 'n sinkende hart, ontdek ek /mcst/backup. Dit wil sê, daar is 'n rugsteuninstrument, en dit is in die stelsel ingebou! “Groot,” het ek gedink, “kom ons kyk hoe dit werk!”
Dit het geblyk dat daar 'n 4Kb bash script /mcst/bin/backup is wat lêerkopiering verskaf. By verstek - na die /mcst/backup-gids. In die bronkode het ek verwag om die rsync-opdrag te sien, maar dit is nie in die verstekkonfigurasie nie. Die skrif kopieer eenvoudig lêers. Die opdrag lyk so iets:
cp -rpdx <file backup> <file>
Die hele lêer /mcst/bin/backup is hierEk waarsku jou dadelik dat hierdie skrif alleen nie genoeg is om ten volle te verstaan nie. Dit trek funksies uit /mcst/bin/source, wat iets soos 'n biblioteek van funksies is. Ek het dit nie ingesluit nie (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
Alhoewel, miskien het ek iets nie verstaan nie? Miskien kan iemand in die kommentaar verduidelik: hoe verseker hierdie skrif veilige en betroubare datarugsteun? [TBD]
rsync, terloops, is by die byvoeging ingesluit. bewaarplekke. Weergawe 3.1.3. Ek dink die gebruik van rsync is steeds 'n beter alternatief vir die /mcst/bin/backup-toepassing.
Volgende het ek besluit om 'n vars een te sit Veeam Agent vir Linux. Iemand sal vra: "Wat het Veeam en invoervervanging daarmee te doen?" Ja, dit is nie in die register nie, maar dit is gesertifiseer deur FSTEC, wat beteken dat in die afwesigheid van alternatiewe dit gebruik kan word. Spandeer vyftien minute aan alternatiewe van , Ek kon 3 skakels vir die woord "rugsteun" vind (nie een het verband hou met my vraag vir die woord "reserwe"). Ek het nie 'n diepgaande ontleding van hierdie programme gedoen nie, so ek sal nie probeer om te oordeel hoe geskik dit is vir die rugsteun van masjiene wat Linux gebruik nie. Wie dit nodig het, sal sy eie gevolgtrekking maak en dit in die kommentaar deel.
Stadium Drie - installering van Veeam Agent vir Linux.
Dus, Veeam Agent vir Linux bestaan uit twee pakkette: die veeamsnap kernmodule (terloops, ) en eie gebruikersspasiekode in die vorm van die veeam-pakket.
Daar was een klein probleem met die installering van die kernmodule - die vermiste dkms-pakket. Dit is 'n diens waarmee u kernmodules vanaf bron kan bou. As 'n reël is dit beskikbaar op alle deb-uitkerings. Ek moes dit van 'n derdeparty-deb-bewaarplek aflaai. Een ding wat my gelukkig gemaak het, is dat die pakket nie van die argitektuur afhang nie, so dit pas soos 'n inheemse een. Waarom is dit nie by die lys van beskikbare pakkette ingesluit nie, of eerder nie ontwikkel [TBD] nie? Miskien word aanvaar dat niemand enige nie-MCST kernmodules moet bou en laat loop nie. Daar is regtig 'n teenstrydigheid hier - aangesien daar linux-opskrifte is. Dit wil sê, die module kan, indien verkies, met die hand saamgestel word en deur 'n skrif geloods word wanneer die masjien begin. Ek dink jy moet nie gereelde opdaterings van MCST [TBD] verwag nie.
"OK, die module is geïnstalleer - die moeilikste deel is verby," het ek gedink... Die veeam-pakket vir die deb-bewaarplek is vir die amd64-platform, en die Elbrus-bedryfstelsel het 'n x86_64 [TBD]-platform. Die verskil is natuurlik net in die naam, maar hierdie verskil maak byna alle pakkette van derdeparty-deb-bewaarplekke onversoenbaar met die Elbrus OS. Hierdie irriterende misverstand kan eenvoudig uitgeskakel word: haal net die pakket uitmekaar, korrigeer die inligting oor die argitektuur en sit dit weer aanmekaar. Hoe om dit te doen oombliklik.
mkdir tmp
dpkg-deb -R original.deb tmp
# edit DEBIAN/postinst
dpkg-deb -b tmp fixed.deb
Nog 'n probleem is afhanklikhede. Die nodige lêers blyk daar te wees, maar die pakkette is nie. Die indruk was dat die name van die pakkette verskil van hul "ingevoerde analoë". Miskien is die biblioteke anders verpak. Ek het nie te veel in detail ingegaan nie, amper al die afhanklikhede verwyder, en die installasie het voortgegaan.
Toe het probleme met die diensbeginkode ontstaan. Die skrip /lib/init/vars.sh ontbreek. Om een of ander rede kom Elbrus daarsonder klaar, so ons sal dit ook verwyder. Vervolgens moes ons die boodskapuitvoerfunksie vervang: die log_daemon_msg en log_end_msg funksies ontbreek. Nadat ek in die /lib/lsb/init-functions-lêer rondgesoek het, het ek die log_success_msg-funksie gevind - dit sal goed wees vir ons vir eksperimente. Terloops, in die /lib/lsb/init-functions-lêer is die reël "# Source SuSE se rc-funksies" aan die begin van die [TBD]-lêer.
Na so 'n rowwe verwerking van die pakket met 'n lêer, is die hele masjien-rugsteun op die NFS-deel suksesvol geloods. Die rugsteunmontering was ook suksesvol. So, ek glo dat Veeam Agent vir Linux beslis geskik is vir die rugsteun van 'n masjien met die Elbrus PDK, afgelaai "net so" sonder enige verpligtinge. Selfs na al die wysigings met 'n lêer.
Natuurlik word die Elbrus OS-verspreidingstel nie formeel ondersteun nie, aangesien dit nie by die lys van ondersteunde ingesluit is nie. Daarbenewens is Veeam Agent vir Linux nie daarop getoets deur die QA-afdeling nie, so diegene. daar is geen ondersteuning nie (ten minste ten tyde van die publikasie van die artikel).
Ek hoop dat die artikel nuttig sal wees vir diegene wat bevel nr. 334 van 29.06.2017 Junie XNUMX probeer implementeer. Myne vir jou ... [TBD].
Bron: will.com