Hi, so I’m thinking about swapping over from Duplicacy and I noticed that Kopia cannot handle multiple repo’s in one container, and it is recommended to just use multiple containers that pull from the same location. But I’m trying to set up a test instance of that, and I am hitting a wall.
So I have a home lab with different VM’s and a NAS. Currently, I have the VM’s rsync the files through ssh via rsync to the NAS in a backups folder daily. Then Duplicacy backups up those files daily to another vm with a external drive attached to it, then weekly backs up the files to Backblaze B2. The issue I’m running into thinking about it is, do I need 3 Kopia containers on the NAS? One to act as a server and set up a local repo, One for the SFTP to the VM from the local NAS repo with the external drive and one to Backblaze from the local NAS repo. I feel like that becomes just as convoluted as my other setup and wouldn’t the two containers that are backing up to the external drive and B2 also not only have their own snapshots but also try to compress them as well on top of the already compressed and snapshotted files? I feel like I’m missing something.
Potential Solutions:
- Single Container Approach:
- Use a single Kopia container on the NAS to handle all backups.
- This container could sync:
- Locally (to the external drive).
- Remotely (to Backblaze B2).
- Clarify Compression/Snapshot Logic:
- Kopia doesn’t re-compress or re-snapshot files when backing up from a repo. Instead, it transfers the already-compressed/snapshotted data. This avoids redundancy.
- Alternative Workflow:
- Skip the local repo entirely and back up directly from the NAS folder to both the external drive and Backblaze B2. This might simplify things further, depending on your needs.
Doesn’t kopia only allow you to upload to one repo per kopia instance?
I guess everything happens after you connect to a repo. You can use script to connect one after another one to multiple repo.
I believe sync-to connects to two repo in the same instance.