Object Storage-migratie naar STACKIT

De migratie in acht stappen

Dezelfde volgorde werkt voor elke broncloud.

1. 01

   Buckets, consumers en instellingen inventariseren

   Som elke bucket of elk storage account op, met wie erin leest en schrijft en welke instellingen erop staan: versiebeheer, lifecycleregels, versleuteling, replicatie, openbare toegang. De run leest de instellingen uit uw Terraform.

2. 02

   Elke bucket classificeren

   Laat het assessment een klasse toekennen. In de demo: de Amazon S3-bucket is REDESIGN, het Azure storage account REPLATFORM, de Google-bucket RECONFIGURE. De klasse geeft aan hoeveel applicatiewerk u kunt verwachten.

3. 03

   Oplossen wat geen tegenhanger heeft

   Pak eerst de gemarkeerde instellingen aan, hier SSE-KMS-versleuteling, cross-region replicatie en lifecycleregels, want die bepalen of de bucket ongewijzigd kan verhuizen.

4. 04

   Buckets en toegang aanmaken

   Pas de Terraform voor buckets en credentials groups toe. Instellingen die de provider niet kan overnemen, komen als S3 API-documenten die u met een toegangssleutel toepast.

5. 05

   De huidige objecten kopiëren

   Kies een tool en een host, voer een eerste kopie uit terwijl schrijvers doorwerken en controleer die. rclone is een voorbeeld dat de run noemt.

6. 06

   Geschiedenis kopiëren als u die nodig hebt

   Een gewone sync kopieert alleen de huidige versie. Als de versiegeschiedenis ertoe doet, plan de kopie per versie dan apart.

7. 07

   Consumers omschakelen

   Elke consumer wijzigt endpoint, regionaam en inloggegevens, en voor Azure ook de clientbibliotheek. Laat de bron ongemoeid tot het doel is gecontroleerd.

8. 08

   Controleren, accepteren, uitfaseren

   Vergelijk aantallen sleutels, bytes en voorbeeldinhoud en faseer de bron na acceptatie uit.

Drie buckets, drie clouds

De invoer van de run: een Amazon S3-bucket met versiebeheer en SSE-KMS, een Azure storage account met één container, een Google Cloud Storage-bucket met versiebeheer en een lifecycleregel. Voor deze pagina geschreven.

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"
    }
  }
}

• Waarom één rootmodule

  De run accepteert meerdere providers in één map, zodat een multicloudomgeving in één keer wordt beoordeeld en in één set golven wordt geordend.

Hoe elke bucket is geclassificeerd

Gelezen uit de run van 4 november 2026.

De tekst in de rechterkolom parafraseert de run. De klasse benoemt het soort werk en geeft geen toestemming voor uitvoering.

Wat de run voor het doel opstelt

Resourceblokken van de opgestelde Terraform, zonder reviewopmerkingen, en het S3 API-document voor versiebeheer. Het plan stelt versiebeheer in via een STACKIT S3 API-aanroep, omdat de providerresource alleen een naam en een objectvergrendeling kent.

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

  De Azure-container werd de bucket acmefilesgwc-invoices, samengesteld uit account- en containernaam. Controleer de naamregels voordat u erop vertrouwt.

• Inloggegevens

  Per consumer die u in een variabele opgeeft, worden een credentials group en een sleutel geschreven. De run meldt dat een sleutel uit een willekeurige groep alle buckets van het project bereikt, dus sleutels scheiden geen buckets: houd de sleutel voor de kopie op de host die de data verplaatst en gebruik aparte projecten of bucketbeleid dat de groep noemt waar de toegang moet verschillen.

Het kopieerplan voor de bucket met geschiedenis

Stap 3 tot en met 6 van het bestand voor de datakopie dat de run voor de Amazon S3-bucket schreef, zonder de opmaakcommentaren waarmee elke stap is gelabeld.

| 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 |

• Alleen de AWS-bucket kreeg stappen

  In deze run zijn de datastappen en de versiebeheeraanroep alleen voor de Amazon S3-bucket geschreven. Het Azure-account en de Google-bucket staan als stateful eenheden in de lijst, met het mechanisme nog open, en de README noemt rclone. Het versiebeheer van de Google-bucket is als waarschuwing gemarkeerd, maar er is geen versiebeheerdocument voor geschreven. Gebruik de rclone-stappen en controles van het AWS-plan als sjabloon; de stappen voor de versiegeschiedenis gebruiken AWS-commando's en gelden niet zoals ze er staan.

Verschillen die in de praktijk knellen

Elk punt is door de leverancier gedocumenteerd of in de run vermeld.

• De versiegeschiedenis reist niet mee met een gewone kopie

  Amazon S3 bewaart versies met versie-ID's en plaatst bij het verwijderen delete markers. De run meldt dat een gewone sync alleen de huidige versie kopieert, dat versie-ID's niet kunnen worden behouden en dat het tijdstip van laatste wijziging het tijdstip van de kopie wordt.

• Niet-actuele versies bij Google worden aangeduid met generation

  Cloud Storage bewaart vervangen objecten als niet-actuele versies met hun generationnummers. Bepaal of u die op STACKIT nodig hebt voordat u een kopie plant.

• SSE-KMS heeft geen equivalent

  De run meldt dat STACKIT geen SSE-KMS-integratie heeft en in een test aws:kms met HTTP 501 beantwoordde, dus het concept neemt de instelling niet over. De gedocumenteerde modi zijn platformbeheerde AES256 en SSE-C, waarbij de client de sleutel levert.

• Geo-replicatie gaat niet mee

  Azure GRS kopieert data asynchroon naar een secundaire regio. De run meldt dat STACKIT Object Storage binnen de regio over drie availability zones repliceert en geen beheerde cross-region replicatie kent, dus een tweede kopie vereist een eigen syncjob.

• Azure is geen S3-dienst

  Blobcontainers hebben een andere API en authenticatie. Plan applicatiewijzigingen, niet alleen een nieuw endpoint. De AzCopy-pagina documenteert S3 naar Blob; gebruik voor de andere richting een kopieertool met S3-ondersteuning, zoals rclone.

• Lifecycleregels worden niet opgesteld voor de Google-bucket

  De run noemt de regel als niet overgenomen en schrijft er geen S3 API-document voor. Uw team kan er een schrijven in de vorm van het lifecycledocument dat de run voor andere buckets maakt.

Beslissingen voor uw architecten

Wat uw team vastlegt voordat het kopiëren begint.

• Kopieertool en host

  De dataverplaatsing is DECISION REQUIRED voor alle drie de eenheden. Die hangt af van omvang, wijzigingssnelheid en toegestane downtime, en geen daarvan wordt door de bron vermeld.

• Schrijfstop

  Het venster is UNKNOWN tot de klant het opgeeft, en het runbook neemt er geen aan.

• Versleutelingsmodel

  Kies AES256 of SSE-C en leg vast wie de sleutels beheert.

• Wijzigingen bij consumers

  Maak een lijst van elke applicatie, SDK, signed URL en connectiestring die elke bucket of elk account gebruikt.

Vragen van opslagteams

Bronnen

• STACKIT-documentatie: Object Storage
• STACKIT-documentatie: versleuteling van Object Storage
• STACKIT-documentatie: bucketversiebeheer
• Amazon S3-documentatie: S3 Versioning
• Google Cloud-documentatie: Object Versioning
• Microsoft Learn: dataredundantie van Azure Storage
• Microsoft Learn: data kopiëren vanuit Amazon S3 met AzCopy