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/
