[rear-users] Migrate to SSD
jsmeix at suse.de
Tue Feb 13 12:24:11 CET 2018
On Feb 13 10:15 mario wrote (excerpt):
> ... i like to migrate ... to an SSD disk
In general migrating a system onto different hardware
does not "just work", cf. "Inappropriate expectations" at
In sufficiently simple cases it may "just work" but in general
do not expect too much built-in intelligence from a program
(written in plain bash which is not a programming language
that is primarily meant for artificial intelligence ;-)
that would do the annoying legwork for you.
For an example you may have a look at the
"P2V HP microserver to VmWare" issue
Migrating a system onto same hardware only with a bigger
harddisk should work o.k. more or less straightforward
but do not expect really good partitioning alignment.
In contrast migrating a system that was installed
on a single traditional rotating 800GiB harddisk
onto new hardware with two SSDs each one 400GiB
will certainly not "just work".
For migrating harddisks (with partitions, filesytems,
and mountpoints) it should be sufficient to edit
disklayout.conf before you run "rear recover" and
adapt /mnt/local/etc/fstab afterwards (cf. below).
It could be laborious and unhandy to manually edit
disklayout.conf within the ReaR rescue/recovery system.
In this case have a look at RECOVERY_UPDATE_URL
For an example how RECOVERY_UPDATE_URL works see
When you use the ReaR master code via 'git clone/checkout' see
what is special about the disklayout.conf file location
in the ReaR rescue/recovery system that you must consider
to make RECOVERY_UPDATE_URL work.
> Well how rear works with TRIM, etc for SSD disk ?
In general ReaR has no have special support for SSDs,
neither special support for what filesystems work "best" on SSDs
nor special support for what mount options are "best" on SSDs
nor anything else what is "considered best" on SSDs.
In general ReaR is not meant to somehow "optimize"
a system during "rear recover" - in contrast ReaR is
first and foremost meant to recreate a system as much
as possible exactly as it was before.
Accordingly by default with same replacement disk size
you get partitions recreated at the exact same byte values
as they have been on the original system.
With bigger replacement disk size you get partitions recreated
with some automatically resized partitions via
with some partition alignment via
where my offhanded guess is it is something like 1 MiB
because of the '/ 1024 / 1024' in 100_include_partition_code.sh
or perhaps you may even get only 1 Byte as alignment
in case of FEATURE_PARTED_ANYUNIT which may finally
explain the root cause behind
But a partition alignment of 1 MiB (or parhaps even only 1 Byte)
is really not what is o.k. for SSDs because flash-storage devices
have a physical block size of at least something about 4 MiB
(nowadays probably more like 8 MiB or even more)
regardless what tools or files in /sys/block/sdX may tell
(often one gets only the fallback/compatibility block size
of 512 bytes but not the actual physical block size
because often storage devices "just lie" ;-), cf.
Currently there is no partition alignment config variable
in ReaR where you could specify e.g. 8 MiB as partition
alignment value that is used in ReaR's MIGRATION_MODE.
Currently such a value only exists for "rear format"
cf. USB_PARTITION_ALIGN_BLOCK_SIZE in default.conf
> Have i to change same thing in FSTAB
> for example or it does the work for me ?
Because you get all your files from your backup
you get in particular etc/fstab and your bootloader
config files from your backup - i.e. you get all
your config files from your "old" system.
At the end of "rear recover" it does only some minimal
adaptions of some config files from your backup so that
in general in case of a system migration you should after
"rear recover" in the running ReaR rescue/recovery system
carefully check your config files in /mnt/local/... and
manually adapt and enhance them as needed.
In particular if you changed your disk partitioning layout,
filesystems, mountpoints, and things like that,
you would have to manually create after "rear recover" in
the still running ReaR rescue/recovery system the right
matching /mnt/local/etc/fstab anew.
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)
More information about the rear-users