Homelab Backup Strategy: 3-2-1 with Restic, Borg, Kopia and Proxmox

A homelab can contain years of accumulated work: virtual machines, Docker volumes, configuration files, monitoring history, home automation data, source code, credentials and documents. Reinstalling an operating system may be easy. Reconstructing all the data and every configuration decision is not.

This guide builds a practical backup strategy for self-hosted infrastructure using free and open-source tools such as Restic, BorgBackup, Kopia and Proxmox Backup Server, with concrete examples and a strong focus on restore testing.

Backups are a recovery system, not a copy command

A backup process is complete only when it answers what is protected, how often copies are created, how many versions are retained, where those copies live, what credentials recovery requires and how long a restore will take.

The 3-2-1 rule

3 copies of important data
2 different storage types
1 copy off-site

A practical homelab implementation can look like this:

Production data
   |
   +-- Local backup NAS/server
   |
   +-- Encrypted off-site repository

3-2-1-1-0

A more defensive variation adds one offline or immutable copy and zero unverified backup errors. The final zero matters because successful job logs do not prove that the data can actually be restored.

Create a data inventory first

• virtual machines and LXC containers;
• Docker Compose files and environment files;
• Docker volumes and bind mounts;
• database dumps;
• application configuration;
• SSH and TLS keys;
• password-manager data;
• home automation databases;
• photos and documents;
• infrastructure-as-code repositories.

Prioritize by recovery value

Class	Example	Priority
Irreplaceable	Personal files, secrets	Highest
Application data	Databases, volumes	High
Configuration	Compose, Ansible, service config	High
Rebuildable	OS packages, ISO images	Lower

Restic

Restic is a lightweight encrypted backup tool with deduplication and support for local repositories, SFTP and several object-storage backends.

apt update
apt install restic

Initialize a repository

export RESTIC_REPOSITORY=/mnt/backup/restic
export RESTIC_PASSWORD_FILE=/root/.restic-password

chmod 600 /root/.restic-password
restic init

Create a backup

restic backup \
  /etc \
  /srv \
  /home

List and restore

restic snapshots

mkdir -p /restore-test
restic restore latest \
  --target /restore-test

Restic retention

restic forget \
  --keep-daily 7 \
  --keep-weekly 5 \
  --keep-monthly 12 \
  --prune

Retention should follow the workload. A frequently changing database may need many short-term restore points while a configuration repository changes less often.

Verify Restic repositories

restic check

Repository checks are useful but do not replace actual restores. Integrity checks and restore tests answer different questions.

BorgBackup

BorgBackup is a mature deduplicating backup tool that is particularly useful for Linux-to-Linux repositories over SSH.

apt install borgbackup

Initialize

borg init \
  --encryption=repokey-blake2 \
  /mnt/backup/borg

Create an archive

borg create \
  --stats \
  /mnt/backup/borg::'{hostname}-{now}' \
  /etc \
  /srv \
  /home

Retention

borg prune \
  --keep-daily=7 \
  --keep-weekly=5 \
  --keep-monthly=12 \
  /mnt/backup/borg

Kopia

Kopia is another strong option for encrypted snapshot-based backups. It supports local, network and object-storage repositories and offers both CLI and graphical workflows.

kopia repository create filesystem \
  --path /mnt/backup/kopia

kopia snapshot create /srv
kopia snapshot list

Which tool fits which job?

Tool	Strong fit
Restic	Simple encrypted backups, object storage
BorgBackup	Linux repositories, SSH, mature deduplication
Kopia	Policy-driven snapshots, CLI and GUI
Proxmox Backup Server	Proxmox VM and LXC environments

Proxmox Backup Server

If the homelab runs Proxmox VE, Proxmox Backup Server is usually the natural solution for VM and LXC protection.

• incremental backups;
• deduplication;
• compression;
• verification jobs;
• retention and pruning;
• client-side encryption options;
• file-level restore;
• tight Proxmox VE integration.

Keep the backup datastore on storage independent from the production host whenever possible. A backup VM stored on the same physical disks as the workloads does not protect against host storage failure.

Docker backup strategy

For Docker, protect more than the Compose file. A useful inventory includes:

compose.yaml / docker-compose.yml
.env
bind-mounted application data
named-volume data
database dumps
reverse-proxy configuration
TLS-related configuration

Do not assume that copying a live database directory creates a consistent backup.

Database-consistent backups

MariaDB / MySQL

mysqldump \
  --single-transaction \
  --routines \
  --triggers \
  DATABASE \
  > database.sql

PostgreSQL

pg_dump DATABASE > database.sql

Store the dump together with the application configuration needed to rebuild the service.

Application-native backups

When a self-hosted application provides its own export or backup feature, include it in the wider strategy. Native backups may preserve metadata that is difficult to recover from raw files alone.

Off-site storage

The off-site copy can live at another physical location, on a trusted remote server or in object storage. The important property is failure independence from the primary site.

Encrypt backups before they leave the site

Restic, Borg and Kopia support encrypted repositories. Encryption is especially important when backups contain passwords, SSH keys, application tokens, personal files or database contents.

Protect recovery credentials

A backup password stored only on the failed server can turn a healthy encrypted repository into unusable data. Store recovery credentials independently, for example in a password manager with its own recovery plan.

Immutable or offline copies

If an attacker with administrative privileges can delete production data and every mounted backup, the backups are not sufficiently isolated. Consider at least one offline, append-only or immutable copy where practical.

Automate and monitor

Backups should run unattended, but failures must be visible. Monitor at least:

• time of the last successful backup;
• repository free space;
• backup job exit status;
• verification-job status;
• retention and prune failures;
• off-site replication failures.

Restore testing

A meaningful test restores data into an independent temporary location and verifies that the file, database or application can actually be used.

1. provision or reinstall the base system;
2. restore configuration;
3. restore application data;
4. restore databases;
5. restore secrets;
6. start services in the correct order;
7. verify functionality and dependencies.

RPO and RTO

• RPO: how much recent data can you afford to lose?
• RTO: how long can the service remain unavailable?

A service with a one-hour RPO cannot be protected by a weekly backup. A service with a short RTO may need a fast local restore path in addition to its off-site archive.

A practical homelab architecture

Proxmox / Docker / Linux hosts
          |
          | nightly backups
          v
Local backup server or NAS
          |
          | encrypted replication
          v
Off-site repository
          |
          +-- periodic restore test

What not to do

• do not keep the only backup on the production disk;
• do not rely only on RAID;
• do not treat hypervisor snapshots as a complete long-term backup system;
• do not copy live database files without understanding consistency;
• do not expose backup storage with unnecessary credentials;
• do not skip restore tests.

RAID is not backup

RAID improves availability against some disk failures. It does not protect against deletion, ransomware, filesystem corruption, administrator error, theft or loss of the entire storage system.

Snapshots are not automatically backups

Snapshots are excellent for short-term rollback, but a snapshot on the same system shares many of the same failure modes as production. Use snapshots as one layer, not the whole strategy.

Checklist

1. Inventory irreplaceable and application data.
2. Define RPO and RTO.
3. Create an independent local backup.
4. Create an encrypted off-site copy.
5. Keep multiple historical versions.
6. Use application-consistent database backups.
7. Protect backup credentials independently.
8. Monitor every scheduled job.
9. Run repository integrity checks.
10. Perform real restore tests.
11. Document recovery procedures.
12. Review the strategy whenever the homelab changes.

Final thoughts

The best homelab backup system is not necessarily the most complicated one. A small environment using Restic or Borg, an independent local destination and an encrypted off-site copy can be safer than an elaborate design that nobody monitors or tests.

The purpose of a backup is not to create files. The purpose is to make recovery predictable.