#1162 Issue closed: New kind of "backup" method: BACKUP=BLOCKCLONE

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2017-01-11 11:19:

@gozora likes to implement a new kind of "backup" method:

BACKUP=BLOCKCLONE

It is not an usual file-based backup/restore method.

This new kind of "backup" method does not work
on files but on whole disk partitions, see
https://github.com/gozora/rear/tree/block_clone

It is a prerequirement for NTFS support
https://github.com/rear/rear/issues/1078

jsmeix commented at 2017-01-11 11:22:

See also
https://github.com/rear/rear/issues/1158#issuecomment-271826895
and
https://github.com/rear/rear/issues/1158#issuecomment-271823712

jsmeix commented at 2017-01-11 11:29:

@gdha
I added you as assignee because I like to know
what you think about it.

In general I like it when ReaR is enhanced so that it is
useful also in non-standard environments.

As far as I understand @schlomo in
https://github.com/rear/rear/issues/1078#issuecomment-262832981
I think he agrees to have a backup method
that can take care of all the non-Linux stuff.

According to
https://github.com/rear/rear/issues/1158#issuecomment-271826895
"It is working piece of code currently"
so that from my point of view (we are directly after ReaR 2.0 release)
https://github.com/gozora/rear/tree/block_clone
should be "just merged" now (the sooner the better)
so that other users can test it with the
current GitHub master code.

jsmeix commented at 2017-01-11 11:38:

@gozora
I assume your BACKUP=BLOCKCLONE implementation
works strictly separated from other currently working stuff in ReaR
so that no regressions are expected for currently working stuff.

Some initial notes on your
https://github.com/gozora/rear/tree/block_clone

It looks as if BLOCKCLONE_SOURCE_DEV
can currently contain only a single block device node
which means BACKUP=BLOCKCLONE is currently
limited to a single disk (or a single partition?).

I wonder if BACKUP=BLOCKCLONE should be
enhanced to also work on multiple disks
(or multiple partitions on multiple disks?)
or if this is not needed because via multiple backups
with multiple config files one can get the same result?

I fail to understand from the comments in default.conf
if BACKUP=BLOCKCLONE is meant to work on a whole disk
(i.e. for all partitions on that disk) or if it is meant to work
for a single whole partition on a disk that could contain
also several other partitions?

In other words:

If one has one disk /dev/sda
with /dev/sda1 an ext4 Linux partition
and /dev/sda2 a NTFS Windows partition
how is then BACKUP=BLOCKCLONE
meant to be used?

If one has two disks /dev/sda and /dev/sdb
with /dev/sda1 an ext4 Linux partition
and /dev/sdb1 a NTFS Windows partition
how is then BACKUP=BLOCKCLONE
meant to be used?

gozora commented at 2017-01-11 11:56:

Hello @jsmeix,
First of all thanks for checking!

I wonder if BACKUP=BLOCKCLONE should be
enhanced to also work on multiple disks
(or multiple partitions on multiple disks?)
or if this is not needed because via multiple backups
with multiple config files one can get the same result?

This is correct, if user wants to backup multiple partitions, I've fully relied on multiple backups feature.
In my scenario I've backed up windows which resided on 2 partitions as follows:

rear -C windows_boot mkbackuponly
rear -C windows_data mkbackuponly

Where BLOCKCLONE_SOURCE_DEV for windows_boot was /dev/sda1 and for windows_data /dev/sda2.

I fail to understand from the comments in default.conf
if BACKUP=BLOCKCLONE is meant to work on a whole disk
(i.e. for all partitions on that disk) or if it is menat to work
for a single whole partition on a disk that could contain
also several other partitions?

It doesn't matter if you set whole disk or partition for backup. One of BLOCKCONE tools is dd so in theory you can backup image of whole disk if you like.

If one has one disk /dev/sda
with /des/sda1 an ext4 Linux partition
and /dev/sda2 a NTFS Windows partition
how is then BACKUP=BLOCKCLONE
meant to be used?

You will ignore /dev/sda1 as most probably it will be subject of standard ReaR backup method like NETFS and you use separate config file for /dev/sda2 similar to my windows_data example above.

Maybe you can check https://github.com/rear/rear/issues/1078#issuecomment-264712525 . There is my initial configuration described.

I'll provide you configuration for two disks scenario later today.

gozora commented at 2017-01-11 12:00:

@jsmeix sorry I've messed up!
The comet listed earlier is for two disk scenario.

This https://github.com/rear/rear/issues/1078#issuecomment-266287176 should be for window/linux sharing same disk

Sorry for that!

jsmeix commented at 2017-01-11 12:16:

Could you describe those two main use cases
in a preliminary documentation document
(or for now only in default.conf - as you like)
so that interested users have initial example configs?

gozora commented at 2017-01-11 12:18:

100% yes, writing documentation is planned for this week, hope I can make it.
Once I have it, I'll create pull request against upstream ReaR so you can decide its next destiny.

jsmeix commented at 2017-01-11 12:19:

I already made my decision in
https://github.com/rear/rear/issues/1162#issuecomment-271845452

It should be "just merged" now (the sooner the better)!

gozora commented at 2017-01-11 12:22:

Happy to hear that @jsmeix !

BTW, do you know about other users than @danboid who would be interested in backing up "exotic" filesystems ?

jsmeix commented at 2017-01-11 12:31:

Currently I don't know about other users - and in particular
I myself do not use Windows or other "exotic" systems ;-)

gozora commented at 2017-01-11 12:38:

I'm advocate of "three windows R" policy:

  1. Retry
  2. Reboot
  3. Reinstall

But this was a nice challenge, so I took it ;-)

gozora commented at 2017-01-19 09:15:

Pull request https://github.com/rear/rear/pull/1172 was created with initial BLOCKCLONE code

jsmeix commented at 2017-01-27 13:46:

With
https://github.com/rear/rear/pull/1172
"BLOCKCLONE backup method"
and
https://github.com/rear/rear/pull/1180
"BLOCKCLONE documentation"
merged
this issue is done, see also
https://github.com/rear/rear/issues/1078#issuecomment-275433991


[Export of Github issue for rear/rear.]