restic copy works “inside” the repository while rclone works “outside.” This means that restic copy can work in multiple scenarios where rclone cannot:
- The source and destination repositories do not need to have the same master encryption key. The downside is that restic has to decrypt and encrypt each blob that it copies between repositories to account for this.
- You can selectively copy only some snapshots; restic will copy only the blobs used by those snapshots that don’t exist in the destination repository. This obviously requires more work: the source snapshots have to be crawled to find the blobs that don’t exist in the destination, then restic has to create new packs for those and transfer them to the remote repository.
In comparison, file copy/sync tools like rclone/rsync are only suitable when you are trying to duplicate an entire repository and all of its contents indiscriminately. Off-site mirroring is a good example of this.
On the other hand, if you wanted the off-site repository to have a different master key, or retain a different set of snapshots, then rclone/rsync would not be appropriate anymore and you would need to use restic copy instead.
restic copy is way more flexible, but generally will require more CPU time, read IOPs, and memory to transfer the same amount of data.
rclone is also generally better about doing transfers in parallel. You can even specify the number of parallel transfers with the --transfers flag. On the other hand, I believe restic limits the number of archiver threads to 2, so in practice you won’t see more than two parallel transfers, which could easily account for the slower overall speed.