-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In RAWDISK recovery mode, auto disk mapping is not working #1852
Comments
@GreenBlood All looks perfectly fine to me and works exactly as it should It automatically detects that sda is not the expected one Comparing disks Device sda has size 95420416 but 21474836480 is expected (needs manual configuration) Switching to manual disk layout configuration and then it automatically finds that sdb has the expected size Using /dev/sdb (same size) for recreating /dev/sda so that it automatically creates the disk mapping proposal Current disk mapping table (source -> target): /dev/sda /dev/sdb and asks for your confirmation that this is really Confirm or edit the disk mapping 1) Confirm disk mapping and continue 'rear recover' 2) Edit disk mapping (/var/lib/rear/layout/disk_mappings) 3) Use Relax-and-Recover shell and return back to here 4) Abort 'rear recover' (default '1' timeout 300 seconds) where you could use item @GreenBlood FYI: # Relax-and-Recover UserInput function default behaviour ... # USER_INPUT_TIMEOUT # USER_INPUT_INTERRUPT_TIMEOUT # USER_INPUT_PROMPT # USER_INPUT_MAX_CHARS # USER_INPUT_user_input_ID in usr/share/rear/conf/default.conf |
@jsmeix Well let me briefly explain you my use case. I use rear to automate the recovery processes of linux servers in a cloud environnement. I used to generate a rescue ISO, boot it on a VM with all the disks expected, and using the unattended mode and some fiddling, restored the server automatically. Now I recently changed my cloud environment and was not able anymore to boot on ISO, hence my use of RAWDISK. The issue I'm having is that because of the sda=>sdb mapping thing, the automated workflow is interrupted. I have no issue with how rear builds the mapping, but I'd wish to know if it's possible to, by default, accept all changes, because the source sda and dest sdb are the same size, imho it would make sense to me to be able to just say to rear "do your thing" EDIT : As I read the UserInput section in default.conf, I think I understand how I would do it. I'd have to set a default value for all input that might come up using |
@GreenBlood USER_INPUT_TIMEOUT=1 in your etc/rear/local.conf In your case you cannot use For example how things look for me with # export USER_INPUT_TIMEOUT=1 # rear -D recover Relax-and-Recover 2.4 / Git Using log file: /var/log/rear/rear-d228.log Running workflow recover within the ReaR rescue/recovery system Starting required daemons for NFS: RPC portmapper (portmap or rpcbind) and rpc.statd if available. Started RPC portmapper 'rpcbind'. RPC portmapper 'rpcbind' available. RPC status rpc.statd available. Using backup archive '/tmp/rear.Tt2PwYPVHGbJsLD/outputfs/d228/backup.tar.gz' Will do driver migration (recreating initramfs/initrd) Calculating backup archive size Backup archive size is 1.1G /tmp/rear.Tt2PwYPVHGbJsLD/outputfs/d228/backup.tar.gz (compressed) Comparing disks Ambiguous possible target disks need manual configuration (more than one with same size found) Switching to manual disk layout configuration Using /dev/sda (same name and same size) for recreating /dev/sda Current disk mapping table (source -> target): /dev/sda /dev/sda UserInput -I LAYOUT_MIGRATION_CONFIRM_MAPPINGS needed in /usr/share/rear/layout/prepare/default/300_map_disks.sh line 211 Confirm or edit the disk mapping 1) Confirm disk mapping and continue 'rear recover' 2) Edit disk mapping (/var/lib/rear/layout/disk_mappings) 3) Use Relax-and-Recover shell and return back to here 4) Abort 'rear recover' (default '1' timeout 1 seconds) UserInput: No real user input (empty or only spaces) - using default input UserInput: Valid choice number result 'Confirm disk mapping and continue 'rear recover'' Continuing 'rear recover' by default Examining /dev/sda to automatically resize its last active partition Skipping /dev/sda (size of new disk same as size of old disk) UserInput -I LAYOUT_FILE_CONFIRMATION needed in /usr/share/rear/layout/prepare/default/500_confirm_layout_file.sh line 26 Confirm or edit the disk layout file 1) Confirm disk layout and continue 'rear recover' 2) Edit disk layout (/var/lib/rear/layout/disklayout.conf) 3) View disk layout (/var/lib/rear/layout/disklayout.conf) 4) View original disk space usage (/var/lib/rear/layout/config/df.txt) 5) Use Relax-and-Recover shell and return back to here 6) Abort 'rear recover' (default '1' timeout 1 seconds) UserInput: No real user input (empty or only spaces) - using default input UserInput: Valid choice number result 'Confirm disk layout and continue 'rear recover'' Continuing 'rear recover' by default Doing SLES12-SP1 (and later) btrfs subvolumes setup because the default subvolume path contains '@/.snapshots/' UserInput -I LAYOUT_CODE_CONFIRMATION needed in /usr/share/rear/layout/recreate/default/100_confirm_layout_code.sh line 26 Confirm or edit the disk recreation script 1) Confirm disk recreation script and continue 'rear recover' 2) Edit disk recreation script (/var/lib/rear/layout/diskrestore.sh) 3) View disk recreation script (/var/lib/rear/layout/diskrestore.sh) 4) View original disk space usage (/var/lib/rear/layout/config/df.txt) 5) Use Relax-and-Recover shell and return back to here 6) Abort 'rear recover' (default '1' timeout 1 seconds) UserInput: No real user input (empty or only spaces) - using default input UserInput: Valid choice number result 'Confirm disk recreation script and continue 'rear recover'' Continuing 'rear recover' by default Start system layout restoration. Creating partitions for disk /dev/sda (gpt) Creating filesystem of type btrfs with mount point / on /dev/sda2. Mounting filesystem / Running snapper/installation-helper Creating filesystem of type xfs with mount point /home on /dev/sda4. Mounting filesystem /home Creating swap on /dev/sda3 Disk layout created. UserInput -I LAYOUT_MIGRATED_CONFIRMATION needed in /usr/share/rear/layout/recreate/default/200_run_layout_code.sh line 98 Confirm the recreated disk layout or go back one step 1) Confirm recreated disk layout and continue 'rear recover' 2) Go back one step to redo disk layout recreation 3) Use Relax-and-Recover shell and return back to here 4) Abort 'rear recover' (default '1' timeout 1 seconds) UserInput: No real user input (empty or only spaces) - using default input UserInput: Valid choice number result 'Confirm recreated disk layout and continue 'rear recover'' Continuing with recreated disk layout by default Restoring from '/tmp/rear.Tt2PwYPVHGbJsLD/outputfs/d228/backup.tar.gz' (restore log in /var/lib/rear/restore/recover.backup.tar.gz.1866.restore.log) ... Backup restore program 'tar' started in subshell (PID=4795) Restored 12 MiB [avg. 4298 KiB/sec] Restored 116 MiB [avg. 19859 KiB/sec] Restored 251 MiB [avg. 28627 KiB/sec] Restored 453 MiB [avg. 38658 KiB/sec] Restored 636 MiB [avg. 43443 KiB/sec] Restored 853 MiB [avg. 48551 KiB/sec] Restored 1008 MiB [avg. 49171 KiB/sec] Restored 1219 MiB [avg. 52035 KiB/sec] Restored 1428 MiB [avg. 54162 KiB/sec] Restored 1582 MiB [avg. 54009 KiB/sec] Restored 1792 MiB [avg. 55631 KiB/sec] Restored 2008 MiB [avg. 57123 KiB/sec] Restored 2190 MiB [avg. 57508 KiB/sec] Restored 2433 MiB [avg. 59330 KiB/sec] OK Restored 2444 MiB in 45 seconds [avg. 55630 KiB/sec] Restoring finished (verify backup restore log messages in /var/lib/rear/restore/recover.backup.tar.gz.1866.restore.log) Recreating directories (with permissions) from /var/lib/rear/recovery/directories_permissions_owner_group UserInput -I RESTORED_FILES_CONFIRMATION needed in /usr/share/rear/finalize/default/020_confirm_finalize.sh line 35 Confirm restored config files or edit them 1) Confirm it is OK to recreate initrd and reinstall bootloader and continue 'rear recover' 2) Edit restored etc/fstab (/mnt/local/etc/fstab) 3) View restored etc/fstab (/mnt/local/etc/fstab) 4) Use Relax-and-Recover shell and return back to here 5) Abort 'rear recover' (default '1' timeout 1 seconds) UserInput: No real user input (empty or only spaces) - using default input UserInput: Valid choice number result 'Confirm it is OK to recreate initrd and reinstall bootloader and continue 'rear recover'' Continuing 'rear recover' by default Applying disk layout mappings in /var/lib/rear/layout/disk_mappings to certain restored files... The original restored files get saved in var/lib/rear/saved_original_files/ (in /mnt/local) Applied disk layout mappings to restored 'boot/grub2/grub.cfg' (in /mnt/local) Applied disk layout mappings to restored 'boot/grub2/device.map' (in /mnt/local) Applied disk layout mappings to restored 'etc/sysconfig/bootloader' (in /mnt/local) Applied disk layout mappings to restored 'etc/fstab' (in /mnt/local) Applied disk layout mappings to restored 'etc/mtools.conf' (in /mnt/local) Applied disk layout mappings to restored 'etc/smartd.conf' (in /mnt/local) Applied disk layout mappings to restored 'etc/sysconfig/smartmontools' (in /mnt/local) Patching /etc/default/grub_installdevice: Replacing [/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001] by [/dev/disk/by-id/ata-QEMU_HARDDISK_QM00003] Updating udev configuration (70-persistent-net.rules) Running mkinitrd... Recreated initrd (/sbin/mkinitrd). Installing GRUB2 boot loader... Determining where to install GRUB2 (no GRUB2_INSTALL_DEVICES specified) Found possible boot disk /dev/sda - installing GRUB2 there Finished recovering your system. You can explore it under '/mnt/local'. Exiting rear recover (PID 1866) and its descendant processes Running exit tasks I.e. all those Perhaps I found a possible problem with the disk migration In the above terminal output (I use latest GitHub master code) Applying disk layout mappings in /var/lib/rear/layout/disk_mappings to certain restored files... The original restored files get saved in var/lib/rear/saved_original_files/ (in /mnt/local) Applied disk layout mappings to restored 'boot/grub2/grub.cfg' (in /mnt/local) Applied disk layout mappings to restored 'boot/grub2/device.map' (in /mnt/local) Applied disk layout mappings to restored 'etc/sysconfig/bootloader' (in /mnt/local) Applied disk layout mappings to restored 'etc/fstab' (in /mnt/local) Applied disk layout mappings to restored 'etc/mtools.conf' (in /mnt/local) Applied disk layout mappings to restored 'etc/smartd.conf' (in /mnt/local) Applied disk layout mappings to restored 'etc/sysconfig/smartmontools' (in /mnt/local) Patching /etc/default/grub_installdevice: Replacing [/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001] by [/dev/disk/by-id/ata-QEMU_HARDDISK_QM00003] Those changes had happened all the time but since That part is from scripts like But in your particular case I assume But the above scripts had modified certain files on the recreated system. |
@GreenBlood Some remarks:
Block device names (and by the way, the virtual ISO optical drive is also a block device) are assigned by the respective kernel driver in initialization order. (For some information on bus-based naming, see Device Names and Persistent block device naming - ArchWiki.) In my view the easiest option for you would be to present your recovery boot device to the kernel either
It looks like QEMU has very limited boot options but may boot anyway from secondary devices if the first hard disk is not bootable, so some ideas:
|
I made #1854 |
I think the initial question in this issue how to The possible problems that could happen when |
full log.log
Relax-and-Recover 2.4-git.0.26e6eec.unknown / 2018-07-03
(From PR RAWDISK output portability improvements (fix #1846) #1850 )
CentOS 6.9
x86_64 (amd64)
BIOS
When using RAWDISK recovery environment to restore a server, the disk layout configuration (mapping) does not work correctly.
Because RAWDISK acts as a block device, it is recognized as (in my case)
sda
, so the root partition of the disk to be restored becomessdb
. When runningrear recover
, it should automagically find the appropriate disk based on its size. But here it does not work.As an information, source disk and the destination disk are litteraly the same, I merely boot the virtual machine on the recovery environnement. So size is the same.
Logs for
rear -D recover
:(Was asked by @jsmeix to post this issue)
Regards,
Green
EDIT : Added debug log, 300_map_disks.sh begins at line 15345
The text was updated successfully, but these errors were encountered: