root@DietPi:~# cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=13
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘not applicable’
G_LIVE_PATCH_STATUS[1]=‘applied’
G_LIVE_PATCH_STATUS[2]=‘applied’
G_LIVE_PATCH_STATUS[3]=‘applied’
root@DietPi:~# echo $G_DISTRO_NAME $G_RASPBIAN
bullseye 0
root@DietPi:~# uname --all
Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
root@DietPi:~# dpkg --print-architecture
arm64
root@DietPi:~# echo $G_HW_MODEL_NAME
RPi 4 Model B (aarch64)
Factory power supply
Samsung EVO Select 64GB card
On my home network, I use an RPi 4b/8GB running DietPi 9.13 on a 64GB card. Its only purpose has been to run Pi-hole but I did install additional software with the intent to investigate it. Never happened.
Lately, I’ve been getting DISK_EXTENDED alerts in the Pi-hole dashboard.
Disk shortage ahead: 93% is used (58.8GB used, 62.8GB total) on ext4 filesystem mounted at /
Hunting around the iNet, I came up with a few commands, the output of which outline the basics of the problem but get me and my skill set no closer to a solution.
root@DietPi:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 59G 51G 5.1G 91% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 6.2M 3.9G 1% /dev/shm
tmpfs 1.6G 160M 1.4G 11% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.9G 0 3.9G 0% /tmp
tmpfs 50M 492K 50M 1% /var/log
/dev/mmcblk0p1 253M 34M 219M 14% /boot
overlay 59G 51G 5.1G 91% /mnt/dietpi_userdata/docker-data/overlay2/94e41b7976941c14814013717e38aa7a63e89f52c205cae9fb05dc3619285b35/merged
root@DietPi:~# sudo du -hsx /* | sort -rh | head -n 40
du: cannot access '/proc/969097/task/969097/fd/4': No such file or directory
du: cannot access '/proc/969097/task/969097/fdinfo/4': No such file or directory
du: cannot access '/proc/969097/fd/3': No such file or directory
du: cannot access '/proc/969097/fdinfo/3': No such file or directory
48G /mnt
2.0G /etc
769M /usr
312M /lib
160M /run
85M /var
36M /root
34M /boot
9.8M /bin
6.8M /sbin
248K /opt
20K /home
16K /lost+found
4.0K /srv
4.0K /media
0 /tmp
0 /sys
0 /proc
0 /dev
What I get from all that is DietPi is storing backups in a directory it probably shouldn’t be and they’re piling up.
I’m a Mac Guy, so I fired up iTerm, logged into the 4b and navigated to the Backup/Restore function. I turned off daily backups, reduced the amount of backups to keep from 14 to 10 and turned on Space Check. There is an option to delete backups from /mnt/dietpi-backup, but I haven’t done that yet as it’s not the offending directory. I’m guessing the previous limit of 14 backups is also not being observed because of a directory mixup.
Some deep background.
I’m about a Level Zero at this stuff. Over its four years of service, the 4b has run off the same card, so all updates have been built on past installations for both DietPi and Pi-hole. There have been power outages during that time and… of course… me poking at it periodically with a keyboard, not really knowing what I’m doing. Which is to say, it could be jacked up on blocks and missing a few wheels.
Ideas on how I can remove the backups from the wrong directory and direct future backups to the correct directory? Is this accomplishable with a dashboard and will one fit in the remaining space on the card?
Thanks