#227 Issue closed
: recovery on smaller disks¶
Labels: support / question
, fixed / solved / done
wdpoorte opened issue at 2013-04-12 13:19:¶
When recovering a server on a VM with smaller disks, I get an error during layout creation. The system has some not-used partitions labeled as PVs (for possible future use by applications).
When I uncomment these partitions, together with the corresponding lvmdev lines, the recovery goes smoothly.
We use the following in our config:
ONLY_INCLUDE_VG=( "vg00" )
It would be a good idea according to me if you could modify the code so that unused partitions and PVs are excluded from the disklayout.
disklayout:
#disk /dev/sda 10737745920 msdos
disk /dev/sdb 146778685440 msdos
part /dev/sdb 536870912 1048576 primary boot /dev/sdb1
part /dev/sdb 68719476736 537919488 primary lvm /dev/sdb2
part /dev/sdb 24121442304 69257396224 primary none /dev/sdb3
part /dev/sdb 1024 93378838528 extended none /dev/sdb4
part /dev/sdb 44500516864 93379887104 logical lvm /dev/sdb5
part /dev/sdb 8897167360 137881452544 logical lvm /dev/sdb6
#disk /dev/sdc 10737745920 msdos
lvmdev /dev/vg00 /dev/sdb2 9PIZAC-p8uE-iUCg-4Nez-3cv7-q1Mn-Tt91te 134217728
#lvmdev /dev/vg_data /dev/mapper/mpathbp2 hDdsZq-xZ3z-Tlch-2yM6-eKH1-6qvY-crKZtW 20916630
lvmdev /dev/#orphans_lvm2 /dev/sdb5 Eg2A17-Top3-zugP-V9XR-s1lD-3GMc-NaGQK3 86915072
lvmdev /dev/#orphans_lvm2 /dev/sdb6 Y6NAmW-hnfj-Cl73-l9V7-nDA8-KpZO-jceoP6 17377280
lvmgrp /dev/vg00 32768 2047 67076096
#lvmgrp /dev/vg_data 4096 2553 10457088
lvmvol /dev/vg00 lv00 256 16777216
lvmvol /dev/vg00 lv01 256 16777216
lvmvol /dev/vg00 lv02 256 16777216
lvmvol /dev/vg00 lv03 256 16777216
lvmvol /dev/vg00 lv04 256 16777216
lvmvol /dev/vg00 lv05 256 16777216
lvmvol /dev/vg00 lv06 81 5308416
#lvmvol /dev/vg_data lv_data 2000 16384000
fs /dev/mapper/vg00-lv00 / ext3 uuid=74f9aa74-dd67-4ae5-9344-9381585f7d19 label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16384 options=rw
fs /dev/sdb1 /boot ext3 uuid=d5b2ad22-1534-4f4c-8f00-6adac825f93e label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16384 options=rw
fs /dev/mapper/vg00-lv05 /home ext3 uuid=141b6688-8192-438e-a83b-d4afe18c72a5 label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16384 options=rw
fs /dev/mapper/vg00-lv01 /opt ext3 uuid=67e9e9ab-ffb4-4f4b-8a67-84349ae84c1c label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16384 options=rw
fs /dev/mapper/vg00-lv02 /tmp ext3 uuid=c74bc757-d860-4106-a039-cf3cf800116e label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16384 options=rw
fs /dev/mapper/vg00-lv03 /usr ext3 uuid=2852b22d-663f-45f9-b3e4-9d8db7ff6eeb label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16384 options=rw
fs /dev/mapper/vg00-lv06 /usr/openv ext3 uuid=87f1b2e7-83e5-47c6-93db-d4edcb21e8be label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16374 options=rw
fs /dev/mapper/vg00-lv04 /var ext3 uuid=6e88469c-2561-4ec9-bee5-8790e073469d label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16384 options=rw
swap /dev/sdb3 uuid=8ca85cce-3053-440e-b4a7-302914bc38aa label=
logicaldrive /dev/sdb 0|A|1 raid=1 drives=1I:1:1,1I:1:2, spares= sectors=32 stripesize=256
smartarray 0
#multipath /dev/mapper/mpathb /dev/sda,/dev/sdc
#part /dev/mapper/mpathb 24643584 unknown primary boot /dev/mapper/mpathbp1
#part /dev/mapper/mpathb 10709314560 unknown primary none /dev/mapper/mpathbp2
gdha commented at 2013-05-07 12:29:¶
could you give an example of before/after your changes? This will make me see the diffs better. Thanks Werner.
dagwieers commented at 2013-06-07 16:58:¶
I don't think excluding unused partitions or volumes during recovery is what most people would expect. Sure, in your case it would be better to get rid of them in order to have the recovery work, but recovering to smaller disks is not something we advise to do, there are many other issues that are hard to impossible to cover when doing a recovery to smaller disks.
The fact that you were able to recover in this case by manually adapting the configuration is exactly how it was designed for cases like yours.
If one does have ample diskspace, one would expect a system that is exactly the same, including unused partitions and unused logical volumes. If you expect such unused entries to not be around, I would suggest not creating them in the first place, until the moment you need them... ;-)
dagwieers commented at 2013-06-07 17:04:¶
Hmm, there's one thing I do not understand from the report. You only include vg00, still you mention that the creation fails unless you uncomment the stuff you excluded explicitely. This seems more like a bug.
Can you provide us with a debug log of the failed layout creation as well as the necessary layout-file ? Without this it is impossible to understand what is going on :-/
gdha commented at 2013-11-04 15:30:¶
@wdpoorte is there a way to reproduce this?
gdha commented at 2015-02-03 09:36:¶
@wdpoorte the disklayout you pasted above was that a modified one or original before the changes??
gdha commented at 2015-09-23 11:57:¶
The orphans VGs are filtered out since rear-1.16
./layout/save/GNU/Linux/34_false_blacklisted.sh:get_child_components "$blockdev" | grep "^/dev" | grep -v "\#orphans" >> "$TMP_DIR/blacklisted.devices"
[Export of Github issue for rear/rear.]