Self-Hosting

Self-hosted backup server: Kopia vs Restic vs Borg (2026)

Self-hosted backup server for a home network in 2026: Kopia vs Restic (with Backrest) vs Borg vs Duplicati, plus when Proxmox Backup Server, UrBackup, or Synology Active Backup fits better.

Problem summary

'Self-hosted backup server' means two different things, and most comparisons blur them. One is the target: the machine or share your computers push backups to (a NAS folder, an SSH host, a restic rest-server, a kopia server, Proxmox Backup Server). The other is the client tool that does the backing up. Settle the target first, because the target decides the one feature that matters most at home: who is allowed to delete history. A client that can prune its own backups can be told to erase them by ransomware that lands on that client; a server that runs append-only refuses. Then pick the tool by how you work. Restic (0.19.x) is the default for most home operators: a single binary, every common backend, and an append-only rest-server; add Backrest if you want a web UI and scheduler on top. Kopia (0.23.x) is the pick if you want a built-in GUI and a repository server with per-user access out of the box. Borg (1.4.x stable; 2.0 still beta) wins when everything is Linux and you want the tightest compression over SSH, with borgmatic for policy. Duplicati (2.4.0) is the point-and-click uploader for a Windows PC to cloud storage, with a local-database design you must understand before you trust it. And if what you actually want is whole-PC image backups or VM backups, none of the four is the right layer: that is UrBackup or Synology Active Backup for Business for PCs, and Proxmox Backup Server if you run Proxmox VE.

Operator snapshotEvidence first

First proof

Write down what must come back after a disaster: folders, whole PCs, or VMs and containers.

Screen to open

restic -r rest:https://backup.lan:8000/laptop snapshots

Expected signal

You can name the recovery unit for each machine in one line.

Stop boundary

Stop before backing up a live database file with a plain copy; it is the most common cause of a backup that will not restore.

Layer path

1'Self-hosted backup server' is two decisions wearing one name. The target is where snapshots land (a NAS share, an SSH host, a restic rest-server or kopia server, Proxmox Backup Server). The client is the tool on each computer that reads files and pushes encrypted, deduplicated snapshots. Comparisons that only rank client tools skip the decision that matters most at home: who is allowed to delete history.

2Target first. A repository the client can prune is a repository ransomware on that client can erase. restic's rest-server has --append-only, Borg has an append-only server mode tied to the SSH key, Kopia's server issues per-user credentials, and Proxmox Backup Server has its own access control and verify jobs. Choose the target for its delete policy, then match a client to how you work.

3Client second, by how you work. restic 0.19.x: single binary, every common backend, CLI-first; Backrest adds a web UI and scheduler. Kopia 0.23.x: CLI plus a desktop GUI and a built-in repository server. Borg 1.4.x: Linux-first over SSH with the strongest compression choices and borgmatic for policy; Borg 2.0 is still beta and not for production. Duplicati 2.4.0: web UI uploader from one PC to consumer cloud storage, with a local-database design to understand before trusting.

4Different layer, different tool. Whole-PC image backups of Windows machines are UrBackup or Synology Active Backup for Business territory; VM and container backups on Proxmox VE belong on Proxmox Backup Server. File-level dedup tools do not give you a bare-metal restore. Safety boundary for every option: a backup you have not restored from is a hope, not a backup. Dump databases before snapshotting, and drill a restore to a scratch location.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Name what you are protecting, machine by machine

Check: For each computer, write folders, whole-PC image, or VM/container. Note the OS.

Expected result: A one-page list that shows whether you need a file tool, an image tool, or both.

If not: If a machine needs an image restore, do not try to make a file tool do it.

Pick the target and its delete policy

Check: Choose a NAS share, SSH host, rest-server, kopia server, or Proxmox Backup Server. Turn on append-only where the tool offers it.

Expected result: Clients can add snapshots; only a trusted server-side job can delete them.

If not: If your target cannot be made append-only, add an offsite copy that is (object storage with versioning or a rotated offline drive).

Pick the client tool by OS mix and how you operate

Check: Mixed OS plus a UI → restic with Backrest or Kopia. Linux-only over SSH → Borg 1.4 with borgmatic. One PC to cloud → Duplicati.

Expected result: A tool every machine can run and that you will still understand in six months.

If not: If you are torn, start with restic behind Backrest; its repository is readable by plain restic if Backrest ever goes away.

Make databases and app data consistent before each snapshot

Check: Add a pre-backup hook that stops the container or runs pg_dump / mysqldump / sqlite3 .backup into the backed-up folder.

Expected result: Every snapshot contains a dump that restores to a working application.

If not: If a hook is impossible, snapshot the filesystem (ZFS/Btrfs) first and back up from the snapshot.

Safe stop: Stop before backing up a live database file with a plain copy; it is the most common cause of a backup that will not restore.

Set retention and a scheduled integrity check

Check: Define keep-daily/weekly/monthly, then schedule restic check --read-data-subset, kopia maintenance and verify, or borg check on the server.

Expected result: Old snapshots age out predictably and corruption is caught within a week, not at restore time.

If not: If checks never run because the server sleeps, fix the schedule before adding more clients.

Prove the append-only policy from a client

Check: From a client, attempt forget/prune against the target and confirm it is refused.

Expected result: The server rejects the delete and the snapshot list is unchanged.

If not: If the delete succeeds, the target is not protecting you; fix it now, not after an incident.

Run a restore drill and add the offsite copy

Check: Restore a folder and one application (with its database dump) to a scratch location and start it. Then add the third copy offsite.

Expected result: The app boots from restored data; you know how long the restore took; a copy exists outside the house.

If not: If the restore fails, the plan is not done, whatever the job logs say. Fix and repeat before trusting it.

Decision tree

If: Mixed Windows/macOS/Linux machines, you want a dashboard, and you want ransomware-resistant history

Then: restic behind Backrest, pushing to a rest-server in append-only mode, is the best fit in this group.

Action: Run rest-server --append-only on the NAS or a small Linux box, install Backrest on each client (or one central Backrest for the server itself), schedule check --read-data-subset weekly.

If: Several people's machines share one server and you want a GUI without assembling parts

Then: Kopia with kopia server gives per-user credentials and a UI out of the box.

Action: Run kopia server in a container on the NAS, create one user per machine, connect KopiaUI clients, set retention policy per source.

If: Everything is Linux, you back up over SSH, and compression ratio matters (media, logs, mail)

Then: Borg 1.4 with borgmatic is the tightest fit.

Action: Restrict each client's SSH key to borg serve --append-only, write retention in borgmatic's YAML, and stay on the 1.4 series until 2.0 leaves beta.

Safe stop: Stop before migrating a working 1.x repository to a Borg 2.0 beta; the formats are not compatible and the project says not to use 2.0 in production.

If: One Windows PC to a consumer cloud (OneDrive, Google Drive, B2), no server at home

Then: Duplicati fits the job and the destinations.

Action: Install Duplicati 2.4, export the job configuration to a safe place, and run a restore of a few files to a scratch folder before relying on it.

If: You need a whole Windows PC back, not folders

Then: This is an image-backup job, which the four file tools do not do.

Action: Use Synology Active Backup for Business if you own a supported Synology, otherwise UrBackup server plus its Windows client; verify a bare-metal restore once on a spare disk.

If: You run Proxmox VE and want VM/container backups deduplicated and verified

Then: Proxmox Backup Server is the purpose-built target.

Action: Install PBS 4.x on separate hardware or a separate disk, add it as storage in Proxmox VE, schedule verify and prune jobs, and consider its S3 backend for the offsite copy.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
A client can run forget/prune and the snapshots disappear from the server	Whether the target was started with --append-only (restic rest-server) or the SSH key uses borg serve --append-only	Target delete policy, not the client tool	Enable append-only on the target and move pruning to a scheduled job on the server
Backups 'succeed' but a restored database refuses to start	Whether the database was dumped or the container stopped before the snapshot, versus a hot file copy	Application consistency, independent of tool choice	Add a pre-backup hook (Backrest/borgmatic/Kopia actions) that dumps the DB, then re-run a restore drill
Duplicati restore is stuck in 'recreating database' for hours	Whether the job's local SQLite database still exists and matches the remote volume list	Duplicati's local-database design	Keep the local DB and exported job config backed up separately; for big sets consider a dedup tool that reads the repository directly
Repository check reports errors or missing packs	Output of restic check --read-data-subset, kopia snapshot verify, or borg check --verify-data	Storage or transport corruption at the target	Stop writing new snapshots to that repository, copy what is intact to fresh storage, then repair per the tool's docs
A Windows laptop is not in the backup at all	Client OS list versus the tool's supported clients	Tool/platform mismatch (Borg has no Windows client)	Add restic/Backrest, Kopia, Duplicati, or an image tool for that machine

Reference

Commands and settings paths

Confirm snapshots exist on the target for this client

restic -r rest:https://backup.lan:8000/laptop snapshots

Where: The client machine, with RESTIC_PASSWORD set

Expected: A list of dated snapshots for this host and path set.

Failure means: An empty list or an auth error means the job is not landing where you think.

Safe next step: Fix credentials and repository URL before touching retention or scheduling.

Prove the target refuses deletes from a client

restic -r rest:https://backup.lan:8000/laptop forget --keep-last 1 --prune

Where: The client machine, against an append-only rest-server

Expected: The command fails with a permission or 403-style error and the snapshots remain.

Failure means: If it succeeds, the server is not append-only and ransomware on this client could erase history.

Safe next step: Restart rest-server with --append-only and run pruning only from the server side.

Verify repository integrity with real data reads

restic -r <repo> check --read-data-subset=5%

Where: The server or any trusted machine with the repository password, on a schedule

Expected: 'no errors were found' after reading a sample of pack data.

Failure means: Errors indicate corrupted or missing packs; the backup may not restore cleanly.

Safe next step: Stop new writes, copy intact data aside, then follow restic's repair guidance.

Check Kopia's view of the repository and its last maintenance

kopia repository status && kopia snapshot list

Where: Any connected Kopia client

Expected: Repository connects, and snapshots are listed with recent timestamps.

Failure means: Connection errors or stale timestamps mean scheduled snapshots are not running.

Safe next step: Check the kopia server container logs and the client's policy schedule.

Verify a Borg repository reads back its data

borg check --verify-data ssh://backup@nas/./repo

Where: A Linux client or the server, with the repository passphrase

Expected: Check completes with no errors reported.

Failure means: Errors mean archive or segment corruption at the target.

Safe next step: Copy the repository aside before any repair, then follow Borg's check/repair docs.

Hardware boundary

Hardware and platform boundary

Change only when

Your current 'backup' is a sync folder or a NAS share the client can delete from; move to a dedup tool with an append-only target.
You are backing up several machines by hand and want one dashboard with alerts; add Backrest, kopia server, or Duplicati's UI.
A Windows PC matters enough that you want it back in one piece; add UrBackup or Synology Active Backup as the image layer.

Evidence that matters

Whether the target can refuse deletes from clients (append-only or per-user credentials).
Client OS support across every machine you own, especially Windows.
A scheduler and notifications you will actually see when a job stops.
Object-storage support for the offsite copy (S3, B2, or rclone remotes).

Evidence that does not matter

Raw backup speed on a home network; all of these saturate a laptop's disk or a 1GbE link long before the tool is the bottleneck.
Compression ratio differences on already-compressed photos and video; dedup matters, compression barely does.

Avoid

Avoid starting a new setup on Borg 2.0 while it is beta; the project says not to use it in production.
Avoid a target where the client holds delete rights and nothing else is immutable or offline.
Avoid trusting Duplicati (or any tool) before a restore to a scratch folder has succeeded.
Avoid treating file-level tools as whole-PC protection; there is no bare-metal restore in them.

Related tool

Use the linked tool to turn this runbook into a guided check for your exact setup.

Backup plan builder

Last reviewed

2026-09-05 · Reviewed by HomeTechOps. Written to answer the 'self-hosted backup server' search as a two-part decision (target, then client) rather than a tool ranking, because the target's delete policy is what protects a home from ransomware and most comparisons skip it. Versions and behaviours were taken from each project's own release and documentation pages on 2026-09-05: restic 0.19.1 and rest-server --append-only, Kopia v0.23.1, Borg 1.4.5 with 2.0 still beta, Duplicati 2.4.0.0, Backrest v1.14.1, Proxmox Backup Server 4.2, UrBackup 2.5.37. Whole-PC image and VM backup are separated as a different layer so readers do not expect a bare-metal restore from a file tool. No winner is declared; the append-only proof and the restore drill apply to every option.

Sources/assumptions

Versions verified 2026-09-05 against each project's own release page: restic 0.19.1 (2026-07-05), Kopia v0.23.1 (2026-06-16), BorgBackup 1.4.5 stable (2026-07-19) with 2.0 still in beta (2.0.0b23, 2026-08-23), Duplicati 2.4.0.0 stable (2026-09-03), Backrest v1.14.1 (2026-07-12, bundles restic 0.19.1), Proxmox Backup Server 4.2 (2026-04-29), UrBackup Server 2.5.37 / Client 2.5.30 (2026-04-23). Re-check before pinning a version.
Append-only behaviour is stated from the restic rest-server README and Borg's documented append-only mode: the client can add data but cannot delete or modify existing backups; pruning becomes a separate trusted operation done with the repository password on the server side.
This is a decision map across target, client tool, and what is being protected (files, whole-PC images, VMs/containers). It is not a benchmark and declares no single winner; the right pick depends on your machines and how you work.
Whole-PC image backup and VM backup are treated as a different layer from file-level dedup tools. UrBackup image backups are a Windows-client feature; Proxmox Backup Server's client for physical hosts is Linux-only; Synology Active Backup for Business needs a supported Synology model.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

restic: Restic 0.19.0 Released (2026-06-09) and 0.19.1 (2026-07-05)Used for the current restic release line (0.19.x), the zstd 'fastest'/'better' compression modes, and restic's single-binary, multi-backend model.restic/rest-server on GitHubPrimary source for rest-server's --append-only mode (clients can add backups but cannot delete or modify existing ones), .htpasswd authentication, TLS, and the Docker image.restic docs: Checking integrity and consistencyUsed for restic check / --read-data / --read-data-subset as the repository-integrity and corruption-detection mechanism.Backrest (garethgeorge/backrest) on GitHubUsed for Backrest as a web UI and orchestrator over restic: cron scheduling, snapshot browsing and restore, hooks, notifications, Docker image, and that it bundles a managed restic binary (v1.14.1 bundles restic 0.19.1).Kopia Docs: FeaturesUsed for Kopia's client-side encryption, deduplication and compression, supported storage backends, the KopiaUI desktop app, and the kopia server repository server with per-user access.Kopia releases on GitHubUsed for the current Kopia release (v0.23.1, 2026-06-16) and the fact that the project still carries 0.x version numbers.BorgBackup: release seriesUsed for Borg 1.4 as the current stable series (1.4.5, 2026-07-19) and the project's statement that Borg 2.0 is in testing, not compatible with 1.x repositories, and not to be used in production.BorgBackup Docs: Append-only mode (forbid compaction)Used for Borg's append-only server mode via borg serve --append-only and SSH key restrictions, so a client cannot delete archives.Duplicati: Download (stable channel)Used for the current Duplicati stable release (2.4.0.0, 2026-09-03), the GUI/CLI/Agent flavours, and platform coverage (Windows, macOS, Linux, Docker).Duplicati Docs: The local databaseUsed for Duplicati's per-job local SQLite database and the repair/recreate step required before a restore when that database is lost or damaged.Proxmox: Proxmox Backup Server 4.2 released (2026-04-29)Used for the current PBS release, its purpose (VMs, containers, physical hosts), S3-backed storage with a local cache, and that it is free/libre software with optional paid support.UrBackup: Server changelog (2.5.x)Used for the current UrBackup server line (2.5.37, with client 2.5.30, April 2026) and its file plus image backup model for Windows clients.Synology: Active Backup for BusinessUsed for Active Backup for Business as a free package on supported Synology models with PC agents (Windows, macOS, Linux) and bare-metal restore for Windows.Veeam: The 3-2-1-1-0 rule in practiceUsed for the 3-2-1-1-0 breakdown — the extra immutable/offline copy and zero errors on a verified recovery test.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Confirm the layer (app, container, network) before deep config.
4. Prove the restore; don't assume it.

FAQ

What is a self-hosted backup server, exactly?

Two things people mix up. The target is where backups land: a share on your NAS, an SSH account on a Linux box, a restic rest-server or kopia server container, or a dedicated appliance like Proxmox Backup Server. The client is the tool on each computer that reads files and pushes encrypted, deduplicated snapshots to that target. You need both, and the target is the more important choice because it decides whether a compromised laptop can delete its own history. Pick the target and its delete policy first, then the client tool. Whatever you pick, the plan only counts once you have restored from it: see a home-server backup you've actually restored.

Kopia vs Restic: which should a home user run?

Restic if you are comfortable with a command line or will run Backrest in front of it; Kopia if you want a GUI and a repository server without adding anything. Restic (0.19.1) is a single binary with local, SFTP, REST, S3, B2, Azure, GCS and rclone backends, zstd compression, and the rest-server's append-only mode, which is the cleanest ransomware defence in this group. Backrest (v1.14.1) wraps it with a web UI, cron scheduling, snapshot browsing, restore, notifications and hooks, and bundles restic itself. Kopia (v0.23.1) ships CLI plus KopiaUI, and its kopia server gives several machines a shared repository with per-user credentials from a web page. Both encrypt client-side and deduplicate. The honest caveat on Kopia is that it still carries 0.x version numbers; the format has been stable for years, but read release notes before upgrading.

Is Borg still worth it, and should I wait for Borg 2?

Borg is worth it when every machine that backs up is Linux (or a Mac you are happy to script) and you want the strongest compression choices over plain SSH. Borg 1.4.5 is the current stable series. Borg 2.0 is still a beta (2.0.0b23 in late August 2026), is not compatible with 1.x repositories, changes the command line, and the project itself says not to use it in production, so do not start a new home setup on it. Use borgmatic for retention policy in a YAML file, and set the server's SSH key to append-only mode so a client cannot delete archives. Windows is not a supported Borg client, which is the usual reason a mixed home picks restic or Kopia instead.

Is Duplicati safe to rely on?

Yes for its intended job, which is pushing encrypted backups from a single Windows, macOS or Linux machine to cloud storage through a web UI, with the widest list of consumer cloud destinations in this group (OneDrive, Google Drive, Dropbox, B2, S3, SFTP, WebDAV and more). Duplicati 2.4.0.0 shipped as stable on 2026-09-03. The design point to understand: each backup job keeps a local SQLite database describing what is on the remote. If that database is lost or corrupted, Duplicati must repair or recreate it from the remote volumes before it can restore, and on a large backup that can take a long time. Test a restore to a scratch folder, and export the job configuration, before you trust it with the only copy of anything.

What stops ransomware from deleting my backups too?

A target that refuses deletes from the client. With restic, run rest-server with --append-only: the client can add snapshots but forget and prune are rejected, so pruning happens as a separate trusted job on the server with the repository password. With Borg, restrict the client's SSH key to borg serve --append-only. Kopia's server can hold per-user credentials so one compromised machine does not hold the keys to another's data, and Proxmox Backup Server has its own verify jobs and access control. Whatever you run, prove it: from a client, try to forget a snapshot and confirm the server refuses. That is the '1' in 3-2-1-1-0 (one immutable or offline copy), and the '0' is a restore with zero errors.

When is Proxmox Backup Server, UrBackup, or Synology Active Backup the better answer?

When the thing you want back is a whole machine, not a folder. Proxmox Backup Server (4.2, April 2026) is the right target if you run Proxmox VE: it deduplicates VM and container backups, verifies them on a schedule, and can now use S3 storage behind a local cache; its physical-host client is Linux-only. UrBackup (Server 2.5.37) does file backups of Windows, Linux and macOS clients and full image backups of Windows PCs to a Linux or Windows server, which is what makes a bare-metal restore of a family PC possible. Synology Active Backup for Business is a free package on supported Synology models with agents for Windows, macOS and Linux PCs and bare-metal restore for Windows. If you already own the NAS, it is often the shortest path to whole-PC protection. None of these replace the file-level tools above for a Linux home server; many homes run both layers.

Planning a purchase?

We keep a source-backed, price-free comparison so you can buy once and right. No star ratings, every spec cited.

Mini PC for a Home Server: N150 vs MS-01 vs Tiny →