I’m interested to start using kopia and wanted to see if a particular scenario was feasible (sorry it’s perhaps obvious to those already using kopia but I wasn’t sure from what I’ve gleaned from the documentation and skimming through the forum here)
If I am interested in backing up to a remote location that I can connect to over SFTP but the connection is comparatively slow, could I start off doing my backup with the repository locally and then physically take the hard disk to the remote location and access that same repository remotely over SFTP? (once I plug the hard disk into the remote server)
My rationale is that I’d get the majority of the backup volume done first locally and then the incremental updates would use much less data over the remote connection.
Is that practical and are there any steps I should be aware of to achieve this?
Many thanks!
Neil
There are two types of repositories: cloud-based (s3, gcs, azure, b2) and non-cloud based (everything else).
Cloud repositories use simple flat structure without subdirectories and perform simple writes because underlying providers have horizontal scalability and atomic writes.
Non cloud repositories use sharded subdirectories and rely on temporary files and rename operations to ensure atomic writes.
You can copy data within each type freely (for example move data from b2 bucket to azure container) and the repository will work fine. Moving from file system to sftp or vice versa will also work.
Now to move between cloud and non cloud you can use kopia repository sync-to command from a connected repository. This will move data using blob storage providers inside Kopia which will perform necessary changes to either flatten or shard the repository.