Backup von S3 Content

Wir haben zunehmend Applikationen, die ihre Assets direkt auf S3 speichern und nicht mehr auf irgendwelchen File-Shares.

Braucht man denn da nun noch ein Backup dieser Daten, denn S3 ist ja multi-redundant, d.h. ein physikalischer Datenverlust ist nahezu ausgeschlossen … ?

Ja, man braucht ein Backup, denn auch User löschen versehentlich Daten oder die Applikation könnte einen Bug haben und versehentlich Daten löschen oder überschreiben.

Da die Datenmengen unserer betreuten Applikationen auf S3 recht hoch sind, macht ein stündliches oder nächtliches Script, welches die Daten auf einen anderen S3 Bucket synchronisiert/kopiert, nicht wirklich viel Freude.

Aktuell fahren wir da folgende Ansätze für ein Backup-Konzept von S3-Daten:

Versionierung:

Auf dem entsprechendem S3 Bucket wird Versionierung aktiviert. Dadurch wird beim Überschreiben einer Datei automatisch die alte Version versioniert. Auch beim Löschen einer Datei wird die gelöschte Datei versioniert. Aus diesen versionierten Daten kann man dann jederzeit über entsprechendes Scripting einen gewünschten Status der S3 Daten wider herstellen.

Zusätzlich kann man dann eine entsprechende Lifecycle Rule auf dem S3 Bucket definieren, die älterne Versionen löscht, die älter sind als X Tage. Leider kann man hier nicht definieren, dass man einfach nur die letzen X Versionen haben möchte …

Cross-Region-Replication (existiert seit dem 25.3.2015):

Zusätzlich zu der breits dargestellten Versionierung kann man nun definieren, dass die Inhalte eines S3 Buckets in einen anderen Bucket in einer anderen Region repliziert werden sollen. Dann hat man zum einen noch eine stets aktuelle Sicherung seines Ist-Datenzustands in einer anderen AWS-Region (just in case of ..) und man muss sich bei einem Überschreiben oder versehentlichen Löschen der Daten nicht mit dem Thema Herstellen aus einer Versionierung beschäftigen …

 

One thought on “Backup von S3 Content

  1. Zur Cross-Region-Replication: Warum genau muss man sich bei einem Überschreiben/Löschen dann nicht mit dem Herstellen aus einer Versionierung beschäftigen? Das basiert doch auch „nur“ wieder auf der Versionierung auf dem Ziel-Bucket, oder übersehe ich irgendwas?

    Wenn ich es richtig sehe, deckt das „nur“ folgende Fälle ab: (1) Versehentliches Löschen des Original-Bucket. Da hilft sonst auch keine Versionierung! (2) Man möchte die 0,000001% oder so Datenverlustwahrscheinlichkeit in einer AWS-Region abdecken. (3) Man ist aus Compliance-Gründen gezwungen, die Daten z. B. über mehrere Hundert km redundant zu speichern. (4) Man möchte sich gegen den Verlust des AWS-Accounts absichern (das Ziel-Bucket kann auch zu einem anderen AWS-Account gehören).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.