I want to fully delete a snapshot using the Windows GUI app and then want to add the snapshot again. Now I tried that (deleted all the snapshot version of that snapshot), but what seems to be happening is that all those old snapshots come back. I tried running maintenance after I delete the snapshot, that didnt help it either.
What do you mean? Do you really mean a snapshot, or do you mean a source? As for snapshots, those are point-in-time versions of the source you configured. If you remove a single snapshot, you can’t recreate it, since the time has passed.
To me it rather looks, like you wanted to remove a source and attach it again.
I think I meant source. The source has a lot of snapshots, I delete them all. I then add the same source back. What happens is that I see the old snapshots of the source returning back when I add the source from scratch again.
That’s due to the fact, that the old snapshots have not yet been deleted from the repo. The old data will only be purged after some time. If this is your only source, you might as well just create a new repo and start fresh.
I don’t understand it though, I literally ran this after deleting the source “kopia maintenance run --full” Should this take care of that? It didn’t remove the source, not sure what I am doing wrong here.
Regardless of that I don’t want to create new repository, I just want to delete the source and its snapshots and add it again. Is there a way to do it properly without waiting,? I don’t even know what that time frame is.
Without taking any responsibility here… you could run this command:
kopia maintenance run --full --safety=none
which will remove all deleted snapshots, ignoring their minimal hold time. However, no client must be connected to that repo at that time. Since you’re using KopiaUI, you’d have to run the underlying Kopia server separately to do that. This is surely possible under Windows, but I am not familiar with how to do it, since I am not a Windows person.
That’s why I said, creating a new repo would be faster - unless you’re having other sources in that repo as well.
I’ve looked for that remove repository command but never found it. I’m considering the purchase of a new 22TB drive to hold new backups of everything - then later deleting out the old repositories completely. Have any idea how to accomplish this?
On this next repository, I wish to run the built in error correction feature. Had avoided it originally because it was new/untested possible slow…but now feel it would be an advantage given the errors I see when verifying my present repository.
Just completed chkdsk on both those drives to hopefully mask any bad blocks - but am ready to try Kopia’s alternative.
Larger disk you get, more chances to develop bad sectors over time - it is fact of life:). People using single disk in most cases never notice when one of their pictures gets corrupted. But kopia and similar software is unforgiven - it checks and double checks every bit it reads and reports errors if not correct.
kopia error correction feature is experimental and IMO almost useless for this case. It can fix some flipped bits but for bad sector on mechanical disk you will have 512 or more likely 4096 consecutive bits missing (sector size).
Solution: get yourself two disks and use them in BTRFS or ZFS mirror. Run periodicaly full scrub. Such setup will self heal any random bad sectors without you even noticing.
Well… reading something about “chkdsk” makes me assume that this is a Windows setup - so no BTRFS or ZFS there. However, there are numerous possibilities as of why verification errors could occur - bad drive sectors is only one of them.
I think ReFS does support RAID natively but it is all unchartered water for me:)
You are right of course but with 22TB mechanical hard drive I can almost guarantee to see bad sectors if it is really in use. It is simply nature of this storage type. And manufacturers do no hide it. Usually documented by manufacturer URE rate will be about 10^14 which is less than every 22TB read…
But in actuality, that error figure is likely a limit spec. The drive is nominally capable of much better performance. Microsoft did some experiments with this.
I’m thinking that the real problem is a bad write to the repository. Then Kopia’s checksum later catches it.
I ran a Snapraid array for many years. Little to zero bitrot. Now Snapraid does not use the most rigorous hash, it’s optimized for speed. But I do believe it was reporting fact. In real life, bitrot isn’t a significant problem. Why I’m not too keen about reinventing disk defect management via applications software. Not worth the squeeze.
I do wish that Kopia contained a function which would simply rewrite bad blobs (?) with the correct information when those errors are discovered. The current method of reporting errors but never fixing them leaves much to be desired. A “whut were you thinking” moment.
I am sure Kopia can do that, if all the needed files are still on the disk. But, what about the times, when a BLOB gets corrupted - for whatever reason, and the data that’d be needed to rewrite the BLOB has already been deleted from the source… Kopia constantly shuffles and re-arranges BLOBs as a part of its repo maintenance.
But, what about the times, when a BLOB gets corrupted - for whatever reason, and the data that’d be needed to rewrite the BLOB has already been deleted from the source
But, what about the times, when a BLOB gets corrupted - for whatever reason, and the data that’d be needed to rewrite the BLOB has already been deleted from the source…
True, but many users with static data would be unaffected.
Most of these tools are failing me one way or another.
I understand Kopia is still under development, and like much of what I see. But I don’t see it as a robust solution yet. And I would understand if a robust solution just isn’t possible.
Well… I have been using Kopia for a couple of years now and I’d say, it’s pretty stable. And I am running also a rather big instance of it at work where it has a repo of approx. 93TB of (deduplicated) data… Never had an issue with the repo…