Backup in der Cloud: 3-2-1-Regel, RPO/RTO und eine Kopie, die Ransomware nicht löschen kann

WebDisk Blog · Kategorie: Sicherheit · Lesezeit: ~9 Minuten

Kurz gefasst:- Dateisynchronisation ist kein Backup – sie repliziert auch die Schäden. Eine Sicherungskopie muss vom Original unabhängig und gegen einen einzigen unglücklichen Klick immun sein.- Die 3-2-1-Regel (drei Kopien, zwei verschiedene Medien, eine außerhalb des Standorts) gilt weiterhin; die Cloud schließt ihr schwierigstes Glied – die Kopie außerhalb des Unternehmens.- Ein Backup, das Sie nie testweise wiederhergestellt haben, ist eine Hypothese, keine Absicherung. Der Wiederherstellungstest wird ebenso ernsthaft geplant wie das Backup selbst.

Datenverlust kündigt sich selten an. Eine Festplatte verabschiedet sich ohne Vorwarnung, jemand überschreibt das einzige Exemplar eines Vertrags, und Ransomware verschlüsselt alles, was sie erreichen kann – samt der Netzwerkfreigaben. Für ein Unternehmen bedeutet das Stillstand, finanzielle Verluste, oft auch Reputationsschäden und mitunter sogar rechtliche Konsequenzen. Deshalb ist die Sicherungskopie keine Option mehr – sie ist das Fundament der IT-Sicherheit. Unter einer Bedingung: dass sie mit Verstand angelegt ist und nicht nach dem Motto „man muss ja irgendetwas haben“.

In diesem Artikel ordnen wir dieses Fundament: worin sich ein Backup von der Synchronisation unterscheidet, was die 3-2-1-Regel wirklich besagt, wie sich die Kürzel RPO und RTO in geschäftlich verständliche Entscheidungen übersetzen lassen, warum moderne Ransomware zuerst auf Sicherungskopien zielt – und warum der Wiederherstellungstest eine Pflicht ist und keine gute Praxis „für irgendwann“. Wir schreiben für ein gemischtes Publikum: Profitieren werden sowohl das Einzelunternehmen als auch das IT-Team, das einen Notfallplan aufstellt.

Synchronisation ist kein Backup (und RAID auch nicht)

Die häufigste Sicherheitsillusion lautet: „Ich habe alles in OneDrive/Dropbox, also habe ich ein Backup.“ Haben Sie nicht. Die Synchronisation tut genau das, was der Name verspricht: Sie hält überall denselben Stand. Wird eine Datei auf einem Gerät gelöscht, überschrieben oder von Ransomware verschlüsselt, fließt die Änderung gehorsam auf alle übrigen. Die in solche Dienste eingebaute Versionierung kann für ein einzelnes Dokument die Rettung sein, ist aber kein Wiederherstellungsplan für das Unternehmen – sie umfasst weder Systeme noch Datenbanken oder Konfigurationen und hat keine definierte Prozedur für die Rückkehr in den Betrieb.

Ähnlich RAID und lokale Snapshots: Sie schützen vor dem Ausfall einer einzelnen Festplatte, aber nicht vor menschlichem Fehler, Diebstahl der Hardware, einem Brand im Serverraum oder einem Angriff, der die gesamte Infrastruktur auf einmal erfasst.

Backup ist etwas anderes: eine separate, versionierte Kopie der Daten an einem anderen Ort, die automatisch nach Zeitplan erstellt wird, mit festgelegter Aufbewahrungsdauer und – am wichtigsten – mit einer Wiederherstellungsprozedur, die jemand geübt hat.

Die 3-2-1-Regel: drei Kopien, zwei Medien, eine außerhalb des Unternehmens

Die klassische Regel der Backup-Planung passt in drei Ziffern: Bewahren Sie drei Kopien der Daten auf (Produktion plus zwei Sicherungen), auf zwei verschiedenen Arten von Medien oder Systemen, davon eine außerhalb des Standorts, an dem das Unternehmen tätig ist. Die Logik ist einfach: Jedes Glied schützt vor einem anderen Szenario. Die zweite Kopie rettet beim Ausfall der ersten; ein anderes Medium – bei einem Defekt, der die gesamte Technologie gemeinsam betrifft; die Kopie außerhalb des Unternehmens – bei einem Ereignis, das den ganzen Standort zerstört: Brand, Überschwemmung, Diebstahl, einem Angriff auf das gesamte lokale Netzwerk.

Genau dieses letzte Glied war historisch das schwierigste – es erforderte den Transport von Bändern oder Festplatten an einen zweiten Standort. Backup in der Cloud schließt es auf natürliche Weise: Die Kopien gelangen automatisch in ein entferntes Rechenzentrum, ohne physische Medien und Logistik, und der Speicherplatz wächst mit dem Bedarf. Für Unternehmen, für die es eine Rolle spielt, wo die Daten physisch liegen, ist ein zusätzliches Argument oft eine in Polen betriebene Cloud – die Kopie liegt außerhalb des Unternehmens, aber weiterhin in einer vertrauten Jurisdiktion.

Ehrlicherweise muss man hinzufügen: Die Cloud ist eines der Glieder der 3-2-1-Regel, nicht ihr Ersatz. Eine Kopie ausschließlich in einer einzigen Cloud ist nach wie vor nur eine Kopie.

RPO und RTO verständlich erklärt: Wie viel Sie verlieren können und wie lange Sie stillstehen dürfen

Zwei Kürzel, die jedes Gespräch über Backup ordnen:

• RPO (Recovery Point Objective) – wie viele Daten Sie verlieren können, rückwärts gerechnet vom Ausfall. RPO ist in der Praxis die Antwort auf die Frage: „Wie alt darf die letzte Kopie sein, damit man damit leben kann?“ Ein Backup einmal täglich bedeutet ein RPO von 24 Stunden – im schlimmsten Fall geht ein ganzer Arbeitstag verloren.
• RTO (Recovery Time Objective) – wie lange das Unternehmen auf die Wiederherstellung warten kann, bevor der Stillstand wirklich wehtut. Das ist die Zeit von der Entscheidung „wir stellen wieder her“ bis zum erneuten Funktionieren des Systems.

Beide Werte werden pro System festgelegt, nicht einheitlich für das gesamte Unternehmen. Ein Dokumentenarchiv verkraftet ein RPO in Tagen; die Bestelldatenbank eines Onlineshops – eher in Stunden oder Minuten. Erst von diesen Zahlen aus beginnt die Wahl der Technik: die Häufigkeit der Kopien, inkrementelle Kopien (die nur die Änderungen seit der vorherigen Kopie speichern – wodurch häufiges Backup nicht bedeutet, alles von Grund auf neu zu übertragen), die Prioritäten der Wiederherstellung.

Und eine Sache, über die Werbematerialien selten sprechen: Je ambitionierter RPO und RTO, desto höher die Kosten – für häufigere Kopien, mehr Speicherplatz, eine schnellere Anbindung. Und das reale RTO lässt sich nicht einfach deklarieren: Die Wiederherstellung dauert so lange, wie es Datenvolumen und Bandbreite erlauben. Deshalb wird das RTO in Tests gemessen, nicht in eine Präsentation geschrieben.

Ransomware sucht zuerst nach den Sicherungskopien

Ein moderner Ransomware-Angriff beginnt selten mit der Verschlüsselung. Ein Angreifer, der Zugang zur Infrastruktur erlangt hat, sieht sich zunächst darin um – und spürt methodisch die Backups auf. Er löscht sie, verschlüsselt sie oder beschädigt sie im Stillen, denn er weiß, dass ein Unternehmen mit funktionierendem Backup kein Lösegeld zahlen wird. Erst danach verschlüsselt er die Produktionsumgebung.

Die Lehre aus Tausenden solcher Vorfälle: Eine Sicherungskopie, die sich mit denselben Berechtigungen löschen lässt, mit denen sie geschrieben wurde, ist kein Schutz vor Ransomware. Benötigt wird eine unveränderliche Kopie – gespeichert im Modus WORM (write once, read many – „einmal schreiben, viele Male lesen“) – eine Sperre, die für den festgelegten Zeitraum mit keiner Standardanfrage aufgehoben werden kann: weder von einem Angreifer mit gekapertem Administratorkonto noch von einem fehlbaren Skript noch von uns selbst an einem schlechten Tag. In der Welt der S3-Speicher setzt dies der Object-Lock-Mechanismus um – wir haben ihn ausführlich beschrieben im Artikel über S3 Object Lock (WORM).

Vorerst genügt es, sich das Prinzip zu merken: Das Backup-Repository sollte während der gesamten Aufbewahrungsfrist unveränderlich sein und der Zugriff darauf von den Konten getrennt, mit denen im Alltag die Produktion administriert wird. Im Dienst WebDisk Backup gelangen die Kopien in unseren S3-Objektspeicher.

Warum ist Object Storage ein gutes Ziel für Backups?

Wenn die Kopie außerhalb des Unternehmens liegen soll, muss sie irgendwo physisch hingelangen. Immer häufiger ist dieser Ort Object Storage – ein Objektspeicher mit S3-Schnittstelle, also einer Standard-API, die heute praktisch jedes Backup-Tool spricht. Er hat Eigenschaften, die außergewöhnlich gut zum Backup passen: Speicherplatz wird nach Bedarf hinzugekauft, ohne Vorabinvestition in ein Storage-Array, und Versionierung und Object Lock schützen vor Überschreiben und Löschen.

Mehr dazu finden Sie in unserem Artikel über Object Storage bei WebDisk; der Speicher ist auf Ceph aufgebaut, einer offenen Plattform für die Datenspeicherung, und über Standard-S3-Tools (s3cmd, aws CLI, boto3) zugänglich. Derselbe Speicher, der den Anwendungen dient, ist auch ein natürliches Ziel für Sicherungskopien.

Von der einzelnen Datei bis zum Disaster Recovery

Backup in der Cloud beschränkt sich nicht auf Dokumente. Dateibasierte Kopien schützen ausgewählte Verzeichnisse auf Windows-, Linux- und macOS-Systemen und ermöglichen es, eine einzelne Datei wiederherzustellen. Blockbasierte Kopien umfassen das gesamte Betriebssystem samt Konfiguration, Anwendungen und Datenbanken – und sie öffnen den Weg zum Disaster Recovery, also zum Notfallplan für die Wiederherstellung des Betriebs der IT-Systeme.

Disaster Recovery ist mehr Philosophie als Technologie. Es geht davon aus, dass der Ausfall mit Sicherheit eintritt – die Frage lautet nicht „ob?“, sondern „wann?“ – und legt deshalb im Voraus fest, welche Dienste in welcher Reihenfolge und wo wieder in Betrieb genommen werden. Backup in der Cloud ist hier mehr als ein Speicher für Kopien: Eine aus einer blockbasierten Kopie wiederhergestellte Umgebung lässt sich als virtuelle Maschine in der WebDisk Cloud starten – die wiederhergestellten Server kommunizieren über dieselben internen Adressen wie vor dem Ausfall. Das Unternehmen kann in der Cloud arbeiten, bevor es die eigene Infrastruktur wieder aufgebaut hat. Technisch ist das übrigens ein naher Verwandter der Migration einer Umgebung in die Cloud – nur eben unter Druck ausgeführt, weshalb es sich umso mehr lohnt, das Ganze vorher zu üben.

Der Wiederherstellungstest ist eine Pflicht, keine Option

Ein Backup, das nie jemand wiederhergestellt hat, kann sich genau in dem Moment als unbrauchbar erweisen, in dem es am dringendsten gebraucht wird – und dann ist es für Korrekturen bereits zu spät. Der grüne Status „Kopie erstellt“ sagt nur, dass etwas gespeichert wurde; er sagt nicht, dass man daraus zurückkehren kann. Ein minimaler, wiederholbarer Test sieht so aus:

1. Wählen Sie ein Szenario – eine einzelne Datei, eine Datenbank, ein ganzer Server. Testen Sie nacheinander alle, nicht nur das einfachste.
2. Stellen Sie in eine isolierte Umgebung wieder her, niemals in die Produktion – der Test darf nicht selbst einen Ausfall verursachen.
3. Messen Sie die Zeit vom Start bis zum funktionierenden Dienst. Das ist Ihr reales RTO – vergleichen Sie es mit Ihren Annahmen.
4. Prüfen Sie die Konsistenz: Das System startet, die Datenbank öffnet sich, die Anwendung meldet Benutzer an. „Die Dateien wurden kopiert“ ist zu wenig.
5. Dokumentieren Sie die Prozedur Schritt für Schritt und wiederholen Sie den Test regelmäßig (zum Beispiel vierteljährlich) sowie nach jeder wesentlichen Änderung der Infrastruktur.

Dieser Liste sollte man das Monitoring des Backups selbst hinzufügen: Eine Kopie, die stillschweigend nicht mehr erstellt wird, ist der heimtückischste Fehlermodus – alles sieht gut aus bis zu dem Tag, an dem etwas wiederhergestellt werden muss.

Was löst Backup in der Cloud nicht?

• Die Physik der Leitung. Die erste Vollsicherung und die vollständige Wiederherstellung einer großen Umgebung dauern so lange, wie es das Internet zulässt. Inkrementelle Kopien und Deduplizierung (das nur einmalige Speichern sich wiederholender Blöcke) entschärfen den Alltag, aber der Notfallplan muss die Zeit einer vollständigen Wiederherstellung einkalkulieren – daher der Wert einer Wiederherstellung direkt in der Cloud, nah an den Daten.
• Backup ist kein Archiv. Ein Backup dient der Wiederherstellung des aktuellen Stands; ein Archiv – der langjährigen Aufbewahrung gemäß gesetzlichen Anforderungen. Sie haben unterschiedliche Aufbewahrungsfristen und unterschiedliche Kosten; sie zu verwechseln führt entweder zu Lücken oder zu überhöhten Ausgaben.
• Unveränderlichkeit schützt die Integrität, nicht die Vertraulichkeit. Eine WORM-Kopie übersteht einen Angriff, aber ein Angreifer mit Zugriff kann die Daten lesen. Für die Vertraulichkeit sorgt die Verschlüsselung – bei der Übertragung und im Ruhezustand; bei WebDisk Backup werden die Kopien bereits an der Quelle verschlüsselt und bleiben im Speicher verschlüsselt.
• Die Cloud entbindet nicht von der 3-2-1-Regel. Eine Kopie in der Cloud ist ein Glied der Kette – kritische Daten sollten weiterhin mehr als eine Sicherungskopie haben.
• Technologie ersetzt keine Prozeduren. Zeitplan, Aufbewahrung, Monitoring der Ausführung und eine geübte Wiederherstellung sind ebenso wichtig wie der Speicher selbst – sie sind es, die ein Backup von einer Dateiablage unterscheiden.

Häufige Fragen

Reicht OneDrive oder Dropbox als Backup für ein Unternehmen aus? Nein. Die Synchronisation repliziert den aktuellen Stand – auch Löschungen und die Folgen von Ransomware. Die Versionierung in solchen Diensten rettet einzelne Dateien, stellt aber weder einen Server noch eine Datenbank oder Konfiguration wieder her und gibt keinerlei Garantien für die Zeit bis zur Wiederaufnahme des Betriebs.

Worin besteht die 3-2-1-Backup-Regel? Bewahren Sie drei Kopien der Daten auf (Produktion plus zwei Sicherungen), auf zwei verschiedenen Arten von Medien oder Systemen, davon eine außerhalb des Unternehmensstandorts. Jedes Glied schützt vor einem anderen Szenario – vom Ausfall eines einzelnen Geräts bis zu einem Ereignis, das den gesamten Standort zerstört. Backup in der Cloud schließt das letzte, historisch schwierigste Glied: die Kopie außerhalb des Unternehmens.

Was bedeuten RPO und RTO? RPO (Recovery Point Objective) sagt, wie viele Daten Sie verlieren können, rückwärts gerechnet vom Ausfall – ein Backup einmal täglich bedeutet ein RPO von 24 Stunden. RTO (Recovery Time Objective) ist die Zeit von der Entscheidung „wir stellen wieder her“ bis zum erneuten Funktionieren des Systems. Beide Werte werden für jedes System separat festgelegt, und das reale RTO erfährt man in Wiederherstellungstests, nicht aus Deklarationen.

Wie oft sollte man Sicherungskopien erstellen? So oft, wie es das RPO des jeweiligen Systems vorgibt: Wenn der Verlust von vier Arbeitsstunden akzeptabel ist, genügt ein Backup alle vier Stunden; wenn nicht – brauchen Sie häufigere inkrementelle Kopien. Beginnen Sie mit der geschäftlichen Frage „Wie viel können wir verlieren?“, nicht mit den Möglichkeiten des Tools.

Kann Ransomware auch das Backup in der Cloud verschlüsseln? Sie kann es versuchen – und wenn das Kopien-Repository eine gewöhnliche Ressource ist, die mit vollen Berechtigungen aus dem angegriffenen Netzwerk erreichbar ist, hat sie damit mitunter Erfolg. Deshalb sollte das Backup-Repository für die Dauer der Aufbewahrungsfrist unveränderlich (WORM) und von den alltäglichen Administrationskonten getrennt sein. Die Details des S3-Object-Lock-Mechanismus beschreiben wir in einem separaten Artikel im Blog.

Was kostet Backup in der Cloud? Dienste dieser Art arbeiten im Abonnementmodell – bezahlt wird monatlich für die geschützten Geräte und den gebuchten Speicherplatz, ohne Investitionen in eigene Bandbibliotheken oder Storage-Arrays. Die aktuellen Pläne und Preise von WebDisk Backup finden Sie auf der Seite des Dienstes.

Womit anfangen, wenn ich heute gar kein Backup habe? Mit einer Inventur: Was ist wirklich kritisch? Legen Sie RPO und RTO für die zwei bis drei wichtigsten Systeme fest, richten Sie für sie ein automatisches Backup an einen Standort außerhalb des Unternehmens ein – und führen Sie im ersten Monat einen Wiederherstellungstest durch. Ein getestetes Backup ist mehr wert als fünf ungetestete.

Zusammenfassung

Backup in der Cloud ist kein einzelnes Produkt, sondern eine Strategie: Die 3-2-1-Regel gibt die Architektur vor, RPO und RTO übersetzen sie in die Sprache des Business, ein unveränderliches Repository verteidigt die Kopien gegen Ransomware, und ein regelmäßiger Wiederherstellungstest verwandelt Hoffnung in eine erprobte Prozedur. Die Cloud schließt in dieser Strategie die schwierigsten Elemente – die Kopie außerhalb des Unternehmens und den Ort, an dem sich die Umgebung nach einem Ausfall wieder in Betrieb nehmen lässt.

Genau so haben wir WebDisk Backup gebaut: dateibasierte Kopien von Windows-, Linux- und macOS-Systemen, blockbasierte Kopien von Servern und virtuellen Maschinen sowie Backup von Kubernetes-Umgebungen, basierend auf Lösungen von Veeam, inkrementell und dedupliziert, an der Quelle verschlüsselt, gespeichert in unserem Object Storage – mit der Möglichkeit, die gesamte Umgebung wiederherzustellen: als virtuelle Maschinen in der WebDisk Cloud. Möchten Sie den Backup-Plan oder einen Wiederherstellungstest in Ihrer Organisation durchsprechen? Schreiben Sie uns.