[rear-users] rear auto_resize_disks

Jeroen Hoekx jeroen.hoekx at hamok.be
Thu Apr 19 13:19:44 CEST 2012

Hi Kai-Olaf,

On 19 April 2012 12:41, Kai-Olaf Pieth <pieth at dc-systeme.de> wrote:

> The logic of the auto_resize_disk.sh is actually not ok I think. I tested to restore a system backed from a ~500GB Raid to a 146GB Raid.
> Problem 1: The root partition on c0d0p3 gets shrunk to only ~10Gb. But there are 12GB used on the original system:
> Filesystem              Size  Used Avail Use% Mounted on
> /dev/cciss/c0d0p3        37G   12G   24G  34% /
> When I start restore there are files missing. The system boots but doesn't work really good of course :-(

This is something we can't really fix in a good way. Rear does not
know the disk usage of the last backup. It knows the usage when the
rescue image was created.

Also, things like LVM complicate our views on the system, so I decided
to keep things simple.

In general, if you know the target system in advance you should
prepare /etc/rear/disklayout.conf the way you want it.

> The 4th partition /dev/cciss/c0d0p4 gets a size of 136GB but there are only 76GB used and these are all excluded via
> BACKUP_PROG_EXCLUDE=( '/lvol1/*' )
> Original df:
> Filesystem              Size  Used Avail Use% Mounted on
> /dev/mapper/vg00-lvol1  461G   76G  360G  18% /lvol1
> Problem 2: rear does not inform the user about this "soft" tar-error. tar runs through the whole archive with errors. Everything looks fine until you boot your system.
> Only when there are necessary files missing for restoring the bootloader for example, then you see errors that are related to these functions.

Can you open a new issue for this? We have another ticket on tar
warnings, so we should think about handling them.

> Problem 3: The swap partition also gets shrunk. In my case it's a 1GB partition and I want to work with a minimum of 1GB of swap on all my systems because I dont want to have the OOM Killer killing my processes too early :-)

Use swap on lvm :-)

You can open an issue on this. I think we can solve this.

> Earlier development versions of rear(from a month or 2 ago) where only resizing the last volume that does not fit on the disk. That's also not the holy grail, but it worked for me because I want the last volume(data volume) to always use the whole space available and the first one's(boot,swap,root) have to stay at a static size.

The logic changed from resizing only RAID and LVM partitions to
resizing any partition except for boot and grub partitions.

There is of course no optimal solution. If you would like to submit
patches for more flexible handling, feel free to do it!



More information about the rear-users mailing list