restic vs Kopia for Linux server backups

Choose restic if you want a focused backup command-line tool and can provide scheduling, monitoring, and restore procedures around it. Choose Kopia if its built-in policies, KopiaUI, and Repository Server fit how your team will operate. For either choice, the fastest safe path is to inventory what must be recovered, create a disposable repository, and restore representative data into an isolated target before migrating production backups.

Both create encrypted, deduplicated snapshots of selected files and directories. Neither discovers every recovery dependency or makes a live database directory consistent simply by reading it. Set a recovery point objective (RPO)—the most data you can afford to lose—and a recovery time objective (RTO)—the time allowed to restore service. A schedule can support an RPO, but missed runs and untested restores can defeat it. If scope is uncertain, start with a [Linux server recovery inventory](/blog/what-to-back-up-linux-server).

Restic exposes explicit commands for backup, snapshot listing, restore, repository checks, retention, and pruning. It does not include an official graphical control plane or scheduler. On Linux, plan for a system timer or other scheduler, protected credentials, stale-run detection, failure alerts, and a documented restore procedure. The [restic backup guide](/blog/restic-backup-guide) covers the surrounding workflow.

That separation suits teams with established automation and operators comfortable restoring directly from a repository. Its failure mode is scattered ownership: one host gets a different wrapper, another stops running jobs, and nobody notices until recovery. If managing that layer is the problem, [Rested Backups](https://restedbackups.com) runs encrypted restic workflows on a connected Linux server and keeps schedules, run outcomes, snapshots, and restore work visible in one workspace. You still own backup scope, configured storage access, the recovery key, and restore testing.

Kopia policies cover settings including snapshot frequency, retention, exclusions, and compression, with inheritance across sources. KopiaUI provides a graphical way to work with repositories, policies, snapshots, maintenance, and restores. This can reduce external scheduling work, provided the machine responsible for snapshots is running and configured correctly.

Check the effective policy for each source, not just a global setting. An inherited exclusion can omit a newly moved application path; an unexpected retention setting can remove the recovery point you expected to keep. Document who owns repository maintenance and how another operator connects and restores without the original workstation or UI.

A restic restore needs the repository location, storage access, and its repository password. The password unlocks encrypted data; backend permissions determine what a client can do to stored objects. Separate repositories or scoped storage credentials can limit operational blast radius, but neither supplies central scheduling or an application-level authorization model by itself. Keep recovery information outside the host being protected and test it from a clean environment. See the [backup key ownership plan](/blog/backup-encryption-key-loss-recovery-ownership-plan).

Kopia Repository Server can proxy backend access and authenticate clients without giving each client the underlying storage credentials. Its documented manifest isolation and access rules are useful, but its shared deduplicated content is not a conventional per-file, multi-tenant confidentiality boundary. Read the [Repository Server documentation](https://kopia.io/docs/repository-server/) before using one shared repository for parties that require strict separation.

Both projects document local and remote storage options, including object-storage routes; exact backend behavior and setup differ. Verify the destination you will actually use, access from a clean rescue host, and whether credentials can be recovered independently of the failed server. For an S3-backed restic repository, test the permissions needed for reads, writes, locks, and eventual pruning—not merely a successful initial upload. The [restic S3 permissions guide](/blog/restic-s3-permissions) is a useful companion.

Neither tool choice establishes a universal cheaper option. Compare software or control-plane charges, storage and infrastructure, API requests and egress during a full restore, and operator time for setup, alerts, maintenance, and drills. Retention, compression, change rate, and any storage-side immutability controls can change that total. If you require deletion resistance, check how the chosen controls interact with maintenance and pruning rather than treating encrypted snapshots as immutable; see the [restic immutability trade-offs](/blog/immutable-restic-backups-object-lock-versioning-prune).

Neither engine can infer that a readable live PostgreSQL, MySQL, MongoDB, or Redis data directory needs application-aware handling. Use a database-native logical export, a properly coordinated physical backup, or a supported consistent snapshot procedure before backing up the resulting artifact. These approaches have different restore paths and point-in-time recovery capabilities; file snapshots alone do not provide database point-in-time recovery.

For PostgreSQL, decide whether one database, cluster-wide objects, or point-in-time recovery is required before choosing an export. A pg_dump artifact for one database does not include every cluster role or other database. Validate that the export command exited successfully, the artifact is present, and it restores into a disposable PostgreSQL instance. The [PostgreSQL documentation](https://www.postgresql.org/docs/current/backup.html) and [single-database versus all-databases guide](/blog/pg-dump-vs-pg-dumpall) explain the scope distinction.