> At which point I'm basically running 3 virtual file systems on top of each other just to have a better UI, which seemed a bit silly.
This sounds like a system administration problem.
Why, exactly, did you jump to docker/etc instead of what everyone (including NextCloud) recommends which is basically "keep a copy of your nextcloud folder and a dump of your database"?[0]
If you're not confident you can properly recreate your nginx config, then keep a copy of that too.
At that point you're literally like four steps to restore from a blank slate:
pkg install nginx php74 php74-extensions mariadb105-server
mysql -e 'CREATE DATABASE nextcloud;'
mysql nextcloud < backup/nextcloud.sql
rsync /path/to/backup/ /
It sounds like most of your pain comes from trying to optimize the long tail here (recovering from a backup) at the cost of normal operation.
(FWIW, my backup strategy is cron running a shell script that "rsync/mysqldump to second disk; rclone off-site". I've recovered from this successfully (from my local copy, no transfer times) in about a half hour.)
This sounds like a system administration problem.
Why, exactly, did you jump to docker/etc instead of what everyone (including NextCloud) recommends which is basically "keep a copy of your nextcloud folder and a dump of your database"?[0]
If you're not confident you can properly recreate your nginx config, then keep a copy of that too.
At that point you're literally like four steps to restore from a blank slate:
It sounds like most of your pain comes from trying to optimize the long tail here (recovering from a backup) at the cost of normal operation.(FWIW, my backup strategy is cron running a shell script that "rsync/mysqldump to second disk; rclone off-site". I've recovered from this successfully (from my local copy, no transfer times) in about a half hour.)
[0] https://docs.nextcloud.com/server/latest/admin_manual/mainte...