Was ist ein Offsite-Backup?
Ein Offsite-Backup ist eine wiederherstellbare Kopie, die außerhalb des primären Standorts oder der Ausfalldomäne der Produktionsumgebung aufbewahrt wird. Für ein kleines Büro kann das ein Backup in einem anderen Gebäude bedeuten; für einen Cloud-Workload eine andere Region, ein anderes Konto oder einen anderen Anbieter; für ein Homelab eine verschlüsselte Kopie auf einem entfernten Server, in Cloud-Speicher oder auf einer Wechselfestplatte, die anderswo aufbewahrt wird.
Offsite-Backup ist ein Teil der 3-2-1-Regel — das vollständige Framework finden Sie im Leitfaden zur 3-2-1-Backup-Regel.
Offsite bedeutet nicht automatisch sicher
Ein Backup kann Hunderte Kilometer entfernt liegen und trotzdem denselben Ausfallpfad teilen — Produktion und Backup nutzen dieselben Zugangsdaten, eine dauerhaft eingebundene Remote-Freigabe, Löschungen, die sofort synchronisiert werden, oder ein Verschlüsselungsschlüssel, der nur in der Produktion existiert.
Das britische National Cyber Security Centre (NCSC) stellt fest, dass Cloud- und On-Premises-Backups standardmäßig nicht ransomware-resistent sind. Backup-Dienste sollten destruktiven Aktionen widerstehen, den Zugriff bewahren, frühere Versionen schützen und Nutzer bei signifikanten Änderungen alarmieren.
Ein sinnvolles Offsite-Design trennt Standort, Speicher, Zugangsdaten und destruktive Berechtigungen.
Offsite vs. Cloud vs. Replikation vs. Offline
Diese verwandten Begriffe sind nicht austauschbar.
Replikation kopiert Änderungen kontinuierlich oder periodisch auf ein anderes System — nützlich für Verfügbarkeit, kann aber auch versehentliche Löschungen, beschädigte Daten oder Ransomware-Verschlüsselung mitkopieren. Eine entfernte Replik ohne unabhängige Aufbewahrung kann als Backup versagen; ein sinnvolles Offsite-Backup sollte Versionshistorie, Aufbewahrung und einen Weg zur Wiederherstellung eines früheren, sauberen Zeitpunkts bieten.
Ein Offsite-Backup wird an einem anderen Ort aufbewahrt; ein Offline-Backup ist im Normalbetrieb getrennt. Ein Backup kann jede Kombination der beiden sein — ein entfernter PBS-Server ist offsite und online, während extern gelagertes LTO-Tape offsite und offline ist.
Wichtigste Offsite-Backup-Optionen
AWS beschreibt Cloud-Speicher als dauerhaftes Offsite-Ziel für On-Premises-Backups und unterstützt Backup-Workflows über Objektspeicher und Storage-Gateways.
Wie weit entfernt sollte ein Offsite-Backup sein?
Es gibt keine universelle Entfernung. Die Kopie sollte weit genug entfernt sein, dass dasselbe wahrscheinliche physische Ereignis nicht beide Standorte betrifft — berücksichtigen Sie Hochwassergebiete, Waldbrandzonen, Stromnetze, Gebäudeeigentümerschaft, regionale Internetanbieter, Wettermuster und Cloud-Regionen.
Ein Backup im Nachbargebäude schützt möglicherweise vor Diebstahl des Servers, aber nicht vor einem größeren Brand oder Hochwasser. Ein Backup in einer anderen Region bietet stärkere geografische Trennung, erhöht aber Übertragungs- und Wiederherstellungszeit. Wählen Sie den Standort passend zu den Risiken, die Sie trennen möchten.
AWS empfiehlt, Backup-Kopien im Rahmen der Backup-Richtlinie wo sinnvoll in anderen Regionen und Konten zu speichern. Eine andere Region kann das geografische Risiko reduzieren; ein anderes Konto kann das administrative Risiko reduzieren. Die Kombination beider kann eine stärkere Trennung bieten.
Eine praktische Proxmox-Offsite-Architektur
Proxmox Backup Server unterstützt entfernte Server und Synchronisierungs-Jobs zum Kopieren von Datastores zwischen PBS-Installationen. Die Dokumentation empfiehlt eine Offsite-Instanz, da diese seltener von Ransomware betroffen ist, die im lokalen Netzwerk aktiv ist.
Pull- versus Push-Synchronisierung
Bei Pull-basierter Synchronisierung verbindet sich der Zielserver mit der Quelle und ruft die Daten ab — die Quelle benötigt keine umfassenden Löschrechte auf dem Ziel, was die Trennung destruktiver Berechtigungen erleichtern kann. Bei Push-basierter Synchronisierung sendet die Quelle die Daten an das Ziel, nützlich, wenn das Ziel keine Verbindungen initiieren kann. Unabhängig von der gewählten Richtung sollten Zugangsdaten auf die minimal nötigen Berechtigungen beschränkt werden.
Synchronisierte Löschung verhindern
Synchronisierung wird gefährlich, wenn eine Löschung an der Quelle automatisch Daten am Ziel entfernt — ein Angreifer, der die Quelle kontrolliert, könnte Snapshots löschen und abwarten, bis sich die Löschung fortpflanzt. Die Proxmox-Dokumentation weist darauf hin, dass sich die Synchronisierung so konfigurieren lässt, dass fehlende Quell-Snapshots nicht automatisch vom Ziel entfernt werden — das hilft zu verhindern, dass eine kompromittierte Quelle die Löschung von Offsite-Kopien auslöst. Das Offsite-Ziel sollte eine eigene Aufbewahrungsrichtlinie anwenden, statt die Quelle blind zu spiegeln.
Bandbreitenplanung und Übertragungsverzug
Offsite-Backup hängt von der Netzwerkkapazität ab. Schätzen Sie das initiale Datenvolumen, täglich geänderte Daten, das Backup-Fenster, verfügbare Upload-Bandbreite, Kompression, Deduplizierung und Protokoll-Overhead. Nutzen Sie den gemessenen Durchsatz statt der beworbenen Internetgeschwindigkeit.
Initiale Erstbefüllung
Die erste Offsite-Übertragung kann deutlich größer sein als die täglichen inkrementellen Änderungen. Optionen sind, die erste Übertragung über mehrere Tage laufen zu lassen, die Bandbreite vorübergehend zu erhöhen, die Erstkopie lokal durchzuführen, verschlüsselte Medien zu versenden oder zunächst nur kritische Workloads auszuwählen.
Übertragungsverzug kann eine versteckte RPO-Lücke schaffen
Das lokale Repository kann einen aktuellen Wiederherstellungspunkt haben, während das Offsite-Repository um mehrere Stunden zurückliegt — definieren Sie getrennte RPO-Erwartungen für lokale und Offsite-Wiederherstellung. Das zugrunde liegende Konzept erklärt der Leitfaden zu RPO vs. RTO.
Verschlüsselung, Identitätstrennung und Aufbewahrung
Offsite-Backup-Daten sollten normalerweise während der Übertragung, im Ruhezustand, auf Wechselmedien und in Cloud-Speicher verschlüsselt sein. Verschlüsselung schafft eine weitere Anforderung: die Wiederherstellung des Schlüssels. Bewahren Sie den einzigen Entschlüsselungsschlüssel nicht innerhalb der Umgebung auf, die das Backup wiederherstellen soll — testen Sie die Wiederherstellung mit der geschützten Kopie des Schlüssels.
Trennung von Identität und Zugangsdaten
Ein robustes Offsite-Backup sollte sich nicht vollständig auf die normale Produktionsidentität verlassen. Erwägen Sie separate Backup-Administratorkonten, separate Cloud-Konten mit Multi-Faktor-Authentifizierung, eingeschränkte Service-Konten und Warnungen bei Login- und Richtlinienänderungen. Das Konto, das Backups erstellt, benötigt nicht immer die Berechtigung, sie auch zu löschen.
Aufbewahrung am Offsite-Standort
Die Offsite-Kopie sollte eine bewusst festgelegte Aufbewahrungsrichtlinie haben und nicht nur den aktuellen lokalen Zustand duplizieren — das lokale Repository kann häufigere kurzfristige Backups vorhalten, während das Offsite-Repository weniger, aber länger zurückreichende Wiederherstellungspunkte behält. Das reduziert den Übertragungs- und Speicherbedarf und bewahrt gleichzeitig den Schutz vor spät entdeckten Incidents.
Unveränderlichkeit und Offsite-Backup lösen unterschiedliche Probleme
Offsite-Speicherung schützt vor dem Verlust des primären Standorts. Unveränderlichkeit schützt Wiederherstellungspunkte während eines festgelegten Zeitraums vor Löschung oder Änderung. Ein entferntes Online-Backup kann trotzdem gelöscht werden; ein unveränderliches lokales Backup kann trotzdem mit dem Gebäude verloren gehen. Die Kombination aus Offsite-Platzierung mit unveränderlicher oder Offline-Aufbewahrung bietet stärkeren Schutz.
Monitoring und Testen einer Offsite-Wiederherstellung
Überwachen Sie mehr als den bloßen Job-Abschluss — letztes erfolgreiches lokales Backup, letzte erfolgreiche Offsite-Übertragung, Übertragungsverzug, Remote-Verifizierungsstatus, Repository-Kapazität, Änderungen an der Aufbewahrung, Löschversuche und ablaufende Zugangsdaten. Eine Offsite-Kopie kann wochenlang unbemerkt aufhören zu aktualisieren, wenn der Verzug nicht überwacht wird — alarmieren Sie, wenn der neueste entfernte Wiederherstellungspunkt das genehmigte Alter überschreitet.
CISA empfiehlt, offline verschlüsselte Backups zu pflegen und ihre Verfügbarkeit und Integrität regelmäßig in einem Notfallwiederherstellungsszenario zu testen.
Ein Offsite-Wiederherstellungstest sollte davon ausgehen, dass lokale Ressourcen nicht verfügbar sind — testen Sie Zugriff auf das Repository, Notfall-Zugangsdaten, Verschlüsselungsschlüssel, Anbieterzugriff, Ersatzinfrastruktur und die Wiederherstellungsdauer. Testen Sie nicht nur, indem Sie eine kleine Datei aus dem lokalen Büro herunterladen — testen Sie den Wiederherstellungspfad, den Sie nach einem Standortverlust tatsächlich nutzen würden.
Große Datenmengen wiederherstellen
Ein großes Offsite-Backup kann Tage zum Herunterladen benötigen. Berücksichtigen Sie die verfügbare Bandbreite am Ziel, die Abrufgeschwindigkeit des Anbieters, beschleunigte Abrufoptionen, den Export auf physische Medien und den minimal funktionsfähigen Dienst — stellen Sie zuerst die wichtigsten Systeme wieder her.
Das richtige Offsite-Backup-Ziel wählen
Das Wiederherstellungsszenario definieren
Legen Sie fest, ob die Kopie vor Serververlust, Standortverlust, Ransomware, kompromittierten Administratoren oder langfristigen Aufbewahrungsanforderungen schützen muss.
RPO und RTO definieren
Bestimmen Sie das maximal akzeptable Alter der Offsite-Kopie, die maximal akzeptable Wiederherstellungszeit und das minimal nötige Datenvolumen.
Daten und Änderungsrate messen
Erfassen Sie die initiale Datengröße, täglich geänderte Daten, die Wachstumsrate und das Potenzial für Kompression/Deduplizierung.
Gesamtkosten vergleichen
Berücksichtigen Sie Speicher, Requests, Abruf, Egress, Hardware, Strom, Konnektivität, Support, Medientransport und Personalzeit — nicht nur den beworbenen Preis pro Terabyte.
Sicherheitsmaßnahmen überprüfen
Bestätigen Sie Verschlüsselung, Multi-Faktor-Authentifizierung, separate Konten, Aufbewahrungssperre, Löschschutz, Audit-Logs und Notfallwiederherstellung.
Wiederherstellung testen
Führen Sie einen repräsentativen Restore durch, bevor Sie das Ziel als produktionsbereit betrachten.
Ein praktisches Beispiel für Homelab und Kleinunternehmen
Ein Homelab kann Familienfotos, Dokumente, Passwort-Manager-Daten und Konfiguration für den Offsite-Schutz priorisieren und wiederherstellbare Medienbibliotheken sowie Test-VMs nur lokal belassen. Ein Plan für ein Kleinunternehmen sollte festlegen, welche Systeme offsite gesichert werden, welche maximale Übertragungsverzögerung akzeptabel ist, die Mindestaufbewahrung, den Wiederherstellungsstandort und die Löschbefugnis.
Häufige Offsite-Backup-Fehler
Ein NAS im selben Raum teilt dieselben physischen Risiken. Verschieben Sie eine Kopie in eine andere Ausfalldomäne.
Ein kompromittiertes Konto kann Produktions- und Backup-Kopien löschen. Trennen Sie Identitäten und Berechtigungen.
Erreichbarer Netzwerkspeicher kann von Malware verschlüsselt oder gelöscht werden. Beschränken Sie Konnektivität und destruktiven Zugriff.
Eine Löschung an der Quelle kann entfernte Wiederherstellungspunkte entfernen. Nutzen Sie unabhängige Aufbewahrungs- und Löschkontrollen.
Das lokale Backup kann aktuell sein, während die Offsite-Kopie Tage alt ist. Überwachen Sie das Alter der Wiederherstellungspunkte.
Abruf, Egress, Requests und Support können die Wiederherstellungskosten dominieren. Berechnen Sie die vollständigen Lifecycle-Kosten.
Ein Test mit einer Ein-Megabyte-Datei beweist nicht, dass eine Zehn-Terabyte-Umgebung innerhalb des RTO wiederhergestellt werden kann. Testen Sie in repräsentativem Umfang.
Das verschlüsselte Offsite-Backup wird nach einem Standortverlust unbenutzbar. Schützen Sie Schlüssel unabhängig.
Entfernter Speicher kann trotzdem eine sofortige Löschung erlauben. Ergänzen Sie, wo nötig, unveränderlichen oder Offline-Schutz.
Große, ersetzbare Datensätze können Bandbreite und Budget verbrauchen, die für kritische Daten benötigt werden. Klassifizieren Sie Workloads.
Daten können überleben, während Netzwerk-, Hypervisor-, Firewall- und Anwendungseinstellungen verloren gehen. Sichern Sie auch die Wiederherstellungsdokumentation.
Anbieterausfälle, Kontosperrungen oder kommerzielle Änderungen können die Wiederherstellung beeinträchtigen. Verstehen Sie die Exportoptionen und führen Sie unabhängige Dokumentation.
Offsite-Backup-Checkliste
0 / 30Häufig gestellte Fragen
Ein Offsite-Backup ist eine wiederherstellbare Kopie, die außerhalb des primären physischen Standorts oder der Infrastruktur-Ausfalldomäne aufbewahrt wird.
Es schützt Wiederherstellungsdaten, wenn Produktion und lokale Backups vom selben Incident betroffen sind, etwa durch Feuer, Diebstahl, Überschwemmung, Ransomware oder Standortverlust.
Ja, Cloud-Backup kann eine Offsite-Kopie bereitstellen. Cloud-Speicher sollte trotzdem hinsichtlich Aufbewahrung, Löschschutz, Zugangsdaten, Kosten und Restore-Performance bewertet werden.
Das kann der Fall sein, wenn es sich in einer anderen Ausfalldomäne befindet und über geeignete Zugriffskontrollen, Aufbewahrung, Monitoring und Restore-Tests verfügt.
Nein. Ein entferntes Online-Repository kann über kompromittierte Zugangsdaten oder Synchronisierung weiterhin erreichbar sein. Ergänzen Sie Kontotrennung, eingeschränkte Löschrechte, Unveränderlichkeit oder Offline-Medien.
Es sollte weit genug entfernt sein, dass derselbe wahrscheinliche physische Incident nicht beide Standorte betrifft. Die passende Entfernung hängt von lokalen Risiken und Wiederherstellungsanforderungen ab.
Der Zeitplan sollte sich am erforderlichen Offsite-RPO, der verfügbaren Bandbreite, der Datenänderungsrate und der Bedeutung des Workloads orientieren.
Nicht zwangsläufig. Lokaler Speicher kann häufige, aktuelle Backups vorhalten, während Offsite-Speicher weniger, aber länger zurückreichende Wiederherstellungspunkte behält.
Ja. Ein entfernter Proxmox Backup Server kann Backup-Daten zwischen PBS-Installationen synchronisieren. Berechtigungen, Löschverhalten, Verifizierung und die Remote-Aufbewahrung sollten sorgfältig konfiguriert werden.
Beide Modelle können geeignet sein. Pull-basierte Synchronisierung kann helfen, die Kontrolle der Quelle über das Ziel einzuschränken, während Push sich für Netzwerkumgebungen eignet, die ausgehende Verbindungen leichter zulassen.
Ja, wenn das Tape transportiert und außerhalb des primären Standorts gelagert wird. Es sollte verschlüsselt, inventarisiert, abrufbar und regelmäßig getestet sein.
Sie können sich für kleine Umgebungen eignen, wenn die Festplatten verschlüsselt, konsequent rotiert, nach Gebrauch getrennt und sicher an einem anderen Ort aufbewahrt werden.
Stellen Sie repräsentative Daten oder komplette Systeme wieder her und gehen Sie dabei davon aus, dass das lokale Repository nicht verfügbar ist. Validieren Sie Zugriff, Schlüssel, Infrastruktur, Anwendungen, RPO und RTO.
Priorisieren Sie unersetzliche Daten, Identität, Datenbanken, Konfiguration, Zugangsdaten, Geschäftsunterlagen und Systeme, die für die minimal funktionsfähige Wiederherstellung nötig sind.
Bauen Sie einen weiteren Wiederherstellungspfad auf
Der Wert eines Offsite-Backups liegt in seiner Unabhängigkeit — die Kopie sollte nicht vollständig von demselben Gebäude, derselben Speicher-Hardware, demselben Administratorkonto, derselben Identitätsplattform oder Löschrichtlinie wie die Produktion abhängen.
Beginnen Sie mit den Systemen, die sich am schwersten neu aufbauen ließen. Erstellen Sie ein lokales Backup für schnelle Wiederherstellung, senden Sie eine weitere Kopie an ein wirklich getrenntes Ziel, schützen Sie es vor destruktivem Zugriff und überwachen Sie, wie weit es zurückliegt. Stellen Sie dann aus dieser Kopie wieder her, ohne das lokale Repository zu nutzen — ein Offsite-Backup wird erst dann vertrauenswürdig, wenn es die Trennung überstanden, die erforderliche Historie bewahrt und einen nutzbaren Dienst innerhalb der geforderten Zeit wiederhergestellt hat.