Object-Storage-Migration zu STACKIT

Die Migration in acht Schritten

Dieselbe Reihenfolge gilt für jede Quell-Cloud.

1. 01

   Buckets, Verbraucher und Einstellungen inventarisieren

   Erfassen Sie jeden Bucket oder Storage Account, wer ihn liest und beschreibt, und seine Einstellungen: Versioning, Lifecycle-Regeln, Verschlüsselung, Replikation, öffentlicher Zugriff. Der Lauf liest die Einstellungen aus Ihrem Terraform.

2. 02

   Jeden Bucket klassifizieren

   Lassen Sie die Bewertung eine Klasse vergeben. In der Demo: Der Amazon-S3-Bucket ist REDESIGN, der Azure Storage Account REPLATFORM, der Google-Bucket RECONFIGURE. Die Klasse zeigt, wie viel Anwendungsarbeit zu erwarten ist.

3. 03

   Klären, was kein Gegenstück hat

   Klären Sie die markierten Einstellungen zuerst, hier SSE-KMS-Verschlüsselung, regionsübergreifende Replikation und Lifecycle-Regeln, denn sie entscheiden, ob der Bucket unverändert umziehen kann.

4. 04

   Buckets und Zugriff anlegen

   Wenden Sie das Terraform für Buckets und Credentials Groups an. Einstellungen, die der Provider nicht abbilden kann, liegen als S3-API-Dokumente bei, die Sie mit einem Zugriffsschlüssel anwenden.

5. 05

   Aktuelle Objekte kopieren

   Wählen Sie Werkzeug und Host, erstellen Sie eine erste Kopie, während die Schreiber weiterarbeiten, und prüfen Sie sie. rclone ist ein Beispiel, das der Lauf nennt.

6. 06

   Historie kopieren, wenn Sie sie brauchen

   Ein einfacher Sync kopiert nur die aktuelle Version. Ist die Versionshistorie wichtig, planen Sie das Kopieren je Version gesondert.

7. 07

   Verbraucher umstellen

   Jeder Verbraucher ändert Endpunkt, Regionsnamen und Zugangsdaten, bei Azure auch seine Client-Bibliothek. Lassen Sie die Quelle unberührt, bis das Ziel verifiziert ist.

8. 08

   Verifizieren, abnehmen, stilllegen

   Vergleichen Sie Anzahl der Objektschlüssel, Bytes und Stichproben des Inhalts, und legen Sie die Quelle nach der Abnahme still.

Drei Buckets, drei Clouds

Die Eingabe des Laufs: ein Amazon-S3-Bucket mit Versioning und SSE-KMS, ein Azure Storage Account mit einem Container, ein Google-Cloud-Storage-Bucket mit Versioning und Lifecycle-Regel. Für diese Seite geschrieben.

resource "aws_s3_bucket" "media" {
  bucket = "acme-media-assets"
}

resource "aws_s3_bucket_versioning" "media" {
  bucket = aws_s3_bucket.media.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "media" {
  bucket = aws_s3_bucket.media.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

resource "azurerm_storage_account" "files" {
  name                     = "acmefilesgwc"
  resource_group_name      = azurerm_resource_group.files.name
  location                 = azurerm_resource_group.files.location
  account_tier             = "Standard"
  account_replication_type = "GRS"
}

resource "azurerm_storage_container" "invoices" {
  name                  = "invoices"
  storage_account_id    = azurerm_storage_account.files.id
  container_access_type = "private"
}

resource "google_storage_bucket" "reports" {
  name                        = "acme-reports-eu"
  location                    = "EUROPE-WEST3"
  uniform_bucket_level_access = true

  versioning {
    enabled = true
  }

  lifecycle_rule {
    condition {
      age = 180
    }
    action {
      type = "Delete"
    }
  }
}

• Warum ein Root-Modul

  Der Lauf akzeptiert mehrere Provider in einem Ordner. Eine Multi-Cloud-Umgebung wird so in einem Durchgang bewertet und in einer gemeinsamen Wellenfolge geordnet.

Wie jeder Bucket klassifiziert wurde

Aus dem Lauf vom 4. November 2026 gelesen.

Die rechte Spalte gibt den Lauf sinngemäß wieder. Die Klasse benennt die Art der Arbeit und genehmigt nichts.

Was der Lauf für das Ziel entwirft

Ressourcenblöcke des entworfenen Terraform, ohne Prüfkommentare, und das S3-API-Dokument für Versioning. Der Plan aktiviert Versioning über einen S3-API-Aufruf von STACKIT, weil die Provider-Ressource nur einen Namen und eine Objektsperre kennt.

resource "stackit_objectstorage_bucket" "media" {
  project_id = var.project_id
  name       = "acme-media-assets"
}

resource "stackit_objectstorage_bucket" "files" {
  project_id = var.project_id
  name       = "acmefilesgwc-invoices"
}

resource "stackit_objectstorage_bucket" "reports" {
  project_id = var.project_id
  name       = "acme-reports-eu"
}

{
  "Status": "Enabled"
}

• Namen

  Der Azure-Container wurde zum Bucket acmefilesgwc-invoices, gebildet aus Konto- und Containername. Prüfen Sie die Namensregeln, bevor Sie sich darauf verlassen.

• Zugangsdaten

  Pro Verbraucher, den Sie in einer Variable aufführen, werden eine Credentials Group und ein Schlüssel geschrieben. Laut Lauf erreicht ein Schlüssel aus einer beliebigen Gruppe jeden Bucket des Projekts; Schlüssel trennen Buckets also nicht. Halten Sie den Schlüssel der Kopie auf dem Kopier-Host und nutzen Sie dort, wo sich Zugriffe unterscheiden müssen, eigene Projekte oder Bucket Policies, die die Gruppe nennen.

Der Kopierplan für den Bucket mit Historie

Die Schritte 3 bis 6 der Kopierdatei, die der Lauf für den Amazon-S3-Bucket geschrieben hat, ohne die Markup-Kommentare, die jeden Schritt kennzeichnen.

| 3 | Copy the current object of every key (sketch: `rclone copy aws-source:acme-media-assets stackit-s3:acme-media-assets --checksum`, with a remote for each side). | DEFINED |
| 4 | Copy the version history: a plain sync copies the current version only. Versioning must be enabled on the target before the first object lands. Each earlier version is read with its version id (`aws s3api list-object-versions`, `get-object --version-id`) and written oldest first, so the newest becomes the current version. The version ids of the source cannot be kept and the last-modified time becomes the copy time. | DEFINED |
| 5 | Recreate the delete markers: a key whose latest source entry is a delete marker is written and then deleted on the target (`aws s3api delete-object` without a version id creates the marker). Whether STACKIT creates a marker this way is not verified. | DEFINED |
| 6 | Verify: the number of keys and bytes of every prefix equal on both sides, the number of versions and delete markers per key equal; a sample read from the target with an access key of a credentials group (`rclone check`, `aws s3api head-object`). An ETag is not compared (multipart and encrypted objects differ). | DEFINED |

• Nur der AWS-Bucket bekam Schritte

  In diesem Lauf wurden Datenschritte und der Versioning-Aufruf nur für den Amazon-S3-Bucket geschrieben. Azure-Konto und Google-Bucket stehen als zustandsbehaftete Einheiten mit offenem Mechanismus in der Liste; die README nennt rclone. Das Versioning des Google-Buckets meldet der Lauf als Warnung, schreibt dafür aber kein Versioning-Dokument. Nehmen Sie die rclone-Schritte und Prüfungen des AWS-Plans als Vorlage; die Schritte zur Versionshistorie nutzen AWS-Befehle und passen so nicht.

Unterschiede, die in der Praxis Probleme machen

Jeder Punkt ist vom Hersteller dokumentiert oder im Lauf festgehalten.

• Eine einfache Kopie nimmt die Versionshistorie nicht mit

  Amazon S3 hält Versionen mit Version-IDs und legt beim Löschen Delete Markers an. Der Lauf hält fest: Ein einfacher Sync kopiert nur die aktuelle Version, Version-IDs lassen sich nicht erhalten, und der Änderungszeitpunkt wird zum Kopierzeitpunkt.

• Nicht aktuelle Versionen in Cloud Storage tragen eine Generationsnummer

  Cloud Storage behält ersetzte Objekte als nicht aktuelle Versionen mit ihren Generationsnummern. Entscheiden Sie, ob Sie sie auf STACKIT brauchen, bevor Sie eine Kopie planen.

• SSE-KMS hat kein Gegenstück

  Laut Lauf hat STACKIT keine SSE-KMS-Integration und beantwortete aws:kms in einem Test mit HTTP 501; der Entwurf übernimmt die Einstellung daher nicht. Dokumentiert sind plattformverwaltetes AES256 und SSE-C, bei dem der Client den Schlüssel mitliefert.

• Georeplikation folgt nicht

  Azure GRS kopiert Daten asynchron in eine zweite Region. Laut Lauf repliziert STACKIT Object Storage innerhalb der Region über drei Availability Zones und hat keine verwaltete regionsübergreifende Replikation; eine zweite Kopie braucht einen eigenen Sync-Job.

• Azure ist kein S3-Dienst

  Blob-Container haben eine andere API und Authentifizierung. Planen Sie Anwendungsänderungen, nicht nur einen neuen Endpunkt. Die AzCopy-Seite dokumentiert S3 nach Blob; für die Gegenrichtung nehmen Sie ein S3-fähiges Kopierwerkzeug wie rclone.

• Lifecycle-Regeln werden für den Google-Bucket nicht entworfen

  Der Lauf führt die Regel als nicht übernommen und schreibt kein S3-API-Dokument dafür. Ihr Team kann eines in der Form des Lifecycle-Dokuments schreiben, das der Lauf für andere Buckets erzeugt.

Entscheidungen Ihrer Architekten

Was Ihr Team klärt, bevor die Kopie beginnt.

• Kopierwerkzeug und Host

  Der Datenumzug ist für alle drei Einheiten DECISION REQUIRED. Sie hängt von Größe, Änderungsrate und tolerierter Ausfallzeit ab, die die Quelle nicht nennt.

• Schreibstopp

  Das Zeitfenster ist UNKNOWN, bis der Kunde es nennt, und das Runbook nimmt keines an.

• Verschlüsselungsmodell

  Wählen Sie AES256 oder SSE-C und halten Sie fest, wer die Schlüssel hält.

• Änderungen bei den Verbrauchern

  Listen Sie jede Anwendung, jedes SDK, jede signierte URL und jeden Connection String auf, die einen Bucket oder ein Konto berühren.

Fragen von Storage-Teams

Quellen

• STACKIT-Dokumentation: Object Storage
• STACKIT-Dokumentation: Verschlüsselung in Object Storage
• STACKIT-Dokumentation: Bucket-Versionierung
• Amazon-S3-Dokumentation: S3 Versioning
• Google-Cloud-Dokumentation: Object Versioning
• Microsoft Learn: Datenredundanz in Azure Storage
• Microsoft Learn: Daten mit AzCopy aus Amazon S3 kopieren