Skip to content

How I Back Up My Homelab

Backups are one of the most important parts of running a homelab.

Containers are easy to recreate. Data is not.

Over time I moved toward a backup strategy that is:

  • Simple
  • Automated
  • Easy to restore
  • Lightweight
  • Easy to understand months later

This page explains the general approach I currently use for backing up my Docker-based homelab environment.

My General Backup Philosophy

I prefer:

  • Simple tools over complex backup systems
  • File-based backups where possible
  • Nightly automated backups
  • Backup storage on separate hardware
  • Easy manual restores without proprietary software

The goal is reliability and recoverability rather than enterprise-level complexity.

For a homelab, simple and dependable is usually better than complicated and fragile.

What I Back Up

My backups primarily focus on Docker-related data.

That includes:

  • Docker Compose files
  • Container configuration folders
  • Application data
  • Environment files
  • Persistent volumes
  • Scripts and automation files

Most services are stored under a central Docker folder structure similar to:

/docker/
├── jellyfin
├── vaultwarden
├── homeassistant
├── immich
├── paperless
└── backups

This makes backups much easier because almost everything important lives in one location.

Why I Prefer Docker Compose

One major advantage of Docker Compose is portability.

A complete application stack is often just:

  • A docker-compose.yml
  • A data folder
  • A few environment variables

That means restoring services is usually straightforward.

In many cases:

docker compose up -d

is enough to rebuild the application after restoring the data.

This simplicity is one reason I strongly prefer Docker Compose for homelab services.

My Backup Method

My current approach uses:

  • A lightweight Alpine Linux container
  • rsync
  • A nightly cron job
  • A dedicated backup destination

The backup container:

  • Runs automatically every night
  • Copies Docker data into dated folders
  • Removes old backups automatically
  • Requires very little maintenance

This has proven reliable and easy to troubleshoot.

Why I Use rsync

I like rsync because it is:

  • Fast
  • Reliable
  • Widely supported
  • Efficient with changed files
  • Easy to restore manually

It also works extremely well over:

  • Local disks
  • NAS shares
  • External drives
  • Remote Linux systems

Unlike some backup systems, rsync backups remain directly readable without special software.

Backup Storage Matters

One important lesson:

Backups stored on the same physical disk are not real backups.

I try to keep backups on separate storage whenever possible.

Good options include:

  • A second SSD
  • A Synology NAS
  • External USB storage
  • Another server
  • Remote storage

Even simple separation significantly improves recovery options.

Automation Is Essential

Manual backups sound good until life becomes busy.

Eventually they stop happening.

Automated nightly backups solve this problem completely.

Once configured properly, backups become part of the infrastructure rather than a task to remember.

Restore Testing Is Important

A backup is only useful if it can actually be restored.

I occasionally test restores by:

  • Recovering a container folder
  • Rebuilding a test container
  • Verifying application data
  • Confirming permissions still work correctly

Even a small restore test provides confidence that the backup strategy is functioning properly.

Databases Require Extra Thought

File-level backups work well for many applications, but databases sometimes need additional consideration.

Applications using:

  • PostgreSQL
  • MariaDB
  • MySQL

may benefit from:

  • Database dumps
  • Application-aware backup methods
  • Snapshot-based backups

For many homelab environments, filesystem backups are still sufficient, but it is worth understanding the difference.

What I Avoid

Over time I learned I prefer to avoid backup systems that are:

  • Extremely complex
  • Difficult to restore manually
  • Dependent on proprietary software
  • Hard to troubleshoot
  • Too resource-intensive

Homelabs should remain maintainable.

A backup system that becomes stressful to manage defeats its own purpose.

Current Status

My current setup performs:

  • Nightly automated backups
  • Retention cleanup
  • Incremental-style rsync backups
  • Backup storage on separate systems

It has worked reliably for my Docker-based homelab environment and remains simple enough to understand and maintain without constant attention.

For the actual Docker container setup I currently use, see: