Restic vs Borg vs Kopia: Choose Your Server Backup Tool

Choose the destination before the backup tool

For a single VPS running Ubuntu 24.04 LTS, we would start with Restic and an off-server object-storage repository. That keeps the initial design understandable without making you maintain another Linux server. Choose something else when your storage arrangement or recovery workflow gives you a concrete reason.

A repository on the VPS disk can help recover an accidentally changed file, but it disappears with that disk. Put your recovery copy outside the production server's failure boundary. Once you choose the tool, follow the DIY VPS backup procedure to turn that decision into a scheduled, monitored job.

Pick Restic when object storage is the straightforward answer

Restic fits a server you already operate through shell scripts and systemd. It can write directly to S3-compatible object storage or use SFTP, so you can choose a destination without deploying a matching Restic process there. Repository access also requires its encryption password, separate from the storage credentials. The Restic repository documentation explains these backend arrangements.

We prefer this arrangement when the backup configuration should be small enough to review alongside application operations. You can make the source paths explicit and keep the success signal tied to the command's result. The trade-off is that you own the scheduling and failure handling; installing the executable does not create a backup service.

Keep preparation failures visible to that service. If a database export fails, the job must not quietly back up yesterday's export and announce success. Record the freshness of the input as well as the completion of the backup, especially when a separate process produces files for Restic to collect.

Pick Borg when you have a suitable SSH destination

Borg is a good fit when you want a dedicated backup machine or already have storage that supports Borg over SSH. For that remote arrangement, the destination needs to run Borg; a generic SFTP account is not equivalent. You gain a clear place to manage repository access, but someone still owns the destination's disk capacity and availability.

Borg's repository service supports restricting an SSH key to repository operations and enforcing append-only access for that key. This makes it possible to separate the production machine's backup access from privileged maintenance access. Follow the Borg repository hosting documentation rather than giving the backup account an unrestricted shell.

We would choose Borg when that SSH boundary is already part of the operating model. We would choose Restic instead when the requirement is simply to write backups into an object-storage bucket. Introducing a filesystem gateway merely to make Borg fit that destination creates another component you must understand during recovery.

Pick Kopia when policies and visual recovery help your team

Kopia offers a CLI and KopiaUI, with policies that control snapshot behavior and retention. Policies can inherit settings from broader scopes, with more specific settings taking precedence. Its getting-started documentation covers both interfaces and shows how to inspect those policies.

In a Restic vs Kopia decision, both can serve an object-storage backup design. The useful distinction is whether you want explicit shell-driven operations or a tool that carries more of the policy model itself. KopiaUI can also suit the person who will browse and recover files, even if you prefer the CLI for server administration.

That convenience creates configuration you must inspect. Confirm the effective policy for each important source path, especially after changing a global setting. If you use internal scheduling, ensure the scheduling process stays running and starts after a reboot; a saved schedule cannot execute itself.

Kopia assigns repository maintenance to a designated owner, and reclaiming unused storage can take multiple maintenance cycles. When replacing a server, check that ownership instead of assuming another client will take over. The Kopia maintenance documentation explains this coordination and its safety delays.

Separate encryption from protection against deletion

Encryption protects backup contents from someone who lacks the required decryption material. It does not stop a compromised server from deleting repository objects when its storage credentials permit deletion. Assess the backup identity's permissions separately from the repository's encryption settings.

Keep recovery credentials outside the VPS, in a location you can access when the server and its local files are gone. Preserve any required key material as well as the passphrase. A password stored only inside the repository it unlocks creates an unrecoverable dependency.

• Scope the routine backup identity to the intended repository or storage location.
• Keep storage administration credentials away from the production server where practical.
• Use a supported append-only or immutable design when protection against client-side deletion is required.
• Verify that retention and maintenance still function under the chosen storage permissions.

Do not assume denying every delete operation produces a working immutable repository. Normal operations may need to remove temporary coordination files, while maintenance needs different permissions again. Validate the tool and backend combination before relying on that boundary.

We recommend Claude Code for reviewing backup scripts and diagnosing redacted failure logs, with execution limited to approved operations. Keep destructive maintenance and credential changes behind explicit human approval. Apply the same production agent guardrails to backups that you apply to the application server.

Back up recoverable application state

None of these tools makes a running database consistent merely by reading its files. A filesystem backup can capture different files at different moments while the database continues writing. Use a database-supported backup method, then let your chosen tool transport and retain the resulting artifacts.

For Postgres, choose a logical export or a coordinated physical-backup approach according to your recovery requirements. Include the supporting database configuration and roles needed to make the restored application work. The Postgres backup and restore-drill guide covers that separate responsibility.

Treat application uploads as persistent state too, and consider their relationship to database records. Restoring a database from one moment and uploaded files from another can leave missing attachments. Where that matters, coordinate writes during capture or use an application-supported consistency method.

Write the inclusion list before adding exclusions. You should be able to identify where every irreplaceable path is recovered from, including configuration needed to rebuild the service. Exclude disposable caches deliberately, and keep the backup repository itself outside the source tree.

Budget for maintenance and verify your own workload

Do not choose from an unsupported claim that one tool is universally faster or lighter. A directory containing many small files behaves differently from a few large database exports. Compression can add CPU work, and repository checks can compete with the application for disk access.

On your own VPS, observe an initial backup and a later backup after representative changes. Watch application responsiveness while the backup runs, then repeat the exercise for repository maintenance. If memory or disk pressure affects requests, adjust the schedule before reaching for more aggressive settings.

Set retention from the mistakes you need to recover from. Accidental deletion noticed immediately needs a different history from damaged records discovered much later. Retention removes recovery choices, so review the proposed selection before enabling automatic removal.

Removing old recovery points and reclaiming their unused storage are separate concerns. Give repository maintenance an owner and leave enough free capacity for it to operate. Keep arbitrary storage lifecycle rules from deleting live repository data underneath the backup tool.

Monitor the age of the latest successful backup and alert when scheduled work stops appearing. An error alert cannot help when the job never starts. Connect this to your minimum server monitoring setup, and treat warnings about unreadable source files as incomplete coverage until resolved.

Recover one application before enabling unattended retention

Choose the candidate that fits your destination, then complete a recovery exercise before automating deletion of old backups. Write down the maximum acceptable data loss and the time you can tolerate without the service. Those requirements determine whether the resulting procedure is useful.

Create an off-server backup of a representative application. Include a database backup produced through its supported method and a known uploaded file. Record the recovery point identifier and the capture time somewhere outside the source VPS.

Connect from a clean recovery environment using your saved recovery instructions. Obtain credentials from their independent storage location rather than copying configuration from the production server. List the repository's recovery points and select the recorded identifier.

Restore into an empty location and start an isolated application instance. Import the database using its own restore tooling and check file ownership before starting the service. Disable outbound notifications and scheduled jobs so the exercise cannot affect real users.

Record the recovery duration and fix every undocumented dependency. Schedule the next drill, then enable retention only after reviewing which recovery points it will preserve. If you are replacing an existing tool, retain access to its repository until the new setup has both sufficient history and a working recovery procedure.