Unfortunately it’s no longer possible to switch off encryption for already encrypted source files. What about combining the genious Kopia with programs like gocryptfs, cryptomator, cryfs…?
therefore not only the snapshot should be encrypted, but all source files in the repository. If the user wants to work with it, he must mount it as a local filesystem, like mounting snapshots. When mounted, files are added by encrypting them on the fly.
And what would be the benefit of that exactly? Kopia doesn’t have a glimpse of knowledge about the underlying fs - it gets the source files decrypted handed to it. If you’re talking about snapshotting an “encrypted” fs offline, where you come across the encrypted files themselves, I’d say that Kopia is not the right tool to use for backing that up, or at least Kopia will not be able to play out all its strengths, since you Kopia doesn’t get any actual contents it can use the deduplication algorithm on, due to the encrypted files defeating the content-addressable-storage setup.
It should be irrelevant when Kopia encrypts files, when the file is created or during snapshoting. So the original source data should be “snapshot 0” and every file exists only encrypted. But when snapshot 0 ist mounted, kopia and users can work with it.
I don’t know how kopia works and if that would be possible.
The benefit of it is, that you have encryption and Backup in one program. Kopia forces the User to encrypt on Google Drive, so why not encrypt the source files? I don’t speak of file system encryption Like veracrypt, but file encryption.
In my case, I combine Veracrypt’s encrypted container (not system encryption) and Kopia to achieve that goal. Then you can do what you desire: mount the container whenever you need to change or back up its contents.
However, I don’t think the two can be combined as they have different goals. Veracrypt focused on minimizing data leaks on the source device at the expense of ease of transport, while Kopia did the opposite, focusing on the speed and efficiency of data transfer at the expense of data leaks on the source device.
I used container-based encryption like veracrypt but changed to file-based. The reasons are: backups are difficult especially in clouds. So decoding the container and encoding the backup again is essential. It’s possible but you have no 1:1 backup and the advantages of container-based encryption are lost when the backup is file-based. The container has a fixed size and cannot be resized (exception bestcrypt). If there is an error with the container you might loose all files.
File-based encryption has exactly the same goals like backups, the first encryption is a backup of the original data.
You can use gogryptfs that won’t take any amount of storage by providing encrypted view/mount dynamically that can be subject for backup, but as @budy said, the very useful features as compression and deduplication will be lost
That is just the reason why I opened this thread. A Kopia backup can be mounted as a filesystem like a gocrypt-filesystem. If it would be possible that Kopia does not use the original data as backup source but the latest encrypted backup, it should work just like gocryptfs.
kopia is cloud backup - cloud storage mostly is object based - it means you can’t just modify part of the file - you have to upload all file . It is total misunderstanding about how things work trying to talk about block level encryption vs. cloud object storage.
As far as I know Kopia uses splitting, that means you can modify parts of files. The feature I suggest is encryption of local data, further backups can be done where you want.
No idea if this would work.
Splitting is sorely used to identify identical parts of files and fuels the dedup feature. So, files will be chunked into smaller parts, thats true, but you’ll never know, where the chunking took place. Then there are blobs - which may contain one or multiple files/chunks - they just serve as an performance accelerator, since dealing with a lot of small files will degrade the performance. Since blobs do hold chunks, which will be subject to ageing, they need to be rewritten now and then, unless you intent on never remove any snapshot. So Kopia doesn’t actually modify parts of the backed up files, but rather blobs (containers) to tender to the ageing and pruning of snapshots.
As for your inital idea… mounted Kopia snapshots are read-only - you cannot use them as a base for your encrypted fs, since you can’t write to it - or did I misunderstand your suggestion about working with mounted Kopia snapshots?
Just right, there is no need to write to the encrypted data if it’s only used for backups. And if I understand you right, that would be impossible to change because all is optimised for backups. What about melting Kopia with a program like gocryptfs? (I know how time-consuming programming is…) This is just an idea, I have no idea about the underlying techniques.
There are some attempts to combine gocryptfs with backups e.g. here and here.
I am experimenting with Kopia for a similar setup as you. I want to back up my Windows C-drive to an external HD encrypted with Veracrypt.
Do you snapshot manually or do you use a policy with set frequency?
Hi Sauna,
I had the same setup with veracrypt. But this is not secure on the PC, because every backup program I know stores information about the backup locally insecurely. That’s why I now only backup files that are already encrypted. I do file-based encryption with gocryptfs (cppcryptfs under Windows).
I use automatic snapshots, but different ones for data that changes frequently such as Thunderbird or Firefox profiles. The memory consumption is not that big. The disadvantage is that compression of already encrypted data does not work and deduplication/splitting only to a limited extent.
If you find a better solution, feel free to write.