the image backup on linux (urbackup beta) is working quite well.
But currently it seems impossible to backup a rootfs that is on a software raid.
Urbackup reports an error that it cannot read the MBR. I guess (as I don’t know the code) that Urbackup checks the mounted device for the rootfs (e. g. / on /dev/sda2) and then tries to read the MBR from the /dev/sda. On software raid the rootfs is mounted e. g. on /dev/md2 but of course the MBR is not on /dev/md. It is on /dev/sd(a|b) or /dev/nvme0n1 etc.
I don’t know if it is possible to handle that kind of situation.
The problem is that it is easy to get the real disk with GPT/MBR of e. g. /dev/sda1 but it is harder to get the real disks (it can be multiple!) of e. g. /dev/md1.
And on restore it might be even more complicated e.g. when there are now 4 drives instead of 2 on backup etc. Raid config is very dynamic.
File backup has nothing (or at least not much) in common with image backup.
Yes, RAID can be complicated/dynamic, but I am talking about a specific (simple) case of a mirror. No real RAID “funny business” of stripes etc going on here…
For restore, if necessary, just restore to a single drive, and then regenerate the mirror manually.
File and image backup ARE similar in that they both use the same snapshot method (dattobd etc).
Should be possible to do for this for RAID mirror special use case.
Sure it’d be “easy” to add. Someone just has to do it and I currently don’t have a personal use case (it’s all VMs/cloud instances).
And as said, more than half of the work would be the restore (and testing that). The best implementation would allow some reformatting e.g. switching from mdraid RAID6 to a single disk or RAID1.