Linux Backup from Veeam on Elbrus OS. Import substitution ['?' | '.' | '!']

Hello.
Recent articles on habré Import substitution in practice. Part 1. Options и The music did not play for a long time ... or how the Elbrus OS did not become 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 precisely in the context of import substitution.

Linux Backup from Veeam on Elbrus OS. Import substitution ['?' | '.' | '!']
source 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 who want to know what came of it, please under cat.

So, a small digression, otherwise suddenly someone does not know. "Elbrus" is CPU with a rather specific command system. In addition to it, there is the Elbrus OS software. And - contrary to a common misconception - for the Elbrus OS to work, it is not necessary to have a hardware complex based on the Elbrus processor. There is "PDK" Elbrus "for x86" - in fact, he appeared in the public domain in the form of an installation disk. By the way, there is a footnote “PDK - platform development kit, developer kit” - excellent, which means that there is at least a compiler there.

Another small forced retreat. The fact is that I once dealt with domestic software, such as "MSVS" and RTOS "Baguette". There was experience in working with the domestic element base, including the processor from the MCST. Therefore, with all 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 really want to, I will put the [TBD] tag. So we will try to do without outright trolling and banal moans. In the end, the Russian defense industry and government agencies need to be understood. Big country, small budget. [TBD].

Zero stage - download. It is noteworthy that the news that the Elbrus OS became available caused a resonance, so much so that the distribution server lay down. [TBD] Thanks to Yandex and the engineer who thought of moving it there. So the download speed pleases.

The first stage - installation. I put on the first hypervisor that came free for free use. I allocated two cores, a couple of gigs of RAM, 32 MB for video (there will be a graphical interface, I thought). Disochek as usual - 32 GB.
Started the installation. I did not use the installation instructions, so I can not comment on it. The TUI installation interface is severely minimalistic.

Linux Backup from Veeam on Elbrus OS. Import substitution ['?' | '.' | '!']
Well, great, without a mouse, then we can do it.

With the next window, I coped with the second attempt. Why not choose sr0 [TBD] as the default device when installing from disk?
Select the CD-ROM source and move on.

Linux Backup from Veeam on Elbrus OS. Import substitution ['?' | '.' | '!']

When choosing a time zone, I suddenly realized that the system was using the init boot process and I was working from TTY0.

Linux Backup from Veeam on Elbrus OS. Import substitution ['?' | '.' | '!']

OK, then we will attribute Elbrus to the community Old Believers[TBD]. In principle, this is good: you don’t need to ask for the source code to see how the download process works, since everything is in 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, Debian 7 had 3.2 [TBD].

Next, select the default partitioning of the disk and ... We see a warning:

Linux Backup from Veeam on Elbrus OS. Import substitution ['?' | '.' | '!']

Hmm, somehow the automatic partitioning coped with a 32 gig disk poorly. I did not change the disk, I passed the quest with manual disk marking 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 - search for alternatives.
Having rummaged with the contents of the second disk, I realized that this is a repository with additional. packages. And looking at /etc/apt/sources.list, I realized that it needs to be mounted in /mnt/cdrom. But I did not find /etc/os-release. But there is /etc/mcst-version with contents 3.0-rc36. 3.0 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 the eye, and there, with bated breath, I discovered /mcst/backup. That is, there is a backup tool, and it is built into the system! “Great,” I thought, “Let’s see how it works!”

It turned out that there is a 4Kb bash script /mcst/bin/backup that provides file copying. By default, 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 command looks something like this:

cp -rpdx <file backup> <file>

The entire /mcst/bin/backup file is hereI immediately warn you that this script alone is not enough for a complete understanding. It pulls functions from /mcst/bin/source which is some kind of function library. I did not bring it (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

But maybe I don't understand something? 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 the /mcst/bin/backup application.

Next, I decided to put a fresh Veeam Agent for Linux. Someone will ask: “What does Veeam and import substitution have to do with it?” Yes, it is not in the registry, but it is certified by the FSTEC, which means that if there are no alternatives, it can be used. After spending fifteen minutes on alternatives from Registry, I was able to find 3 links for the word "backup" (none related to my question, for the word "reserve"). I haven't done a deep analysis of these programs, so I won't try to judge how suitable they are for backing up Linux machines. Whoever needs it will make a conclusion himself and share it in the comments.

Stage three - installation of Veeam Agent for Linux.
So, Veeam Agent for Linux consists of two packages: the veeamsnap kernel module (by the way, source here) and proprietary user-space code as the veeam package.

There was one small problem with installing the kernel module - the lack of a 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 the architecture, so I got up like a native. Why was it not included in the list of available packages, or rather, [TBD] was not developed? Perhaps it is intended that no one should build and run any non-MCST kernel modules. There really is a hitch here - since there are linux-headers. That is, the module, if desired, can be assembled by hand and run at the start of the machine with a script. I don't think you should expect frequent updates from MCST [TBD].

“OK, the module is up – the hardest part is over,” I thought… The veeam package for the deb repository is available for the amd64 platform, while 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 unfortunate misunderstanding is eliminated in an elementary way: it is enough to disassemble the package, correct the information about the architecture and assemble 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. I got the impression that the names of the packages are different from "import analogues". Perhaps the libraries are packaged differently. I did not go into details, removed almost all dependencies, and the installation went.

Next, problems with the service start code surfaced. The /lib/init/vars.sh script was missing. For some reason, Elbrus does without it, so we will also remove it. Next, I had to replace the message output function: there were no log_daemon_msg and log_end_msg functions. Digging through the /lib/lsb/init-functions file, I found the log_success_msg function - it will do 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-share successfully started. Mount backup was also successful. So, I believe, for backing up a machine with the Elbrus PDK, downloaded for "just like that" without any obligations, Veeam Agent for Linux will definitely fit. Even after all the file modifications.

Of course, the Elbrus OS distribution kit is not formally supported, since 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. there is 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 order No. 334 of 29.06.2017/XNUMX/XNUMX. Mine to you… [TBD].

Source: habr.com

Add a comment