Additionally:
I do my backups every day and use dietpi-backup which stops and starts all services. I suppose that at one point the redis server doesn’t come up again.
Are there two conflicting mounts at /mnt/usb? Not sure whether the systemd-1 ... autofs entry is sort of an intermediate for the x-systemd.automount option.
How do you mount and unmount the NFS drive before/after daily backup?
I am not sure what you mean. There is actually no nfs mounting involved to the Backup server.
Although the Backup share is provided as cifs and nfs share, it is mounted from the RPi side via a mount script which I call from within the backupscript and that uses cifs:
mount -t cifs -o credentials=/root/.smbcredentials,vers=3.0 //192.168.0.8/Backup /mnt/NAS/backup
The attached usb-SSD with the owncloud-data is mounted via fstab
PARTUUID=0e81ddd4-4235-4a3f-aaf0-259d329b37db /mnt/usb ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
The backupscript then works on this :
SOURCE=/mnt/usb/data/owncloud_data/
BACKUPDIR=/mnt/NAS/backup/Owncloud
Ah sorry, CIFS it was. And the script does also unmount that CIFS share again after the backup finished?
Yes. That is if the script survives until the end. There is a possibility that the backup takes too long and the NAS would close the connection by going into standby. But that usually does not happen. And the next backup would then unmount the day after.
would that be a possibility to stop the NFS backup for a while to see how it goes?
Hey guys, please don’t mix up NFS all the time. No NFS involved here. But maybe you meant NAS? Also I don’t think stoping the backup is a good idea or neccessary. There is no evidence that the backup has anything to do with it. The mounts are unmounted and that is a setup that I run for years without problems. The question in my eyes is why does disabling ReadOnlyDirectories=/ in systemd solve the problem. What is the actual effect of this.
another option might be going to Debian Bookworm. Maybe there something has been fixed Debian Bookworm has been released – DietPi Blog
What would be best practise to upgrade a diet-pi own/nextcloud server from 11 to 12?
On install we download latest Nextcloud available, depending on operating system release (Debian version). Afterwards NC updates/upgrades would need to be down using regular NC tools. Cloud and Backup Systems Software Options - DietPi.com Docs In your case, the updater script might be best.
First you need to update NC to the latest version available on Bullseye, and then you can update Debian to Bookworm. After that it should be possible to update NC further to the latest available version 30.
I have an Owncloud and a Nextcloud instance running on that machine. Owncloud upgrades already bad and nextcloud even worse. I always hate to do the mandatory updates if something with security concerns are comiong up. I hesitate to upgrade anything if it’s not neccessary.
But thanks for the suggestions.
If you don’t mind please go over to TigerVNC Server crashes regularly - #5 by Pausentee
It’s an issue that actually needs more attention atm because I get an insane amount of errors there.
Just for claryfication:
- /mnt/* should exclude the /mnt directory from being backuped by DietPi-Backup, right?
My include/exclude list goes like this:
+ /mnt/dietpi_userdata/
- /mnt/*
- /media/
- /tmp
- /var/tmp
Because I found an issue here that it was in fact included in the backup and ran out of diskspace.
I run DietPi-Backup by calling G_INTERACTIVE=0 /boot/dietpi/dietpi-backup 1 || exit 1 in my script.
Update: unfortunately all - and + are being reformated by this editor 
So I don’t know if you can actually can read what is included and excluded.
If I run DietPi-Backup /mnt is not backuped, so I guess that’s fine. I just can’t explain how that happened that it obviously didn’t work at some point.
Using code tags is preventing the text from being reformatted 
I am not so familiar with those kind of trickeries…
But on the matter, is my include/exlude list okay as it is?
as far as I can see, you added /tmp and /var/tmp only.
Normally /tmp should not be backed up by default as it is a tmpfs. Therefore, the entry does not really make sense.
And /var/tmp does not actually contain any large data, except for some DietPi logs.