Hej alle sammen.
Seneste artikler om Habré и efterlod mig ikke ligeglad. Jeg besluttede at studere dette problem i forbindelse med backup-opgaven. Desuden i Veeam Software-produkter er nævnt, hvilket betyder, at problemet kan være relevant specifikt i forbindelse med importsubstitution.
![Linux Backup fra Veeam på Elbrus OS. Importer erstatning ['?' | '.' | '!']](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Først og fremmest besluttede jeg at downloade Elbrus OS, eller rettere sagt kun den tilgængelige distribution til x86_64-arkitekturen, se, hvordan det virker, og prøv at installere Veeam Agent til Linux på det. Hvis du vil vide, hvad der kom ud af dette, så se kat.
Så en lille digression, hvis nogen ikke ved det. "Elbrus" er sådan med et ret specifikt kommandosystem. Ud over det er der Elbrus OS-software. Og - i modsætning til en almindelig misforståelse - for at Elbrus OS skal fungere, er det ikke nødvendigt at have et hardwaresystem baseret på Elbrus-processoren. Der er "PDK "Elbrus" for x86" - faktisk dukkede det op i det offentlige domæne i form af en installationsdisk. Forresten er der en fodnote "PDK - platformsudviklingskit, udviklerkit" - fantastisk, det betyder, at der i det mindste er en compiler der.
Endnu et lille tvungen tilbagetog. Faktum er, at jeg engang beskæftigede mig med indenlandsk software, såsom MSVS og Baguette RTOS. Jeg havde erfaring med at arbejde med husholdningskomponenter, herunder en processor fra MCST. Derfor kan jeg med fuldt ansvar sige, at der er en vis specificitet på dette område, og jeg vil forsøge ikke at berøre det i artiklen. Når jeg virkelig vil, sætter jeg mærket [TBD]. Så vi vil forsøge at undvære direkte trolling og banal stønnen. I sidste ende skal den russiske forsvarsindustri og offentlige myndigheder forstås. Stort land - lille budget.. [TBD].
Nul fase - Hent. Det er bemærkelsesværdigt, at nyheden om, at Elbrus OS er blevet tilgængelig, forårsagede en resonans, så meget, at distributionsserveren gik ned. [TBD] Tak til Yandex og ingeniøren, der tænkte på at flytte det dertil. Så downloadhastigheden er god.
Den første etape - installation. Jeg installerede det på den første hypervisor, der var tilgængelig til fri brug. Jeg tildelte to kerner, et par koncerter RAM, 32 MB til video (der vil være en grafisk grænseflade, troede jeg). Disken er som sædvanlig - 32 GB.
Jeg startede installationen. Jeg brugte ikke installationsvejledningen, så jeg kan ikke kommentere den. TUI-installationsgrænsefladen er meget minimalistisk.
Godt, vi kan godt undvære en mus.
Jeg klarede det næste vindue i andet forsøg. Hvorfor ikke vælge standardenheden sr0 [TBD], når du installerer fra disk?
Vælg cd-rom-kilden og gå videre.
Mens jeg valgte tidszonen, indså jeg pludselig, at systemet bruger init boot-processen, og jeg arbejder fra TTY0.
OK, så lad os klassificere "Elbrus" som et fællesskab [TBD]. I princippet er dette godt: du behøver ikke bede om kildekoden for at se, hvordan downloadprocessen fungerer, da alt er scriptet.
Resten er næsten ligegyldigt: vi lægger alt og er enige. Undervejs finder vi ud af, at kernen er brugt 3.14.79-13.84. Hmm, Debian 7 havde 3.2 [TBD].
Vælg derefter standarddiskpartitioneringen og... Vi ser en advarsel:
Hmm, på en eller anden måde klarede den automatiske partitionering sig ikke godt med en 32 gig disk. Jeg ændrede ikke disken; jeg fuldførte opgaven med manuel diskpartitionering i "alt-i-en"-stilen. Jeg var nødt til at installere ext3, da /boot ikke kunne være i ext4.
Systemet kom op uden hændelser.
Den anden fase - søg efter alternativer.
Efter at have rodet gennem indholdet af den anden disk, indså jeg, at dette er et lager med yderligere. i pakker. Og ser på /etc/apt/sources.list, indså jeg, at det skal monteres i /mnt/cdrom. Men jeg fandt ikke /etc/os-release. Men der er /etc/mcst-version med indholdet 3.0-rc36. 3.0 er nok versionen - det ser ud til at passe, men rc36? Generelt vil tredjepartssoftware højst sandsynligt ikke kunne genkende denne distribution på klassisk vis.
I rodpartitionen fanger /mcst-biblioteket mit øje, og der opdagede jeg med et synkende hjerte /mcst/backup. Det vil sige, at der er et backupværktøj, og det er indbygget i systemet! "Fantastisk," tænkte jeg, "lad os se, hvordan det her virker!"
Det viste sig, at der er et 4Kb bash-script /mcst/bin/backup, der giver filkopiering. Som standard - til mappen /mcst/backup. I kildekoden forventede jeg at se kommandoen rsync, men den er ikke i standardkonfigurationen. Scriptet kopierer simpelthen filer. Kommandoen ser nogenlunde sådan ud:
cp -rpdx <file backup> <file>
Hele filen /mcst/bin/backup er herJeg advarer dig med det samme om, at dette manuskript alene ikke er nok til fuldt ud at forstå. Det trækker funktioner fra /mcst/bin/source, som er noget i retning af et bibliotek af funktioner. Jeg inkluderede det ikke (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
Selvom jeg måske ikke forstod noget? Måske kan nogen forklare i kommentarerne: hvordan sikrer dette script sikker og pålidelig sikkerhedskopiering af data? [TBD]
rsync er i øvrigt inkluderet i tilføjelsen. depoter. Version 3.1.3. Jeg tror, at brug af rsync stadig er et bedre alternativ til /mcst/bin/backup-applikationen.
Dernæst besluttede jeg at sætte en frisk Veeam Agent til Linux. Nogen vil spørge: "Hvad har Veeam og importsubstitution med det at gøre?" Ja, den er ikke i registret, men den er certificeret af FSTEC, hvilket betyder, at den i mangel af alternativer kan bruges. Bruger femten minutter på alternativer fra , Jeg var i stand til at finde 3 links til ordet "backup" (ingen relateret til mit spørgsmål om ordet "reserve"). Jeg har ikke lavet en dyb analyse af disse programmer, så jeg vil ikke prøve at bedømme, hvor velegnede de er til at sikkerhedskopiere maskiner, der kører Linux. Den, der har brug for det, vil drage sin egen konklusion og dele den i kommentarerne.
Trin tre — installation af Veeam Agent til Linux.
Så Veeam Agent til Linux består af to pakker: veeamsnap-kernemodulet (forresten, ) og proprietær brugerrumskode i form af veeam-pakken.
Der var et lille problem med at installere kernemodulet - den manglende dkms-pakke. Dette er en tjeneste, der giver dig mulighed for at bygge kernemoduler fra kilden. Som regel er den tilgængelig på alle deb-udlodninger. Jeg var nødt til at downloade det fra et tredjeparts deb-lager. En ting, der gjorde mig glad, er, at pakken ikke afhænger af arkitekturen, så den passer som en indfødt. Hvorfor var det ikke inkluderet på listen over tilgængelige pakker, eller rettere sagt ikke udviklet [TBD]? Måske antages det, at ingen skal bygge og køre nogen ikke-MCST-kernemoduler. Der er virkelig en uoverensstemmelse her - da der er linux-headere. Det vil sige, at modulet, hvis det ønskes, kan samles i hånden og startes af et script, når maskinen starter. Jeg tror, du ikke skal forvente hyppige opdateringer fra MCST [TBD].
"OK, modulet er installeret - den sværeste del er overstået," tænkte jeg... Veeam-pakken til deb-lageret er til amd64-platformen, og Elbrus OS har en x86_64 [TBD]-platform. Forskellen ligger selvfølgelig kun i navnet, men denne forskel gør næsten alle pakker fra tredjeparts deb-lagre inkompatible med Elbrus OS. Denne irriterende misforståelse kan simpelthen elimineres: Du skal bare skille pakken ad, rette oplysningerne om arkitekturen og sætte den sammen igen. Hvordan gør man det med det samme.
mkdir tmp
dpkg-deb -R original.deb tmp
# edit DEBIAN/postinst
dpkg-deb -b tmp fixed.deb
Et andet problem er afhængigheder. De nødvendige filer ser ud til at være der, men det er pakkerne ikke. Indtrykket var, at navnene på pakkerne afveg fra deres "importerede analoger". Måske er bibliotekerne pakket anderledes. Jeg gik ikke for meget i detaljer, fjernede næsten alle afhængigheder, og installationen gik videre.
Så opstod der problemer med servicestartkoden. Scriptet /lib/init/vars.sh manglede. Af en eller anden grund klarer Elbrus det uden, så vi fjerner det også. Dernæst var vi nødt til at erstatte meddelelsesoutputfunktionen: log_daemon_msg og log_end_msg funktionerne manglede. Efter at have rodet rundt i filen /lib/lsb/init-functions, fandt jeg funktionen log_success_msg - den vil være god for os til eksperimenter. Forresten, i filen /lib/lsb/init-functions er linjen "# Source SuSEs rc-funktioner" i begyndelsen af [TBD]-filen.
Efter en sådan hårdhændet behandling af pakken med en fil, blev sikkerhedskopieringen af hele maskinen på NFS-sharet lanceret med succes. Backup-monteringen var også vellykket. Så jeg tror, at til at sikkerhedskopiere en maskine med Elbrus PDK, downloadet "bare sådan" uden nogen forpligtelser, er Veeam Agent til Linux bestemt egnet. Selv efter alle ændringerne med en fil.
Selvfølgelig er Elbrus OS-distributionssættet ikke formelt understøttet, da det ikke er inkluderet på listen over understøttede. Derudover blev Veeam Agent til Linux ikke testet på det af QA-afdelingen, så de. der er ingen støtte (i hvert fald på tidspunktet for udgivelsen af artiklen).
Jeg håber, at artiklen vil være nyttig for dem, der forsøger at implementere ordre nr. 334 af 29.06.2017. juni XNUMX. Min til dig... [TBD].
Kilde: www.habr.com