DIY advice

Zitat von smudger

Would something like this run as a scheduled task do the job

Code

dd if=/dev/sda of=/dev/sdb bs=1M

Or do you recommend any other dd options other than block size?

The idea of a live nightly backup appeals to me.

I can still do an offline backup once a week/month to another ssd

I would never use disk device identifiers such as /dev/sda, especially for the destination target. Those assignments are not guaranteed to be static. If they change for any reason, /dev/sdb could be one of your data disks and dd is destructive on write. All the data on your /dev/sdb would be replaced with the backup data.

See the script I posted above for a suggestions. It writes to a file with a unique name.

dd if=/dev/sda of=/dev/sdb bs=1M

Am I correct in thinking that this approach would lead to two drives with the same UUID therefore possibly confusing the system? And that it would be OK to clone the OS drive but the copy would have to be removed before a reboot to avoid this?

That is mostly correct. Both disks would have the same filesystem UUID and since that is the identifier in fstab that specifies which disk to boot there would be an ambiguity. Which disk actually boots could change from boot to boot or it could stay the same.

I ran into this problem when I upgraded from OMV 4 to OMV 5. I cloned the OMV 4 disk and upgraded the clone to OMV 5. I left both disks in the machine thinking I could select which one to boot by using the BIOS boot menu. I forget which one always booted, but no matter which I chose from the menu one of them could never be booted. I was able to solve it by changing the filesystem UUID on one of the disks to a random value. Eventually I was satisfied with OMV 5 and didn't need to have OMV 4 available as a boot choice, so I removed that disk and set it aside.

I also changed fstab to identify the single boot disk by label instead of UUID for clarity.

I don't think this will work as intended. I think that at a minimum the boot sector would not be copied. I've never used dd with disk-by-label sources and targets so I could be wrong.

Zitat von chente

I can think of a way to protect against errors in the system or its manipulation. It could be to "reproduce" the existing configuration on a clean OMV system in an automated way:

1. Regularly keep a backup of all system configuration. Including file systems, custom settings in the GUI, installed plugins, docker, etc.

2. In case of disaster recreate the saved system (using a script?). The clean version of OMV is installed and the saved settings are applied to the clean system.

I assume that the accuracy of the rebuild would depend on the accuracy and quantity of settings saved in the backup.

Does something similar exist or has there been?

Alles anzeigen

AFAIK, currently there is no such thing, not has there been.