Where did you mount the NFS share? Maybe somewhere in
/mnt/dietpi_userdata/? Sounds like some sort of ‘loop’, it’s backing up the actual backup location?!
Good point. The NFS share is mounted at /mnt/backups. I have a couple other things mounted in /mnt, but nowhere else. No symlinks to other folders or anything like that either.
/mnt/* should be excluded (except
/mnt/dietpi_userdata/). Means it should exclude
/mnt/backups as well. Can you share following
Filesystem Size Used Avail Use% Mounted on
/dev/root 30G 4.8G 24G 17% /
devtmpfs 454M 0 454M 0% /dev
tmpfs 487M 0 487M 0% /dev/shm
tmpfs 195M 5.5M 189M 3% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.0G 0 1.0G 0% /tmp
tmpfs 50M 12K 50M 1% /var/log
/dev/mmcblk0p1 127M 55M 72M 44% /boot
192.168.1.110:/mnt/backups 114G 22G 92G /mnt/backups
can you share the entire log of the backup run pls
dietpi-backup.txt (140.8 KB)
any quota on the NFS share that could limit the size? But I’m not 100% if this is a space issue at all as
rsync is terminating with code 20
No, I haven’t set any quotas.
It’s a bit strange to me, because all my other RPis running 8.10.2 (4, 2, and two 0s) are all backing up to that drive fine.
Something seems to be wrong on
rsync. Are you able to perform a backup to an attached USB drive? Just for testing?
Alright, finally got a chance to try a local usb drive. Freshly formatted, it backed up without issue. Total backup size is 3.7 GB. So I’m not sure if that points to an issue with Rsync or NFS.
any chance to check logs on NFS server?
@MichaIng any idea what could cause
rsync to terminate during execution?
Interestingly, exit code 20 according to the man page means “Received SIGUSR1 or SIGINT”, here it says “SIGINT, SIGTERM, or SIGHUP”. SIGINT is the only match, which would be sent when hitting Ctrl+C keys.
Does the kernel report errors, either on DietPi client or NFS server side?
dmesg -l emerg,alert,crit,err
The backup size estimation indeed is usually much too large with an NFS target, size it adds the number of files+dirs * block size, as worst case max space the data will take. On NFS drives however, the block size is extremely large, not related to the actual target drive block size, but some transfer packet size, I think. Something we need to handle differently .
Could the SIGINT be from canceling the backup through the Whiplash menu when it says there isn’t enough space?
There are no kernel issues reported on the client or server.
I tried just running a backup and ignoring the space warning and it worked fine, coming in at 3.7 GB. A scheduled backup won’t work however, which is a bummer.
I’m not sure where the NFS logs live. I didn’t see anything in /var/logs.