Server-Administration

Linux Backup-Strategie: Was du sicherst, wohin du sicherst und wie du zurückkommst

Ein Backup ist erst eines, wenn du die Wiederherstellung geübt hast. Alles davor ist eine Kopie mit Hoffnung. Halte dich an 3-2-1, prüfe Restores nach Kalender und lege mindestens eine Kopie unveränderbar ab.

4 Kapitel mit allen Befehlen
Administrator steckt ein Netzwerkkabel in einen Serverschrank
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum viele Linux-Backups im Ernstfall nicht helfen

In den meisten Umgebungen läuft irgendetwas: ein rsync-Job auf ein NFS-Share, ein Snapshot auf dem Storage, ein Dump der Datenbank per Cron. Das Problem ist selten, dass gar nichts gesichert wird. Das Problem ist, dass niemand genau sagen kann, wie lange eine vollständige Wiederherstellung dauert, welcher Datenstand dabei herauskommt und ob die Sicherung nach einem Kompromittierungsfall überhaupt noch vertrauenswürdig ist.

Ransomware hat die Anforderungen verschoben. Angreifer suchen gezielt nach Backup-Servern, gemounteten Shares und hinterlegten Zugangsdaten und löschen oder verschlüsseln die Sicherungen, bevor sie die Produktivsysteme angehen. Ein Backup-Ziel, das vom gesicherten System aus beschreibbar ist, ist deshalb kein Schutz gegen dieses Szenario. Dazu kommt der regulatorische Druck: NIS2 zählt Backup-Management und Wiederherstellung ausdrücklich zu den Risikomanagement-Maßnahmen, die Geschäftsleitungen verantworten müssen.

Typische Fehler sind gut bekannt und trotzdem verbreitet. Ein laufender PostgreSQL- oder MySQL-Dienst wird auf Dateiebene mitgesichert und ergibt einen inkonsistenten Stand. LVM-Snapshots werden als Backup betrachtet, obwohl sie auf demselben Volume Group liegen. Es gibt keine dokumentierte Reihenfolge, in der Systeme nach einem Totalausfall wieder hochkommen. Und die letzte echte Wiederherstellung liegt Jahre zurück oder hat nie stattgefunden.

Miniatur-Szene: geöffneter Serverschrank mit Werkzeug, Patchpanel und grünem Uptime-Balken
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Von der Anforderung zum geprüften Restore

  1. 01 Schutzbedarf, RPO und RTO klären
  2. 02 Sicherungsarten je System wählen
  3. 03 Ziele trennen und unveränderlich halten
  4. 04 Aufbewahrung und Löschfristen festlegen
  5. 05 Wiederherstellung testen und dokumentieren
Was du mitnimmst

So baust du eine Backup-Strategie, die einen Ausfall übersteht

Eine tragfähige Strategie beantwortet vier Fragen für jedes System: Wie viel Datenverlust ist tolerierbar, wie lange darf die Wiederherstellung dauern, wo liegt die Kopie und wer hat darauf Schreibrechte. Der Rest ist Umsetzung.

RPO und RTO je System festlegen

Bevor du über Werkzeuge redest, ordnest du jedem Dienst einen tolerierbaren Datenverlust (Recovery Point Objective) und eine maximale Ausfallzeit (Recovery Time Objective) zu. Ein Fileserver mit täglicher Sicherung und ein Abrechnungssystem mit fünf Minuten RPO brauchen unterschiedliche Verfahren, und erst aus diesen Zahlen ergibt sich, ob Snapshots, inkrementelle Sicherungen oder kontinuierliche Archivierung passen.

Die 3-2-1-Regel konsequent umsetzen

Drei Kopien der Daten, auf zwei unterschiedlichen Medien oder Systemen, davon eine außer Haus. Viele Häuser erweitern das auf 3-2-1-1-0: eine Kopie unveränderlich oder offline und null Fehler beim letzten Wiederherstellungstest. Wichtig ist, dass die Off-Site-Kopie nicht über dieselben Domänen- oder SSH-Anmeldedaten erreichbar ist wie die Produktion.

Unveränderliche und getrennte Ziele einsetzen

Sinnvolle Bausteine sind Object Lock auf S3-kompatiblem Speicher, append-only Repositories wie bei restic oder Borg mit eingeschränktem SSH-Kommando, ZFS-Snapshots mit Hold, oder ein Backup-Server, der die Sicherung aktiv abholt statt sie entgegenzunehmen. Entscheidend ist das Pull-Prinzip: Das gesicherte System darf seine eigenen älteren Sicherungen nicht löschen können.

Anwendungskonsistenz statt Dateikopie

Datenbanken werden mit ihren eigenen Verfahren gesichert. Bei PostgreSQL sind das pg_dump für logische Sicherungen und pg_basebackup mit WAL-Archivierung oder pgBackRest für Point-in-Time-Recovery, bei MySQL und MariaDB je nach Engine mysqldump oder ein physisches Verfahren. Bei virtuellen Maschinen sorgt der QEMU-Guest-Agent dafür, dass Dateisysteme vor dem Snapshot eingefroren werden.

Das System, nicht nur die Nutzdaten sichern

Zur Wiederherstellbarkeit gehören Partitionierung und LVM-Layout, /etc, Paketstände, Zertifikate und Schlüsselmaterial sowie die Konfiguration selbst. Wer Ansible oder eine vergleichbare Automatisierung nutzt, verkürzt die RTO erheblich, weil ein Server neu ausgerollt und nur noch mit Daten befüllt werden muss, statt Byte für Byte zurückgespielt zu werden.

Restore regelmäßig testen und protokollieren

Plane feste Termine, an denen eine vollständige Wiederherstellung auf ein Ersatzsystem läuft, inklusive Zeitmessung und Prüfsummen. Ergänze automatisierte Prüfungen wie restic check oder die Verifikation im Proxmox Backup Server. Ein protokollierter Restore-Test ist gleichzeitig der Nachweis, den Auditoren und Versicherer sehen wollen.

Tutorial

Eine Sicherung, die im Ernstfall trägt

Die meisten Backup-Konzepte scheitern nicht beim Sichern, sondern beim Zurückspielen. Dieser Teil geht deshalb rückwärts vor: erst die Frage, was in welcher Zeit wieder da sein muss, dann die Auswahl des Verfahrens, dann der Schutz gegen Erpressung und zuletzt der Nachweis, dass es wirklich funktioniert.

01

Zuerst die Ziele festlegen

Ohne zwei Zahlen ist jede Diskussion über Werkzeuge sinnlos. Sie ergeben sich nicht aus der Technik, sondern aus dem Geschäft.

Die zwei Kennzahlen

KennzahlFrageBeispiel
RPO (Recovery Point Objective)Wie viel Datenverlust ist verkraftbar?Vier Stunden bedeutet: Sicherung mindestens alle vier Stunden.
RTO (Recovery Time Objective)Wie lange darf die Wiederherstellung dauern?Zwei Stunden bedeutet: Ein Bandarchiv im Auslagerungslager scheidet aus.

Diese Werte unterscheiden sich pro System. Der Warenwirtschaftsserver braucht vielleicht ein RPO von 15 Minuten, das interne Wiki verträgt einen Tag. Wer für alles denselben Maßstab anlegt, zahlt entweder zu viel oder schützt das Falsche. Halte die Zuordnung schriftlich fest, sie ist die Begründung für jede spätere Investition.

Was gesichert gehört, und was oft vergessen wird

  • Nutzdaten und DatenbankenDatenbanken niemals als Dateikopie im laufenden Betrieb, sondern über einen konsistenten Auszug oder einen Snapshot mit vorherigem Flush. Sonst sicherst du einen Zustand, den es so nie gab.
  • Konfiguration unter /etcKlein, schnell gesichert und im Wiederherstellungsfall Gold wert. Wer nur Nutzdaten sichert, baut den Server danach von Hand neu.
  • Verschlüsselungsschlüssel und ZertifikateEine verschlüsselte Sicherung ohne den zugehörigen Schlüssel ist Datenmüll. Der Schlüssel gehört getrennt und nachweislich hinterlegt, nicht auf denselben Server.
  • Die Beschreibung des Systems selbstPartitionierung, Paketliste, Netzkonfiguration. Bei einem Totalausfall entscheidet das darüber, ob die Wiederherstellung zwei Stunden oder zwei Tage dauert.
02

Verfahren auswählen

Es gibt drei gängige Ansätze, die sich nicht ausschließen, sondern ergänzen.

Ansätze im Vergleich

AnsatzStärkeSchwächeTypisch für
Dateibasiert (restic, Borg)deduplizierend, verschlüsselt, einzelne Dateien schnell zurückkein bootfähiges SystemNutzdaten, Konfiguration
Abbild der Maschinekomplettes System in einem Schritt zurückgrob, hoher PlatzbedarfVMs, Hypervisor-Ebene
Dateisystem-Snapshot + Replikationsehr schnell, minimaler Platzbedarfan das Dateisystem gebundenZFS, Btrfs, Proxmox
restic: der pragmatische Standard
export RESTIC_REPOSITORY="s3:https://s3.eu-central-1.example.com/backup-srv01"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"

# Erstmalige Einrichtung
restic init

# Sicherung, dedupliziert und verschlüsselt
restic backup /etc /var/www /srv/daten \
  --exclude-caches --exclude '*.tmp' --tag taeglich

# Aufbewahrung steuern
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

# Integrität prüfen, monatlich mit Daten-Stichprobe
restic check --read-data-subset=5%

restic check gehört in den Zeitplan. Ein Repository, dessen Konsistenz nie geprüft wurde, kann monatelang stillschweigend defekt sein.

Datenbanken konsistent sichern
# MariaDB/MySQL: konsistenter Auszug einer InnoDB-Datenbank
mariadb-dump --single-transaction --routines --events --all-databases \
  | zstd > /var/backups/db-$(date +%F).sql.zst

# PostgreSQL: eigenes Format, erlaubt selektives Zurückspielen
pg_dumpall --globals-only > /var/backups/pg-globals-$(date +%F).sql
pg_dump -Fc meinedb > /var/backups/meinedb-$(date +%F).dump

# Anschließend die Auszüge mit restic sichern

--single-transaction ist bei InnoDB entscheidend: Ohne diese Option sperrt der Auszug die Tabellen oder liefert einen inkonsistenten Stand.

03

Schutz gegen Erpressungssoftware

Der Angriffsablauf ist immer derselbe: Zugang verschaffen, Sicherungen suchen und zerstören, dann verschlüsseln. Wer die Sicherung erreichbar hält, hat keine.

Die drei wirksamen Maßnahmen

  • Pull statt PushDer Backup-Server holt sich die Daten, der Produktivserver hat keinen Zugang zum Sicherungsspeicher. Damit kann ein übernommenes System die Sicherungen nicht anfassen.
  • Unveränderbarkeit erzwingenObject Lock bei S3-kompatiblem Speicher oder append-only-Modus bei Borg. Selbst mit gültigen Zugangsdaten lässt sich dann nichts löschen, bis die Frist abgelaufen ist.
  • Eine Kopie offline oder in einem anderen KontoDie klassische 3-2-1-Regel: drei Kopien, zwei Medientypen, eine außer Haus. Für kleine Umgebungen genügt eine rotierende externe Platte, die nach der Sicherung physisch getrennt wird.
Zugangskonto ohne Löschrecht
# S3-Richtlinie für das Backup-Konto: schreiben ja, löschen nein
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:PutObject", "s3:GetObject", "s3:ListBucket"],
    "Resource": ["arn:aws:s3:::backup-srv01", "arn:aws:s3:::backup-srv01/*"]
  }]
}

# Borg im Nur-Anhängen-Modus auf dem Backup-Server
# ~/.ssh/authorized_keys:
# command="borg serve --append-only --restrict-to-path /backup",restrict ssh-ed25519 AAAA...

Ohne s3:DeleteObject kann ein Angreifer mit erbeuteten Zugangsdaten neue Objekte schreiben, aber keine vorhandenen vernichten. Das Aufräumen alter Sicherungen übernimmt dann eine Lebenszyklusregel oder ein separates Konto.

04

Der Test, den fast niemand macht

Eine Sicherung, aus der noch nie zurückgespielt wurde, ist eine unbewiesene Annahme. Und in Audits ist genau das die Frage, die gestellt wird.

Wiederherstellung prüfen
# Einzelne Datei zurückholen und vergleichen
restic restore latest --target /tmp/wh-test --include /etc/ssh/sshd_config
diff /etc/ssh/sshd_config /tmp/wh-test/etc/ssh/sshd_config

# Was steckt überhaupt in der Sicherung?
restic snapshots
restic ls latest /etc | head

# Datenbank in eine Testinstanz zurückspielen und Datensätze zählen
zstd -dc /var/backups/db-2026-07-01.sql.zst | mariadb -h testserver testdb
mariadb -h testserver -e 'SELECT COUNT(*) FROM testdb.auftraege;'

Der Vergleich am Ende ist der eigentliche Test. Eine Wiederherstellung, die durchläuft, aber leere Dateien erzeugt, hat schon manches Team in Sicherheit gewiegt.

Testplan, der in Audits standhält

  • Monatlich eine einzelne DateiKostet fünf Minuten und deckt die häufigsten Fehler auf: falscher Pfad, abgelaufener Schlüssel, kaputtes Repository.
  • Quartalsweise ein vollständiges SystemErst dabei fällt auf, dass die Partitionierung nicht dokumentiert ist oder der Bootloader fehlt. Am besten auf einer frischen VM.
  • Jährlich ein Ernstfall-Durchlauf mit ZeitmessungNur so erfährst du, ob dein RTO realistisch ist. Die gemessene Zeit ist die belastbare Zahl gegenüber der Geschäftsführung, nicht die geschätzte.
  • Jeden Test protokollierenDatum, wer, was, wie lange, welche Probleme. Ohne Protokoll gilt der Test im Audit als nicht erfolgt.
Gut zu wissen

Häufige Fragen zu Linux-Backup-Strategien

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie oft sollte ich Linux-Server sichern?
Die Frequenz ergibt sich aus dem RPO und nicht aus einer Faustregel. Für Systeme, deren Daten sich selten ändern, reicht oft eine tägliche inkrementelle Sicherung, während transaktionale Datenbanken zusätzlich eine kontinuierliche WAL- oder Binlog-Archivierung brauchen, damit du auf einen beliebigen Zeitpunkt zurückgehen kannst.
Reicht ein Snapshot als Backup aus?
Nein. Ein LVM-, ZFS- oder Hypervisor-Snapshot liegt in der Regel auf demselben Storage wie die Produktivdaten und geht bei Hardwaredefekt, Dateisystemschaden oder einem Angriff mit verloren. Snapshots sind ein hervorragender Ausgangspunkt für eine konsistente Sicherung und ein schnelles Rollback nach Updates, ersetzen aber keine zweite Kopie an einem getrennten Ort.
Was bedeutet 3-2-1-1-0 genau?
Drei Kopien der Daten, gespeichert auf zwei verschiedenen Medien oder Systemen, davon eine an einem anderen Standort, zusätzlich eine unveränderliche oder offline gehaltene Kopie und null Fehler beim letzten Wiederherstellungstest. Die beiden letzten Ziffern sind die Antwort auf Ransomware und auf stillschweigend fehlgeschlagene Sicherungsjobs.
Wie sichere ich PostgreSQL richtig?
Für kleine Datenbanken und Migrationen genügt pg_dump beziehungsweise pg_dumpall, weil das Ergebnis versionsübergreifend einspielbar ist. Für produktive Systeme mit engem RPO nimmst du eine physische Basissicherung per pg_basebackup oder pgBackRest und archivierst die WAL-Segmente, damit Point-in-Time-Recovery möglich ist. Eine reine Dateikopie des Datenverzeichnisses im laufenden Betrieb ist unbrauchbar.
Verlangt NIS2 eine bestimmte Backup-Technik?
Nein, die Richtlinie schreibt keine Produkte oder Verfahren vor. Sie nennt Backup-Management und Wiederherstellung als eine der Risikomanagement-Maßnahmen, die betroffene Einrichtungen dem Stand der Technik entsprechend umsetzen und nachweisen müssen. In der Praxis heißt das: dokumentiertes Konzept, definierte RPO- und RTO-Werte, geschützte Sicherungskopien und belegte Wiederherstellungstests.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Für den Einsteigerkurs ganz gut umgesetzt. Passt soweit und kann man ohne Bedenken weiter empfehlen.
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Backup-Konzept mit uns durchgehen

Wenn du die Umsetzung vertiefen willst, findest du bei cmt die passenden Bausteine: Der Proxmox Grundkurs behandelt Storage und Backup für KVM und LXC, der Proxmox Aufbaukurs ergänzt Cluster, Ceph und Hochverfügbarkeit, und der PostgreSQL Aufbaukurs zu Datensicherung und Integrität geht auf Dumps, WAL-Archivierung und Wiederherstellung ein. Für die Grundlagen auf Systemebene passen die Kurse zu Linux Storage und Dateisystemen sowie zur Linux-Systemadministration. Alle Termine gibt es als Präsenz- oder Live-Online-Schulung, auf Wunsch auch als Inhouse-Termin mit deinen eigenen Systemen im Blick. Melde dich, dann klären wir gemeinsam, welcher Weg zu deiner Umgebung passt.