Linux ih01.iridiumhosting.com 5.14.0-611.5.1.el9_7.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Nov 11 08:09:09 EST 2025 x86_64
LiteSpeed
Server IP : 67.227.241.211 & Your IP : 216.73.216.226
Domains :
Cant Read [ /etc/named.conf ]
User : dustinhy
Terminal
Auto Root
Create File
Create Folder
Localroot Suggester
Backdoor Destroyer
Readme
/
opt /
MXB /
rear /
doc /
user-guide /
Delete
Unzip
Name
Size
Permission
Date
Action
pictures
[ DIR ]
drwxr-xr-x
2026-04-01 09:39
00-relax-and-recover-user-guide.md
354
B
-rw-r--r--
2026-04-01 09:39
01-introduction.md
4.23
KB
-rw-r--r--
2026-04-01 09:39
02-getting-started.md
4.87
KB
-rw-r--r--
2026-04-01 09:39
03-configuration.md
8.09
KB
-rw-r--r--
2026-04-01 09:39
04-scenarios.md
55.4
KB
-rw-r--r--
2026-04-01 09:39
05-integration.md
4.08
KB
-rw-r--r--
2026-04-01 09:39
06-layout-configuration.md
33.13
KB
-rw-r--r--
2026-04-01 09:39
07-tips-and-tricks.md
1.8
KB
-rw-r--r--
2026-04-01 09:39
08-troubleshooting.md
5.3
KB
-rw-r--r--
2026-04-01 09:39
09-design-concepts.md
9.34
KB
-rw-r--r--
2026-04-01 09:39
10-integrating-external-backup.md
5
KB
-rw-r--r--
2026-04-01 09:39
11-multiple-backups.md
13.3
KB
-rw-r--r--
2026-04-01 09:39
12-BLOCKCLONE.md
30.25
KB
-rw-r--r--
2026-04-01 09:39
13-tcg-opal-support.md
15.12
KB
-rw-r--r--
2026-04-01 09:39
14-ZYPPER-and-YUM.md
12.32
KB
-rw-r--r--
2026-04-01 09:39
15-EFISTUB.md
12.43
KB
-rw-r--r--
2026-04-01 09:39
16-Rubrik-CDM.md
5.41
KB
-rw-r--r--
2026-04-01 09:39
17-Portable-Mode.md
2.4
KB
-rw-r--r--
2026-04-01 09:39
Makefile
438
B
-rw-r--r--
2026-04-01 09:39
Save
Rename
# Using Multiple Backups for Relax-and-Recover ## Basics Currently multiple backups are only supported for: * the internal BACKUP=NETFS method with BACKUP_TYPE="" * the internal BACKUP=BLOCKCLONE method * the external BACKUP=BORG method In general multiple backups are not supported for BACKUP_TYPE=incremental or BACKUP_TYPE=differential because those require special backup archive file names. ### The basic idea behind A "rear mkbackup" run can be split into a "rear mkrescue" run plus a "rear mkbackuponly" run and the result is still the same. Accordingly "rear mkbackup" can be split into a single "rear mkrescue" plus multiple "rear mkbackuponly" where each particular "rear mkbackuponly" backups only a particular part of the files of the system, for example: * a backup of the files of the basic system * a backup of the files in the /home directories * a backup of the files in the /opt directory Multiple "rear mkbackuponly" require that each particular "rear mkbackuponly" uses a specific ReaR configuration file that specifies how that particular "rear mkbackuponly" must be done. Therefore the '-C' command line parameter is needed where an additional ReaR configuration file can be specified. ### The basic way how to create multiple backups Have common settings in /etc/rear/local.conf For each particular backup specify its parameters in separated additional configuration files like /etc/rear/basic_system.conf /etc/rear/home_backup.conf /etc/rear/opt_backup.conf First create the ReaR recovery/rescue system ISO image together with a backup of the files of the basic system: rear -C basic_system mkbackup Then backup the files in the /home directories: rear -C home_backup mkbackuponly Afterwards backup the files in the /opt directory: rear -C opt_backup mkbackuponly ### The basic way how to recover with multiple backups The basic idea how to recover with multiple backups is to split the "rear recover" into an initial recovery of the basic system followed by several backup restore operations as follows: Boot the ReaR recovery/rescue system. In the ReaR recovery/rescue system do the following: First recover the basic system: rear -C basic_system recover Then restore the files in the /home directories: rear -C home_backup restoreonly Afterwards restore the files in the /opt directory: rear -C opt_backup restoreonly Finally reboot the recreated system. For more internal details and some background information see [https://github.com/rear/rear/issues/1088](https://github.com/rear/rear/issues/1088) ### How to recover with multiple backups in 'auto_recover'/'automatic' or 'unattended' mode The RECOVERY_COMMANDS array specifies the "rear recover" commands that are automatically called after the ReaR recovery system has started up to recreate the system in 'auto_recover'/'automatic' or 'unattended' mode. So in the above example where the commands rear -C basic_system recover rear -C home_backup restoreonly rear -C opt_backup restoreonly are manually typed in one after the other those commands need to be specified as RECOVERY_COMMANDS array to recover with multiple backups in 'auto_recover'/'automatic' or 'unattended' mode for example like RECOVERY_COMMANDS=( "echo Unattended recovery starts in $USER_INPUT_INTERRUPT_TIMEOUT seconds" "sleep $USER_INPUT_INTERRUPT_TIMEOUT" "rear -n -C basic_system recover" "rear -n -C home_backup restoreonly" "rear -n -C opt_backup restoreonly" ) RECOVERY_COMMANDS_LABEL="Recovery of basic_system with home_backup and opt_backup restore" See the RECOVERY_COMMANDS description in usr/share/rear/conf/default.conf (and as needed also the REBOOT_COMMANDS description therein). ## Relax-and-Recover Setup for Multiple Backups Assume for example multiple backups should be done using the NETFS backup method with 'tar' as backup program to get separated backups for: * the files of the basic system * the files in the /home directories * the files in the /opt directory Those four configuration files could be used: `./etc/rear/local.conf` OUTPUT=ISO BACKUP=NETFS BACKUP_OPTIONS="nfsvers=3,nolock" BACKUP_URL=nfs://your.NFS.server.IP/path/to/your/rear/backup `./etc/rear/basic_system.conf` this_file_name=$( basename ${BASH_SOURCE[0]} ) LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}.log" BACKUP_PROG_EXCLUDE+=( '/home/*' '/opt/*' ) BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}" `./etc/rear/home_backup.conf` this_file_name=$( basename ${BASH_SOURCE[0]} ) LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}.log" BACKUP_ONLY_INCLUDE="yes" BACKUP_PROG_INCLUDE=( '/home/*' ) BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}" `./etc/rear/opt_backup.conf` this_file_name=$( basename ${BASH_SOURCE[0]} ) LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}.log" BACKUP_ONLY_INCLUDE="yes" BACKUP_PROG_INCLUDE=( '/opt/*' ) BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}" The BACKUP_ONLY_INCLUDE setting is described in conf/default.conf. With those config files creating the ReaR recovery/rescue system ISO image and subsequently backup the files of the system could be done like: rear mkrescue rear -C basic_system mkbackuponly rear -C home_backup mkbackuponly rear -C opt_backup mkbackuponly Recovery of that system could be done by calling in the ReaR recovery/rescue system: rear -C basic_system recover rear -C home_backup restoreonly rear -C opt_backup restoreonly Note that system recovery with multiple backups requires that first and foremost the basic system is recovered where all files must be restored that are needed to install the bootloader and to boot the basic system into a normal usable state. Nowadays systemd usually needs files in the /usr directory so that in practice in particular all files in the /usr directory must be restored during the initial basic system recovery plus whatever else is needed to boot and run the basic system. Multiple backups cannot be used to split the files of the basic system into several backups. The files of the basic system must be in one single backup and that backup must be restored during the initial recovery of the basic system. ## Relax-and-Recover Setup for Different Backup Methods Because multiple backups are used via separated additional configuration files, different backup methods can be used. Assume for example multiple backups should be used to get separated backups for the files of the basic system using the NETFS backup method with 'tar' as backup program and to backup the files in the /home directory using the BORG backup method. The configuration files could be like the following: `./etc/rear/local.conf` OUTPUT=ISO REQUIRED_PROGS+=( borg locale ) COPY_AS_IS+=( "/borg/keys" ) `./etc/rear/basic_system.conf` this_file_name=$( basename ${BASH_SOURCE[0]} ) LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}.log" BACKUP_PROG_EXCLUDE+=( '/home/*' ) BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}" BACKUP=NETFS BACKUP_OPTIONS="nfsvers=3,nolock" BACKUP_URL=nfs://your.NFS.server.IP/path/to/your/rear/backup `./etc/rear/home_backup.conf` this_file_name=$( basename ${BASH_SOURCE[0]} ) LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}.log" BACKUP=BORG BACKUP_ONLY_INCLUDE="yes" BACKUP_PROG_INCLUDE=( '/home/*' ) BORGBACKUP_ARCHIVE_PREFIX="rear" BORGBACKUP_HOST="borg.server.name" BORGBACKUP_USERNAME="borg_server_username" BORGBACKUP_REPO="/path/to/borg/repository/on/borg/server" BORGBACKUP_PRUNE_KEEP_HOURLY=5 BORGBACKUP_PRUNE_KEEP_WEEKLY=2 BORGBACKUP_COMPRESSION="zlib,9" BORGBACKUP_ENC_TYPE="keyfile" export BORG_KEYS_DIR="/borg/keys" export BORG_CACHE_DIR="/borg/cache" export BORG_PASSPHRASE='a1b2c3_d4e5f6' export BORG_RELOCATED_REPO_ACCESS_IS_OK="yes" export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK="yes" export BORG_REMOTE_PATH="/usr/local/bin/borg" Using different backup methods requires to get all the binaries and all other needed files of all used backup methods into the ReaR recovery/rescue system during "rear mkbackup/mkrescue". Those binaries and other needed files must be manually specified via REQUIRED_PROGS and COPY_AS_IS in /etc/rear/local.conf (regarding REQUIRED_PROGS and COPY_AS_IS see conf/default.conf). With those config files creating the ReaR recovery/rescue system ISO image together with a 'tar' backup of the files of the basic system and a separated Borg backup of the files in /home could be done like: rear -C home_backup mkbackuponly rear -C basic_system mkbackup In contrast to the other examples above the Borg backup is run first because Borg creates encryption keys during repository initialization. This ensures the right /borg/keys is created before it will be copied into the ReaR recovery/rescue system by the subsequent "rear mkbackup/mkrescue". Alternatively the ReaR recovery/rescue system could be created again after the Borg backup is done like: rear -C basic_system mkbackup rear -C home_backup mkbackuponly rear -C basic_system mkrescue Recovery of that system could be done by calling in the ReaR recovery/rescue system: rear -C basic_system recover rear -C home_backup restoreonly ## Running Multiple Backups and Restores in Parallel When the files in multiple backups are separated from each other it should work to run multiple backups or multiple restores in parallel. Whether or not that actually works in your particular case depends on how you made the backups in your particular case. For sufficiently well separated backups it should work to run multiple different rear -C backup_config mkbackuponly or multiple different rear -C backup_config restoreonly in parallel. Running in parallel is only supported for mkbackuponly and restoreonly. For example like rear -C backup1 mkbackuponly & rear -C backup2 mkbackuponly & wait or rear -C backup1 restoreonly & rear -C backup2 restoreonly & wait ReaR's default logging is not prepared for multiple simultaneous runs and also ReaR's current progress subsystem is not prepared for that. On the terminal the messages from different simultaneous runs are indistinguishable and the current progress subsystem additionally outputs subsequent messages on one same line which results illegible and meaningless output on the terminal. Therefore additional parameters must be set to make ReaR's messages and the progress subsystem output appropriate for parallel runs. Simultaneously running ReaR workflows require unique messages and unique logfile names. Therefore the PID ('$$') is specified to be used as message prefix for all ReaR messages and it is also added to the LOGFILE value. The parameters MESSAGE_PREFIX PROGRESS_MODE and PROGRESS_WAIT_SECONDS are described in conf/default.conf. For example a setup for parallel runs of mkbackuponly and restoreonly could look like the following: `./etc/rear/local.conf` OUTPUT=ISO BACKUP=NETFS BACKUP_OPTIONS="nfsvers=3,nolock" BACKUP_URL=nfs://your.NFS.server.IP/path/to/your/rear/backup MESSAGE_PREFIX="$$: " PROGRESS_MODE="plain" PROGRESS_WAIT_SECONDS="3" `./etc/rear/basic_system.conf` this_file_name=$( basename ${BASH_SOURCE[0]} ) LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}-$$.log" BACKUP_PROG_EXCLUDE+=( '/home/*' '/opt/*' ) BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}" `./etc/rear/home_backup.conf` LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}-$$.log" BACKUP_ONLY_INCLUDE="yes" BACKUP_PROG_INCLUDE=( '/home/*' ) BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}" `./etc/rear/opt_backup.conf` this_file_name=$( basename ${BASH_SOURCE[0]} ) LOGFILE="$LOG_DIR/rear-$HOSTNAME-$WORKFLOW-${this_file_name%.*}-$$.log" BACKUP_ONLY_INCLUDE="yes" BACKUP_PROG_INCLUDE=( '/opt/*' ) BACKUP_PROG_ARCHIVE="backup-${this_file_name%.*}" With those config files creating the ReaR recovery/rescue system ISO image together with a backup of the files of the basic system and then backup the files in /home and /opt in parallel could be done like: rear -C basic_system mkbackup rear -C home_backup mkbackuponly & rear -C opt_backup mkbackuponly & wait Recovery of that system could be done by calling in the ReaR recovery/rescue system: rear -C basic_system recover rear -C home_backup restoreonly & rear -C opt_backup restoreonly & wait Even on a relatively small system with a single CPU running multiple backups and restores in parallel can be somewhat faster compared to sequential processing. On powerful systems with multiple CPUs, much main memory, fast storage access, and fast access to the backups it is in practice mandatory to split a single huge backup of the whole system into separated parts and run at least the restores in parallel to utilize powerful hardware and be as fast as possible in case of emergency and time pressure during a real disaster recovery. Remember that system recovery with multiple backups requires that first and foremost the basic system is recovered where all files must be restored that are needed to install the bootloader and to boot the basic system into a normal usable state so that 'rear recover' cannot run in parallel with 'rear restoreonly'.