Linux Backup from Veeam on OS Elbrus. Import Substitution ['?' | '.' | '!']
Hello.
Recent articles on Habré Import substitution in practice. Part 1. Options and Not for long the music played ... or as OS Elbrus did not become free did not leave me indifferent. I decided to study this question in the key of the backup task. Moreover, Veeam Software products are mentioned in this article , which means that the issue may be relevant precisely in the key of import substitution.
source image
')
First of all, I decided to download the Elbrus OS, or rather, only an affordable distribution for the x86_64 architecture, see how it works, and try to put Veeam Agent for Linux on it. Wishing to learn that from this it turned out, I ask under kat.
So, a small digression, but then suddenly someone does not know. "Elbrus" is such a processor with a rather specific instruction set. In addition to it, there is software OS "Elbrus". And - contrary to a common misconception - for the operation of the Elbrus OS, it is not necessary to have a hardware complex based on the Elbrus processor. There is “PDK“ Elbrus ”for x86” - in fact, it appeared in open access as an installation disk. By the way, there is a footnote “PDK - platform development kit, developer kit” - excellent, so there is at least a compiler.
Another small forced retreat. The fact is that I once dealt with domestic software, such as “MSVS” and the “Baguette” RTOS. There was experience in working with the domestic element base, including the processor from the MCST. Therefore, with full responsibility, I can say that there is a certain specificity in this area, and I will try not to touch on it in the article. When I really want to go straight, I’ll put the [TBD] tag. So we will try to do without frank trolling and banal groans. In the end, the Russian defense industry and government agencies need to understand. The country is big - the budget issmall .. [TBD].
Zero stage - swing. It is noteworthy that the news that OS Elbrus became available, caused a resonance, but such that the distribution server was down. [TBD] Thanks to Yandex and the engineer who guessed to shift it there. So the download speed pleases.
The first stage is installation. I put on the first available free for free use of the hypervisor. I selected two cores, a couple of gigs of RAM, 32 MB per video (after all, there will be a graphical interface, I thought). Disochek as usual - 32 GB.
Launched the installation. I did not use the installation instructions, so I can not comment on it. The installation interface TUI is austerely minimalistic.
Well, well, without a mouse, then we will manage.
With the next window, I coped with the second attempt. Why not install sr0 [TBD] by default when installing from a disk?
Select the source CD-ROM, go further.
When choosing a time zone, I suddenly realized that the system uses the init boot process, and I work from TTY0.
OK, then we assign “Elbrus” to the community of Old Believers [TBD]. In principle, this is good: you do not need to ask for the source code to see how the loading process works, since everything is on scripts.
The rest is almost unimportant: we put everything and agree. Along the way, we learn that the kernel is used 3.14.79-13.84. Hmm, and in Debian 7 it was 3.2 [TBD].
Next, select the partitioning the disk into default sections and ... We see a warning:
Hmm, somehow badly the automatic partitioning coped with the 32 gigabyte disk. I did not change the disc, I completed the quest with a manual marking of the disc in the “all-in-one” style. I had to install ext3, because / boot could not be in ext4.
The system got up without incident.
The second stage is the search for alternatives.
Having rummaged with contents of the second disk, I understood that it is a repository with. packages. And looking at /etc/apt/sources.list, I realized that I should mount it in / mnt / cdrom. But I did not find / etc / os-release. But there is / etc / mcst-version with the contents of 3.0-rc36. 3.0 - this is probably the version - it seems to fit, but rc36? In general, recognizing this distribution in a classic way, third-party software will most likely not succeed.
In the root section, the / mcst directory catches the eye, and there, with a sinking heart, I discovered / mcst / backup. That is, there is a backup tool, and it is built into the system! “Excellent,” I thought, “Let's see how it works!”
It turned out that there is a 4kb bash script / mcst / bin / backup, which provides file copying. The default is to the / mcst / backup directory. In the source, I expected to see the rsync command, but in the default configuration it is not. The script simply copies the files. The team looks something like this:
Although, maybe I did not understand? Maybe someone in the comments will be able to explain: how does this script provide secure and reliable data backup? [TBD]
rsync, by the way, is in the add. repositories. Version 3.1.3. I think using rsync is still the best alternative to the / mcst / bin / backup application.
Next, I decided to put fresh Veeam Agent for Linux . Someone will ask: “And what’s the Veeam and import substitution?” Yes, it’s not in the registry, but it is certified by FSTEC, which means it can be used in the absence of alternatives. After spending about fifteen minutes on alternatives from the registry , I managed to find 3 references to the word “backup” (none related to my question, to the word “reserve”). I didn’t do a deep analysis of these programs, so I won’t try to judge how they are suitable for backing up Linux machines. Who needs it - he will draw a conclusion and share it in the comments.
Stage three - install Veeam Agent for Linux.
So, Veeam Agent for Linux consists of two packages: the veeamsnap kernel module (by the way, the source is here ) and the proprietary user-space code in the form of the veeam package.
There was one small problem with installing the kernel module - the lack of the dkms package. This is a service that allows you to build kernel modules from sources. As a rule, it is on all deb distributions. I had to download it from a third-party deb repository. One was pleased - the package does not depend on the architecture, so it rose like a native one. Why it was not included in the list of available packages, more precisely, they did not develop [TBD]? It may be assumed that no one should build and run all sorts of non-MCST kernel modules. There really is a discrepancy - since there are linux-headers. That is, the module, if desired, can be assembled by hand and run when the machine starts with a script. I think frequent updates from the MCST should not wait [TBD].
“OK, the module is up - the hardest thing is over,” I thought ... The veeam package for the deb repository is for the amd64 platform, and Elbrus has the x86_64 [TBD] platform. The difference, of course, is only in the name, but this difference makes almost all packages from third-party deb repositories incompatible with Elbrus OS. This annoying misunderstanding is eliminated simply: it is enough to disassemble the package, correct the information about the architecture and assemble it back. How to do it instantly googled .
Another problem is dependencies. The necessary files are there, but there are no packages. There was an impression that the names of the packages are different from “imported analogues”. Libraries may be packaged differently. I did not go deep into details, removed almost all dependencies, and the installation went.
Next came the problems with the service start code. There was no script /lib/init/vars.sh. For some reason, "Elbrus" does without it, so we will also remove it. Then I had to replace the message output function: there were no log_daemon_msg and log_end_msg functions. Digging into the file / lib / lsb / init-functions, I found the function log_success_msg - we will fit for experiments. By the way, in the / lib / lsb / init-functions file, the line "# Source SuSE`s rc functions" at the beginning of the [TBD] file.
After such a rough packet processing by a file with a backup of the entire machine on the NFS-ball, it started successfully. Mount backup was also successful. So, I suppose, for backing up the machine with the PDK "Elbrus" downloaded for "just like that" without any obligations, Veeam Agent for Linux will definitely work. Even after all the improvements file.
Of course, formally the Elbrus distribution kit is not supported, since it is not included in the list of supported. In addition, the Veeam Agent for Linux was not tested on it by the QA department, so those. no support (at least at the time of publication of the article).
I hope the article will be useful to those who are trying to implement the order №33 of 06/29/2017. Mine to you ... [TBD].
Recent articles on Habré Import substitution in practice. Part 1. Options and Not for long the music played ... or as OS Elbrus did not become free did not leave me indifferent. I decided to study this question in the key of the backup task. Moreover, Veeam Software products are mentioned in this article , which means that the issue may be relevant precisely in the key of import substitution.
source image
')
First of all, I decided to download the Elbrus OS, or rather, only an affordable distribution for the x86_64 architecture, see how it works, and try to put Veeam Agent for Linux on it. Wishing to learn that from this it turned out, I ask under kat.
So, a small digression, but then suddenly someone does not know. "Elbrus" is such a processor with a rather specific instruction set. In addition to it, there is software OS "Elbrus". And - contrary to a common misconception - for the operation of the Elbrus OS, it is not necessary to have a hardware complex based on the Elbrus processor. There is “PDK“ Elbrus ”for x86” - in fact, it appeared in open access as an installation disk. By the way, there is a footnote “PDK - platform development kit, developer kit” - excellent, so there is at least a compiler.
Another small forced retreat. The fact is that I once dealt with domestic software, such as “MSVS” and the “Baguette” RTOS. There was experience in working with the domestic element base, including the processor from the MCST. Therefore, with full responsibility, I can say that there is a certain specificity in this area, and I will try not to touch on it in the article. When I really want to go straight, I’ll put the [TBD] tag. So we will try to do without frank trolling and banal groans. In the end, the Russian defense industry and government agencies need to understand. The country is big - the budget is
Zero stage - swing. It is noteworthy that the news that OS Elbrus became available, caused a resonance, but such that the distribution server was down. [TBD] Thanks to Yandex and the engineer who guessed to shift it there. So the download speed pleases.
The first stage is installation. I put on the first available free for free use of the hypervisor. I selected two cores, a couple of gigs of RAM, 32 MB per video (after all, there will be a graphical interface, I thought). Disochek as usual - 32 GB.
Launched the installation. I did not use the installation instructions, so I can not comment on it. The installation interface TUI is austerely minimalistic.
Well, well, without a mouse, then we will manage.
With the next window, I coped with the second attempt. Why not install sr0 [TBD] by default when installing from a disk?
Select the source CD-ROM, go further.
When choosing a time zone, I suddenly realized that the system uses the init boot process, and I work from TTY0.
OK, then we assign “Elbrus” to the community of Old Believers [TBD]. In principle, this is good: you do not need to ask for the source code to see how the loading process works, since everything is on scripts.
The rest is almost unimportant: we put everything and agree. Along the way, we learn that the kernel is used 3.14.79-13.84. Hmm, and in Debian 7 it was 3.2 [TBD].
Next, select the partitioning the disk into default sections and ... We see a warning:
Hmm, somehow badly the automatic partitioning coped with the 32 gigabyte disk. I did not change the disc, I completed the quest with a manual marking of the disc in the “all-in-one” style. I had to install ext3, because / boot could not be in ext4.
The system got up without incident.
The second stage is the search for alternatives.
Having rummaged with contents of the second disk, I understood that it is a repository with. packages. And looking at /etc/apt/sources.list, I realized that I should mount it in / mnt / cdrom. But I did not find / etc / os-release. But there is / etc / mcst-version with the contents of 3.0-rc36. 3.0 - this is probably the version - it seems to fit, but rc36? In general, recognizing this distribution in a classic way, third-party software will most likely not succeed.
In the root section, the / mcst directory catches the eye, and there, with a sinking heart, I discovered / mcst / backup. That is, there is a backup tool, and it is built into the system! “Excellent,” I thought, “Let's see how it works!”
It turned out that there is a 4kb bash script / mcst / bin / backup, which provides file copying. The default is to the / mcst / backup directory. In the source, I expected to see the rsync command, but in the default configuration it is not. The script simply copies the files. The team looks something like this:
cp -rpdx <file backup> <file> Entire file / mcst / bin / backup here
Immediately I warn you that for complete understanding of this script alone is not enough. It pulls functions from / mcst / bin / source, which is something like a function library. I did not bring him (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 Although, maybe I did not understand? Maybe someone in the comments will be able to explain: how does this script provide secure and reliable data backup? [TBD]
rsync, by the way, is in the add. repositories. Version 3.1.3. I think using rsync is still the best alternative to the / mcst / bin / backup application.
Next, I decided to put fresh Veeam Agent for Linux . Someone will ask: “And what’s the Veeam and import substitution?” Yes, it’s not in the registry, but it is certified by FSTEC, which means it can be used in the absence of alternatives. After spending about fifteen minutes on alternatives from the registry , I managed to find 3 references to the word “backup” (none related to my question, to the word “reserve”). I didn’t do a deep analysis of these programs, so I won’t try to judge how they are suitable for backing up Linux machines. Who needs it - he will draw a conclusion and share it in the comments.
Stage three - install Veeam Agent for Linux.
So, Veeam Agent for Linux consists of two packages: the veeamsnap kernel module (by the way, the source is here ) and the proprietary user-space code in the form of the veeam package.
There was one small problem with installing the kernel module - the lack of the dkms package. This is a service that allows you to build kernel modules from sources. As a rule, it is on all deb distributions. I had to download it from a third-party deb repository. One was pleased - the package does not depend on the architecture, so it rose like a native one. Why it was not included in the list of available packages, more precisely, they did not develop [TBD]? It may be assumed that no one should build and run all sorts of non-MCST kernel modules. There really is a discrepancy - since there are linux-headers. That is, the module, if desired, can be assembled by hand and run when the machine starts with a script. I think frequent updates from the MCST should not wait [TBD].
“OK, the module is up - the hardest thing is over,” I thought ... The veeam package for the deb repository is for the amd64 platform, and Elbrus has the x86_64 [TBD] platform. The difference, of course, is only in the name, but this difference makes almost all packages from third-party deb repositories incompatible with Elbrus OS. This annoying misunderstanding is eliminated simply: it is enough to disassemble the package, correct the information about the architecture and assemble it back. How to do it instantly googled .
mkdir tmp dpkg-deb -R original.deb tmp # edit DEBIAN/postinst dpkg-deb -b tmp fixed.deb Another problem is dependencies. The necessary files are there, but there are no packages. There was an impression that the names of the packages are different from “imported analogues”. Libraries may be packaged differently. I did not go deep into details, removed almost all dependencies, and the installation went.
Next came the problems with the service start code. There was no script /lib/init/vars.sh. For some reason, "Elbrus" does without it, so we will also remove it. Then I had to replace the message output function: there were no log_daemon_msg and log_end_msg functions. Digging into the file / lib / lsb / init-functions, I found the function log_success_msg - we will fit for experiments. By the way, in the / lib / lsb / init-functions file, the line "# Source SuSE`s rc functions" at the beginning of the [TBD] file.
After such a rough packet processing by a file with a backup of the entire machine on the NFS-ball, it started successfully. Mount backup was also successful. So, I suppose, for backing up the machine with the PDK "Elbrus" downloaded for "just like that" without any obligations, Veeam Agent for Linux will definitely work. Even after all the improvements file.
Of course, formally the Elbrus distribution kit is not supported, since it is not included in the list of supported. In addition, the Veeam Agent for Linux was not tested on it by the QA department, so those. no support (at least at the time of publication of the article).
I hope the article will be useful to those who are trying to implement the order №33 of 06/29/2017. Mine to you ... [TBD].
Source: https://habr.com/ru/post/447960/
All Articles