Hi, On 2024-08-20 20:30, to...@tuxteam.de wrote: > On Tue, Aug 20, 2024 at 07:41:31PM +0200, Ghislain Adnet wrote: >> so what i get from this is that when there a corruption for a random reason >> backuppc will see it but will not do anything to correct it or backup it >> ever again even if it exist on the source client. > > Always test your backups. Bonus points if it is by independent means.
That's all fine and true. But Ghislain is touching a very valid point here. He actually *did* test (or looked at BackupPC's fsck performing a partial test), found out that there is some issue, and now wants to take steps to resolve it. If I understand correctly, the situation here is: 1) Backups have been executed in the past and been working fine. 2) Some corruption on the server happened; e.g., one or several pool files experienced bit rot. 3) BackupPC_fsck detects the issue and reports a file as broken. 4) ... but there is no means for BackupPC itself to *react* on the issue; it simply warns, but there is no recovery. Instead, even on a new backup when the original file is still available on one of the host, the server copy of the file is just taken to be "fine". I.e., BackupPC detects that a file with the same hash is already existing in the pool, so it happily assumes there's no need to retransfer the file. It's simply kept as is, although it was detected as broken in step 3) - this information is not propagated to or used within subsequent backup jobs. *If* this is really correct, it's a serious resilience problem with BackupPC. At least, it fails any "principle of least surprise" check. Of course, BackupPC can't be expected to recreate data that is lost on both server and clients. But *some* remedial action can and should be taken. One somewhat sane reaction, IIUC, would be to move the broken file from the pool into some "quarantine/damaged" area (it could still be "mostly" okay and contain useful information after all, if anything else is lost). At the very least, the pool file should be marked as "suspicious" such that, if it is found on some host during a backup again, a fresh copy will be created in the pool. Or, if you are concerned about hash collisions, a new copy with _1 appended should be recreated and used for the new backups from this point onwards. The same approach should be taken about attrib files. Same logic: If the folder on the host remained unchanged, a new backup should recover any information that BackupPC_fsck detected as lost on the server. I'd totally understand if some manual intervention is required (stopping BackupPC, running some rescue commands etc.) - but from what I understand from Ghislain, there's nothing to help apart from microsurgery or creating an entirely new BackupPC instance, losing all history. And that's the opposite of rock-solid. I've yet to confirm, but my own experience from the last couple of weeks seems to support this observation. Cheers, Alex _______________________________________________ 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/
