Backup reporting space incorrectly

Troubleshooting
1

Creating a bug report/issue

Required Information

  • DietPi version | 8.10.2
  • Distro version | bullseye
  • Kernel version | 5.15.74-v7+ #1595
  • SBC model | rPi3
  • Power supply used | 5V 2A Canakit
  • SD card used | SanDisk ultra

Additional Information (if applicable)

  • Software title | Dietpi-Backup

Steps to reproduce

  1. Mount 128GB NFS share from an RPi 4 running DietPi 8.10.2
  2. Try to backup the Pi 3 to the NFS share.

Expected behaviour

  • It backs up as usual

Actual behaviour

  • Reports that there is approximately 90 GB available, which is accurate, and that the backup will require about 110 GB, which shouldn’t be possible.

Extra details

  • Standard inclusions/exclusions. Include /mnt/dietpi_userdata, which is located on the SD card, and exclude the rest of /mnt and /media.
  • Going through / folder by folder with ‘sudo du -shc’ no folder is larger than 1.5 GB, for a total of about4 GB to back up. Have tried restarting multiple times, remounting the drive, and scanning the drive for errors.
2

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?!

3

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.

4

usually entire /mnt/* should be excluded (except /mnt/dietpi_userdata/). Means it should exclude /mnt/backups as well. Can you share following

df -h
5 
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
6

can you share the entire log of the backup run pls

dietpi-backup 1
7

dietpi-backup.txt (140.8 KB)
Attached

8

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

9

No, I haven’t set any quotas.

10

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.

11

Something seems to be wrong on rsync. Are you able to perform a backup to an attached USB drive? Just for testing?

12

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.

13

any chance to check logs on NFS server?

@MichaIng any idea what could cause rsync to terminate during execution?

14

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 :thinking:.

15

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.