#573 Issue closed: updating REAR within an already created iso image¶
Labels: discuss / RFC, won't fix / can't fix / obsolete
abbbi opened issue at 2015-04-08 17:36:¶
hi,
im thinking about a feature in rear which would it make possible to
update a rear version within an already created iso image. This could be
very handy for example if an backup iso image has been created with an
rear version containing a specific bug or is missing a feature. Of
course it is better
to go on with testing restores just after creating a backup.
So one way would be of course to unpack the iso image and update the
rear version in it to a more
recent version, then repack. This however would not mean that the
restore works, maybe the
disklayout created with the old version is incompatible. So i think it
would be great to have a
compatibility version in the files created during backup. Then some
shellscript could handle things
to repack the iso image and check if included items are compatible. Any
thoughts on that?
gdha commented at 2015-04-09 08:49:¶
Would a live update not be easier to implement via e.h. HTTP protocol? Just a thought...
schlomo commented at 2015-04-09 17:14:¶
Hi @abbbi, nice to hear back from you. Are you working on something specific?
I think there are two ways to think about ReaR:
- Run it seldom, probably manually
- Run is often and automated
I am a big fan of running stuff often and automated so that I probably would not have this problem at all. I think that if you are in the middle of a Disaster Recovery then you will have enough stress to deal with so that you probably would not upgrade ReaR as part of your general recovery procedure.
If you have a system that won't recover then in my experience people either give up or start to do the steps outlined in the diskrestore.sh manually.
Another problem I see is cross-version compatibility: So far when we write code for ReaR we know that the version running during recovery will be the same as the one running during mkbackup/mkrescue. That means that we will never have a problem of incompatibilities between the two sides and we can easily change some internal data format or behavior by changing it on both sides.
What you propose would essentially run a big risk that the more recent recovery code will not handle the older data format of the recovery data or it might even handle it different from what was intended by the older code.
While it might be true that so far the changes in the data format have been rather infrequent, I would hesitate to turn our recovery data format into an official interface, at least as long as we don't have automated tests for that.
I can imagine that another idea that comes up regularly might be more useful for what you have in mind: The ability to create a generic recovery media that could then be "connected" to an existing backup. That way one would also get a new ReaR version for recovery.
jsmeix commented at 2015-04-10 09:11:¶
Regarding "that the more recent recovery code will not handle the older data format of the recovery data":
When I implemented generic basic btrfs support (see https://github.com/rear/rear/issues/497) I just adapted the data format in disklayout.conf as I needed it and I did not at all care about backward compatibility.
For me it is mandatory that what created disklayout.conf and what uses it is from one same rear. I mean really "one same rear" not only same rear version. "One same rear" means that the user can adapt/enhance his rear as he likes.
When I enhance my current generic basic btrfs support (see https://github.com/rear/rear/issues/556) I will again change the data format in disklayout.conf as I will need it.
gdha commented at 2015-06-16 10:03:¶
@abbbi As we will not change our current design there is no need to keep this open, right? Or is there still something you want to share with us?
abbbi commented at 2015-06-16 10:03:¶
hi,
nope, currently nothing new to share on this topic
[Export of Github issue for rear/rear.]