After update to DietPi 8.7 dietpi-backup gets stuck

[maartenlangeveld]

On both my Rpi0-W and NanoPi NEO2 my daily automated backup configured through dietpi-backup (amount 2 for Rpi0 and 5 for NanoPi NEO2) got stalled at rsync dry run after recent update to DietPi 8.7.1.

[Joulinar]

Is a manually backup working? What is the target of your backup? Is this local storage or network attached?

[maartenlangeveld]

Manual backup works. I did remove some old data_x folders (except the latest backup: data folder) before to cleanup. Maybe that caused backup to get stuck on dry-run?

[Joulinar]

was it local storage or could it be a full file system?

[MichaIng]

A missing old data_x directory btw shouldn't cause any issues. Missing ones are just recreated one by one with every iteration. When you say "stalled", do you mean it just aborted in the middle of the dry run (and how do you know that since cron doesn't log output?), or is there an insufficient free space log shown in the .dietpi-backup_stats file?

If it still fails with cron but works with manual execution, we'd need to forward the cron job's output to a log file to know what happened.

[maartenlangeveld]

With "stalled" I mean the process did not die but did not nothing either. I saw the processes sitting idle in 'htop' for hours. Has not happened since, however.

[maartenlangeveld]

My RPi0 hanged last night, do not now the cause.

[maartenlangeveld]

I think I have an idea what caused these issues. Recently I started to make multiple rotating backups on daily basis using diepi-backup.

However once a week I make a backup (over the network, nfs-mount) to the other device using 'dietpi-update 1 ' by means of my own cron job. Apparently this triggers multiple backups (as configured in the dietpi-backup menu) only with a different destination than configured in the menu. Since both devices have not enough memory to also store multiple backups from each other they probably will hang. And since I recently started using rotating backups (locally) and my network backup only runs once a week it took some time to reach this conclusion.

I guess I'll have to make the network backups using my own rsync command and not using dietpi-backup to avoid them also being rotated.

[maartenlangeveld]

Ideally would be the possibility of having the option to define multtiple backup-jobs using the dietpi-backup menu :-) !!

e.g.

• daily local rotating backup
• weekly single network backup

[MichaIng]

When you change the backup location, only a single new backup is created in one run. The configured amount of "slots" is not forcefully created. When the target drive is full, rsync should error out, not hang, although I'm not 100% sure about this when NFS is used.

How do you make the weekly backup? Best would be to change the setting in /boot/dietpi/.dietpi-backup before the daily cron job runs, and back afterwards, so no two parallel and/or redundant backups are created.

We thought about adding another weekly rotation option by times when adding the daily one, although not with a different target location. I'll think about this, i.e. how to implement without having too many complicated looking options.

[maartenlangeveld]

What I did before was a weekly cronjob using a tab in /etc/cron.d/ containing something like:

8 5 * * Mon  root mount /mnt/rpi-zero-w-backup-nanopi
9 5 * * Mon  root /boot/dietpi/dietpi-backup 1 /mnt/rpi-zero-w-backup-nanopi

As I only want to backup the latest backup remotely to another SBC on my network I have now in stead added a tab to /etc/cron.weekly:

#!/bin/sh
#
# Backup latest system-backup to NanoPi NEO2 (nfs-mount /mnt/rpi-zero-w-backup-nanopi/)

mount /mnt/rpi-zero-w-backup-nanopi
rsync -azq /mnt/dietpi-backup/data /mnt/rpi-zero-w-backup-nanopi/ &>/dev/nulletc/

[MichaIng]

Ah nice, I totally forgot that the target path can be set/overridden via CLI 😅.

Indeed your second solution looks best when you want a single iteration on the remote drive only.

I'm still not sure why the backup would stall on the dry-run, especially since an actual rsync succeeds? This is the exact command, if you want to debug it:

cd /tmp
cat << '_EOF_' > .dietpi-backup_filter_inc_exc
# Backup data, log and config
- /mnt/rpi-zero-w-backup-nanopi/
- /boot/dietpi/.dietpi-backup_settings
# RAM dirs
- /dev/
- /proc/
- /run/
- /sys/
- /tmp/
# Swap files
- /var/swap
- .swap*
# Fake RTC timestamp
- /etc/fake-hwclock.data
# Unlinked inodes
- /lost+found/
# APT cache
- /var/cache/apt/*
_EOF_
rsync --dry-run --stats -aH --info=name0 --info=progress2 --delete-excluded --exclude-from=.dietpi-backup_filter_inc_exc / /mnt/rpi-zero-w-backup-nanopi/data/

[maartenlangeveld]

I'm still not sure why the backup would stall on the dry-run, especially since an actual rsync succeeds?

I presume since my rsync solution only backups latest backup iteration to remote device. The dietpi-backup function tried to backup all iterations to the remote device which had not enough memory to store 5 iterations, I guess.

[MichaIng]

The dietpi-backup function tried to backup all iterations

It does only a single backup iteration per run, so that shouldn't be the issue.

[maartenlangeveld]

Then I do not know what caused the issue. This issue may be closed as far as I am concerned.

[MichaIng]

Okay let's close it as you have a working solution. I'm also still not sure why the backup would hang on the dry run 🤔.