Blobdaten müssen wiederherstellbar und kosteneffizient sein? Versionierung, Soft Delete, Lifecycle und Inventory konfigurieren

Veröffentlicht am:

CloudTrips benötigt Schutz vor versehentlichem Überschreiben und Löschen, ohne jede alte Kopie dauerhaft im teuren Hot-Tier zu behalten. Versionierung bewahrt die Änderungshistorie, Soft Delete bietet ein Wiederherstellungsfenster, Lifecycle Management automatisiert Tiering und Löschen und Inventory beschreibt die gespeicherten Objekte.

Versionierung → behält frühere Blobversionen nach dem Überschreiben
Soft Delete   → behält gelöschte Blobs und Versionen für einen Zeitraum
Lifecycle     → verschiebt oder löscht Daten nach Altersbedingungen
Inventory     → geplanter CSV- oder Parquet-Bericht über gespeicherte Objekte

Schutz erhöht die gespeicherte Kapazität und damit die Kosten. Die Lifecycle-Richtlinie liefert den passenden Kostenkontrollmechanismus.

Storage Account erstellen

Suche nach Storage accounts, wähle Create und trage ein:

Subscription: CloudTrips TEST
Resource group: Create new → rg-cloudtrips-blob-protection-test-weu
Storage account name: stctprotectdmytrotest
Region: West Europe
Performance: Standard
Redundancy: Locally-redundant storage (LRS)

Lasse Hierarchical namespace deaktiviert, da Blobversionierung für Accounts mit hierarchischem Namespace nicht verfügbar ist. Wähle Review + create > Create.

Storage-Account-Übersicht mit Blob-Protection-Testaccount und LRS-Konfiguration

Versionierung und Soft Delete aktivieren

Öffne den Storage Account und wähle Data management > Data protection. Konfiguriere und speichere:

Enable versioning for blobs: Enabled
Enable soft delete for blobs: Enabled
Blob retention period: 14 days
Enable soft delete for containers: Enabled
Container retention period: 14 days

Versionierung besitzt keine feste Aufbewahrungszeit: Frühere Versionen bleiben, bis sie explizit gelöscht oder von einer Lifecycle-Regel entfernt werden. Soft Delete hält ein gelöschtes Blob oder eine Version 14 Tage vor der endgültigen Löschung. Container Soft Delete schützt zusätzlich vor dem Löschen des gesamten Containers.

Data-protection-Seite mit Blobversionierung und 14-tägigem Blob- und Container-Soft-Delete

Container und zwei Blobversionen erstellen

Erstelle unter Data storage > Containers zwei private Container:

documents
inventory-reports

Erstelle lokal Version 1:

printf 'CloudTrips policy version 1\n' > cloudtrips-policy.txt

Öffne documents, wähle Upload und lade cloudtrips-policy.txt hoch. Ersetze danach den lokalen Inhalt:

printf 'CloudTrips policy version 2\n' > cloudtrips-policy.txt

Lade denselben Dateinamen erneut hoch und erlaube das Überschreiben des Ziel-Blobs. Azure macht Version 2 aktuell und behält Version 1 als frühere Version.

Öffne das Blob und wähle Versions. Version 2 bleibt das aktuelle Blob im Container, während diese Ansicht die beibehaltene Version 1 auflistet. Ein Eintrag nach einmaligem Überschreiben ist daher korrekt.

Blob-Versionsansicht mit der nach dem Überschreiben des aktuellen Blobs beibehaltenen früheren Version

Jeder Schreibvorgang erzeugt eine weitere kostenpflichtige Version. Versionierung schützt Historie, doch eine aktive Anwendung benötigt eine Lifecycle-Regel gegen unbegrenztes Wachstum.

Gelöschtes Blob wiederherstellen

Lösche cloudtrips-policy.txt. Aktiviere im Container Show deleted blobs und öffne das gelöschte Blob. Da Versionierung aktiv ist, erzeugt das reine Wiederherstellen gelöschter Versionen keine aktuelle Version. Öffne Versions, wähle die Version mit CloudTrips policy version 2 und dann Make current version.

Öffne oder lade das wiederhergestellte Blob herunter und bestätige den Inhalt:

CloudTrips policy version 2

Wurde eine Version selbst soft-gelöscht, wähle zuerst Undelete und fördere danach die benötigte Version. Soft Delete stellt wiederherstellbare Versionen her; Make current version bestimmt, welche zum aktiven Blob wird.

Durch Hochstufen der benötigten gespeicherten Version wiederhergestelltes Blob

Lifecycle Management konfigurieren

Wähle Data management > Lifecycle management > List view > Add a rule und konfiguriere:

Rule name: manage-document-history
Rule scope: Limit blobs with filters
Blob type: Block blobs
Blob subtype: Base blobs, Versions

Wähle auf dem ersten Tab Details sowohl Base blobs als auch Versions. Azure zeigt danach für jeden ausgewählten Subtyp einen eigenen Konfigurationstab an.

Füge unter Base blobs hinzu:

Condition: Last modified
Older than: 30 days
Then: Move to cool storage

Füge unter Versions hinzu:

Older than version creation: 7 days
Then: Delete the version

Trage unter Filter set als Präfix ein:

documents/

Speichere die Regel. Das Präfix beginnt mit dem Containernamen, deshalb betrifft die Regel den Container inventory-reports nicht.

Lifecycle-Regel zum Verschieben 30 Tage alter Basis-Blobs nach Cool und Löschen sieben Tage alter früherer Versionen unter documents

Lifecycle-Bedingungen werden asynchron ausgewertet, normalerweise einmal pro Tag. Ein neues Test-Blob wird in diesem Trip nicht 30 Tage alt; die gespeicherte und aktivierte Regel ist daher der Nachweis. Gelöschte Versionen können außerdem während des 14-tägigen Soft-Delete-Fensters kostenpflichtig bleiben.

Blob Inventory konfigurieren

Wähle Data management > Blob inventory > Add your first inventory rule und konfiguriere:

Rule name: daily-document-inventory
Destination container: inventory-reports
Object type: Blob
Format: CSV
Schedule: Daily
Blob types: Block blobs
Prefix match: documents/
Include blob versions: Enabled
Include deleted blobs: Enabled, falls angezeigt

Wähle nützliche Schemafelder wie:

Name
Creation-Time
Last-Modified
Content-Length
Access-Tier
VersionId
Current Version status
Deleted
Remaining Retention Days

Wenn Include deleted blobs aktiviert ist, verlangt Azure sowohl Deleted als auch Remaining Retention Days im Schema. Wähle beide Felder aus oder deaktiviere die Option für gelöschte Blobs und lasse beide Felder weg.

Speichere und aktiviere die Inventory-Regel.

Blob-Inventory-Regel mit Ziel inventory-reports und eingeschlossenen Dokument-Blobversionen

Inventory ist keine sofortige interaktive Auflistung. Azure führt die Policy nach dem täglichen Zeitplan aus und schreibt später Berichte unter einem Pfad in inventory-reports. Die Erzeugung kann bis zu einem Tag dauern, bei großen Accounts auch länger. Der Bericht unterstützt anschließend Audits, Kostenanalysen und die Gestaltung von Lifecycle-Richtlinien.

Konfiguration prüfen

Fasse die Schutzeinstellungen optional zusammen:

az storage account blob-service-properties show \
  --account-name stctprotectdmytrotest \
  --resource-group rg-cloudtrips-blob-protection-test-weu \
  --query "{Versioning:isVersioningEnabled,BlobSoftDelete:deleteRetentionPolicy,ContainerSoftDelete:containerDeleteRetentionPolicy}" \
  --output yaml

Das erwartete Ergebnis zeigt aktivierte Versionierung und beide aktivierten Aufbewahrungsrichtlinien mit 14 Tagen.

Bereinigen

Lösche die eigenständige Ressourcengruppe:

az group delete \
  --name rg-cloudtrips-blob-protection-test-weu \
  --yes

Prüfe, ob sie entfernt wurde:

az group exists --name rg-cloudtrips-blob-protection-test-weu

Erwartetes Ergebnis: false.