I have been encountering this bug for the longest time and have never been able to fully nail down the circumstances that trigger it.
Sometimes when backups fail, the last good (incremental) backup number gets continually incremented, so that after each failed (hourly) backup attempt, this last good (incremental) backup sees its number increased, leaving a growing numerical gap between it and the penultimate (next to last) good backup. For example, suppose you start out with backups: '0, 1, 2, 3', where '0' is filled and '1, 2, 3' are incremental. Then, after the first failed backup, you will have '0, 1, 2, 4', then '0, 1, 2, 5', then '0, 1, 2, 6', etc. The corresponding LOG shows the following: 2023-09-05 17:00:01 Removing empty backup #3 2023-09-05 17:00:01 BackupPC_backupDelete: removing #3 2023-09-05 17:00:01 BackupPC_backupDelete: Merge into backup 2 2023-09-05 17:00:09 BackupPC_refCountUpdate: host host1 got 0 errors (took 8 secs) 2023-09-05 17:00:09 Finished BackupPC_backupDelete, status = 0 (running time: 8 sec) 2023-09-05 18:00:01 DumpPreUserCmd returned error status 65280... exiting 2023-09-05 18:00:01 Removing empty backup #4 2023-09-05 18:00:01 BackupPC_backupDelete: removing #4 2023-09-05 18:00:01 BackupPC_backupDelete: Merge into backup 2 2023-09-05 18:00:01 BackupPC_refCountUpdate: host host1 got 0 errors (took 0 secs) 2023-09-05 18:00:01 Finished BackupPC_backupDelete, status = 0 (running time: 0 sec) 2023-09-05 19:00:00 DumpPreUserCmd returned error status 65280... exiting 2023-09-05 19:00:00 Removing empty backup #5 2023-09-05 19:00:00 BackupPC_backupDelete: removing #5 2023-09-05 19:00:00 BackupPC_backupDelete: Merge into backup 2 2023-09-05 19:00:01 BackupPC_refCountUpdate: host host1 got 0 errors (took 0 secs) 2023-09-05 19:00:01 Finished BackupPC_backupDelete, status = 0 (running time: 1 sec) I think this is due to an error in how 'reverse deltas' are unwound when a failure occurs. Vaguely, I think when a new incremental backup is started (following a previously good incremental backup), the last backup number is initially incremented as that becomes the tentative new "filled" backup. If it is successful, then the last backup with the incremented number remains filled and the previously good incremental backup is created using reverse deltas. If the backup fails, then this should all be unwound. For some reason, with SOME (but *not* ALL) types of backup failures, the tentative initial delta is not properly unwound. You can recreate this problem as follows: 1. Set up ssh keys for 'host1' and make sure that added to /etc/backuppc/.ssh/known_hosts 2. Create full backup sudo -u backuppc /usr/share/backuppc/bin/BackupPC_dump -f host1 3. Create first incremental backup sudo -u backuppc /usr/share/backuppc/bin/BackupPC_dump -i host1 4. Remove key for host1 from /etc/backuppc/.ssh/known_hosts (I think it will also work if known_hosts is not pingable) 5. Create second incremental backup sudo -u backuppc /usr/share/backuppc/bin/BackupPC_dump -i host1 > Are you sure you want to continue connecting (yes/no)? no IMPORTANT TO DECLINE THIS 6. Create third incremental backup sudo -u backuppc /usr/share/backuppc/bin/BackupPC_dump -i host1 > Are you sure you want to continue connecting (yes/no)? no IMPORTANT TO DECLINE THIS etc. You will see that the backup number of the first incremental backup is incremented each time, creating an increasing gap between the base full backup and the first incremental backup. _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/