Can one treat Kopia as a new archival format?

General Topics
1

Not sure about this because I don’t understand how/where Kopia stores checksums. Also not informed as to which hashes Kopia uses (Blake2?) and how they are stored (atomically or some internal centralized database/table).

Any reasons for such speculations? Well, if one treated repositories as self contained archives - you might have a good case for storing multiple copies of those archives. Say one connected and another in the safe deposit box?

Your files would be deduped to increase storage density, and each file would be associated with a decent hash.

I’ll be finishing up a restore test next week, and plan to mirror an existing repository - then disconnect the repository and try to run Kopia from the mirror. Anyone sense problems here? Are repositories robust enough to be used like this?

2

If you’d regard the whole Kopia repo as an entity, you could do that. Think of it of an encrypted archive. Technically, there are differences between different type of repos, when it comes down to the storage level.

So basically, filesyetem based repos would provide that. However, bucket-type repos would be harder and not work if copied as is to a file structure.

3

Thanks for the clarification regarding filesystems.

Now I assume you are referring to cloud storage when you refer to buckets? And that those buckets would need to be restored to a local filesystem BEFORE “archive” access?

4

Something I may try next when disk capacity resources allow. Reducing a Kopia repository to a single uncompressed unencrypted file containing error correction.

While updating an existing Kopia repository should be fast, storing as a single file archive might be more robust. The newer versions of rar allow 1000% Reed Solomon recovery records.

Posting the relevant only because moderator at Tom’s was unhelpful and chatty:

I mailed WinRAR and got the asnwer (They dont ask if it’s homework question or not… lol)

And of course, MultiPar or QuickPar can be use as great solution too.

>1. I need recovery record for non-solid archive?
Yes, if you want to improve the chances of any RAR archives being successfully repaired after data damage, use the recovery record, you can also use recovery volumes but only for multivolume archives.
When damage resistance is the top priority, it is best to avoid solid archiving mode, even though non-solid archiving can result
in a lower compression ratio.

>1.1. If there’s a bad sector in future? I still can open the archive OR ARE all corrupted?
Any files after a corrupted file may be unavailable, so you would be best to provide the recovery record or recovery volumes for important files as they are the best way to attempt recovery from corruption, bad sectors, or email transmission errors.
Note that recovery volumes are available only for multivolume archives.

>2. Make recovery records for nested encrypted rar files?
Typically we can’t damage only an inner archive without damaging an outer archive. Also fixing an outer archive should normally fix an inner archive.
So if an inner archive is not stored separately, we suggest you add the recovery record only to the outer archive.
Note that archives with encrypted file names can only be repaired when a recovery record is present.

>3. How much minimum recovery record needed to repair successfully?
RAR recovery record allows to restore slightly less data than recovery record’s own size.

[FONT=arial, helvetica, sans-serif]Note that repairing a damaged archive is not performed for archives with encrypted file names, as these can be repaired only if a recovery record is present. Recovery volumes can only be used with multivolume archives and a complete repair cannot always be guaranteed as each recovery volume can only reconstruct one missing volume file.

To protect an archive from damage, you need to specify the size of the recovery record in a percentage of the total archive size. As from WinRAR 6.10, the maximum allowed value is 1000%. Larger recovery records allow for recovery from more serious damage, but at the same time it increases the archive size, so 3 - 5% is usually optimal, but you could use 10% or even 20% for important backups.

Also the “Repair” command does not fix broken blocks in a recovery record. Only file data can be corrected. After successful archive repair, you may need to create a new recovery record for saved files.

While the recovery record improves the chances of repairing damaged archives, it does not guarantee a successful recovery.
So to improve the chances of any multivolume RAR archives being successfully repaired in case of data damage, use the recovery record and recovery volumes (where possible) when creating them and avoid solid archiving mode, even though non-solid archiving can result in a lower compression ratio.
The best way to ensure that bad sectors are avoided is to use regular external backups, and also save copies of important files on a different disk drive, or thumb drive.[/FONT]

Applications? My thinking is that this would be near ideal for a “baseline” you might store away for years in a safe deposit box. Such a backup would have many limitations due to age…but it still would be useful. The rar container would obviate the need for disk monitoring and scrubbing. While I have stored files on unpowered drives for more than 10 years without ill effect - containerizing such backups might make sense. The big risk? Kopia disappears. Then there would be no way to access this archive. In that case, a direct “mirror to container” scheme would have made more sense. Since I don’t see the rar format going away.

5

No, due to the nature of buckets, there’s no hierachy of folders in a bucket. Buckets scales laterally, rather then vertically (files/folders). Most filesystems slow down to a crawl, once you exceed a certain number of objects in one folder.

Additionally, the repo’s base files are named slightly different, so you can’t simply download the contents of a repo from a bucket and instruct Kopia to use it as a filesystem based repo.