Restic vs Borg vs Rsync: Backup Tools for Cloud Servers

Introduction

Restic vs Borg vs Rsync is really a decision about what kind of recovery path you need for your cloud servers. On Raff Technologies, we usually think about backup tools in layers: snapshots for fast VM rollback, database-native dumps for application state, and off-server backup repositories for files that must survive the original machine. Restic, Borg, and Rsync can all help, but they solve different problems.

A backup tool is software that copies, stores, verifies, or restores data so you can recover from deletion, corruption, failed deployments, ransomware, or infrastructure failure. Restic and Borg are true backup tools because they create restore points with deduplication and encryption. Rsync is more accurately a synchronization tool: it copies changed files efficiently, but it does not automatically give you historical restore points unless you build retention around it.

In this guide, you will compare Restic, Borg, and Rsync across encryption, deduplication, storage targets, restore behavior, operational complexity, and fit for Raff cloud infrastructure. For the broader recovery strategy, start with Cloud Server Backup Strategies: Snapshots, RPO, and Recovery Planning, then use this guide to choose the right file-level tool.

Quick Recommendation

Use Restic when you want encrypted, deduplicated backups that can be sent to object storage, SFTP, local disks, or other remote repositories. Restic is the cleanest choice for small teams that want off-server cloud backups without operating a separate backup server.

Use Borg when you control the backup destination and want efficient deduplication, compression, encryption, and mountable archives. Borg is excellent when you have a dedicated backup VM or storage server and want mature Linux-style backup workflows.

Use Rsync when you want simple file synchronization, readable backup folders, fast server-to-server copies, or mirror-style backups. Rsync is not enough by itself for serious recovery unless you add retention, database dumps, off-server storage, and restore testing.

The short version is simple: Restic is usually the best fit for object-storage-friendly cloud backups, Borg is excellent for controlled backup repositories, and Rsync is still the right tool for straightforward file transfer and mirroring.

What Restic Does Best

Restic is best when you need encrypted, deduplicated backups that can move cleanly from a cloud server to external storage. It is especially useful when the backup destination is not another Linux server you fully control, such as S3-compatible object storage, a remote storage service, or a separate repository endpoint.

Restic works by storing backup data in repositories. A repository can hold many snapshots, and each snapshot represents the state of selected files at a point in time. Because Restic deduplicates data, repeated backups do not store every file from scratch. Only changed data needs to be added.

The most important Restic advantage for cloud servers is separation. A Raff VM can run your application, while Restic sends encrypted backup data to off-server storage. If the original VM is damaged, deleted, compromised, or rebuilt, the backup repository can still be used from a clean machine.

Restic is a strong fit when:

• You want client-side encryption before data leaves the VM.
• You want deduplication across repeated backups.
• You want object storage as a backup target.
• You want one tool for Linux, macOS, Windows, BSD, and mixed environments.
• You want a simple restore workflow that can run from a new server.

Restic is not perfect for every situation. It still needs careful retention rules, secure repository passwords, monitoring, and restore testing. It also does not replace database-native backup commands. For PostgreSQL, MySQL, or MariaDB, you should dump or export the database consistently first, then let Restic store that output safely.

A practical Raff pattern is to use Restic for encrypted off-server backup repositories, Raff snapshots for VM rollback, and database dumps for application state. That gives you more than one recovery path instead of betting everything on one mechanism.

What Borg Does Best

Borg is best when you want efficient deduplicated archives on storage you control. It is popular with Linux administrators because it combines deduplication, compression, authenticated encryption, pruning, and mountable backup archives in a mature backup workflow.

Borg is especially strong when the destination is another server reachable over SSH. For example, you might run your application on one VM and send Borg backups to a separate backup VM, storage box, or internal backup host. That model is clean when your team controls both sides of the backup path.

One of Borg's strongest operational advantages is how naturally it fits Linux server administration. You can create repositories, push archives over SSH, prune old archives, compact storage, and mount backups to inspect files without fully restoring everything. For teams that already understand Linux permissions, SSH keys, and scheduled jobs, Borg feels direct and powerful.

Borg is a strong fit when:

• You control the backup destination.
• You want deduplication and compression.
• You want encrypted archives.
• You want to mount backup archives and browse files.
• You prefer SSH-based backup infrastructure.
• You are comfortable managing backup repositories yourself.

Borg is less convenient when your preferred target is S3-compatible object storage. Borg can be used with additional layers or gateway patterns, but that is not its simplest native workflow. If your target is object storage, Restic usually has the cleaner operational model.

On Raff, Borg makes sense when you want a dedicated backup VM, a private backup network, or a controlled Linux-to-Linux backup design. It fits teams that want to own the backup server and understand the repository lifecycle.

What Rsync Does Best

Rsync is best when you need fast, simple, incremental file transfer. It is excellent for copying application directories, synchronizing uploads, moving data between servers, and creating readable mirror folders. It remains one of the most useful tools in Linux operations because it is predictable and widely available.

The main thing to understand is that Rsync is not a backup system by default. Rsync synchronizes files. If a file is deleted from the source and your command mirrors deletions to the destination, the destination may lose the file too. That behavior is useful for synchronization, but dangerous if you confuse synchronization with historical recovery.

Rsync becomes more backup-like when you add structure around it. You can combine it with timestamped directories, hard links, tar archives, retention scripts, remote servers, and database dumps. That is why Raff's tutorial on automating backups with cron and rsync on Ubuntu 24.04 uses rsync as part of a broader backup workflow, not as the entire recovery strategy.

Rsync is a strong fit when:

• You want readable files at the destination.
• You need simple server-to-server migration.
• You want to mirror upload directories.
• You need fast incremental copies over SSH.
• You want a backup workflow that is easy to inspect manually.
• You do not need built-in encryption, deduplication, or snapshot history.

Rsync is weaker when you need encrypted repositories, deduplication, versioned snapshots, or long retention chains. You can build some of that manually, but by the time you do, Restic or Borg may be safer and easier to operate.

Feature Comparison

The table shows why there is no universal winner. Restic and Borg are backup tools. Rsync is a transfer tool that can be used in backup workflows. That difference should drive the decision.

Decision Framework: Which Tool Should You Choose?

Choose Restic if your backup target is object storage, remote storage, or a repository you want to keep independent from the original VM. Restic is the most natural fit when your recovery plan says, “I need to rebuild a clean server and pull encrypted backups from outside the failed machine.”

Choose Borg if your backup target is a Linux server you control. Borg is excellent when your team wants compression, deduplication, encryption, pruning, and mountable archives, and you are comfortable maintaining the backup repository.

Choose Rsync if your goal is copying files, mirroring directories, moving data between servers, or keeping a readable backup folder. Rsync is still one of the first tools we reach for during migrations, emergency transfers, and straightforward file-level operations.

The better question is not “Which backup tool is best?” The better question is “Which failure am I designing recovery for?”

How This Fits Raff Infrastructure

On Raff, backup design works best when you separate compute, restore points, and durable storage. A Raff Linux VM should run the workload. Snapshots and automated backups should protect the server state. Object storage or a separate backup target should hold recovery data that must survive the original VM.

That separation matters because the worst incidents are not always simple file deletion. A bad package upgrade, compromised SSH key, corrupted database, accidental recursive delete, or failed deployment can make the original machine untrustworthy. In those cases, your backup tool should let you restore from a clean VM, not force you to depend on the broken one.

For Raff users, a practical design looks like this:

If your backup data is stored in S3-compatible object storage, Restic is usually the cleanest tool. If your backup data goes to a second Linux server over a private network, Borg becomes very attractive. If you need to move files between two machines quickly, Rsync remains the simplest answer.

Snapshots Still Matter

Backup tools do not replace snapshots. Snapshots and file-level backups solve different recovery problems.

A snapshot captures a point-in-time state of the server or volume. It is useful before risky upgrades, kernel changes, package updates, firewall changes, database migrations, or application deployments. When the whole server state breaks, a snapshot can be the fastest route back.

A backup tool captures selected data into a backup workflow. It is useful when you need historical file versions, off-server recovery, database dumps, selective restore, or recovery onto a clean machine.

That is why you should not choose between snapshots and backup tools as if they are competitors. The safer pattern is to combine them. Use snapshots for fast rollback and use Restic, Borg, or Rsync-based workflows for the data you need to recover independently. For a deeper explanation, read Cloud Snapshots vs Backups: What’s the Difference?.

The main risk is overconfidence. A snapshot can preserve a broken state. A file backup can miss system-level configuration. A database dump can miss uploaded media. A mirror can copy accidental deletions. Recovery is safer when you have more than one layer.

Database Backups Need Special Care

Databases deserve their own backup logic. A database is not just a normal folder, because live writes, transactions, indexes, locks, and consistency rules matter. Copying raw database files with Rsync while the database is running can produce a backup that looks complete but fails during restore.

For PostgreSQL, MySQL, and MariaDB, use database-native export tools or proper physical backup methods before sending the output into Restic, Borg, or Rsync. In many small-team setups, a clean logical dump is enough. For larger databases, replication, write-ahead logs, point-in-time recovery, and tested restore procedures become more important.

This is where teams often confuse availability with recoverability. Replication helps keep another database copy available, but it can also replicate bad changes. Backups help you go back to a previous state. Snapshots help you roll back infrastructure quickly. Those are different failure categories, as explained in PostgreSQL Replication vs Backups vs Snapshots.

A good backup tool can store database dumps safely. It cannot make an inconsistent dump consistent after the fact.

Security Considerations

Backup security matters because backup repositories often contain the most complete copy of your application data. If an attacker can access your backups, they may not need access to the production server anymore.

Restic and Borg both support encryption, which makes them better suited for repositories stored outside your direct control. With Restic, encryption is central to the tool's design. With Borg, authenticated encryption is available and commonly used. In both cases, your repository password or key material becomes critical infrastructure.

Rsync does not provide backup encryption by itself. It can run over SSH, which protects data in transit, but the destination files are usually readable by anyone with access to the destination. That may be acceptable for a private backup server with strict permissions, but it is not the same as encrypted backup archives.

For cloud servers, the security checklist is straightforward:

• Store backup credentials outside the backup script when possible.
• Restrict repository access to the minimum required permissions.
• Use separate credentials for backups.
• Do not store the only copy of the backup password on the server being backed up.
• Test restore access from a clean machine.
• Monitor backup job failures.
• Rotate credentials if the VM is compromised.

A backup that works technically but exposes all production data to the wrong account is not a safe backup.

Retention and Restore Testing

Retention decides how far back you can recover. Restore testing proves whether recovery actually works.

Restic and Borg both support retention policies that let you keep recent, daily, weekly, monthly, or yearly restore points. That is useful because most teams do not need every historical backup forever. They need enough restore points to recover from recent mistakes, delayed discoveries, and compliance or operational requirements.

Rsync needs retention to be designed manually. A simple mirrored directory only shows the latest state. If the source is corrupted and the mirror updates, the corruption may replace the good copy. To use Rsync safely for backup, you need timestamped directories, archive rotation, hard-link strategies, or another retention mechanism.

Restore testing is the part teams avoid until they are forced to do it. Do not wait. A practical restore test is simple: create a clean VM, restore the backup, start the service, check logs, validate data, and document the steps. The output of a restore test is not just confidence; it is a runbook.

A backup system is only as strong as the last successful restore test.

Common Mistakes

The first mistake is storing backups only on the same VM. A local backup folder may help with accidental file deletion, but it does not protect against disk failure, compromise, or full-server loss.

The second mistake is using Rsync with delete mirroring and calling it backup. Mirroring has a place, but it can faithfully copy mistakes. If the source loses files and the mirror deletes them too, you have synchronization, not recovery.

The third mistake is backing up databases like normal files. Use database-native tools first. Then back up the dump or backup output.

The fourth mistake is protecting files but not credentials. If all restore passwords, repository keys, and object storage credentials live only on the failed server, the recovery plan has a hidden single point of failure.

The fifth mistake is never testing restore. Backup dashboards can be green while recovery is broken. You only find out by restoring.

Practical Recommendation for Small Teams

For most small teams running cloud servers, the best starting design is layered rather than tool-specific.

Use VM snapshots before risky changes. Use automated backups for broad server protection. Use Restic for encrypted off-server backups to object storage or remote repositories. Use Borg if your team controls a dedicated backup server and wants efficient archives. Use Rsync for migration, file mirrors, and simple readable copies.

A simple backup architecture for a Raff VM might look like this:

This design avoids the biggest trap: relying on one tool to solve every failure. Restic, Borg, and Rsync are all useful. They are strongest when used for the jobs they were built to do.

Conclusion

Restic, Borg, and Rsync are not interchangeable backup tools. Restic is usually the strongest fit for encrypted, deduplicated cloud backups to object storage or remote repositories. Borg is excellent for controlled Linux backup servers with efficient archives, compression, encryption, and mountable backups. Rsync remains the simplest and most practical tool for file synchronization, migration, and readable backup folders.

On Raff, the safest design combines tool-level backups with platform-level protection. Use snapshots and automated backups for server-state rollback, use Restic or Borg for historical recovery, use Rsync where file transfer is the actual job, and store important backup data away from the original VM.

The next step is to connect this guide back to your recovery requirements. Start with Cloud Server Backup Strategies: Snapshots, RPO, and Recovery Planning, review Cloud Snapshots vs Backups: What’s the Difference?, and then implement a file-level workflow using Automate Server Backups with Cron and Rsync on Ubuntu 24.04 or a Restic/Borg workflow.

This guide reflects the way we prefer to design recovery at Raff: no single magic tool, no vague backup promises, and no backup strategy that has not been restored on a clean machine.