There are now on-prem object storage solutions that perform storage-side data de-duplication, compression, and encryption at rest. Kopia eliminated the option to disable encryption, which then severely impacts these valuable efficiency technologies. Kopia encryption is a detriment in the main environment I work with, as the storage is already encrypted end-to-end.
If the Kopia files weren’t encrypted, the storage side would take the backup data together with the primary data, dedupe them together, and provide huge savings. The savings on the primary storage, replica storage, and in the WAN pipe for replication cannot be ignored. We already see these savings with our current solution because it allows unencrypted backup data. We disable encryption of container storage as well to enable these savings.
SO, is there the potential to bring back the option to disable encryption to support these on-prem storage efficiency use cases? Kopia isn’t really viable at scale (10s of PB) as long it forces extra encryption. It would at least double the storage costs and WAN pipe costs, just due to this one simple option.
I though long and hard about what to answer, but due to the lack of details in your post… maybe Kopia is not for you then. My gutt tells me, that you are trying to keep your actual live data and backup data on the same system, which is something, I’d never do. However, all of your arguments seem to point in that direction.
After years long and very heated discussion the latest restic allows to create repositories with no password now. In principle restic does the same as kopia. I use both as none is perfect:)
But in line with @budy I would be very careful in treating solution described in original post as a backup… but of course various people have different ideas:)
I can say this use case would be one of many in a massive global infrastructure footprint with several tiers of storage and data protection. We already have multiple tier-1 data protection software options deployed in the environment. Kopia would be useful to solve some niche use cases, but not if it enforces encryption where none is required.
If I understand the OP correctly, they are looking to use Kopia in conjunction with an enterprise-class storage system that already provides encryption, deduplication, high levels of redundancy, etc. So the OP is asking if some of these features in Kopia, specifically encryption, can be turned off as there’s no need for the multiple layers of encryption, and, in the OP’s case, the additional layer of encryption negates the value of the enterprise-level dedup.
I think this is a reasonable request but unfortunately it appears the ability to turn off encryption is not available today. Hopefully the developers agree and will add this feature to the backlog.
I read the entire discussion on the restic github, quite amusing and informative.
Kopia [server] already allows no password and no encryption enforcement (TLS) if you supply extra flags. I would upvote a feature that allowed for no password & no encryption if this was “locked” behind a flag the user had to intentionally pass to the client.
The restic discussion seemed to focus heavily on “what if I forget my password” or “why don’t you just use a dummy password” but I think that a more important use-case is for friends and family to be able to access my backups in the event that I’m unable to supply a password of any kind. They would not think to try dummy passwords or even attempt a brute force on the repo.
What do you use restic for, that you see kopia lacking in? I haven’t used restic for years (since switching to kopia after restic failed me).
Both let me down in the past and I do not trust neither 100%
Restic made massive progress lately and it has much more responsive community - especially key developers active all the time on their forums and github so you know that whatever issues there is always some help - this is not the case with kopia.
Also I use rustic - alternative restic repo format supporting program. It has few features already that are missing in restic and has much faster dev cycle. I am a big fan of this program.
Both restic and rustic have very close and working rclone support. In kopia it is IMO disaster trying to use rclone serve webdav but to be fair is documented as experimental. And it is - slow and unreliable.I need rclone only supported backends sometimes.
I use kopia for S3 storage as it very nicely deals with object locking. Doing the same with restic would require me taking care (via extra scripting) of many details.
In addition I prefer to use two different programs for key data backups.
