[Rear-users] Tech specs - support matrix

Schlomo Schapiro schlomo at schapiro.org
Mon Dec 20 10:41:20 CET 2010


this is a really good question and one that should in the end also be
answered on our website. I will try to summarize a few things out of my
head. Please correct me where wrong and extend what I missed. In the end
we will take the result from this thread and post it on the web site as

As a first step we introduced the "rear validate" feature which allows
users to report their experience back to us. Sadly only a minority of
ReaR users actually send feedback so that we are still in the dark with
regard to user experience.

In general ReaR is designed to support the following:
* ext*/XFS/ReiserFS/JFS support with UUID and LABEL support. For ext* we
also restore the block/inode size (at least there was a patch for that
some time ago)
* Filesystems on entire disks without partitions, on partitions, on MD
devices and on LVM devices
* MSDOS partitions (GPT only on ia64 so far)
* MD software RAID (the one you manage with mdadm)
* HP hardware RAID (cciss/hpacucli) configuration
* LVM (everything that vgcfgrestore can handle, advanced stuff like
mirroring and snapshots or complicated stripings not tested)
* LVM on MD (but not MD on LVM)
* grub and lilo (lilo only for SUSE, other distros try only grub), elilo
for ia64 and yaboot for ppc (IIRC)
* i386 and x86_64 well tested and supported, ia64 tested in some
HW/distro combinations but not recieving constand testing with new
releases, ppc supported but only the patch author can test it
* DRBD (patch came in very recently, has been tested only by patch
contributer), but not all combinations with LVM/MD
* DHCP configuration for network interfaces (also new patch), so far no
autodetection if the system uses DHCP but manually enabled
* ip addr and ip route and ip rule cloning, even for multiple network
* network bonding

The following is definitively not supported (as of current trunk/1.9.0):
* fake RAID (the one you manage with dmraid)
* other Device Mapper things (ReaR does not copy any device mapper
specific stuff, LVM is handled through lvm commands)
* multipathing (driver based could theoretically work, Device Mapper
based not supported)
* encryption (e.g. cryptsetup, LUKS, ecryptfs ...)

Open issues that I know about:
* Correct order of driver loading, e.g. for multiple storage or network
drivers. There is a good chance that we load the drivers in a different
order than the original system.
* kernel module configuration that is not in /etc/modprobe* (we simply
ignore it as we don't know about it).
* firmware loading for HP blades. Apparently our firmware loading code
is not perfect as it seemed to have worked for other setups (which made
us implement it in the first place).
* some users seem to have trouble with their first attempts but besides
inconclusive error reports I don't get enough information to say
anything about that
* grub2 probably does not work, I have not done any tests nor seen any
reports nor seen any patches. My experience with Ubuntu 10.10 shows me
that it is quite different from grub
* See https://sourceforge.net/tracker/?group_id=171835&atid=859452 for
our bug tracker

I will try to put your points into the ReaR context, as we think about them:

Am 20.12.2010 09:30, schrieb Kai Dupke:
> A) File System Support
> * boot file systems
> - EXT2
> - EXT3
> What is with ReiserFS, EXT4, XFS?
> * data file systems
> - all FS supported by the running system

For ReaR all file systems are equal, regardless of their use (boot
device or data).

> B) Boot Loader
> - GRUB

In most cases we cannot do more than run grub-install (hd0) or something
like that. We don't know how to guess the true boot device and hope that
grub knows what it does. This for sure fails in complex setups, e.g.
software RAID. For SUSE there is a different (from all other distros)
logic: We check /etc/sysconfig/bootloader to choose lilo or grub and in
the case of grub we rely on /etc/grub.conf to do the right thing. If
this does not work then the user has to fix it on his own. For all other
distros we just call grub-install and hope fore the best. If installing
grub fails we print out a big fat warning.

> C) Storage
> - all local disk support by the running system
> - single-path SAN

This is the same to ReaR, /dev/sd*, /dev/hd*, /dev/cciss/* ...

> - Disk-by-path
With 1.7 we warn the user that he should verify and don't to anything
about it. IIRC with 1.9 (due to P2V) we try to patch it up but this has
seen little test coverage (IMHO)

> - storage device

what do you mean here?

Kind Regards,

More information about the rear-users mailing list