April 22, 2019 at 08:05Veeam Linux Backup on Elbrus OS. Import Substitution ['?' | '.' | '!']
Hello.
Recent articles on Habr Import substitution in practice. Part 1. Options and Not for long the music played ... or how the OS Elbrus never became free did not leave me indifferent. I decided to study this issue in the key of the backup task. Moreover, in this article Veeam Software products are mentioned, which means that the issue may be relevant in the context of import substitution.
the source of the image
First of all, I decided to download the Elbrus OS, or rather, only the available distribution kit for the x86_64 architecture, see how it works, and try to install Veeam Agent for Linux on it. Those wishing to find out what came of it, please, under cat.
So, a small digression, otherwise suddenly someone does not know. Elbrus is a processor with a rather specific instruction system. In addition to it, there is Elbrus OS software. 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 a "Elbrus PDK for x86" - in fact, it appeared in the public domain as an installation disk. By the way, there is a footnote “PDK - platform development kit, development kit” - excellent, which means that there is at least a compiler.
Another small forced retreat. The fact is that I once dealt with domestic software such as MSVS and RTO Baget. There was experience in working with the domestic element base, including with the processor from the MCST. Therefore, I can say with all responsibility that there is a certain specificity in this area, and I will try not to touch upon it in this article. When I’ll really want to, 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 be understood. The country is big - the budget issmall .. [TBD].
Zero stage- download. It is noteworthy that the news that the Elbrus OS became available caused a resonance, such that the distribution server was down. [TBD] Thanks to Yandex and the engineer who thought of moving it there. So the download speed is good.
The first step is installation. I put on the first available free hypervisor. I allocated two cores, a couple of gigs of RAM, 32 MB per video (there will be a graphical interface there, I thought). The disk as usual - 32 GB.
Launched the installation. I did not use the installation instructions, so I can not comment on it. The TUI installation interface is harshly minimalist.
Well, excellent, without a mouse, then we'll get by.
I dealt with the next window from the second attempt. Why not install sr0 [TBD] by default when installing from disk?
Select the source of the CD-ROM, go further.
Choosing the time zone, I suddenly realized that the system uses the init boot process, and I'm working from TTY0.
OK, so let’s take Elbrus to the Old Believer community [TBD]. In principle, this is good: you do not need to ask for the source to see how the boot process works, since everything is in scripts.
The rest is almost unimportant: we put everything and agree. Along the way, we find out that the kernel is used 3.14.79-13.84. Hmm, Debian 7 had 3.2 [TBD].
Next, select the partitioning of the disk by default and ... We see a warning:
Hmm, somehow the automatic markup was bad with a 32 gig disk. I didn’t change the disk, I went through a quest with manual disk layout in the “all in one” style. I had to install ext3, since / 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 additional. packages. And looking at /etc/apt/sources.list, I realized that I need to 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 converge, but rc36? In general, third-party software most likely will not be able to recognize this distribution in the classical way.
In the root section, the / mcst directory catches your eye, and there with a sinking heart I found / mcst / backup. That is, there is a backup tool, and it’s built into the system! “Great,” I thought, “Let's see how it works!”
It turned out that there is a bash script / mcst / bin / backup that is 4kb in size, which allows copying files. By default - to the directory / mcst / backup. In the source, I expected to see the rsync command, but it is not in the default configuration. The script simply copies the files. The command looks something like this:
Although, maybe I did not understand what? Maybe someone in the comments can explain: how does this script provide safe and reliable data backup? [TBD]
rsync, by the way, is in add. repositories. Version 3.1.3. I think using rsync is still the best alternative to / mcst / bin / backup.
Next, I decided to put the fresh Veeam Agent for Linux . Someone will ask: “What does Veeam have to do with import substitution?” Yes, it is not in the registry, but it is certified by the FSTEC, which means that in the absence of alternatives it can be used. Having spent about fifteen minutes on alternatives from the registry, I managed to find 3 links for the word "backup" (not a single one related to my question to the word "reserve"). I did not do a deep analysis of these programs - therefore I will not try to judge how suitable they are for backing up machines under Linux. 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 source. As a rule, it is on all deb distributions. I had to download it from a third-party deb repository. One pleased - the package does not depend on architecture, so it stood up as a native. Why was it not included in the list of available packages, or rather, did not develop [TBD]? Perhaps it is assumed that no one should collect and run all kinds of non-MCST kernel modules. There really is a problem here - 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 you should not wait for frequent updates from the ICST [TBD].
“OK, the module got up - the hardest part is behind,” I thought ... The veeam package for the deb repository is for the amd64 platform, and the Elbrus OS 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 the Elbrus OS. This annoying misunderstanding is eliminated in an elementary way: it is enough to parse the package, correct the information about the architecture and collect it back. How to do it googled instantly.
Another problem is dependencies. The necessary files seem to be there, but there are no packages. There was an impression that the names of the packages differ from “foreign analogues”. Libraries may be bundled differently. I did not go deep into the details, removed almost all the dependencies, and the installation went.
Next came up problems with the service start code. There was no script /lib/init/vars.sh. For some reason, “Elbrus” is doing without it, so we will remove it as well. Then we had to replace the message output function: there were no functions log_daemon_msg and log_end_msg. Rummaging around in the file / lib / lsb / init-functions, I found the function log_success_msg - it will work for us 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 processing of the package with a file, the entire-machine backup on the NFS ball successfully started. The backup mount was also successful. So, I suppose, for backing up a machine with the Elbrus PDK, downloaded for "just like that" without any obligation, Veeam Agent for Linux is definitely suitable. Even after all the modifications with a file.
Of course, formally, the Elbrus OS distribution is not supported, as it is not included in the list of supported ones. In addition, Veeam Agent for Linux on it was not tested by the QA department, so those. no support (at least at the time of publication of the article).
I hope this article will be useful to those who are trying to implement order No. 334 of June 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 how the OS Elbrus never became free did not leave me indifferent. I decided to study this issue in the key of the backup task. Moreover, in this article Veeam Software products are mentioned, which means that the issue may be relevant in the context of import substitution.
the source of the image
First of all, I decided to download the Elbrus OS, or rather, only the available distribution kit for the x86_64 architecture, see how it works, and try to install Veeam Agent for Linux on it. Those wishing to find out what came of it, please, under cat.
So, a small digression, otherwise suddenly someone does not know. Elbrus is a processor with a rather specific instruction system. In addition to it, there is Elbrus OS software. 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 a "Elbrus PDK for x86" - in fact, it appeared in the public domain as an installation disk. By the way, there is a footnote “PDK - platform development kit, development kit” - excellent, which means that there is at least a compiler.
Another small forced retreat. The fact is that I once dealt with domestic software such as MSVS and RTO Baget. There was experience in working with the domestic element base, including with the processor from the MCST. Therefore, I can say with all responsibility that there is a certain specificity in this area, and I will try not to touch upon it in this article. When I’ll really want to, 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 be understood. The country is big - the budget is
Zero stage- download. It is noteworthy that the news that the Elbrus OS became available caused a resonance, such that the distribution server was down. [TBD] Thanks to Yandex and the engineer who thought of moving it there. So the download speed is good.
The first step is installation. I put on the first available free hypervisor. I allocated two cores, a couple of gigs of RAM, 32 MB per video (there will be a graphical interface there, I thought). The disk as usual - 32 GB.
Launched the installation. I did not use the installation instructions, so I can not comment on it. The TUI installation interface is harshly minimalist.
Well, excellent, without a mouse, then we'll get by.
I dealt with the next window from the second attempt. Why not install sr0 [TBD] by default when installing from disk?
Select the source of the CD-ROM, go further.
Choosing the time zone, I suddenly realized that the system uses the init boot process, and I'm working from TTY0.
OK, so let’s take Elbrus to the Old Believer community [TBD]. In principle, this is good: you do not need to ask for the source to see how the boot process works, since everything is in scripts.
The rest is almost unimportant: we put everything and agree. Along the way, we find out that the kernel is used 3.14.79-13.84. Hmm, Debian 7 had 3.2 [TBD].
Next, select the partitioning of the disk by default and ... We see a warning:
Hmm, somehow the automatic markup was bad with a 32 gig disk. I didn’t change the disk, I went through a quest with manual disk layout in the “all in one” style. I had to install ext3, since / 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 additional. packages. And looking at /etc/apt/sources.list, I realized that I need to 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 converge, but rc36? In general, third-party software most likely will not be able to recognize this distribution in the classical way.
In the root section, the / mcst directory catches your eye, and there with a sinking heart I found / mcst / backup. That is, there is a backup tool, and it’s built into the system! “Great,” I thought, “Let's see how it works!”
It turned out that there is a bash script / mcst / bin / backup that is 4kb in size, which allows copying files. By default - to the directory / mcst / backup. In the source, I expected to see the rsync command, but it is not in the default configuration. The script simply copies the files. The command looks something like this:
cp -rpdx The whole file / mcst / bin / backup is here
I warn you right away that to fully understand this script alone is not enough. It pulls functions from / mcst / bin / source, which is something like a library of functions. I did not cite 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 what? Maybe someone in the comments can explain: how does this script provide safe and reliable data backup? [TBD]
rsync, by the way, is in add. repositories. Version 3.1.3. I think using rsync is still the best alternative to / mcst / bin / backup.
Next, I decided to put the fresh Veeam Agent for Linux . Someone will ask: “What does Veeam have to do with import substitution?” Yes, it is not in the registry, but it is certified by the FSTEC, which means that in the absence of alternatives it can be used. Having spent about fifteen minutes on alternatives from the registry, I managed to find 3 links for the word "backup" (not a single one related to my question to the word "reserve"). I did not do a deep analysis of these programs - therefore I will not try to judge how suitable they are for backing up machines under Linux. 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 source. As a rule, it is on all deb distributions. I had to download it from a third-party deb repository. One pleased - the package does not depend on architecture, so it stood up as a native. Why was it not included in the list of available packages, or rather, did not develop [TBD]? Perhaps it is assumed that no one should collect and run all kinds of non-MCST kernel modules. There really is a problem here - 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 you should not wait for frequent updates from the ICST [TBD].
“OK, the module got up - the hardest part is behind,” I thought ... The veeam package for the deb repository is for the amd64 platform, and the Elbrus OS 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 the Elbrus OS. This annoying misunderstanding is eliminated in an elementary way: it is enough to parse the package, correct the information about the architecture and collect it back. How to do it googled instantly.
mkdir tmp
dpkg-deb -R original.deb tmp
# edit DEBIAN/postinst
dpkg-deb -b tmp fixed.deb
Another problem is dependencies. The necessary files seem to be there, but there are no packages. There was an impression that the names of the packages differ from “foreign analogues”. Libraries may be bundled differently. I did not go deep into the details, removed almost all the dependencies, and the installation went.
Next came up problems with the service start code. There was no script /lib/init/vars.sh. For some reason, “Elbrus” is doing without it, so we will remove it as well. Then we had to replace the message output function: there were no functions log_daemon_msg and log_end_msg. Rummaging around in the file / lib / lsb / init-functions, I found the function log_success_msg - it will work for us 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 processing of the package with a file, the entire-machine backup on the NFS ball successfully started. The backup mount was also successful. So, I suppose, for backing up a machine with the Elbrus PDK, downloaded for "just like that" without any obligation, Veeam Agent for Linux is definitely suitable. Even after all the modifications with a file.
Of course, formally, the Elbrus OS distribution is not supported, as it is not included in the list of supported ones. In addition, Veeam Agent for Linux on it was not tested by the QA department, so those. no support (at least at the time of publication of the article).
I hope this article will be useful to those who are trying to implement order No. 334 of June 29, 2017. Mine to you ... [TBD].