I’m having some errors checking a cubbit ds3 repo. During running maintenance full I give
“unable to get content data and info: invalid checksum at …” in almost 2000 files.
I read some post and I know this could be a data corruption, but I don’t know if it’s only backupped data to be corrupted or also original data.
How could I go forward to solve?
p.s.: in this repository I backup 2 workstations.
Hard to tell at which point the corruption happened. If possible you should run a memtest to see if the issues are caused by faulty memory on the clients.
Run kopia snap verify the see if this is a temporary or permanent issue with your repository/provider.
If the issue persists you can run kopia snapshot create --force-hash=100 for all of your sources and hope that Kopia is able to re-add all missing data. I doubt that this will help with your issue but there is no harm in trying.
You might have to run kopia snap fix invalid-files and kopia snapshot fix remove-files to remove all corrupted content from your repository.
Valuable information here. Information best learned by osmosis. Thanks.
I run new backup software over extended periods before fully making changes and trusting the new product. “Recovery in the event of corruption” was a serious concern, and these comments offer a path to test.
Have noted that Kopia plays nice with drive pool virtual drives. It “sees” the virtual drive as just another disk. That’s actually unusual and sets Kopia apart.
Unfortunately this compatibility does not seem to extend to virtual drives as a backup target/repository host and I’ve been unable to isolate the problem. Kopia will run for a long time - but then crashes hard. I’m aware that the problem may actually stem from my legacy hardware. The target drivepool may be undersupplied with CPU, memory, or physical disk speed for this task. If so, that’s a shame. Because it is common to push older hardware into the backup role. And one of the advantages drivepool supplies is an almost infinitely expanding storage capacity even with older drives. It can work well, but I’m not seeing that with Kopia.
One of the questions I always had was how might Kopia’s repository respond to the loss of a physical disk which was part of a large virtual disk hosting that repository? Assuming the primary copy was still intact, could one regenerate the repository from it quickly?
One of the most ancient rock climbing rules is “three limbs on the rock at all times”. Covers most of the risks. Similar situation to having a good primary copy when the backup fails. You still have risk, but most of the time there is still an exit which leaves you in one piece.
A feature which I would find useful for testing disk pools as backup targets? Some means to slow down the data flow. When Kopia fails with drive pools - the mess is quite spectacular.
StableBit - The home of StableBit CloudDrive, StableBit DrivePool and the StableBit Scanner (very robust…but uses a lot of disk space)