Linux-Backup-Strategien: rsync, tar und Snapshot-Tools

1. Warum ein Backup-Konzept mehr ist als ein Cron-Job

Ein einzelner rsync-Aufruf in der Crontab fuehlt sich wie ein Backup an, ist aber nur ein Baustein davon. Ein tragfaehiges Backup-Konzept beantwortet vier Fragen gleichzeitig: Wie werden Daten effizient uebertragen, wie werden sie konsistent zu einem festen Zeitpunkt eingefroren, wo liegen die Kopien physisch, und wie wird regelmaessig geprueft, dass eine Wiederherstellung tatsaechlich funktioniert. Wer nur die erste Frage beantwortet, hat eine Kopie, aber keine Strategie.

Auf einer kleinen Serverflotte mit mehreren Anwendungsservern, einer Datenbank und wechselnden Storage-Backends kommen typischerweise drei Werkzeugklassen zum Einsatz: rsync für die effiziente Uebertragung von Dateibaeumen, tar für portable, versionierbare Archive und Snapshot-Mechanismen wie LVM oder Btrfs für konsistente Zustaende während laufender Schreibzugriffe. Keines dieser Werkzeuge ersetzt die anderen vollstaendig, sie lösen unterschiedliche Teilprobleme und werden in der Praxis kombiniert eingesetzt.

Die folgenden Abschnitte behandeln jedes Werkzeug im Detail, zeigen die 3-2-1-Regel als organisatorischen Rahmen und schliessen mit dem wichtigsten, oft vernachlaessigten Schritt: dem regelmaessigen Restore-Test, ohne den jede Backup-Strategie nur eine unbewiesene Annahme bleibt.

2. rsync: effiziente inkrementelle Synchronisation

rsync ueberträgt bei jedem Lauf nur die tatsaechlich geaenderten Bloecke einer Datei, nicht die gesamte Datei erneut. Der Delta-Transfer-Algorithmus vergleicht Pruefsummen zwischen Quelle und Ziel und identifiziert exakt die Byte-Bereiche, die sich seit dem letzten Lauf veraendert haben. Bei grossen, sich langsam aendernden Datenbestaenden wie Uploads-Verzeichnissen oder Log-Archiven reduziert das die uebertragene Datenmenge oft um mehr als neunzig Prozent gegenueber einer vollstaendigen Kopie.

Die Flags -a (Archiv-Modus, erhaelt Berechtigungen, Zeitstempel und Symlinks), -v (verbose) und --delete (entfernt im Ziel Dateien, die in der Quelle geloescht wurden) bilden die Basis fast jedes produktiven Aufrufs. Ueber SSH transportiert rsync die Daten zusaetzlich verschluesselt und authentifiziert, ohne dass ein separater VPN-Tunnel noetig ist. Wichtig ist der Unterschied zwischen quelle/ und quelle als Pfadangabe: Der abschliessende Schraegstrich bestimmt, ob der Inhalt eines Verzeichnisses oder das Verzeichnis selbst in das Ziel kopiert wird, ein Detail, das bei falscher Anwendung zu doppelt verschachtelten Verzeichnisstrukturen fuehrt.

#!/usr/bin/env bash
set -euo pipefail

# Sync application uploads to a remote backup host over SSH
# Trailing slash on source: copy contents, not the directory itself
rsync -avz --delete \
  --exclude='cache/' \
  --exclude='*.tmp' \
  -e "ssh -i /root/.ssh/backup_ed25519 -p 2222" \
  /var/www/app/pub/media/ \
  backup@backup01.mironsoft.de:/srv/backups/app-media/

# Dry-run first to preview what would change, without touching anything
rsync -avz --delete --dry-run \
  /var/www/app/pub/media/ backup@backup01.mironsoft.de:/srv/backups/app-media/

# Bandwidth-limited nightly sync (2 MB/s) to avoid saturating uplink
rsync -avz --bwlimit=2000 --delete \
  /var/lib/mysql-backup/ backup@backup01.mironsoft.de:/srv/backups/db/

3. rsync mit Hardlinks: Snapshot-artige Historie ohne Snapshot-Tool

Ein haeufig uebersehenes rsync-Feature ist --link-dest, mit dem sich eine taegliche Versionshistorie erzeugen laesst, ohne für jeden Tag eine vollstaendige Kopie zu speichern. Dabei verweist rsync bei unveraenderten Dateien per Hardlink auf die Version im vorherigen Backup-Verzeichnis, anstatt die Datei erneut zu schreiben. Nur tatsaechlich geaenderte Dateien belegen zusaetzlichen Speicherplatz. Das Ergebnis sieht für jeden Tag wie eine vollstaendige, unabhaengige Kopie aus, verbraucht aber nur den Speicherplatz der tatsaechlichen Änderungen.

Dieses Muster, oft als "rsync-basierte Snapshots" bezeichnet, war lange vor breiter Verfuegbarkeit von Btrfs oder ZFS der Standardweg für platzsparende Versionshistorien und wird bis heute in Tools wie rsnapshot und Borg als Grundprinzip verwendet. Der entscheidende Vorteil gegenueber einem einfachen taeglichen tar-Dump: Man kann jederzeit auf jeden beliebigen Tag zurueckgreifen, ohne inkrementelle Archive in der richtigen Reihenfolge wiederherstellen zu müssen, weil jedes Tagesverzeichnis für sich vollstaendig navigierbar ist.

#!/usr/bin/env bash
# daily-snapshot.sh: hardlink-based daily backup history
set -euo pipefail

readonly BACKUP_ROOT="/srv/backups/app"
readonly TODAY="$(date +%Y-%m-%d)"
readonly LATEST_LINK="${BACKUP_ROOT}/latest"

mkdir -p "${BACKUP_ROOT}/${TODAY}"

# --link-dest points to yesterday's snapshot; unchanged files become hardlinks
rsync -a --delete \
  --link-dest="${LATEST_LINK}" \
  /var/www/app/ \
  "${BACKUP_ROOT}/${TODAY}/"

# Update the "latest" pointer for the next run's --link-dest
rm -f "${LATEST_LINK}"
ln -s "${BACKUP_ROOT}/${TODAY}" "${LATEST_LINK}"

# Disk usage stays low: only changed files consume real space
du -sh "${BACKUP_ROOT}"/*/

4. tar: portable Archive für Langzeitarchivierung

Waehrend rsync Dateibaeume synchron haelt, erzeugt tar ein einzelnes portables Archiv, das sich unabhaengig vom Zielsystem transportieren, komprimieren und langfristig aufbewahren laesst. Fuer Compliance-Anforderungen oder monatliche Vollarchive ist ein tar-Archiv oft die praktischere Form, weil ein einzelnes Objekt leichter in ein Objektspeicher-System wie S3 oder in ein Bandlaufwerk-Archiv wandert als tausende Einzeldateien.

Die Kombination tar czf mit gzip-Kompression ist der Standard, wobei zstd über --use-compress-program=zstd bei modernen Systemen deutlich schneller komprimiert und dabei aehnliche oder bessere Kompressionsraten liefert, besonders bei mehreren CPU-Kernen mit -T0. Fuer inkrementelle tar-Archive gibt es --listed-incremental, das eine Snapshot-Datei fuehrt und bei jedem Lauf nur seit dem letzten Archiv geaenderte Dateien einschliesst, was bei sehr grossen, selten vollstaendig geaenderten Datenbestaenden erhebliche Zeit spart.

#!/usr/bin/env bash
set -euo pipefail

readonly DATE_TAG="$(date +%Y%m%d)"
readonly ARCHIVE_DIR="/srv/backups/archives"
readonly SNAR_FILE="${ARCHIVE_DIR}/app.snar"

mkdir -p "${ARCHIVE_DIR}"

# Full monthly archive with zstd compression (faster than gzip, multi-core)
tar --use-compress-program="zstd -T0 -19" \
  -cf "${ARCHIVE_DIR}/app-full-${DATE_TAG}.tar.zst" \
  --exclude='./cache' --exclude='./var/log' \
  -C /var/www/app .

# Incremental archive: only files changed since last run of this snapshot file
tar --listed-incremental="${SNAR_FILE}" \
  -czf "${ARCHIVE_DIR}/app-incr-${DATE_TAG}.tar.gz" \
  -C /var/www/app .

# Verify archive integrity without extracting
tar -tzf "${ARCHIVE_DIR}/app-full-${DATE_TAG}.tar.zst" > /dev/null && echo "OK"

# Extract a single file from a large archive without unpacking everything
tar -xzf "${ARCHIVE_DIR}/app-full-${DATE_TAG}.tar.zst" ./app/etc/env.php

5. LVM-Snapshots: konsistente Backups ohne Downtime

Sowohl rsync als auch tar haben ein gemeinsames Problem: Laeuft der Backup-Vorgang mehrere Minuten und schreibt die Anwendung waehrenddessen weiter, landet ein inkonsistenter Zustand im Backup, in dem manche Dateien vor, andere nach einer zusammengehoerigen Aenderung erfasst wurden. Bei einer Datenbank kann das ein korruptes oder nicht wiederherstellbares Backup bedeuten. LVM-Snapshots lösen dieses Problem auf Blockebene: lvcreate --snapshot friert den Zustand eines Logical Volumes in Millisekunden ein, indem es Copy-on-Write für alle nachfolgenden Schreibzugriffe aktiviert.

Der eigentliche Datenbestand bleibt für die Anwendung ohne Unterbrechung beschreibbar, während der Snapshot einen unveraenderlichen, konsistenten Blick auf den Zustand zum Erstellungszeitpunkt liefert. Dieser Snapshot wird gemountet, mit rsync oder tar gesichert und danach wieder entfernt. Wichtig: Ein LVM-Snapshot ist kein Backup an sich, sondern nur ein konsistentes Zeitfenster, aus dem heraus gesichert wird. Bleibt der Snapshot dauerhaft bestehen, waechst er mit jeder Aenderung am Original und kann bei vollem Copy-on-Write-Speicherbereich das komplette Volume Group in Schwierigkeiten bringen.

#!/usr/bin/env bash
# lvm-snapshot-backup.sh: consistent backup via LVM snapshot, near-zero downtime
set -euo pipefail

readonly VG="vg_data"
readonly LV="lv_mysql"
readonly SNAP_NAME="mysql_backup_snap"
readonly MOUNT_POINT="/mnt/backup-snap"

cleanup() {
  mountpoint -q "$MOUNT_POINT" && umount "$MOUNT_POINT"
  lvs "/dev/${VG}/${SNAP_NAME}" &>/dev/null && lvremove -f "/dev/${VG}/${SNAP_NAME}"
}
trap cleanup EXIT

# Flush MySQL to disk and briefly lock tables for a consistent snapshot point
mysql -e "FLUSH TABLES WITH READ LOCK; SELECT SLEEP(1);" &
sleep 0.5

# Create a 5 GB copy-on-write snapshot volume
lvcreate --size 5G --snapshot --name "$SNAP_NAME" "/dev/${VG}/${LV}"

mkdir -p "$MOUNT_POINT"
mount -o ro "/dev/${VG}/${SNAP_NAME}" "$MOUNT_POINT"

# Original volume is writable again as soon as the snapshot exists
rsync -a "$MOUNT_POINT/" backup@backup01.mironsoft.de:/srv/backups/mysql-snap/

echo "[OK] Snapshot backup completed, cleanup runs via trap"

6. Btrfs- und ZFS-Snapshots als Alternative

Wo LVM auf Blockebene arbeitet, bieten Btrfs und ZFS native Snapshot-Funktionen direkt im Dateisystem, was die Handhabung in vielen Faellen vereinfacht. btrfs subvolume snapshot -r /data /data-snapshots/2026-07-12 erzeugt in Sekundenbruchteilen einen schreibgeschuetzten, konsistenten Zustand eines Subvolumes, ohne separate Snapshot-Verwaltung wie bei LVM. Da Btrfs- und ZFS-Snapshots Copy-on-Write auf Dateisystemebene statt auf Blockebene nutzen, sind sie in der Regel platzsparender bei vielen kleinen Änderungen und lassen sich direkt unter einem Pfad durchsuchen, ohne vorher gemountet werden zu müssen.

ZFS geht noch einen Schritt weiter mit zfs send und zfs receive, womit sich Snapshots inkrementell und effizient auf ein entferntes System replizieren lassen, inklusive aller Metadaten wie Kompression und Deduplizierung. Fuer Systeme, die ohnehin auf Btrfs oder ZFS als Root-Dateisystem setzen, sind native Snapshots meist die pragmatischere Wahl gegenueber LVM-Snapshots, weil kein zusaetzlicher Copy-on-Write-Speicherbereich manuell dimensioniert werden muss und die Snapshot-Verwaltung Teil des normalen Dateisystem-Tooling ist.

#!/usr/bin/env bash
set -euo pipefail

# Btrfs: create a read-only snapshot of a subvolume
btrfs subvolume snapshot -r /data "/data-snapshots/$(date +%Y-%m-%d)"

# List existing snapshots with creation time
btrfs subvolume list -s /data

# ZFS: create a snapshot and replicate it incrementally to a remote host
zfs snapshot tank/app@$(date +%Y-%m-%d)
zfs send -i tank/app@yesterday tank/app@$(date +%Y-%m-%d) | \
  ssh backup01.mironsoft.de zfs receive backup-pool/app

# Prune snapshots older than 30 days (btrfs example)
find /data-snapshots -maxdepth 1 -mtime +30 -exec btrfs subvolume delete {} \;

7. Die 3-2-1-Regel praktisch auf einer Serverflotte umsetzen

Die 3-2-1-Regel besagt: drei Kopien der Daten, auf zwei verschiedenen Speichermedien, davon eine Kopie an einem geografisch getrennten Ort. In der Praxis bei einer kleinen Serverflotte bedeutet das konkret: Kopie eins ist die Produktionsdatenbank selbst, Kopie zwei ist ein taegliches rsync-Backup auf einen dedizierten Backup-Server im selben Rechenzentrum, Kopie drei ist ein woechentliches verschluesseltes tar-Archiv, das auf ein Objektspeicher-System bei einem anderen Anbieter oder in einer anderen Region hochgeladen wird.

Entscheidend ist, dass der Backup-Server keine Schreibrechte auf die Produktionssysteme hat, sondern per Pull-Prinzip selbst per SSH auf die Quellen zugreift. Damit kann ein kompromittiertes Produktionssystem nicht gleichzeitig die Backups manipulieren oder loeschen, ein Angriffsszenario, das bei Ransomware-Vorfaellen regelmaessig beobachtet wird. Fuer die Offsite-Kopie eignen sich Object-Storage-Dienste mit Immutability-Optionen, bei denen hochgeladene Objekte für eine definierte Frist auch mit Admin-Rechten nicht geloescht werden können, was zusaetzlichen Schutz gegen kompromittierte Zugangsdaten bietet.

# backup-policy.yaml: documented 3-2-1 policy for the server fleet
# Copy 1: production data itself (not a backup, the source)
copy_1:
  location: production database and application servers
  medium: local NVMe storage

# Copy 2: on-site, different medium, pull-based via SSH
copy_2:
  location: dedicated backup host in the same datacenter
  medium: rsync daily snapshot with --link-dest history
  retention: 14 daily snapshots
  access: pull-only, backup host has read-only SSH key on sources

# Copy 3: off-site, different provider and region
copy_3:
  location: object storage, different provider, different region
  medium: weekly encrypted tar.zst archive
  retention: 12 weekly archives, then monthly for 12 months
  immutability: object lock enabled for 30 days

restore_test:
  frequency: monthly
  scope: full restore of one random backup into an isolated environment

8. Restore-Tests: ein Backup ist erst verifiziert, wenn es wiederhergestellt wurde

Ein Backup, das nie wiederhergestellt wurde, ist keine Sicherheit, sondern eine unbewiesene Annahme. In der Praxis scheitern Restores erstaunlich haeufig an Details, die ein reiner Backup-Job nie aufdeckt: eine vergessene Datei in der Exclude-Liste, ein Archiv, das zwar geschrieben, aber nie auf Vollstaendigkeit geprueft wurde, oder eine Datenbank-Dump-Datei, die aufgrund eines abgebrochenen Prozesses unvollstaendig ist. Diese Fehler zeigen sich ausschließlich im Ernstfall, wenn ein tatsaechlicher Restore ansteht, es sei denn, man testet ihn regelmaessig vorher.

Ein produktiver Restore-Test gehoert monatlich in den Kalender, nicht nur nach grossen Änderungen an der Backup-Konfiguration. Der Test sollte in einer isolierten Umgebung erfolgen, die die Produktion nicht beeinflusst, etwa einem separaten Testserver oder einem temporaeren Container. Wichtige Kennzahlen dabei sind die tatsaechliche Restore-Dauer (Recovery Time Objective) und der maximale Datenverlust seit dem letzten Backup (Recovery Point Objective), beide sollten dokumentiert und mit den tatsaechlichen Business-Anforderungen abgeglichen werden, nicht nur theoretisch angenommen.

#!/usr/bin/env bash
# monthly-restore-test.sh: verify a backup is actually usable
set -euo pipefail

readonly TEST_DIR="/tmp/restore-test-$(date +%s)"
readonly ARCHIVE="/srv/backups/archives/app-full-$(date +%Y%m%d).tar.zst"

mkdir -p "$TEST_DIR"

echo "[1/4] Extracting archive into isolated test directory..."
tar --use-compress-program="zstd -d" -xf "$ARCHIVE" -C "$TEST_DIR"

echo "[2/4] Restoring database dump into a throwaway database..."
mysql -e "CREATE DATABASE IF NOT EXISTS restore_test;"
zcat /srv/backups/db/latest.sql.gz | mysql restore_test

echo "[3/4] Validating row counts against expected baseline..."
mysql restore_test -e "SELECT COUNT(*) FROM sales_order;" | tail -1

echo "[4/4] Cleaning up test environment..."
mysql -e "DROP DATABASE restore_test;"
rm -rf "$TEST_DIR"

echo "[OK] Restore test passed, log result and RTO/RPO in the runbook"

9. Backup-Werkzeuge im direkten Vergleich

Die vorgestellten Werkzeuge lösen unterschiedliche Teilprobleme und schliessen sich nicht gegenseitig aus. Die folgende Tabelle stellt gegenueber, wofuer welches Werkzeug tatsaechlich geeignet ist und wo typische Fehlanwendungen liegen.

Die Tabelle macht deutlich, dass keines der Werkzeuge universell richtig ist. Wer rsync auf eine laufende Datenbank ohne vorherigen Snapshot ansetzt, riskiert stille Inkonsistenzen. Wer nur auf tar-Vollarchive setzt, verschenkt Speicherplatz und Zeit. Die robusteste Strategie kombiniert alle drei Werkzeugklassen entlang der 3-2-1-Regel und schließt den Kreis mit regelmaessigen Restore-Tests.

10. Zusammenfassung

Eine robuste Linux-Backup-Strategie besteht nicht aus einem einzelnen Werkzeug, sondern aus der gezielten Kombination mehrerer. rsync synchronisiert Dateibaeume effizient und ermoeglicht mit --link-dest eine platzsparende taegliche Historie. tar erzeugt portable, gut archivierbare Vollarchive für Langzeitaufbewahrung und Compliance. LVM-, Btrfs- oder ZFS-Snapshots lösen das Konsistenzproblem, indem sie einen Datenbestand in Millisekunden einfrieren, ohne die Anwendung zu unterbrechen. Die 3-2-1-Regel gibt den organisatorischen Rahmen vor: drei Kopien, zwei Medien, eine Kopie geografisch getrennt.

Der wichtigste Punkt bleibt der am haeufigsten ausgelassene: ein Backup, das nie wiederhergestellt wurde, ist nicht verifiziert. Monatliche Restore-Tests in einer isolierten Umgebung decken fehlende Dateien, korrupte Archive und unrealistische RTO/RPO-Annahmen auf, bevor ein echter Datenverlust eintritt. Wer diese vier Bausteine, effiziente Synchronisation, konsistente Snapshots, geografisch verteilte Kopien und regelmaessige Restore-Tests konsequent kombiniert, hat eine Backup-Strategie, die im Ernstfall tatsaechlich traegt.

11. FAQ: Linux-Backup-Strategien