Wow, you put a lot of thought into this. Impressive - and thank you for sharing the script.
My question about whether fsarchiver or borgbackup support snapshotting the FS before backing it up, alas, remains unanswered - but Google suggests they do not.
I may just not change anything at all and rely on my manual Clonezilla images. I do tend to go down various rabbit holes when it comes to things like this. 
It's a mystery. Not one worth thinking about too much, though. 
Makes sense, although I wonder why, once I set up my dashboard in Firefox on PC #1, it comes up exactly the same way in Firefox on PC #2 - and I'm not syncing anything except bookmarks between them.
But thanks! Will set it up on Android.
Once again, merry Christmas!
When I log into the OMV GUI using Firefox on my Android phone, the dashboard comes up empty - and in light mode, although I have it set to dark mode in Firefox on my various PCs.
It also came up in German instead of English the first time... luckily, as German is my native tongue, switching back was easy.
Is there a specific reason, i.e. cookies or such, why the dashboard shows nothing on Android? I doesn't matter if I use mobile or desktop mode. Is it sufficient if I simply recreate the same widgets on mobile Firefox and call it a day?
Merry Christmas!
I have the System/Backup plugin set up to save my running OMV (7.7.24-4) system to a disk image with dd once a month, keeping the last 3 or 4 images. Works just fine, though I've never had to restore any of them.
(I also back up the system in offline mode manually once or twice a year by booting into Clonezilla.)
Obviously(?), the dd way provides no point-in-time snapshot of the filesystem, so I'm a bit concerned that the lack of image consistency could cause issues if I ever do need to restore them. But I don't know if either fsarchiver or borgbackup are capable of creating such snapshots, or if this requires some kind of LVM setup (if that's even possible for the OMV filesystem).
What say the experts?
I've added a lot of packages outside of the OMV UI and made countless tweaks as I've used the system. I do not believe screenshots would be sufficient to restore my configuration. I'm really thinking more either in-place installation or just doing nothing, because I have had no actual issues with it other than packages that aren't available on older debian. Not breaking anything that's currently working is my top priority, especially since I access a lot of the functionality via windows and stuff like SMB took forever to get working correctly.
Until just over a month ago, I too was stuck on OMV 5. And I've been in the same boat - having tweaked a lot of things outside of OMV itself, configured everything just the way I like it, etc. - so yes, the prospect of a completely fresh install is daunting.
But consider that even if your system is continuing to work just fine, eventually it won't. You've already missed out on security updates at the least, and something will come and bite you.
I spent the last month setting up OMV 7 from scratch (I prefer to wait for OMV8 to be stable and an upgrade path to become available before I go that route). It took a lot of time but was SO worth it. Many of the things I'd bolted on to the old OMV5 install I was able to reconfigure in a much cleaner way using the OMV7 GUI (for example, setting up a network bridge interface, WireGuard, moving Emby from host-level operation to a Docker container, even automatic updating of my SSL cert via acme.sh and update_cert.sh, etc.). As I've gained a lot of experience both with OMV and with Linux/Debian generally, I'm now happy with a more polished and up-to-date system. Most importantly, I'm back in the loop with functionality and security updates - AND a proper upgrade path. Then there's the plugins - there's a whole lot more of them than in OMV5. The KVM and Compose plugins alone are superb.
Consider these points. I recommend that you take the time for a fresh install and just go step by step. Maybe you can spare another computer as a temporary server in the meantime - I did this, too, by cloning the old OMV5 install to a mini-PC and some of my data copied to an external HDD.
I, too, have run into this issue.
After reading this thread and the Github issue, I decided to simply issue a systemctl disable nut-driver@<upsnamehere>.service so the service doesn't try to start again on reboot. I did notice that it tries and fails (watching the process on a connected monitor) before OMV finishes booting and is ready.
That shouldn't affect the NUT service running in netclient mode, right?
As the subject says.
Asking more out of curiosity than anything - I don't actually plan to attempt such an upgrade. I'm still running OMV5 on Debian Buster and it's been performing admirably. I don't feel the need to upgrade yet, but once I do, I will start fresh with a clean install of OMV7 and reconfigure everything to my needs.
Also, it's nice to see the forums are alive and well after a few years of me not hanging around here, and so is OMV.
Generally I'd agree with you - I do use Docker containers for a few other things, but find Emby well-behaved enough to not interfere with other things the host is doing. If that ever changed, I would definitely containerize it.
On a side note, I have a habit of installing an OS once and never again (even Windows on my PCs). I spend too much time tweaking and customizing things to ever want to do it again from scratch; that's what disk image backups are for, IMHO.
I run Emby directly (no Docker)... it just works, and I've never had to manually set it up for autostart at boot time.
I guess where I'm coming from, the question is "why bother with Docker, running Emby at host level is so ridiculously easy to run and manage," but maybe I'm missing something.
One thing you could do is place a specific file - even a zero-byte file with a specific name - on your hard disk. Set up Syncback to check for the existence of that file and start the backup only when it's found.
Since the file wouldn't appear in your Samba shared folder if the disk is disconnected (as it's not on the SD card), that would stop Syncback from running the backup.
Gut gemacht. Genau das versuchte das System Dir mit config/service/smb/shares/share mitzuteilen.
Try different ports in OMV - something like, say, 18000 for http and 19000 for https. Then forward these ports through the router, but keep the same ports on the local and public side, avoiding 8080 and 8443 altogether.
I think that's what gderf was getting at as well.
...and what error, pray tell, are you getting?
We're not mind readers.
Device or resource busy - something else has a lock on the disk.
You could start a secure wipe, then abort it after a few seconds. For good measure, you might also disconnect the drive after that wipe, wait a moment, then reconnect it.
And did you set a range of ports in your FTP settings for passive connections? These will also need to be forwarded through your router. For example, something like 11500 to 11600.
After that many updates, I would strongly suggest you reboot your system immediately, if you haven't already. Then you can continue to try and get docker working.
LUKS is a Linux standard encryption scheme and not dependent on OMV. So yes, it will work in OMV 6.
Where can I enable this option? I'm not seeing it in OMV under FTP settings. Thanks!
It's on the Advanced page of the FTP settings.
