MIGRATIONS-PLAYBOOK · DATEN
Praxis-Playbook zur Datenmigration auf STACKIT
Daten nach STACKIT zu übertragen heißt, pro Speicher dieselbe Abfolge zu durchlaufen: Preflight, Probelauf, Kopie, Schreibstopp, letzte Synchronisation, Abgleich, Aufräumen. Zwischen einer PostgreSQL-Datenbank, einem Bucket, einem Volume und einem Cache unterscheidet sich nur die Methode. StackToIT überträgt selbst keine Daten; es listet die zustandsbehafteten Einheiten Ihrer Umgebung, bietet die jeweils dokumentierten Methoden an und schreibt die Prüfungen, die bestehen müssen, bevor Sie den Umzug abnehmen. Dieses Playbook geht die Abfolge an einer Umgebung mit vier Speichern durch.
Die Abfolge, Speicher für Speicher
1. Zustandsbehaftete Einheiten auflisten
Beginnen Sie bei migration/data-movement.md. Die Datei listet jede Einheit mit eigenen Daten: Datenbank, Cache, Block-Volume, Objektspeicher. Queues und das System auf der Platte eines Servers gelten nicht als zustandsbehaftet. Die neben einer Einheit genannte bereitgestellte Kapazität ist das, was bereitgestellt wurde, nicht die Datenmenge.
2. Die Zahlen nennen, die die Quelle nicht kennt
Datenmenge, Änderungsrate, Bandbreite, Recovery Point, Recovery Time und tolerierte Downtime stehen nie im Terraform. Der Lauf markiert jede als UNKNOWN, bis Sie sie liefern, und eine ausgegebene Dauer ist nur eine Untergrenze der Übertragung. Ohne diese Zahlen lässt sich für keine Methode zeigen, dass sie in ein Fenster passt.
3. Eine Methode je Speicher wählen
Der Plan listet je Einheit Kandidaten und kennzeichnet andere Methoden mit Begründung als nicht unterstützt. Die Wahl ist eine festgehaltene Entscheidung, kein Standardwert. Die Tabelle unten zeigt die vier Speicher dieses Laufs.
4. Preflight
Klären Sie die Voraussetzungen, die der Preflight prüft, bevor etwas kopiert wird: Extensions, Rollen und TLS der Datenbank, Versionen und archivierte Objekte im Bucket, Dateisystem und freier Platz auf dem Volume, die für die Kopie nötigen Befehle und die TLS-Einstellungen der Clients beim Cache. Einige, etwa die Objekt-Metadaten, klärt erst der Probelauf.
5. Probelauf
Kopieren Sie einmal in das leere Ziel, während die Quelle in Betrieb bleibt, und messen Sie den echten Durchsatz. Erst der Probelauf macht aus der Fensterschätzung eine Zahl, die Sie vertreten können.
6. Schreibstopp, letzte Synchronisation
Stoppen Sie die Schreiber, kopieren Sie, was sich seit dem letzten Durchlauf geändert hat, und lassen Sie die Quelle unberührt. Bei Objektspeichern sieht der Plan vor dem Stopp eine erste Kopie und eine Delta-Synchronisation vor, damit die gesperrte Phase kurz bleibt.
7. Abgleichen
Vergleichen Sie beide Seiten bei weiterhin gestoppten Schreibern: Zeilenzahlen, Prüfsummen und Sequenzen bei der Datenbank, Objektzahl und Bytes beim Bucket, Schlüsselzahl und Schlüssellisten beim Cache. Nehmen Sie den Umzug nur mit einem festgehaltenen GO ab.
8. Umschalten, dann aufräumen
Richten Sie die Clients auf das Ziel, behalten Sie die Quelle für den Zeitraum, den die verantwortliche Person festhält, und löschen Sie danach temporäre Schlüssel, Dump-Dateien und den Migrationshost. Am wichtigsten ist der Object-Storage-Schlüssel: Ein in einem Projekt erstellter Zugang hat Zugriff auf alle Buckets dieses Projekts (Dokumentation).
Vier zustandsbehaftete Einheiten, aufgelistet
Eine für diese Seite geschriebene Umgebung, von StackToIT am 4. November 2026 bewertet: eine PostgreSQL-Datenbank, ein versionierter Bucket, ein Block-Volume und ein Cache. Die ersten beiden Bereiche: die datenführenden Blöcke der Eingabe als zwei wörtliche Zeilenbereiche von main.tf, von der Datenbank bis zum Volume und danach der Cache (die Netzwerk-, Server- und Attachment-Blöcke dazwischen und davor sind weggelassen). Letzter Bereich: die Tabelle am Anfang von migration/data-movement.md, unverändert; auf schmalen Bildschirmen scrollt sie seitlich.
resource "aws_db_instance" "orders" {
identifier = "orders-db"
engine = "postgres"
engine_version = "15.7"
instance_class = "db.m5.large"
allocated_storage = 200
storage_type = "gp3"
username = "orders"
password = var.db_password
db_subnet_group_name = aws_db_subnet_group.main.name
multi_az = true
backup_retention_period = 7
skip_final_snapshot = true
}
resource "aws_s3_bucket" "uploads" {
bucket = "acme-orders-uploads"
}
resource "aws_s3_bucket_versioning" "uploads" {
bucket = aws_s3_bucket.uploads.id
versioning_configuration {
status = "Enabled"
}
}
resource "aws_ebs_volume" "reports" {
availability_zone = "eu-central-1a"
size = 500
type = "gp3"
}resource "aws_elasticache_cluster" "sessions" {
cluster_id = "sessions"
engine = "redis"
engine_version = "7.0"
node_type = "cache.t3.small"
num_cache_nodes = 1
subnet_group_name = "sessions"
}| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| aws_db_instance.orders | aws_db_instance | STACKIT PostgreSQL Flex | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| aws_ebs_volume.reports | aws_ebs_volume | STACKIT Block Storage | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| aws_elasticache_cluster.sessions | aws_elasticache_cluster | STACKIT Key Value Store (Valkey) | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| aws_s3_bucket.uploads | aws_s3_bucket | STACKIT Object Storage | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |Jedes Verfahren beginnt als UNKNOWN
Vier Einheiten, vier Zustände DECISION_REQUIRED. Datenklasse, Recovery Point und Downtime-Toleranz stammen wörtlich aus der Applications-Datei des Kunden; ohne diese Datei bleiben sie NOT_PROVIDED, und es wird kein Standardwert angenommen.
Beim Volume bleibt eine Methode
Für das Block-Volume wird nur eine Kopie auf Dateiebene zwischen Servern angeboten; deshalb übernimmt der Ausführungsplan sie. Die übrigen drei Einheiten warten auf Ihre Antwort.
Nichts wird ausgeführt
Die Datei sagt es in den ersten Zeilen: StackToIT überträgt nie Daten. Jeder Schritt im Plan richtet sich an eine Person.
Welche Methode für welchen Speicher
So, wie der Lauf sie listet. Werkzeuge, die eine Methode nennt, installiert und startet der Betreiber selbst; der Plan führt sie nicht aus und prüft sie nicht.
| Speicher und Ziel | Methoden, die der Plan listet | Nicht angeboten, und warum |
|---|---|---|
| PostgreSQL-15.7-Datenbank → PostgreSQL Flex (angeboten: Versionen 14–18) | Export und Import mit den Engine-Clients (Dump und Restore); logische Replikation; ein eigenes Werkzeug. Logische Replikation braucht die eingeschaltete Einstellung dafür an der Quelle, also eine Parameteränderung und einen Neustart dort, und ein ungelesener Replikations-Slot füllt den Speicher der Quelle. | Nichts ist gestrichen. Schema, spätere DDL, Sequenzen und Large Objects repliziert die logische Replikation nicht: Das Schema wird zuerst kopiert, die Sequenzen beim Schreibstopp. |
| Versionierter Bucket → Object Storage | Kopie mit rclone oder Synchronisation mit der AWS-Kommandozeile; ein eigenes Werkzeug. Der Plan sieht eine erste Kopie, eine Delta-Synchronisation, den Schreibstopp und eine letzte Synchronisation vor. | S3-Replikation: Die AWS-Dokumentation nennt nur S3-Buckets als Ziel, daher bietet der Plan eine Kopie. Eine Kopie aktueller Objekte trägt keine älteren Versionen, Delete Marker, Retention, ACLs oder Policies mit; die Voraussetzung „Versionen“ steht auf FAILS, bis Sie entscheiden, dass die Historie gebraucht wird. |
| 500-GiB-Block-Volume → Block Storage | Kopie auf Dateiebene zwischen Servern, etwa mit rsync, mit einem Durchlauf bei laufenden Diensten und einem letzten Durchlauf im Schreibstopp. | Block-Image-Kopie: Keine gelesene Seite sagt, dass ein Image einer Datenplatte Quelle eines STACKIT-Volumes sein kann, und ein AWS-Snapshot hat keinen Exportweg, den der Plan nennen könnte. |
| Redis-7.0-Cache → Key Value Store (Valkey) | Ein Client, der Schlüssel kopiert (scan, dump, restore) im Schreibstopp, wie im STACKIT-Tutorial, das den Befehl MIGRATE und alternativ ein Skript nutzt. | Einspielen einer exportierten Sicherungsdatei und Replikation vom alten Primary: Keine gelesene STACKIT-Seite und keine API dokumentiert beides, und der Quell-Cache bietet die Replikationsbefehle nicht an. |
Die Cache-Methode ist aus dem Ablauf des Tutorials abgeleitet und wurde, wie der Plan selbst festhält, von StackToIT nicht gegen einen Key Value Store ausgeführt. Das Tutorial nennt im Schnitt etwa 50 Sekunden je Gigabyte und warnt, dass Schlüssel mit Zeilenumbrüchen die Befehlszeilen-Pipe stören können.
Die Schritte und Prüfungen eines Umzugs
Aus migration/data-movement-plan.json, für die Methode Dump und Restore der Datenbank. Links: die sechs Schritte. Rechts: die Prüfungen für Zeilenzahlen, Prüfsummen und Sequenzen mit dem jeweils genannten Befehl.
"steps": [
{
"kind": "preflight",
"id": "MAN/data/aws_db_instance.orders/preflight",
"in_plan": true
},
{
"kind": "rehearsal",
"id": "MAN/data/aws_db_instance.orders/rehearsal",
"in_plan": true
},
{
"kind": "write-freeze",
"id": "MAN/data/aws_db_instance.orders/write-freeze/dump-restore",
"in_plan": true
},
{
"kind": "final-sync",
"id": "MAN/data/aws_db_instance.orders/final-sync/dump-restore",
"in_plan": true
},
{
"kind": "reconcile",
"id": "MAN/data/aws_db_instance.orders/reconcile/dump-restore",
"in_plan": true
},
{
"kind": "cleanup",
"id": "MAN/data/aws_db_instance.orders/cleanup/dump-restore",
"in_plan": true
}
], {
"id": "row-counts",
"kind": "COUNT_COMPARISON",
"mode": "COMMAND",
"what": "Count the rows of every table on both sides, with the writers stopped (an exact count of each table; the estimates of pg_stat_user_tables are not counts).",
"expected": "the same tables with the same number of rows on both sides",
"command": "SELECT format('SELECT %L AS tbl, count(*) FROM %I.%I;', schemaname || '.' || tablename, schemaname, tablename) FROM pg_tables WHERE schemaname NOT IN ('pg_catalog', 'information_schema') \\gexec"
},
{
"id": "table-checksums",
"kind": "CONTENT_CHECK",
"mode": "COMMAND",
"what": "Take the md5 of the rows of every keyed table that matters on both sides, ordered by its key (a key range for a large table; DateStyle, TimeZone and extra_float_digits equal in both sessions).",
"expected": "the row count and the md5 are equal on both sides for every table checked",
"command": "SELECT count(*), md5(string_agg(t::text, ',' ORDER BY t.<key-column>)) FROM <schema>.<table> t;",
"not_provided": [
"the key column of each table (<key-column>)",
"the tables that matter"
]
},
{
"id": "sequences",
"kind": "CONTENT_CHECK",
"mode": "COMMAND",
"what": "Compare the position of every sequence on both sides, so that the first insert on the target does not repeat a key.",
"expected": "the positions are equal, or the target's is higher",
"command": "SELECT sequencename, last_value FROM pg_sequences ORDER BY 1;"
},Prüfungen vergleichen, statt zu vertrauen
Jede Prüfung nennt, was verglichen wird und welches Ergebnis als gleich gilt. Zeilenzahlen nutzen eine exakte Zählung je Tabelle, nicht die Schätzwerte des Planers; Prüfsummen brauchen je Tabelle eine Schlüsselspalte, die Sie benennen.
Manche Prüfungen gehören absichtlich Ihnen
Anwendungsprüfung und Rollback-Grenze sind als manuell markiert: Lesen und Schreiben gehören der Anwendung, und wie lange die Quelle bleibt, entscheidet die verantwortliche Person. Der Plan nennt die Grenze, aber kein Datum.
Rollback ist die unberührte Quelle
Bei NO-GO zeigen die Clients weiter auf die Quelle, die bis zum Schreibstopp aktuell ist. Bis das Ziel nach dem Umschalten den ersten Schreibzugriff annimmt, heißt Rollback nur, die Verbindungseinstellungen zurückzusetzen. Danach erlauben die täglichen Backups von PostgreSQL Flex samt Transaktionslogs eine Point-in-Time-Wiederherstellung, allerdings nur in eine neue Instanz im selben Projekt; ein In-Place-Restore gibt es nicht, weshalb die Clients erneut umgestellt werden (Dokumentation).
Entscheidungen Ihrer Architekten
Methode je Speicher
Dump und Restore oder logische Replikation ist ein Tausch zwischen längerem Schreibstopp und einer Änderung an der Quelle. Entscheiden Sie, sobald Datenmenge und tolerierte Downtime feststehen.
Versionshistorie des Buckets
Nur aktuelle Objekte kopieren oder das Verfahren für Versionen und Delete Marker einplanen. Die Standardkopie trägt keine Historie mit.
Berechtigungen und Rollen
Rollen, Grants und Extensions der Datenbank werden auf dem Ziel neu angelegt; der Plan listet die Abfragen, die sie an der Quelle auslesen.
Sessions im Cache
Ob sich das Kopieren eines Session-Caches überhaupt lohnt oder die Nutzer sich neu anmelden, ist eine fachliche Entscheidung. Diese Einordnung ist Praxis, kein Befund des Laufs.
Wie lange die Quelle bleibt
Bis wann die Quelle erhalten bleibt und ob Schreibzugriffe auf dem Ziel zurückkopiert oder als verloren akzeptiert werden.
Fragen zur Datenmigration
Kopiert StackToIT meine Daten?
Nein. Es listet die zustandsbehafteten Einheiten, die Kandidaten, die Voraussetzungen und die Prüfungen und öffnet keine Verbindung zu Ihren Daten. Jeden Schritt führt eine Person oder Ihr eigenes Werkzeug aus.
Wie lange dauert die Kopie?
Das kann der Lauf nicht sagen. Eine Dauer ist eine Untergrenze aus Datenmenge und Bandbreite, die Sie nennen, und sie zeigt nur, ob diese Grenze die akzeptierte Downtime schon übersteigt. Messen Sie den Durchsatz im Probelauf.
Können die Datenbanken während des Umzugs online bleiben?
Logische Replikation hält die Quelle bis zum Schreibstopp in Betrieb, auf Kosten eines Neustarts der Quelle und eines Replikations-Slots, den Sie beobachten müssen. Dump und Restore laufen im Schreibstopp; der Stopp dauert also so lange wie Dump, Restore und Prüfungen.
Was geschieht mit Bucket-Versionen und ACLs?
Eine Kopie aktueller Objekte trägt keines von beiden mit. Der Plan kennzeichnet die Voraussetzung „Versionen“ und verweist auf die Prüfungen, die zeigen, ob die Quelle sie hat.
Wie komme ich zurück?
Vor dem ersten Schreibzugriff auf dem Ziel richten Sie die Clients wieder auf die Quelle. Danach entscheidet die Rollback-Grenze, die die verantwortliche Person festgehalten hat, ob Schreibzugriffe zurückkopiert werden oder verloren sind.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.