[rear-users] Destination disk partitioning
cal-s at blue-bolt.com
Mon Jul 23 10:24:46 CEST 2012
Hi, Jeoren et al
On 21/07/12 11:36, Jeroen Hoekx wrote:
> 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 NETFS/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 ).
Ah, auto_resize_disks.sh, right? Must have a trawl through that.
disklayout.conf appears to have been altered when restoring to a smaller
device - at least it's consistent with the new partitions. Can't find a
layout for the original disk partitions - what's it called if it still
My vote would be to make swap resizing (or retention) optional, then,
via a commandline switch to rear - you can never have too many switches
:) This seriously affects the ability to restore to smaller volumes
than the source.
> 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.
Please identify which script you're referring to? rescue.conf contains
no disk definitions - at least mine never do.
>> 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.
What's Mondo in this context?
Personally, i think the success of ReaR hinges on ease of use and
anything that makes the process of fitting machineA into machineB would
be a major win. Alternatviely, a method of breaking out of the
disklayout script into parted would help. As a side note, the
disk-partitioning routine is a bit opaque and re-presents itself
multiple times during rescue with no indication of why it's doing so.
> rear-users mailing list
> rear-users at lists.relax-and-recover.org
Cal Sawyer | Systems Engineer
BlueBolt Ltd, London
More information about the rear-users