BorgBackup vs Restic: which one actually protects your VPS data?

The wrong backup tool is the one that crashes your VPS during the weekly prune job. Both BorgBackup and Restic are mature deduplicating backup tools. Both encrypt. Both deduplicate. Both push data over SSH to an off-site repository. The difference is how they behave when your server has 2 GB of RAM and a tight CPU budget. This article compares them on real resource usage, restore workflows, and failure modes. It ends with a decision framework for typical ServerSpan VPS sizes and a commercial handoff if you would rather not manage backup infrastructure yourself.

Memory usage is the first filter

On a 2-vCPU/2-GB KVM VPS, a typical Borg backup consumes 50 to 150 MB of memory. Restic usually takes 100 to 200 MB for the same dataset. The gap widens during repository maintenance. Restic's prune operation is known to balloon past 1 GB on multi-terabyte repositories because it holds chunk hashes in memory. Borg's prune stays leaner. On a small VPS, that difference matters. An out-of-memory kill during a 3 AM cron job leaves you with no backup and a dead process. If your VPS has 1 GB of RAM or less, Borg is the safer default. If you have 4 GB or more, the RAM difference becomes irrelevant and other factors take over.

Throughput favors Borg

Benchmarks on mixed file workloads show Borg pushing 180 to 220 MB/s locally, while Restic manages 120 to 160 MB/s. The gap comes from Borg's tighter C/Cython core versus Restic's Go runtime overhead. Over a network link, both tools are bottlenecked by bandwidth, not CPU. On a LAN or fast datacenter link, Borg finishes its backup window faster. For a 50 GB VPS image, that is the difference between a twenty-minute backup and a forty-minute backup. If your backup window is tight and your target is another server in the same rack, Borg saves time.

Restic wins on backend diversity

Restic speaks native S3, Backblaze B2, Azure Blob, and Google Cloud Storage. Borg handles local storage and SSH/SFTP natively. To reach S3 with Borg, you mount a bucket via rclone and point Borg at the local mount. That works. It is also another moving part that can fail at 2 AM when the mount drops. If your backup target is a cloud object store, Restic is the cleaner choice. If your target is another Linux server or a backup service that exposes Borg over SSH, Borg is native and needs no middleware.

The 2 AM config rescue

Borg lets you mount any backup archive as a filesystem. When a single config file is missing and you do not want to wait for a full restore, this matters. You run the mount command, browse the archive like a normal directory, copy the file, and unmount. Restic also supports mounting, but the typical production restore uses explicit snapshot targeting with flags for the target path and the specific file. In a panic, browsing is faster than reconstructing command-line arguments. The Borg workflow looks like this:

borg mount ssh://user@backup-server/repo /mnt
cp /mnt/backup-2026-05-18/etc/nginx/nginx.conf /etc/nginx/
borg umount /mnt

For a full disaster recovery, both tools require a complete restore to a fresh directory. The FUSE mount is not a substitute for a tested restore procedure. It is a shortcut for the small mistakes that happen more often than total disk failures.

Repository corruption and how each tool reports it

Both repositories can corrupt. Both tools can check. Running borg check verifies the integrity of every archive and reports segment failures. If it returns an integrity error with a specific segment file offset, you have a damaged segment. Borg's check can often repair this with the --repair flag, but you must accept that it may drop damaged chunks to restore consistency. Restic's check --read-data-subset 1% samples a random 1% of your data each run. This is a practical compromise for large repositories. A full restic check --read-data on a terabyte repository takes hours and hammers your backup server. If Restic reports a pack ID mismatch, you have a pack file that was truncated during transfer. The fix is usually a rebuild-index followed by a prune. Neither tool will fix corruption automatically without your explicit command. Both require you to read the output and make a decision.

Append-only mode and the trust boundary

Append-only mode prevents a compromised VPS from deleting its own backups. With Borg, you enforce this at the SSH level. You restrict the backup user to borg serve --append-only in the authorized_keys file. The client can create new archives but cannot prune or delete old ones. A separate, trusted machine must run the actual prune job. With Restic, append-only mode requires running the rest-server backend with --append-only. The Restic client pushing to a plain SFTP target cannot be restricted this way. You must deploy the rest-server binary on your backup host. That is an extra service to maintain. If you are backing up to a generic SFTP account on a shared host, Borg's SSH-level restriction is easier to enforce without installing new software on the target.

Setting up each tool

The initialization commands set the tone for the workflow. Borg requires you to pick an encryption mode up front. Restic requires a repository path and a password. Both need the target directory to exist before you run init.

# BorgBackup
borg init --encryption=repokey-blake2 ssh://user@backup-server/repo

# Restic
restic init -r sftp:user@backup-server:/repo

Borg uses named archives. You create an archive called backup-{now} and Borg stores it in the repository. Restic uses snapshot IDs. You run backup and Restic assigns a hash. Borg's named archives are easier to read in a panic. Restic's hashes are harder to typo but harder to remember. For automation, both tools read environment variables or password files. Neither tool stores your passphrase server-side. Losing it means losing the backup. Store it in a password manager, not in the backup script.

The numbers that decide it

Metric	BorgBackup	Restic
Local backup speed	180-220 MB/s	120-160 MB/s
Memory usage (typical)	50-150 MB	100-200 MB
Prune memory (large repo)	Stays low	Can exceed 1 GB
Native cloud backends	No (via rclone)	Yes (S3, B2, Azure, GCS)
Native SSH/SFTP	Yes	Yes
FUSE mount	Yes	Yes

When to pick which

Pick BorgBackup if your VPS has 2 GB of RAM or less, your backup target is another Linux server over SSH, and you want the fastest restore workflow for single-file rescues. Pick Restic if you need native S3 or B2 support, you are backing up from multiple operating systems, or your VPS has 4 GB of RAM and you prefer a single static binary with no Python dependency. Both tools are overkill for a 500 MB website. Both tools are necessary for a 500 GB database server. Neither tool replaces a disaster recovery plan. For that, you need tested restore procedures and off-site storage that is physically separate from your primary VPS.

If you want to go deeper on building a full disaster recovery strategy beyond just picking a backup tool, see our guide on VPS disaster recovery planning. If you are still comparing backup tools broadly, our earlier article on automated backup strategies for VPS covers rsync and Restic in more detail.

If you would rather not manage this yourself

Backup infrastructure is only useful if the cron jobs run, the repositories stay healthy, and someone tests a restore every quarter. That is ongoing work. If you do not want to manage backup scripts, off-site storage targets, and 2 AM restore testing yourself, ServerSpan Linux administration services include automated BorgBackup or Restic deployment with monitored restore testing. We configure the repository, the append-only restrictions, the cron schedules, and the integrity checks. You get the protection without the pager duty.

Frequently asked questions

Can I migrate from one tool to the other without re-uploading everything?

No. The repository formats are incompatible. A migration means initializing a new repository with the target tool and running a fresh initial backup. Plan for the bandwidth and time.

Will either tool run on a 1 GB RAM VPS?

Borg will. Restic might, depending on dataset size. For a 1 GB VPS, add a swap file and monitor the OOM killer logs. Better yet, use a larger VPS for anything production-critical.

What happens if I lose the repository password?

For both tools, the password is the encryption key. There is no recovery mechanism. The backups are irretrievable. Store the passphrase in a password manager that is not on the server being backed up.

Can I back up to the same VPS?

You can, but you should not. A backup on the same machine protects against accidental deletion, not against hardware failure or ransomware. Get the data off the server.