Either there is some rare edge or condition in BackupPC causing
de-duplication to fail (which I think is unlikely) or perhaps at some
point your backuppc instance crashed in the middle of saving one of
the above pool files in some indeterminate state that caused it to
create a duplicate in the next backup.
Did you by any chance change the compression level? (though I don't
think this will break de-duplication)
What is the creation date of each of the chain elements? My Occam's
razor guess would be that all 5 were created as part of the same backup.
We did change the compression level (but before doing that we have
checked documentation and different compression levels are supposed to
be full compatible).
Yes, all those files cpool files seem to be from the same wake up/run,
here are their dates:
-rw-r----- 1 backuppc backuppc 396 Jan 6 01:05
cpool/e8/c4/e9c4eb5dbc31a6b94c8227921fe7f91001
-rw-r----- 1 backuppc backuppc 332 Jan 6 01:05
cpool/80/ac/80ad24bf7a216782015f19937ca2e0c801
-rw-r----- 1 backuppc backuppc 337 Jan 6 01:21
cpool/f4/5a/f45b2ef773ddec67f7de7a8097ec636901
-rw-r----- 1 backuppc backuppc 283 Jan 6 01:05
cpool/e2/78/e2797a05cc323d392bec223f4fc3d1c501
-rw-r----- 1 backuppc backuppc 292 Jan 6 01:21
cpool/52/20/52214a481a6dad3ec037c73bae5518bd01
Actually this server first started at 5-Jan , so 5-Jan and 6-Jan was
among the first backups that this server took.
As you suggest, it's really hard to know whether there is an issue
when you have not yet run a full BackupPC_nightly.
That being said, why do you divide it up over so many days? Is your
backup set that *large* that it can't complete in fewer nights?
Yes, I will give it a few days/weeks to check again. Wait first to have
first refCount completed.
2nd backup server sizing stats, when in a "steady" state, will be much
like the stats of the 1st server.
This is about 70-80 hosts utilizing about 10 TB (in the BackupPC data
folder size), keeping about 1300 backups in total (full and incrementals).
We divide our nightly in so many days, because we run nightly in work
hours and the actual backups at night. We have one wakeup in the middle
of the day that allows only nightly to run, all real backups are at night.
When nightly is running, BackupPC gets much slower. So when a restore is
needed this can be a pain.
Running a restore of some GB (not many) while nightly is running (during
work hours) can be really slow due to heavy I/O.
We expect our storage even on steady state to be about 50-60% full, so
there is no rush to remove files.
Having fast restores on demand in business hours is definitely the
priority here over emptying disk space some days earlier.
Thank you.
_______________________________________________
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/
