I am in the process of trying to implement an open source backup software that is fast and reliable for our company. Currently we use BackupPC, which uses rsync to backup files at the background. Rsync is slow (especially for incremental backups) because it compares the source and destination folders for differences first, before backing up the (new) files to the destination.
This is why I want to know if Restic uses the same way? We do not want the slowness that rsync adapts for incremental backups. What is the protocol that is used by Restic for the backups?
Hi @anaigini and welcome to the restic community! 
Many others have actually implemented restic in their business - even the CERN has it set up with a huge amount of users and big repositories in regards to size. Forum link: CERN is testing restic for their backups - #13 by robvalca
So rest assured, restic can indeed be used in bigger environments then a couple VPSs or Raspberry Pis 
So in regard to speed: So restic is designed in a way that incremental backups are fast. There are always cases where a backup can take longer, but as long as you make sure that you are using the restic cache, which restic will use by default, then I don’t think you have to worry about it much.
To learn more about restic cache: Manual — restic 0.16.3 documentation
Restic keeps a cache with some files from the repository on the local machine. This allows faster operations, since meta data does not need to be loaded from a remote repository.
But as always: Usecases and setups can vary and I highly recommend testing it out.
I did not go into the very technicalities of how restic works - all this is documented in the restic documentation at Restic Documentation — restic 0.16.3 documentation.
But if you need to know how restic is designed, then head over to References — restic 0.16.3 documentation
I hope this answers some of your questions Let us know if not.
We have tons of active users here that can definitely give you more technical information if needed.
If the volume is really high, my recommendation is to try to split the directory structure, as restic is really easy to scale so you can run backup processes in parallel. Also, avoid to use huge single repositories and segregate a bit, the prune and check processes will appreciate this 
. People seems worried about this because you don’t get the full benefit of file de-duplication but you still have the chunk de-duplication which does an amazing job. Small repos are fast to operate, you can move them around easily, operations on them are less resource hungry and with the plus that minimizes the risk in case of a problem.
Having some external machinery to decide when to backup something or not is really helpful too, in general.
Of course it will depend on your specific use case, but restic it’s a really flexible and powerful tool. In any case, I would give it a try!
I hope it helps!
1 Like