Errors when backup disk is full

[AmaruCoder]

I have been using this script for almost two years. Thank you laurent22 for writing it. In the past few days, however, I have been receiving two error messages: write error: Broken pipe (32) and error in socket IO (code 10) at io.c(848). After some perusal of the backup disk, I noticed that it is full.

What is the safe way to remove old backups to make some room for new ones?

[laurent22]

It's actually meant to automatically clean up old backup set in this situation, but it looks for specific strings in the error message:

rsync-time-backup/rsync_tmbackup.sh

Line 574 in c0b2ccd

NO_SPACE_LEFT="$(grep "No space left on device (28)\|Result too large (34)" "$LOG_FILE")"

Maybe the logic needs to be updated to handle the error you're having, except that error message doesn't seem to be related to the server being full?

[AmaruCoder]

It is true that the errors don't seem related to lack of space. But, 1. The backup disk is full, and 2. The latest backup only copied a small portions of the files.

How could I safely remove old backups to try again?

[laurent22]

What if you add socket.io error message to the list at the line i mentioned above?

[AmaruCoder]

I tried that, and I get now a long list of Permission denied messages and the rsync_tmbackup goes into a loop. And I have to stop it with Ctrl-C.

[AmaruCoder]

It seems thatrsync_tmbackup tries to expire old backups but when they are not deleted it goes back to try the backup again without catching that error. Is there any way to test this or, better yet, to simply safely remove old backups to make room for new ones?

[laurent22]

You could simply go on the server and delete the oldest directories. It's possible that rsync requires some minimal space even to perform deletion

[AmaruCoder]

I removed a few of the older backups, and rsync_tmbackup.sh ran without problems. Thank you for all your help. What should I do to prevent this from happening in the future?

[AmaruCoder]

I got the error message again. Checking the disk space, it seems that the script is no longer making incremental backups, but tries to backup the whole disk again. Any suggestions how to troubleshoot this issue?

[jksinton]

Hi, I encountered this issue. I thought everything was working fine because backups were still being generated and the oldest were being deleted, but come to find out a month's worth of backups were partial. Luckily, I double checked the latest to see if everything was there.

Perhaps, there could be an available space quota: For example, rsync-tmbackup will delete older backups until there's a certain amount of free space available on the disk, similar to Nextlcoud's trashbin:

https://github.com/nextcloud/server/blob/master/apps/files_trashbin/lib/Trashbin.php#L848

Alternatively, there could be a warning that the backup may not have successfully completed when the write error: Broken pipe is encountered.

Thank you for continuing to support this tool. It has helped me make migrations with ease. I'll see if I can work on implementing one of these feature requests.

[jruhym]

I second the available-space-quota feature request of @jksinton. I am backing up to a zfs pool on a headless server. It gets notoriously slow when nearly full. It has taken many hours to delete the oldest backup. I had to use tmux so that I didn't need a constant ssh login during that time.
I don't want to sound critical. I love this script. I used to use TimeMachine over nfs until macOS put an end to that.