This is a serious matter, so please treat it that way.
After spending days recovering my limping system I need a serious way to save / backup operating system , not some silly data, got that covered.

Here is "the spec" :
Manually, nothing automatic, preferably using command line , not GUI
backup / copy /save the entire operating system PARTITION to another PARTITION.
The "copy to " partition must be enabled so grub to find it, hence eventually boot able as the original.

The reasons are simple:
Upgrading to new version release is "Russian roulette " - going from Ubutu 16 to 18 on-the -fly took almost an hour. Downloading from ISO USB stick is much gooder, but not too "what is happening , progress" oriented.

Both methods are hard to verify if all previous packages are still workable.

So my "primary directive" is NOT to have download packages AFTER the OS fails.

I had good luck with "ddrescue". Can anybody recommend alternative or is that as good as it gets with Linux ?

Secondary though - would RAID5 work to do the above "automatically"? I realize if something catastrophic happen to running OS and it gets passed to RAID array the system may not boot again using the RAID array. That is why I am using multiboot anyway and it saved me from total meltdown many times.

You need a backup tool like clonezilla https://clonezilla.org/ which I have used to backup my MythTV boot partition and restore it after the OS update left it unbootable.

RAID5 is not a backup solution, so no it will not do you want. You could use a RAID1, were you remove one of the drives then do the update, and if it fails remove that drive and put the other back, boot from it and wipe the failed drive and then put it back in and rebuild the array.

Ability to readily and conveniently save an OS partition onto the same system is one of several advantages to configuring a system in multiboot. So configured the admin can clone one partition to another using yet another, or save it to a file on any mounted filesystem (other than the source). The source cannot be the booted system because of open files and potential file corruption on both source and target on subsequent boot(s).

You cannot succeed to have a bootable pure, direct clone of any OS partition to another partition on the same system and have either be bootable without tweaking one or the other to remove all references to the duplicated filesystem LABELs (if any) and UUIDs in bootloader configurations and fstabs. Any time such tweaks are not made, tragic filesystem corruption can be expected.

For cloning and imaging (compressed or not), which are backup routines here, I use the same non-free application that I use for partitioning and for OS and partition inventory management: DFSee. The same instance can both create a new target partition, and clone to it. Bootloader management must be done separately afterward.

Thanks for replies.
I am not sure I should worry about duplicating ID's
If I clone partition of NOT currently running OS AND do not run "update-grub" I should not see the cloned OS in the grub menu next time I reboot.
I know this does not agree with posts here, but that is my current experience - grub does not automatically update on reboot.
So if my primary OS fails - either boot or faulty package - I should be able to switch to backup OS ( 3rd OS in the schema ) - do update-grub and on next reboot select the cloned OS.

I realize it is convoluted process, but beats going thru same "recovery" for hours - likes last time.
I'll take a look on implementing RAID1 - I always prefer KISS method.

Grub won't be affected with that action until time comes for a Grub update, but the kernel can be any time. You may or may not be booting what you think you are booting if UUIDs are not unique. You may load kernel and initrd from the one specified by Grub, but find mounted the other. You'll need to check the device name each boot to know which of the two identical UUIDs got mounted to /. I hazard to guess the result once time comes for a Grub update, unless os-prober is disabled.

Making UUID unique on a cloned partition is simple enough using tune2fs, which can change or add a LABEL in the same operation. No mounting of the target is required to do so.

There is no best backup solution.

One can use things like Clonezilla to backup parts or all of your system. Clonezilla uses common other programs that you could use alone.

If you simply want to copy file by file of the OS part and not the loader then I might use Gparted.

Raid 1 is great for the OS. Raid 5 or 6 for your data (/home).
Either way a single drive failure and you still keep going.

After cloning or imaging your OS, you can copy it to your new hard drive now. If you image it, you can restore it to your new hard drive. And that's done. Of course, if you don't think your operating works well, you can choose to reinstall it on your new hard drive.




MyFordBenefits.Com

fsarchiver might work:
clone partition:
restore partition:

1 members found this post helpful.