Cloud-Migration: Strategie zur Dateiübertragung

Eine Dateiübertragungsstrategie für die Cloud-Migration hängt an drei Entscheidungen: dem Transportweg (öffentliches Internet, Direct Connect oder physisches Gerät), dem Cutover-Modell (Big-Bang, phasenweise oder Parallelbetrieb) und den Integritätsprüfungen, denen Sie vertrauen. Bei einem 50-TB-Datenbestand auf einer 1-Gbps-Leitung rechnen Sie mit etwa 5 Tagen reiner Übertragungszeit bei Leitungsgeschwindigkeit — weniger bei Komprimierung, mehr bei geteilter Leitung. Planen Sie die Reihenfolge, bevor Sie die Werkzeuge planen, und rechnen Sie 20 % Puffer für Wiederholungen und Abgleich ein.

Den Datenbestand ermitteln, bevor Sie ein Kabel berühren

Bevor Sie sich für AWS DataSync, Azure AzCopy oder Google Storage Transfer Service entscheiden, inventarisieren Sie, was Sie tatsächlich haben. Führen Sie du -sh auf Dateifreigaben aus, fragen Sie Datenbankka kataloge nach Zeilenzahlen ab und exportieren Sie Objekt-Speicher-Manifeste. Ein mittelständisches Unternehmen, das ich geprüft habe, glaubte, 8 TB auf seinem NAS zu haben; die tatsächliche Zahl war 34 TB, sobald man Snapshots und versteckte ~$-Office-Sperrdateien mitgezählt hat.

Klassifizieren Sie den Bestand nach drei Achsen: Größe, Änderungsrate und regulatorisches Gewicht. Dateien unter 1 MB bewegen sich langsam pro Byte wegen des Pro-Objekt-Overheads — ein Bucket mit 200 Millionen kleinen Dateien kann länger dauern als einer mit 10 TB Video. Ranken Sie heiße Daten (täglich geändert) separat von kalten Daten (.pdf-Archive, Rechnungen von 2017). Kalte Daten können Wochen vorher verschoben werden; heiße Daten brauchen Sync-bis-Cutover-Logik.

Einen Transport wählen, der zum Zeitplan passt

Für unter 10 TB mit einer guten Glasfaserleitung gewinnt die Online-Übertragung über TLS 1.3 meist. Zwischen 10 TB und 500 TB reservieren Sie Bandbreite oder provisionieren Sie AWS Direct Connect / Azure ExpressRoute, um das Unternehmens-WAN nicht zu sättigen. Über 500 TB schlägt physisches Seeding das Internet: AWS Snowball Edge fasst 80 TB, Snowmobile bewegt Exabytes in einem Schiffscontainer, und Azure Data Box Heavy speichert 1 PB.

Rechnen Sie ehrlich. Bei 1 Gbps (125 MB/s, realistisch 80 MB/s nach Overhead) dauert 100 TB rund 14 Tage ununterbrochenen Durchsatzes. Wenn Ihr Wartungsfenster 48 Stunden beträgt, ist die Leitung nicht machbar — versenden Sie Festplatten. Berücksichtigen Sie Egress: 100 TB von einem älteren Anbieter bei 0,09 USD/GB zu verschieben kostet 9.000 USD, bevor Sie das Ziel berühren.

Integrität: Vertrauen und trotzdem prüfen

Jede Migration braucht eine Ende-zu-Ende-Integritätsprüfung, nicht nur Transport-Layer-TLS. Erstellen Sie SHA-256- oder xxHash64-Prüfsummen an der Quelle, übertragen Sie sie mit dem Payload und prüfen Sie am Ziel erneut. AWS DataSync tut das standardmäßig; rsync mit --checksum erzwingt es; rclone unterstützt --check-first und crypt-Backends.

Für Compliance-Workloads bewahren Sie das Manifest — eine CSV mit Pfad, Byte-Anzahl und Hash — für den gesamten Aufbewahrungszeitraum auf. Gemäß DSGVO Art. 5(1)(f) müssen Sie nachweisen können, dass Dateien während der Übertragung nicht verändert wurden. Ein falsch ausgerichtetes Byte in einer DICOM-Studie kann dazu führen, dass der Viewer eines Radiologen sie nicht öffnet.

Ausfallzeiten mit Delta-Sync minimieren

Big-Bang-Cutovers sind der Feind des Schlafs. Führen Sie stattdessen Wochen vorher eine erste Massenkopie durch, dann nächtliche Inkrementdeltas bis zum Cutover-Fenster. Werkzeuge wie Rclone (--update --use-server-modtime), AzCopy (--overwrite=ifSourceNewer) und Googles gsutil rsync -d erkennen geänderte Dateien per mtime oder Hash und bewegen nur das Delta.

Datenbanken brauchen einen eigenen Plan. Für eine 2-TB-PostgreSQL-Instanz verwenden Sie pg_basebackup plus WAL-Shipping; für MySQL richten Sie am Ziel ein Replikat ein und promovieren es beim Cutover. Dateisystem-Deltas über rsync können den finalen Sync von Stunden auf Minuten reduzieren, was meist in ein Samstagnacht-Wartungsfenster passt.

Bandbreite begrenzen und zeitgesteuert übertragen

Migrationen, die die gesamte WAN-Bandbreite belegen, enden schlecht — Helpdesk-Tickets häufen sich an, bevor der Arbeitstag beginnt. Drosseln Sie aggressiv. AzCopy akzeptiert --cap-mbps, rclone unterstützt --bwlimit 50M:100M für Tag-/Nachttarife, und DataSync plant Tasks mit stündlichen Bandbreitenbegrenzungen. Eine vernünftige Richtlinie: 30 % der Leitung während der Geschäftszeiten, 90 % nachts, 100 % am Wochenende.

Segmentieren Sie auch den Traffic an der Firewall. Markieren Sie Migrationsflows mit einem DSCP-Wert, damit QoS-Richtlinien keine Videokonferenzen aushungern. Wenn Sie MPLS zu Niederlassungen verwenden, sollten Sie SD-WAN-Breakout in Betracht ziehen, damit Migrationsverkehr lokal aussteigt, statt über die Zentrale zu trombonieren.

Sensible Daten im Transit schützen

Jede Migration mit personenbezogenen Daten, Gesundheitsdaten oder Karteninhaberdaten braucht Verschlüsselung nach dem relevanten Standard. TLS 1.3 ist die Mindestanforderung; für Dateien im Ruhezustand während der Staging-Phase mit AES-256-GCM verschlüsseln. Gemäß DSGVO Art. 32 müssen geeignete technische Maßnahmen zum Schutz personenbezogener Daten getroffen werden; der BfDI empfiehlt Ende-zu-Ende-Verschlüsselung für sensible Übertragungen.

Für ad-hoc-Übertragungen kleiner Batches während der Migration (ein Berater exportiert eine Salesforce-Tabelle oder ein DBA verschiebt einen Credential-Vault) halten Ende-zu-Ende-verschlüsselte Werkzeuge Schlüssel aus der Reichweite des Transport-Anbieters. HexaTransfer erledigt das sauber für Einzeldateien während einer Migration — Verschlüsselung erfolgt im Browser, bevor irgendetwas einen Server berührt.

Den Cutover vor dem Cutover testen

Proben Sie die Migration an einer Teilmenge. Wählen Sie eine Abteilung — etwa 300 GB des Shared Drives des Marketings — und führen Sie die komplette Pipeline durch: Quellinventar, Übertragung, Prüfsummenverifizierung, Berechtigungszuordnung und Anwendungs-Failover. Stoppen Sie jede Phase und dokumentieren Sie, was schiefging.

Häufige Überraschungen: NTFS-ACLs, die sich nicht sauber auf S3-Bucket-Richtlinien abbilden lassen, Symlinks, die rclone als Dateien behandelt, SMB-Share-Pfade in Anwendungskonfigurationen und Groß-/Kleinschreibungsunterschiede zwischen Windows- und Linux-Zielen. Beheben Sie das in der Staging-Umgebung, nicht um 2 Uhr nachts am Go-Live-Tag. Eine Probe, die eine Woche dauert, spart einen Rollback, der einen Monat dauert.

Abgleich nach der Migration

Erklären Sie Erfolg erst nach dem Abgleich. Vergleichen Sie Quell- und Zielobjektanzahl, Gesamtbytes und eine zufällige 1%-Hash-Stichprobe. Fragen Sie Anwendungsmetriken ab — wenn ein Dokumentenmanagementsystem 4,2 Millionen Dateien gemeldet hat und das Ziel 4,19 Millionen zeigt, finden Sie die fehlenden 10.000, bevor Sie die Quelle abschalten.

Halten Sie die Quelle nach dem Cutover mindestens 30 Tage im Nur-Lesen-Modus. Nutzer werden unweigerlich eine Datei benötigen, die nicht migriert wurde, weil sie in ~/Desktop/altes_zeug/ lag statt in der inventarisierten Freigabe. Planen Sie dafür, seien Sie nicht überrascht, und schreiben Sie das Rollback-Runbook, bevor Sie es brauchen.

Jetzt kostenlos testen auf hexatransfer.com — kein Konto, max. 10 GB.