Both tools do the same job with different syntax. Pick one, set the repository and paths, and get init, backup, prune, and restore commands that agree with each other.
The failure mode is always the same: backups run for two years, nobody tests them, and the restore fails when it matters. Schedule a real restore to a scratch directory at least twice a year, and use check --read-data or borg check so the data is verified rather than just the index. The other rule worth following is the offsite one: a backup on a disk in the same machine survives a bad update, not a fire, a theft, or ransomware that walks the mount points.
This backup command builder generates matching init, backup, retention, restore, and verification commands for restic and BorgBackup. It covers exclude patterns, compression levels, tags and archive naming, keep-daily and keep-monthly policies, and the details each tool handles differently, including Borg needing compact after prune to actually free space and restic reading its password from a file for unattended runs.
restic talks to S3, Backblaze B2, Azure, and SFTP natively, so it is the answer if your target is object storage. Borg requires the repository to be local or reachable over SSH with Borg installed at the far end, and in exchange usually compresses better and can run in append-only mode. Both encrypt by default and both are excellent.
With Borg, prune only marks archives for removal; borg compact is what reclaims the disk space. With restic, forget without --prune does the same thing. Running the retention command and expecting space back without the second step is the most common surprise in both tools.
A systemd timer, not cron, because you get journal entries, exit codes, and Persistent catch-up if the machine was off. The systemd timer builder generates both units. Point the service at a small wrapper script that runs backup, then forget, then prune.
No. rclone or a sync client mirrors the current state, so a deletion, corruption, or encryption by ransomware propagates to the copy. A backup keeps history you can go back through. A common good pattern is restic to a local repository, then rclone to push that repository offsite.