Hi,
well, your message means that some attrib files are unaccessible. Likely
destroyed, but you should confirm that e.g. with checking the access rights of
those mentioned files in /var/lib/backuppc/cpool/??/??/
BackupPC_zcat
/var/lib/backuppc/cpool/18/04/18049d6c5bf4339c16a4850421ebf020 | md5sum -
which should print the name of the file as its hash.
Sadly, unless there's a benign but unlikely mishap, this means that the "tables
of contents" of some directories (such as my.server.com's /var/lib/vim/ from
backup #745) are lost beyond repair. And unless those directory are accurately
unchanged (including all timestamps etc.), you will not see a recovery. It's
kinda moot that the files in this directory might still be stored in your pool;
unless you know their hashes, you won't find them for a recovery.
I've been bitten myself by a similar problem due to a hardware defect (broken
SATA cable, with high probability).
First, accept that those files lost. Well - unless they are *really* valuable
(think Bitcoin wallets or so) and you'd realistically consider checking every
single file from your pool, without filename or metadata accessible, to recover
the most precious pieces.
I gave in to my fate. To get rid of the noise from fsck, a partial recovery is
to delete the affected directories from your backups using
BackupPC_backupDelete, e.g. as follows:
BackupPC_backupDelete -h my.server.com -n 745 -s / /var/lib/vim
Because this takes ages, I tried a more nasty surgery (disclaimer: this is not
the realm of official, supported, battle-tested tools but the turf of
tinkerers): replacing those attrib files by attrib_0 (which means "empty
directory"). That's essentially equivalent to manual deletion of directories.
This reduced the noise significantly after a subsequent BackupPC_fsck and
refCntUpdate.
But interestingly, fsck still shows me a couple hundred of "missing pool file
<hash> count >=1" entries, and I can't find out where those belong (even with a
BackupPC_ls across *all* of my backups on that server). As far as I can tell,
it's no longer attrib files that are reported as missing, but apparently
leftovers from poolCnt/refCnt files even surviving a
BackupPC_refCntUpdate -m -f -F -s
If anyone has a hint on how to debug/resolve that, I'd be grateful myself.
E.g., is deleting all refCnt and poolCnt files "save" (i.e., recoverable via a
refCntUpdate) and could potentially remedy that?
In general, I'm somewhat surprised how hard it was to accept partial data loss,
but trying to get to a clean slate with the 99.9% of data still around healthy
and unaffected. Getting rid of the errors (that I accept now) is essential to
reasonably monitor this server in the future; unfortunately, setting up a new
additional server while keeping still the old one available with the past
backups is not possible for this instance.
Hope this helps,
Alex
On 2024-08-09 09:17, Ghislain Adnet wrote:
> hi,
>
> I need your help on a corrupt pool issue. i have a backup server that has
> corrupt pool:
>
> bpc_path_refCountAll: can't read attrib file
> /var/lib/backuppc/pc/my.server.com/745/f%2f/fvar/flib/fvim/attrib_ed3203cd9ac62bd456a37700c2051357
> bpc_attrib_dirRead: can't open
> /var/lib/backuppc/cpool/18/04/18049d6c5bf4339c16a4850421ebf020
> bpc_path_refCountAll: can't read attrib file
> /var/lib/backuppc/pc/my.server.com/745/f%2f/fvar/flog/attrib_18049d6c5bf4339c16a4850421ebf020
> bpc_attrib_dirRead: can't open
> /var/lib/backuppc/cpool/70/18/701886a56156e44efd43bd7ba0dde4e9
> bpc_path_refCountAll: can't read attrib file
> /var/lib/backuppc/pc/my.server.com/745/f%2f/fvar/fspool/attrib_701886a56156e44efd43bd7ba0dde4e9
> bpc_attrib_dirRead: can't open
> /var/lib/backuppc/cpool/d4/a2/d4a30c60507b799b3e67fab9902136f6
> bpc_path_refCountAll: can't read attrib file
> /var/lib/backuppc/pc/my.server.com/745/f%2f/fvar/fspool/fcron/attrib_d4a30c60507b799b3e67fab9902136f6
> bpc_attrib_dirRead: can't open
> /var/lib/backuppc/cpool/ea/86/eb864e3cc6744041fa3f107e2cf6d2fc
> bpc_path_refCountAll: can't read attrib file
> /var/lib/backuppc/pc/my.server.com/745/f%2f/fvar/fwww/attrib_eb864e3cc6744041fa3f107e2cf6d2fc
> bpc_attrib_dirRead: can't open
> /var/lib/backuppc/cpool/a6/04/a604a101e6952191d40a4b2b4be31c26
>
>
> and i can't correct this.
>
> I runned
>
> /usr/bin/perl /usr/share/backuppc/bin/BackupPC_fsck -f -s
>
>
> it just show the error but correct nothing and the corruption prevent any
> restore of the files of course. New backup do nothing to correct it and the
> daily refcount do nothing.
>
>
> Any pointer to correct this ?
>
> --
> cordialement,
> Ghislain ADNET.
> AQUEOS.
>
>
>
> _______________________________________________
> 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/
_______________________________________________
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/
