[rear-users] Destination disk partitioning

Jeroen Hoekx jeroen.hoekx at hamok.be
Sat Jul 21 12:36:52 CEST 2012

Hello Cal,

On 21 July 2012 10:36, Cal at Bluebolt <cal-s at blue-bolt.com> wrote:

> I've been experimenting eith ReaR restores to ESXi VMs over NTEFS/nfs and it works remarkably well and is incredibly fast.  However, the server i'm Rear'ing ( to coin a phrase) has fairly large / and swap partitions.  This makes for having to create a large VM in order to accomodate the captured partition sizes.  I know that ReaR can adapt to some degree when the destination disk is smaller than the source, but it would he good to know how ReaR makes repartitioning decisions and the limit at which it decides can't fit the source data.  In my case, i'd like to shrink / and allocate less swap partition on the VM than exists on the Rear'd server. Have looked over the restore disklayout config but it's a bit impenetrable given it's parted-esque partition size-in-bytes descriptions, which complicates editing disklayout by hand.

We resize pretty much all partitions except /boot and bios_grub (GPT).
There's a feature request to *not* resize swap partitions (
https://github.com/rear/rear/issues/71 ).

One thing that's also on my todo list is to allow other units than
bytes in disklayout.conf. That shouldn't be too hard to implement and
would bring us a long way.

If you don't edit disklayout.conf, but edit the restore script, you
can use whatever unit your parted version understands. That's how I
usually influence the process right now.

> Feature request, then: interactive restore partititioning?

I've been thinking about this, but have always decided to not do it.
It was one thing that always lead to problems when I used it in Mondo.
I personally like editing one config file better. If someone wrote a
good implementation of it, I guess we'd take it, but I won't be the
one to write it.



More information about the rear-users mailing list