Einführung
Das Hochladen eines Entwurfs auf den Berichtsschlüssel eines Finance-Teams würde den freigegebenen Inhalt ersetzen, den Leser sehen. Du aktivierst die Versionierung, reproduzierst diesen Fehler, stellst den freigegebenen Inhalt wieder her und entfernst den Übungsverlauf nach der Wiederherstellungsprüfung.
Schließe zuerst Dokumente mit Schlüsseln und Metadaten organisieren ab, um Objektschlüssel, Eigenschaften, Downloads und Bereinigung kennenzulernen. Diese neue VM stellt die CLI-Verbindung sowie freigegebene Dateien und Entwürfe bereit; den Bucket erstellst du selbst. Verwende Terminal für Befehle und den Tab AWS View daneben, um aktuelle Objekte mit ihrem Verlauf zu vergleichen.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 1.3: S3-Versionsverlauf, Löschmarkierungen und Datenwiederherstellung.
- Developer – Associate (DVA-C02) · Aufgabe 1.3: S3-Versionsverlauf, Löschmarkierungen und Datenwiederherstellung.
- CloudOps Engineer – Associate (SOA-C03) · Aufgabe 2.3: S3-Versionsverlauf, Löschmarkierungen und Datenwiederherstellung.
- Security – Specialty (SCS-C03) · Aufgabe 5.2: Grundlagenübung: S3-Versionsverlauf, Löschmarkierungen und Datenwiederherstellung.
- Data Engineer – Associate (DEA-C01) · Aufgabe 2.3: Grundlagenübung: S3-Versionsverlauf, Löschmarkierungen und Datenwiederherstellung.
Aktiviere die Versionierung vor der Veröffentlichung
In diesem Schritt erstellst du einen leeren Bucket und aktivierst die Versionierung, bevor ein Bericht hochgeladen wird.
Wechsle mit cd (change directory, Verzeichnis wechseln) in den Arbeitsbereich:
cd /home/labex/project
Erstelle den Berichts-Bucket mit mb (make bucket, Bucket erstellen):
aws s3 mb s3://labex-report-history
Du solltest make_bucket: labex-report-history sehen. Versionierung ist eine Bucket-Einstellung: Nach ihrer Aktivierung erzeugen weitere Schreibvorgänge auf einen Schlüssel Versions-IDs, statt seinen zuvor gespeicherten Inhalt zu verwerfen. Dies ist hilfreich zur Wiederherstellung nach versehentlichem Überschreiben, verhindert aber nicht, dass jemand ausdrücklich eine bestimmte Version löscht.
aws s3api stellt einzelne S3-API-Operationen bereit. put-bucket-versioning aktualisiert diese Einstellung; --bucket identifiziert den Behälter und --versioning-configuration Status=Enabled fordert den aktivierten Zustand an:
aws s3api put-bucket-versioning --bucket labex-report-history --versioning-configuration Status=Enabled
Die erfolgreiche Aktualisierung gibt keinen Antwortinhalt aus. Lies die Konfiguration zurück, statt dich allein auf die fehlende Ausgabe zu verlassen:
aws s3api get-bucket-versioning --bucket labex-report-history
{
"Status": "Enabled"
}
AWS View zeigt jetzt Versioning: Enabled am Bucket. Er ist weiterhin leer: Die Aktivierung der Versionierung lädt keinen Bericht hoch und erstellt keine historische Version. Aktiviere die Einstellung, bevor die zu schützenden Daten geschrieben werden.
Erstelle eine ursprüngliche und eine überschriebene Version
In diesem Schritt veröffentlichst du einen freigegebenen Bericht und überschreibst dann seinen aktuellen Inhalt mit einem Entwurf, während das Original im Verlauf erhalten bleibt.
Untersuche die vorbereiteten Dateien mit cat, das ihren Inhalt ausgibt:
cat report-approved.txt
Monthly revenue: 42000
cat report-draft.txt
Monthly revenue: 00000
Veröffentliche die freigegebene Datei unter dem Schlüssel report.txt. Der Quelldateiname und Objektschlüssel können unterschiedlich sein:
aws s3 cp report-approved.txt s3://labex-report-history/report.txt
Öffne report.txt in AWS View und bestätige den freigegebenen Umsatz. Der Verlauf enthält eine Version, die als Current gekennzeichnet ist.
Reproduziere jetzt den Fehler: Lade den Entwurf auf denselben Schlüssel hoch:
aws s3 cp report-draft.txt s3://labex-report-history/report.txt
Die Vorschau ändert sich auf Monthly revenue: 00000. Es gibt weiterhin einen aktuellen Objektschlüssel, aber sein Verlauf hat jetzt zwei gespeicherte Versionen. Beide Dateien haben dieselbe Größe; die Versionierung verfolgt Schreibvorgänge, statt Änderungen nur aus ihrer Größe abzuleiten.
list-object-versions ruft historische Datensätze sowie die aktuelle Version ab:
aws s3api list-object-versions --bucket labex-report-history
Das Array Versions enthält zwei Einträge mit dem Schlüssel report.txt und unterschiedlichen Werten für VersionId. IsLatest: true kennzeichnet den Entwurf als aktuell; die frühere freigegebene Version hat IsLatest: false. IDs und Zeitstempel variieren. Eine normale Objektliste zeigt aktuelle Schlüssel, deshalb verwende die Versionsliste bei der Untersuchung eines Überschreibens.
In der offiziellen S3 Console macht Show versions diese Verlaufseinträge in der Objektliste sichtbar. Dieses Beispiel zeigt ein anderes Objekt und mehr Schreibvorgänge; nutze es, um die Spalte Version ID zu erkennen. Für dieses Lab ist keine Console-Anmeldung erforderlich.
Quelle: AWS Storage Blog.
Rufe die freigegebene Version ab und veröffentliche sie
In diesem Schritt lädst du die frühere freigegebene Version herunter, prüfst ihre Bytes und machst diese Inhalte wieder aktuell, ohne den Verlauf zu löschen.
Zu diesem Zeitpunkt gibt es genau zwei Versionen von report.txt. Suche in der vorherigen Liste den Eintrag mit IsLatest: false: Er ist das freigegebene Original. Kopiere seine VersionId.
Speichere diese ID in einer Shell-Variablen, damit du sie wiederverwenden kannst. Ersetze unten PASTE_APPROVED_VERSION_ID durch den kopierten Wert und behalte die Anführungszeichen bei. Eine Variablenzuweisung enthält keine Leerzeichen um =:
OLD_VERSION='PASTE_APPROVED_VERSION_ID'
Prüfe den Wert, bevor du ihn verwendest:
echo "$OLD_VERSION"
Du solltest die ID der früheren Version sehen und nicht den Platzhalter. $OLD_VERSION liest die Variable; doppelte Anführungszeichen halten den Wert als ein Befehlsargument zusammen.
get-object lädt den Inhalt eines Objekts auf den abschließenden lokalen Pfad herunter. --version-id wählt die historische Kopie statt des aktuellen Entwurfs aus:
aws s3api get-object --bucket labex-report-history --key report.txt --version-id "$OLD_VERSION" recovered-report.txt
Die JSON-Ausgabe beschreibt die abgerufene Kopie. Lies ihren Inhalt:
cat recovered-report.txt
Monthly revenue: 42000
cmp vergleicht Dateibytes. && führt die folgende Meldung nur aus, wenn der Vergleich erfolgreich ist:
cmp report-approved.txt recovered-report.txt && echo 'Approved historical content verified'
Das Abrufen einer älteren Version macht sie nicht aktuell; Leser des Schlüssels ohne Versionsangabe erhalten weiterhin den Entwurf. Veröffentliche die wiederhergestellten Bytes auf diesen Schlüssel:
aws s3 cp recovered-report.txt s3://labex-report-history/report.txt
Dies erstellt eine dritte Version mit dem freigegebenen Bericht. Die alte freigegebene Version und der Entwurf bleiben beide zur Untersuchung erhalten. AWS View zeigt den freigegebenen Inhalt als aktuell und drei Versionsdatensätze. Liste den Verlauf zur Bestätigung auf:
aws s3api list-object-versions --bucket labex-report-history
Der neue Eintrag hat IsLatest: true. Du hast die Daten durch das Schreiben einer neuen aktuellen Version wiederhergestellt, statt den Nachweis des Fehlers zu löschen.
Dieses Beispiel zeigt den wiederhergestellten Bericht als aktuell und drei unterschiedliche Verlaufseinträge. Die gezeigten Versions-IDs sind Beispiele aus jener Sitzung:
Stelle den Zugriff nach einem Löschmarker wieder her
In diesem Schritt beobachtest du, wie ein Löschmarker ein versioniertes Objekt verbirgt, und entfernst dann diesen Marker, um die vorherige aktuelle Version sichtbar zu machen.
Schematische Darstellung: Eine Löschung ergänzt einen aktuellen Marker, während die drei gespeicherten Berichtsversionen erhalten bleiben. Die Kennzeichnungen v1–v3 geben die Schreibreihenfolge an und keine tatsächlichen Versions-IDs.
In einem Bucket mit aktivierter Versionierung erstellt eine Löschanfrage ohne Versions-ID einen Löschmarker. Dies ist ein aktueller Verlaufseintrag, der den Schlüssel als gelöscht kennzeichnet; er enthält keine Dateibytes und löscht die älteren Versionen nicht. Lösche den aktuellen Schlüssel mit dem üblichen Dateibefehl:
aws s3 rm s3://labex-report-history/report.txt
Eine normale Liste zeigt jetzt keine aktuellen Objekte:
aws s3 ls s3://labex-report-history/
In AWS View verschwindet das aktuelle Objekt, während drei Version-Zeilen und ein aktueller Delete marker im Verlauf erhalten bleiben.
Versuche, den Schlüssel herunterzuladen, ohne eine Version auszuwählen:
aws s3 cp s3://labex-report-history/report.txt unavailable-report.txt
Dieser Befehl soll fehlschlagen, mit einem Fehler wegen eines nicht gefundenen Objekts. Durch den aktuellen Löschmarker verhält sich ein gewöhnlicher Lesezugriff so, als wäre das Objekt nicht vorhanden. Dies beweist nicht, dass die historischen Bytes gelöscht wurden.
Lies den vollständigen Verlauf:
aws s3api list-object-versions --bucket labex-report-history
Die Antwort enthält jetzt sowohl DeleteMarkers als auch Versions. Suche den einzelnen Eintrag in DeleteMarkers und kopiere seine VersionId. Diese ID identifiziert den Marker und keinen gespeicherten Bericht.
Ersetze den Platzhalter unten durch diese Marker-ID:
MARKER_VERSION='PASTE_DELETE_MARKER_ID'
Entferne genau diesen Marker mit delete-object. Die Angabe von --version-id löscht den ausgewählten Verlaufseintrag, statt einen weiteren Marker zu erstellen:
aws s3api delete-object --bucket labex-report-history --key report.txt --version-id "$MARKER_VERSION"
Die Antwort identifiziert den gelöschten Marker. Die vorherige freigegebene Version wird wieder aktuell; diese Operation lädt keine weitere Berichtsversion hoch. Bestätige den gewöhnlichen Zugriff, indem du den Schlüssel herunterlädst:
aws s3 cp s3://labex-report-history/report.txt accessible-report.txt
cmp report-approved.txt accessible-report.txt && echo 'Current report accessible again'
Der Vergleich ist erfolgreich. AWS View zeigt report.txt wieder mit dem freigegebenen Inhalt und drei Versionen. Das Entfernen eines Markers stellt den Zugriff wieder her; das dauerhafte Löschen einer Datenversion würde dagegen diese bestimmte Kopie löschen.
Entferne historische Versionen und den Bucket
In diesem Schritt entfernst du alle Datenversionen des Labs, bevor du den leeren Bucket löschst.
Versionsverlauf belegt Speicher, selbst wenn eine normale Objektliste leer ist. Ein einfaches aws s3 rm würde einen weiteren Löschmarker erstellen und reicht deshalb nicht aus, um einen versionierten Bucket zu leeren. Der Marker aus dem vorherigen Schritt wurde bereits entfernt; die drei Datenversionen bleiben erhalten.
Liste den Verlauf vor der dauerhaften Bereinigung auf:
aws s3api list-object-versions --bucket labex-report-history
Du solltest drei Einträge in Versions und keine DeleteMarkers sehen. Alle Einträge gehören zu dieser entbehrlichen Berichtsübung.
Alle drei Einträge gehören zu report.txt. Du hast bereits delete-object --version-id verwendet, um einen Marker zu entfernen; dieselbe Operation kann eine Datenversion dauerhaft entfernen.
Kopiere eine VersionId aus der Liste und ersetze den Platzhalter unten. Führe diesen Befehl einmal für jede der drei unterschiedlichen IDs aus. Eine dauerhafte Löschung kann nicht rückgängig gemacht werden, prüfe daher jedes Mal Bucket, Schlüssel und ID:
aws s3api delete-object --bucket labex-report-history --key report.txt --version-id 'PASTE_VERSION_ID'
Eine erfolgreiche Antwort identifiziert die gelöschte Version. Eine Versions-ID wählt eine historische Kopie aus; sie löscht nicht alle Versionen des Schlüssels. Bestätige nach dem Entfernen aller drei, dass keine Versionen oder Marker übrig sind:
aws s3api list-object-versions --bucket labex-report-history
Die erfolgreiche Antwort enthält keine Einträge für Versions oder DeleteMarkers. Entferne jetzt den leeren Bucket mit rb:
aws s3 rb s3://labex-report-history
Die Ausgabe lautet remove_bucket: labex-report-history. Bestätige, dass der Speicher weiterhin antwortet:
aws s3 ls
Es bleiben keine Buckets übrig und AWS View zeigt No buckets. Lokale Berichtsdateien bleiben verfügbar; nur die S3-Ressourcen dieses Labs und ihr Verlauf wurden entfernt.
Zusammenfassung
Du hast vor der Veröffentlichung die Bucket-Versionierung aktiviert, einen aktuellen Schlüssel von seinen historischen Versions-IDs unterschieden und einen überschriebenen Bericht wiederhergestellt, indem du eine frühere Version abgerufen und ihre geprüften Bytes veröffentlicht hast. Anschließend hast du einen Löschmarker erstellt und entfernt, um den gewöhnlichen Zugriff wiederherzustellen, ohne eine weitere Version hochzuladen.
Versionierung erhält den Verlauf; sie macht eine ausdrückliche Versionslöschung nicht umkehrbar. Zum Abschluss hast du alle Versionen des Labs untersucht und dauerhaft gelöscht, bestätigt, dass keine Marker übrig waren, und den leeren Bucket entfernt.
