A cloud-server backup tool is software that preserves recoverable copies of files or system state outside the live workload so data can be restored after deletion, corruption, compromise, or infrastructure failure.
For Restic vs Borg, the main difference is usually the repository model. Restic is a strong default when you want encrypted, deduplicated backups to S3-compatible object storage, SFTP, or another remote backend. Borg is strongest when you control a Linux backup host and want efficient deduplication, compression, authenticated encryption, and mountable archives over an SSH-based workflow. Rsync solves a different problem: it is excellent for fast file transfer, migration, mirrors, and readable destination copies, but it does not create a versioned backup repository by default.
On Raff Technologies, these tools fit alongside platform-level recovery rather than replacing it. Start with Cloud Server Backup Strategies: RPO, RTO, and Recovery Planning to define what must be recoverable, then use this guide to choose the file-level tool that matches the failure you are designing for.
Restic vs Borg is mainly a repository decision
Restic and Borg overlap in important ways. Both are real backup programs built around deduplicated repositories, encryption, multiple restore points, pruning, and recovery from historical archives. The practical difference is where you want the repository to live and how much backup infrastructure you want to operate.
Restic has a broad backend model. Its official documentation supports local storage, SFTP, REST servers, Amazon S3, S3-compatible object storage, Azure, Google Cloud Storage, Backblaze B2, Swift, and additional services through rclone. That makes Restic attractive when the backup should live outside the VM without requiring a second Linux server dedicated to receiving backups.
Borg's mature stable workflow is more server-centric. A common design is a production Linux server writing deduplicated archives to a separate Linux repository host over SSH. Borg is especially appealing when the team controls both ends of that connection and values compression, mountable archives, and direct repository administration.
Rsync sits beside these two rather than directly replacing them. It copies files efficiently between local or remote paths and can preserve permissions and other file metadata in archive mode. It can be part of a backup design, but history, retention, and protection from mirrored deletions must be designed separately.
A file copy is not a recovery policy; history, off-server separation, and restore testing determine whether it behaves like a backup.
The decision framework separates recovery history from file transfer
Use the recovery requirement first, then choose the tool.
| Decision factor | Restic | Borg | Rsync |
|---|---|---|---|
| Primary job | Versioned backup repository | Versioned backup repository | File copy and synchronization |
| Deduplication | Yes | Yes | No repository-level deduplication by default |
| Encryption in the backup tool | Yes | Yes, when configured | No backup-repository encryption |
| Compression | Supported | Strong built-in options | Not a backup compression model |
| S3-compatible storage | Native fit | Not the primary stable workflow | Requires another storage layer/tool |
| Remote Linux backup host | Good | Excellent | Excellent for copies/mirrors |
| Historical restore points | Built in through snapshots | Built in through archives | Must be designed separately |
| Browse/mount historical backup | Repository restore/mount workflow | Strong mountable archive workflow | Destination is directly readable |
| Best operational fit | Object storage or mixed backends | Controlled Linux repository server | Migration, mirror, readable copy |
| Main operational risk | Repository credentials/password loss | Repository host/key management | Mirroring deletion or corruption |
Choose Restic if:
- the repository should live in S3-compatible object storage;
- you want one backup model across several remote backend types;
- encrypted off-server history matters more than directly readable destination files;
- the team does not want to operate a dedicated Borg repository server.
Choose Borg if:
- you control a Linux backup host or storage server;
- SSH is the natural transport between production and backup infrastructure;
- compression and mountable archives matter;
- the team is comfortable administering repository storage directly.
Choose Rsync if:
- the real job is migration or synchronization;
- operators need files to remain directly readable at the destination;
- a server-to-server copy is more useful than a repository format;
- retention and historical recovery are handled by another layer.
There is no useful universal winner. The correct choice depends on whether you need a backup repository, a controlled backup server, or simply a reliable file transfer.
Restic fits object-storage and mixed-backend recovery
Restic is a strong fit for cloud servers because the repository can be separated cleanly from the source VM.
A practical architecture is:
Application VM ↓ Restic ↓ Encrypted repository ↓ S3-compatible object storage or remote backend
Each Restic backup creates a repository snapshot. Retention policies can preserve daily, weekly, monthly, or time-window-based history while pruning older data according to policy. Deduplication prevents unchanged data from being stored repeatedly as complete copies.
Restic also encrypts repository data before it is stored. That makes the repository password part of the recovery architecture. If the only copy of the repository password is kept on the VM that is lost or compromised, the backup design still has a single point of failure.
For Raff users, Restic can target Raff Object Storage through its S3-compatible interface. This is a useful off-server pattern because the repository is independent from the VM being protected.
One limitation matters when designing retention: Raff Object Storage's current public feature set does not provide bucket versioning or Object Lock. Restic's own repository snapshots and retention policy therefore provide the backup history; do not assume the bucket itself gives you an additional historical or WORM layer.
Restic is usually the better choice than Borg when object storage is the destination. It is also a cleaner choice than Rsync when you need encrypted historical restore points rather than a readable mirror.
Borg fits controlled Linux backup repositories
Borg is strongest when the team controls the repository host.
A typical pattern is:
Production Linux VM ↓ SSH Dedicated backup host ↓ Borg repository
Borg deduplicates content, supports compression, offers authenticated encryption, and lets operators mount archives for inspection or selective restores. Those characteristics make it well suited to Linux administrators who want a backup system that behaves like infrastructure they fully control.
This model has an operational advantage: the backup target can be isolated as its own server role. Access can be restricted, storage capacity can be monitored independently, and the team can decide exactly how repository retention and maintenance are handled.
The trade-off is ownership. Someone must operate the backup host, secure SSH access, monitor capacity, update Borg, protect the repository keys, and verify recovery.
Borg is a strong choice when:
- the organization already has a backup server;
- private Linux-to-Linux connectivity is available;
- the repository should remain under direct administrative control;
- mountable archives simplify file recovery;
- object storage is not the primary target.
For S3-compatible object storage, Restic has the simpler native model. Adding gateways or compatibility layers to make Borg behave like an object-storage client usually increases complexity without improving recovery for a small team.
Rsync fits synchronization, migration, and readable copies
Rsync remains one of the most useful Linux operations tools because it solves file movement directly.
It can copy data locally or to a remote host, usually over SSH, and archive mode can preserve important filesystem metadata. That makes it valuable for:
- server migrations;
- copying upload directories;
- maintaining a readable secondary copy;
- seeding a new server;
- synchronizing application files;
- moving data before a cutover.
The key limitation is historical recovery. A normal Rsync mirror represents the current copied state. If the source loses a file and the synchronization is configured to delete files that no longer exist at the source, the destination can faithfully reproduce the deletion.
The official Rsync documentation explicitly treats --delete as an option that needs care. A dry run is a sensible control before destructive synchronization because synchronization correctness and backup recoverability are not the same thing.
Rsync can be extended into a backup workflow with timestamped directories, --backup-dir, hard-link strategies, external snapshots, or retention scripts. That can work well, but operational complexity rises quickly. If the requirement is already “encrypted deduplicated history with pruning,” Restic or Borg usually expresses that requirement more directly.
Use Automate Server Backups with Cron and Rsync on Ubuntu 24.04 when Rsync really is the right operational building block.
Platform backups, file backups, and database backups solve different failures
One backup mechanism should not be expected to cover every failure mode.
On Raff, platform-level Data Protection protects the VM at the infrastructure layer. Restic or Borg protects selected files through an independent repository model. Rsync transfers files between systems. Databases need their own consistency-aware recovery design.
| Failure or task | Better recovery layer | Why |
|---|---|---|
| Whole VM must be restored | Raff scheduled VM backup | Infrastructure-level VM recovery |
| Risky change needs a short-lived checkpoint | Raff snapshot, when backups are not enabled on that VM | Fast point-in-time VM rollback |
| User deletes a file days ago | Restic or Borg | Historical file-level restore |
| VM is compromised | Restic or Borg restored to a clean VM | Avoid trusting the compromised source |
| Server migration | Rsync | Efficient readable server-to-server transfer |
| Database logical corruption | Database-native backup/PITR | Transaction consistency matters |
| Database dump needs off-server retention | Native dump + Restic/Borg/object storage | Separates database consistency from repository storage |
Raff's current Data Protection model requires another important distinction: a VM with scheduled backups enabled cannot also use snapshots at the same time. Choose the platform protection mode that fits the workload instead of designing around an assumption that both mechanisms can always be stacked on one VM.
File-level tools remain useful beside platform backups because they solve different restore questions. A VM backup may recover the server; a Restic or Borg repository may recover one file or a historical configuration independently.
Database files need extra care. Copying a live PostgreSQL, MySQL, or MariaDB data directory with a generic file-copy command is not a substitute for a database-aware backup method. Use logical dumps, physical backup tooling, or point-in-time recovery appropriate to the engine, then store the resulting backup artifacts according to the retention design.
For the broader recovery layers, read Cloud Snapshots vs Backups and PostgreSQL Replication vs Backups vs Snapshots.
Backup integrity depends on credentials and restore tests
A backup job that finishes successfully has not yet proven that the workload is recoverable.
The recovery design should protect both the data and the credentials required to restore it.
For Restic or Borg repositories:
- keep repository passwords or keys outside the only VM being protected;
- use separate credentials for backup access;
- restrict repository permissions to the minimum required;
- rotate credentials after a compromise;
- monitor backup failures and repository capacity;
- verify repository integrity on a defined schedule;
- test restores from a clean environment.
For object storage, use scoped credentials rather than broad account access where the product supports it. For a dedicated Borg host, restrict SSH access and treat the repository server as production recovery infrastructure rather than a disposable utility VM.
Restore tests should match business recovery requirements. A file-level test can prove that selected files are readable. A service-level test should restore the application data onto a clean VM, start the service, validate logs and dependencies, and confirm that the restored data is usable.
A backup is not proven by job success; it is proven by restoring the data or service that matters.
For a structured recovery exercise, use the Restore Testing Checklist for Production VMs.
Raff supports layered recovery without forcing one backup tool
Raff's role in this architecture is to provide the infrastructure layers while the team selects the file and application backup methods that match its workload.
A practical small-team design can look like this:
| Layer | Raff or application component | Recommended role |
|---|---|---|
| Compute | Raff VM | Runs the workload |
| VM recovery | Raff Data Protection | Scheduled infrastructure-level recovery |
| Short-lived checkpoint | Raff snapshot, when compatible with the VM's protection mode | Pre-change rollback |
| File-level history | Restic or Borg | Independent historical repository |
| Off-server repository | Raff Object Storage or separate backup host | Keeps recovery data away from source VM |
| Database consistency | Database-native backup method | Produces recoverable database state |
| Migration | Rsync | Moves files between systems |
Raff Object Storage is S3-compatible, which makes it a natural Restic repository target when object storage is the chosen backend. A dedicated Linux backup VM is the more natural Borg pattern. Rsync remains useful when the real requirement is moving data rather than maintaining historical repository snapshots.
This layered model also avoids overpromising. Platform backups do not replace database-native recovery. Restic does not replace VM recovery for every system failure. Borg does not remove the need to secure a backup host. Rsync does not create historical retention unless the team builds that retention explicitly.
The strongest design is the smallest set of recovery layers that covers the failures the business actually needs to survive.
Conclusion
Restic vs Borg is primarily a repository and ownership decision. Choose Restic when encrypted, deduplicated backups need to go to S3-compatible object storage or another remote backend. Choose Borg when you control a Linux backup host and want efficient SSH-based repositories, compression, encryption, and mountable archives. Choose Rsync when synchronization, migration, or a directly readable secondary copy is the actual job.
Do not make the tool carry responsibilities that belong to another recovery layer. Use platform-level VM protection for VM recovery, database-native methods for transaction-consistent database backups, and file-level repositories for historical data recovery.
Start with Cloud Server Backup Strategies: RPO, RTO, and Recovery Planning, then use Restore Testing Checklist for Production VMs to prove that the design works before an incident does it for you.