Kopia alternative,
without running your own server.

What Kopia Repository Server actually is

Kopia has two sides: the backup client (free, open source), and the Kopia Repository Server - a self-hosted component that acts as a gatekeeper between clients and underlying storage. You run the server, maintain it, issue client credentials, handle TLS, back up the server itself, and hope nothing breaks.

For a homelab or developer with three machines, this is a lot of operational overhead. The repository server is a useful component in multi-tenant corporate deployments. For personal or small-team backups, it is often overkill.

The alternative: someone else hosts the storage

A managed encrypted backup target removes the server operation entirely. You run the backup client. The target is a hosted SFTP endpoint, backed by ZFS, with pre-provisioned encryption at the client level. No Kopia Repository Server to run.

ServerCrate is this kind of managed target. It is optimized for Restic, but Kopia speaks SFTP natively, so you can:

kopia repository create sftp \
  --host=vault.servercrate.net \
  --port=22150 \
  --username=vaultuser \
  --path=/data \
  --keyfile=/root/.ssh/id_servercrate

The Kopia repository lives inside your ServerCrate vault. You get the Kopia tooling you like, without the Kopia server overhead.

ServerCrate vs Kopia Repository Server

The honest comparison:

When to stick with Kopia Repository Server

• You need fine-grained per-client permissions enforced at the server layer
• Your organization has a strict "all backup infrastructure must be on-premises" policy
• You already operate Kubernetes or similar and running one more stateful service costs almost nothing
• You need policy inheritance and centralized management across dozens of clients

For those cases, the self-hosted path is correct. For everything else, a managed target is simpler, cheaper, and more reliable.

When ServerCrate is the better choice

• You back up 1-20 machines, not hundreds
• You do not want to operate a backup server on top of operating your actual systems
• You want offsite geographic isolation from your primary infrastructure
• You want predictable flat pricing, not hardware + electricity + time
• You specifically want a Restic-native target

Using Kopia with ServerCrate

Kopia supports SFTP as a first-class storage backend. The configuration is straightforward:

# Create a Kopia repository on your ServerCrate vault
kopia repository create sftp \
  --host=vault.servercrate.net \
  --port=22150 \
  --username=vaultuser \
  --path=/data/kopia \
  --password=your-kopia-password

# Set up policies as normal
kopia policy set --global \
  --keep-latest 10 \
  --keep-hourly 48 \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12

# Back up
kopia snapshot create /home /etc /var/www

Kopia will layout its repository format inside /data/kopia in your vault. Restic can use the rest of the vault for a separate repository if you want to run both for comparison.

What you give up going managed

Honestly, very little for typical use cases. You do not have root on the storage host, so you cannot install arbitrary things there - but a backup target is not somewhere you want to run arbitrary things anyway. The smaller surface area is a feature.

Kopia's server-side access control (ACLs on specific paths within a repository) is a Kopia Repository Server feature. With SFTP, you get file-level access at the vault boundary, not path-level. For single-user or single-team vaults, this is not a limitation.

Migration from Kopia Repository Server

If you are running your own Kopia server and want to move:

1. Create a new Kopia repository on ServerCrate via SFTP
2. Point one client at the new repository and take a full snapshot
3. Verify restore from the new repository works
4. Cut over the remaining clients
5. Keep the old repository around for 30-90 days as insurance, then decommission

Kopia does not have a native repository-to-repository migration tool. The practical approach is fresh snapshots on the new repository and retiring the old one once confidence is built.

If Kopia is not the constraint

Most people evaluating Kopia arrive there because they want encrypted, deduplicated, snapshot-based backup and Kopia is one of the three or four tools that does it well. If you are flexible on the client tool, Restic is slightly simpler operationally, has a larger community, and is what ServerCrate is primarily designed around. See our comparison of Restic alternatives for the full landscape.

Kopia strengths worth keeping in mind

If you decide Kopia is the right tool, here is what you're actually getting that Restic doesn't match:

• Policy-based snapshots. Kopia's snapshot policies are more expressive than Restic's retention flags. You can define per-path rules ("keep 30 snapshots for /var/www but only 7 for /tmp"), control compression per extension, and exclude by pattern more granularly.
• Built-in UI. Kopia ships a web UI for browsing snapshots, running restores, and monitoring repository health without leaving the browser. Restic has third-party UIs (Backrest, Autorestic) but nothing first-party.
• Parallel uploads and smart caching. Kopia generally outperforms Restic on high-bandwidth connections because it uploads more aggressively. On a gigabit link backing up a multi-hundred-gigabyte dataset, the throughput difference is noticeable.
• Multi-tenant repository server. Kopia Repository Server supports multiple users sharing one physical repository with separate credentials and access scopes. Restic assumes one repository equals one set of credentials.

Restic strengths worth keeping in mind

And here is where Restic wins:

• Fewer moving parts. Restic is a single static binary with no daemon, no server component, no UI server to keep updated. restic backup, restic restore, restic forget. That's almost the whole surface area.
• Older codebase, more audits. Restic has been around since 2015 and has seen multiple independent security reviews. Kopia is newer. Both are competent; Restic has more scar tissue.
• Better documentation ecosystem. More tutorials, more third-party integrations (restic-rest-server, autorestic, resticprofile, backrest), more Stack Overflow answers. When something goes wrong at 2am, search results matter.
• Simpler repository format. Restic's on-disk format is well-documented and hasn't changed incompatibly since 2018. You can write a reader in Python in a weekend.

When neither is the right answer

If you're backing up a large PostgreSQL or MySQL database, both Restic and Kopia will back up files correctly but neither handles live database state — you still need to pg_dump or use filesystem snapshots first. For VMware ESXi or Proxmox VMs with live guests, you likely want Proxmox Backup Server or Veeam for the hypervisor layer and Restic/Kopia only for the config and extracted data. Pick the backup tool that matches the data model, not the other way around.