Cloud Exit: So holst du Workloads zurück ins eigene Rechenzentrum

# AWS: Instanzen mit Typ, Zustand und Namens-Tag
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,Tags[?Key==`Name`].Value|[0]]' \
  --output table

# Azure: dasselbe in kurz
az vm list -d -o table

# Der einfache Teil der Migration ist der, der schon als Code existiert
terraform state list | wc -l
terraform state list | grep -c 'aws_db_instance\|aws_s3_bucket'

# Dasselbe Image, dasselbe cloud-init wie in der Cloud, nur lokal
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2

qm create 9000 --name debian13-tmpl --memory 2048 --net0 virtio,bridge=vmbr0
qm importdisk 9000 debian-13-genericcloud-amd64.qcow2 local-lvm
qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0
qm set 9000 --ide2 local-lvm:cloudinit --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0
qm template 9000

# Klon mit denselben Nutzerdaten wie im Cloud-Rollout
qm clone 9000 120 --name app01 --full
qm set 120 --ciuser deploy --sshkeys ~/.ssh/id_ed25519.pub --ipconfig0 ip=dhcp

# Erst messen, dann kopieren: Menge und Objektzahl bestimmen die Dauer
aws s3 ls --summarize --human-readable --recursive s3://prod-assets | tail -3

# rclone spricht beide Seiten, MinIO ist S3-kompatibel
rclone sync s3:prod-assets minio:prod-assets \
  --transfers 16 --checkers 32 --fast-list --progress

# Zweiter Lauf im Wartungsfenster holt nur das Delta
rclone sync s3:prod-assets minio:prod-assets --checksum --fast-list

# Prüfen statt vertrauen
rclone check s3:prod-assets minio:prod-assets --one-way --checksum

-- Auf der Quelle (bei Managed-Diensten muss die logische Replikation
-- über einen Parameter aktiviert und die Instanz neu gestartet werden)
CREATE PUBLICATION migration FOR ALL TABLES;

-- Schema vorab mit pg_dump --schema-only auf das Ziel einspielen,
-- dann auf dem neuen Server abonnieren
CREATE SUBSCRIPTION migration
  CONNECTION 'host=quelle.example.internal dbname=app user=repl'
  PUBLICATION migration;

-- Rückstand beobachten, erst bei null umschalten (auf der Quelle)
SELECT application_name,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS bytes_rueckstand
FROM pg_stat_replication;

-- Erzeugt die setval-Anweisungen, die du auf dem Ziel ausführst
SELECT format('SELECT setval(%L, %s);',
              schemaname || '.' || sequencename,
              last_value)
FROM pg_sequences
WHERE last_value IS NOT NULL;

# Aktuelle TTL ablesen, sie bestimmt die Dauer der Umschaltung
dig +noall +answer app.example.de

# TTL auf 60 setzen, danach mindestens die alte TTL abwarten
# Erst dann fragen alle Resolver wieder frisch nach
watch -n 30 'dig +noall +answer @1.1.1.1 app.example.de'

# Im Fenster: von beiden Seiten aus prüfen, wohin die Clients gehen
tail -f /var/log/nginx/access.log      # neues Ziel
aws logs tail /aws/alb/prod --follow   # alte Seite, sollte versiegen

# Welche wiederkehrenden Aufgaben laufen wirklich?
systemctl list-timers --all | grep -Ei 'backup|certbot|unattended|pgbackrest'

# Backup prüfen, dann auf einem Testhost zurückspielen
sudo -u postgres pgbackrest --stanza=app check
sudo -u postgres pgbackrest --stanza=app --delta restore   # nie auf dem Primary

# Zertifikate: Ablauf überwachen, nicht auf Erinnerungsmails hoffen
for h in app.example.de api.example.de; do
  echo | openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null \
    | openssl x509 -noout -enddate -subject
done