Was Sie einrichten
Angreifer, die in ein Netzwerk eindringen, versuchen meist zuerst die Sicherungen zu löschen oder zu verschlüsseln und danach die Server. Eine Sicherung, die ein gestohlenes Administratorkonto löschen kann, reicht deshalb nicht. Diese Anleitung baut mit BackupZit einen Schutz in Schichten auf: eine primäre Sicherung auf lokalem Speicher, eine Kopie an einem anderen Ort und Speicher, auf dem Sicherungen vor Ablauf einer festgelegten Frist nicht zerstört werden können, selbst mit den Zugangsdaten des Speichers. BackupZit ist kostenlos und Open Source (AGPLv3); alles hier Beschriebene gehört zum kostenlosen Produkt.
Die 3-2-1-Regel und 3-2-1-1-0
Die 3-2-1-Regel: 3 Kopien Ihrer Daten, auf 2 verschiedenen Medien, 1 davon außer Haus. Die Erweiterung 3-2-1-1-0 ergänzt 1 Kopie, die unveränderlich oder offline ist, und 0 Fehler bei der Prüfung der Sicherungen. In BackupZit:
| Teil | In BackupZit |
|---|
| 3 Kopien | Die Produktivdaten, ein Sicherungsauftrag und ein Kopierauftrag. |
| 2 Medien | Zwei Speicherziele, z. B. ein NAS über SMB oder SFTP und ein S3-Bucket. |
| 1 außer Haus | Die Kopie geht in die Cloud (S3, Azure Blob Storage) oder auf ein gehärtetes Repository in einem anderen Gebäude. |
| 1 unveränderlich oder offline | S3 mit Object Lock, ein gehärtetes Repository oder wechselnde USB-Datenträger. |
| 0 Fehler | Automatische Wiederherstellungstests und die Prüfung aller gespeicherten Daten, mit einer Warnung, wenn etwas fehlschlägt. |
Sie brauchen eine BackupZit-Konsole mit Agenten auf den zu schützenden Maschinen; die Anleitungen für Proxmox VE, Hyper-V und Windows-Datenträgerabbilder zeigen diese ersten Schritte.
Schritt 1 — Primärer Speicher für schnelle Wiederherstellungen
Öffnen Sie in der Konsole Speicher → Speicherziel hinzufügen. Für die erste Kopie wählen Sie Speicher im lokalen Netz, damit Sicherungen und Wiederherstellungen mit voller Geschwindigkeit laufen: eine SMB-Freigabe auf einem Dateiserver oder NAS oder einen Linux-Server bzw. ein NAS über SFTP (dessen Hostschlüssel wird festgelegt). Geben Sie dem Ziel ein eigenes Konto, das nur in den Sicherungsordner schreiben darf, und nehmen Sie den Sicherungsspeicher nicht in die Windows-Domäne auf.
Beim Speichern testet die Konsole das Ziel sofort — ein falsches Passwort, ein falscher Hostschlüssel oder eine falsche Freigabe zeigt sich jetzt und nicht erst bei der ersten Sicherung. Verbindung testen in der Speicherliste wiederholt den Test.
Schritt 2 — Unveränderlichen Speicher hinzufügen
BackupZit kennt zwei Arten von Speicher, auf denen Sicherungen vor Ablauf ihrer Frist weder gelöscht noch überschrieben werden können. Idealerweise liegt er auch außer Haus, sodass ein Ziel beides abdeckt.
Variante A: S3 mit Object Lock
- Legen Sie den Bucket mit aktiviertem Object Lock an — bei AWS, Wasabi und Backblaze B2 eine Option beim Anlegen des Buckets, bei MinIO
mc mb --with-lock.
- Fügen Sie eine Lifecycle-Regel hinzu, die nicht aktuelle Versionen nach einem Tag löscht (MinIO:
mc ilm rule add --noncurrent-expire-days 1 --expire-delete-marker). Das Löschen einer gesperrten Sicherung setzt nur einen Löschmarker; die Regel gibt den Platz frei, sobald die Sperren enden.
- Fügen Sie in der Konsole ein Ziel vom Typ S3-kompatibel (AWS, Wasabi, Backblaze B2, MinIO, …) mit Endpunkt, Bucket und einem Zugriffsschlüssel für diesen Bucket hinzu.
- Aktivieren Sie Unveränderliche Sicherungen (S3 Object Lock, Compliance-Modus) für … Tagen (Standard 30) und wählen Sie eine Frist, die mindestens so lang ist wie die Aufbewahrung, die geschützt sein soll.
Jede Datei, die die Agenten schreiben, wird dann für diese Frist plus einen Tag im Compliance-Modus gesperrt: Niemand — weder ein Angreifer mit den Schlüsseln noch der Eigentümer des Buckets — kann sie vorher löschen oder überschreiben. Daten, die eine neue Sicherung aus älteren übernimmt, erhalten eine verlängerte Sperre, sodass jeder Wiederherstellungspunkt die volle Frist geschützt ist. Auf unveränderlichem Speicher meldet sich der Verbindungstest nur an und listet, und er prüft, ob der Bucket wirklich Object Lock hat.
Azure und Google Cloud: Für Azure Blob Storage aktivieren Sie in Azure die Unveränderlichkeit auf Versionsebene mit einer zeitbasierten Aufbewahrungsrichtlinie für den Container. Google Cloud Storage funktioniert als S3-Ziel, aber ohne die Option Object Lock; legen Sie stattdessen in Google Cloud eine Aufbewahrungsrichtlinie für den Bucket fest (und sperren Sie sie).
Variante B: gehärtetes Repository auf Ihrem eigenen Linux-Server
Auf einem eigenen Linux-Server läuft backupzit-repo (deb- und rpm-Pakete hängen an jedem GitHub-Release):
apt install ./backupzit-repo_*.deb # oder: dnf install ./backupzit-repo-*.rpm
vi /etc/backupzit-repo/repo.env # BACKUPZIT_REPO_LOCK_DAYS=30
systemctl start backupzit-repo
backupzit-repo add-key office-console # zeigt den Zugriffsschlüssel einmal an
backupzit-repo fingerprint # Fingerabdruck des Zertifikats
Fügen Sie in der Konsole ein Ziel vom Typ Gehärtetes Repository (backupzit-repo unter Linux, unveränderlich) mit der Serveradresse (Standardport 8500), dem Zugriffsschlüssel und dem Fingerabdruck hinzu.
- Agenten und Konsole können nur Dateien hinzufügen; vorhandene Dateien werden nie überschrieben.
- Jede Datei erhält das Attribut „unveränderlich“ (
chattr +i) für die auf diesem Server eingestellte Frist plus einen Tag. Nicht einmal root kann sie löschen, ohne das Attribut zuerst zu entfernen.
- Löschungen von Clients — durch die Aufbewahrung oder einen Angreifer mit dem Zugriffsschlüssel — verbergen Dateien nur, bis ihre Frist abläuft.
- Die Frist wird nur auf dem Repository-Server eingestellt; Konsole und Agenten können sie nicht ändern.
Schalten Sie nach der Einrichtung SSH und anderen Fernzugriff auf diesem Server ab und schützen Sie seine lokale Konsole, iDRAC/iLO oder den Hypervisor-Zugang: Der Schutz ist nur so stark wie sein root-Konto.
Schritt 3 — Verschlüsselung und Wiederherstellungsschlüssel
Lassen Sie Sicherungen verschlüsseln (AES-256) eingeschaltet (Standard). Dateiinhalte, Namen, Ordnerstruktur und Snapshot-Listen werden mit AES-256-GCM verschlüsselt, bevor sie den Agenten verlassen, und jede Änderung an den Daten wird erkannt. Unveränderlichkeit verhindert das Löschen, Verschlüsselung das Lesen — Sie brauchen beides.
Für jedes verschlüsselte Ziel zeigt die Konsole einen Wiederherstellungsschlüssel und bietet ein Wiederherstellungsblatt an. Bewahren Sie es offline und getrennt von den Sicherungen auf: Mit dem Schlüssel, dem Speicherort und dessen Zugangsdaten können Sie auch ohne Konsole wiederherstellen; ohne den Schlüssel kann niemand die Sicherungen lesen — auch nicht der BackupZit-Support.
Schritt 4 — Sicherungsauftrag und Aufbewahrung
Legen Sie den Auftrag unter Sicherungsaufträge mit dem primären Speicher aus Schritt 1 an. Unter Sicherungen behalten stellen Sie die neuesten N sowie tägliche, wöchentliche und monatliche Wiederherstellungspunkte ein — zum Beispiel halten 3 neueste, 7 tägliche, 4 wöchentliche und 6 monatliche etwa ein halbes Jahr mit rund 20 Wiederherstellungspunkten vor. Die Deduplizierung speichert unveränderte Daten nur einmal.
Wiederherstellungspunktziel (RPO), Stunden legt fest, wie alt die neueste gute Sicherung werden darf, z. B. 26 für einen täglichen Auftrag. Ein Auftrag, der es verfehlt, erscheint auf dem Dashboard und wird gemeldet — das erfasst auch einen Agenten, der tagelang offline ist, oder einen versehentlich entfernten Zeitplan.
Schritt 5 — Kopie außer Haus mit einem Kopierauftrag
Legen Sie einen zweiten Auftrag an und wählen Sie Sicherungskopie. Unter Die Sicherungen kopieren von wählen Sie den Auftrag aus Schritt 4 und als Speicherziel das unveränderliche Ziel oder das Ziel außer Haus aus Schritt 2.
- Der Agent des Quellauftrags kopiert die vorhandenen Sicherungen; die geschützte Maschine wird nicht erneut gelesen.
- Gesendet werden nur Daten, die am Ziel noch fehlen, neu verschlüsselt mit dem Schlüssel des Ziels.
- Nach jeder Sicherung des Quellauftrags (Standard) hält die Kopie aktuell; ein normaler Zeitplan geht auch, z. B. einmal pro Nacht bei einer langsamen Leitung.
- Die Kopie hat ihre eigene Aufbewahrung, z. B. 7 tägliche auf dem NAS und 12 monatliche in der Cloud. Jeder Wiederherstellungspunkt ist N Tage ab seiner Erstellung gesperrt; bei einer Sperre von 30 Tagen sind ältere monatliche Punkte also nicht mehr geschützt. Eine längere Sperre schützt mehr davon, belegt aber auch mehr Daten.
Datei- und VM-Sicherungen (Proxmox VE, Hyper-V, VMware) werden aus der Kopie wie aus dem Original wiederhergestellt, Kopien von Datenträgerabbildern mit dem Kommandozeilen-Agenten. Jetzt kopieren startet eine Kopie sofort.
Offline-Kopie für kleine Büros: Der Zieltyp Wechselnde USB- / Wechseldatenträger (Offline-Kopien) findet Datenträger an ihrer Volumebezeichnung (BZBACKUP1, BZBACKUP2 …). Richten Sie einen Kopierauftrag darauf, tauschen Sie die Datenträger z. B. wöchentlich und bewahren Sie den abgezogenen an einem sicheren Ort auf. Ist kein Datenträger angeschlossen, schlägt der Lauf mit einer Warnung fehl.
Schritt 6 — Wiederherstellungstests und Datenprüfung
Eine Sicherung ist erst bewiesen, wenn sie wiederhergestellt wurde. Unter Einstellungen → Wiederherstellungstests:
- Die neueste Sicherung jedes Jobs automatisch testen (standardmäßig wöchentlich): Eine zufällige Auswahl von Dateien aus der neuesten Sicherung wird in einen temporären Ordner wiederhergestellt, Byte für Byte gegen die gespeicherten Prüfsummen geprüft und wieder gelöscht; bei Datenträgerabbildern werden zufällige Blöcke geprüft. So werden Speicherzugriff, Zugangsdaten, Schlüssel und Daten getestet.
- Gespeicherte Daten prüfen (standardmäßig monatlich): Jedes Datenstück in jedem Repository wird gelesen und geprüft; so fallen eine sterbende NAS-Festplatte oder schleichender Datenverfall früh auf. Auf S3 und Azure läuft die Prüfung nur mit Auch auf Cloud-Speicher (S3, Azure) — sie lädt alles herunter, achten Sie auf die Downloadkosten.
- Proxmox-VM-Aufträge können einen Starttest ergänzen, der jede VM aus der Sicherung mit getrenntem Netzwerk startet.
Wiederherstellung testen und Daten prüfen auf der Seite eines Auftrags starten beides sofort. Ergebnisse erscheinen unter Aktivität und Berichte; ein fehlgeschlagener Test sendet wie jeder Fehler eine Warnung.
Schritt 7 — Warnungen und Ransomware-Erkennung
Eine Kopie außer Haus, die seit Wochen fehlschlägt, ist keine Kopie. Richten Sie Einstellungen → E-Mail-Benachrichtigungen ein (prüfen mit Test-E-Mail senden) und lassen Sie Fehler eingeschaltet: eine E-Mail pro fehlgeschlagenem Lauf mit dem Grund — Sicherungen, Kopien, Wiederherstellungen und Wiederherstellungstests — plus auf Wunsch ein Tagesbericht. Einstellungen → Chat und Webhooks sendet dasselbe an Slack, Microsoft Teams oder einen beliebigen HTTP-Endpunkt. Auf dem Dashboard listet Benötigt Aufmerksamkeit fehlgeschlagene Aufträge, verpasste Zeitpläne und RPOs, Agenten offline und Speicher, der zu 90 % voll ist oder in 30 Tagen voll sein wird.
Jede Sicherung wird außerdem mit dem jüngsten Verlauf ihres Auftrags verglichen. Sie wird als verdächtig markiert, wenn sich weit mehr Dateien als üblich geändert haben, neue Daten sich nicht mehr komprimieren lassen (verschlüsselte Dateien wirken zufällig), die Zahl der Dateien um ein Drittel oder mehr gefallen ist oder die Menge neuer Daten sprunghaft gestiegen ist. BackupZit sendet dann eine Warnung, führt sie unter zu prüfende verdächtige Sicherungen und pausiert die Aufbewahrung des Auftrags (Aufbewahrung ist pausiert), sodass die letzten sauberen Sicherungen nicht gelöscht werden, auch wenn weiter beschädigte kommen. Nach der Prüfung der Maschine klicken Sie Geprüft – Aufbewahrung fortsetzen.
Schritt 8 — Die Konsole schützen
Unveränderlicher Speicher schützt die Sicherungen; die Konsole entscheidet weiterhin, was gesichert und behalten wird. Verlangen Sie unter Einstellungen → Anmeldung & Sicherheit die Zwei-Faktor-Anmeldung für Administratoren und schalten Sie die Vier-Augen-Freigabe ein: Das Löschen von Aufträgen oder Speicherzielen, das Verkürzen der Aufbewahrung, das Fortsetzen der Aufbewahrung nach einer verdächtigen Sicherung und das Ausschalten der Freigabe brauchen dann einen zweiten Benutzer. Halten Sie die Konsole im internen Netz, veröffentlichen Sie Port 8443 nicht im Internet und nutzen Sie für die Fernverwaltung ein VPN. Mit Einstellungen → Konsolensicherung sichert sich die Konsole außerdem täglich selbst auf ein Netzwerk-Speicherziel.
Nach einem Angriff
Wurden Sicherungen gelöscht oder überschrieben, lesen Sie den Speicher so, wie er vor dem Angriff war — nur lesend, auf S3 mit Object Lock und auf dem gehärteten Repository:
backupzit-agent snapshots --repo <repository> --as-of 2026-10-01T14:30
backupzit-agent restore --repo <repository> --as-of 2026-10-01T14:30 --target D:\Restore latest
Auf einem gehärteten Repository kann der Administrator verborgene Dateien auch zurückholen, damit die Sicherungen normal weiterlaufen:
backupzit-repo status
backupzit-repo undelete --since 2026-10-01T14:00
Grenzen
- Unveränderlichkeit gilt nur für die Dauer der Sperre. Eine gelöschte Sicherung ist nach Ablauf ihrer Frist wirklich weg; wählen Sie die Frist also danach, wie lange ein Angriff unbemerkt bleiben könnte.
- Ein gehärtetes Repository ist nur so sicher wie sein root-Konto und der Zugang zu seiner Konsole, iDRAC/iLO oder seinem Hypervisor.
- SMB, SFTP und lokale Datenträger haben keine eigene Unveränderlichkeit; kombinieren Sie sie mit einer unveränderlichen oder Offline-Kopie.
- Gesperrte Daten belegen Platz, bis ihre Sperre endet, auch nach dem Löschen; ohne die Lifecycle-Regel wird S3-Speicher nicht frei.
- Unveränderlichkeit macht Daten nicht sauber: Dateien, die vor der Sicherung verschlüsselt wurden, werden verschlüsselt gesichert. Stellen Sie einen Punkt vor dem Angriff wieder her — die Erkennung hält diese Punkte vor, indem sie die Aufbewahrung pausiert.
- Ohne den Wiederherstellungsschlüssel kann niemand verschlüsselte Sicherungen lesen.
- Die Vier-Augen-Freigabe gilt in der Konsole; Administratorgruppen in Active Directory oder Entra ID müssen dort geschützt werden.
