TL;DR
Die Migration von AWS zurück auf On-Premises-NAS erfordert Planung, die in den meisten Cloud-Migrationsguides fehlt. Dieser Guide deckt die praktischen Schritte ab: Egress-Kosten und Transferzeiten schätzen, zwischen Direct Download und physischem Transfer wählen, Protokoll-Übersetzung (S3 zu NFS/SMB), und Datenintegrität nach dem Move verifizieren.
Cloud Repatriation ist längst kein Randphänomen mehr. Laut IDC haben 80% der Organisationen, die Workloads in die Cloud verschoben haben, einige davon wieder zurück On-Premises gebracht. Die Gründe variieren: Egress-Kosten, Latenz, Compliance oder schlicht die Erkenntnis, dass ein Fileserver im eigenen Rechenzentrum für große Datasets günstiger ist.
Dieser Guide deckt die praktischen Schritte für die Migration von AWS (S3, EFS oder FSx) zurück auf On-Premises-NAS-Storage ab.
Bevor irgendetwas passiert: verstehen, was du verschiebst.
# Alle Buckets und ihre Größen auflisten
aws s3 ls
aws s3 ls s3://dein-bucket --recursive --summarize
Zentrale Fragen:
# EFS-Größe via CloudWatch prüfen
aws cloudwatch get-metric-statistics \
--namespace AWS/EFS \
--metric-name StorageBytesTotal \
--dimensions Name=FileSystemId,Value=fs-12345678 \
--start-time 2026-04-01T00:00:00Z \
--end-time 2026-04-15T00:00:00Z \
--period 86400 \
--statistics Average
FSx gibt es in mehreren Varianten. Prüfe, welche du nutzt, da sich der Migrationspfad unterscheidet:
AWS berechnet Gebühren für Daten, die ihr Netzwerk verlassen:
| Datenvolumen | Kosten pro GB |
|---|---|
| Erste 10 TB/Monat | $0,09 |
| Nächste 40 TB/Monat | $0,085 |
| Nächste 100 TB/Monat | $0,07 |
| Über 150 TB/Monat | $0,05 |
Beispiel: 200 TB in einem Monat herunterladen kostet ca. $12.500 an Egress-Gebühren.
Egress verhandeln
Bei großen Repatriations (100+ TB) kontaktiere deinen AWS Account Manager. AWS bietet manchmal Egress-Waivers oder Rabatte für Kunden, die Workloads migrieren, besonders wenn du andere AWS-Services beibehältst.
Berechne, wie lange der Transfer über deine Internetverbindung dauert:
| Verbindung | 100 TB Transferzeit |
|---|---|
| 1 Gbps | ~10 Tage |
| 10 Gbps | ~1 Tag |
| 100 Mbps | ~100 Tage |
Wenn deine Verbindung unter 1 Gbps liegt und du über 50 TB verschiebst, ziehe AWS Snowball in Betracht (physisches Gerät, das in dein Rechenzentrum geliefert wird). Der Break-Even-Point liegt ungefähr bei:
Wenn Daten in Glacier oder Glacier Deep Archive liegen, musst du sie vor dem Download wiederherstellen:
| Retrieval Tier | Dauer | Kosten pro GB |
|---|---|---|
| Expedited | 1-5 Minuten | $0,03 |
| Standard | 3-5 Stunden | $0,01 |
| Bulk | 5-12 Stunden | $0,0025 |
Bei großen Repatriations Bulk Retrieval verwenden. Daten in Batches wiederherstellen, um Concurrent-Restore-Limits zu vermeiden.
| Source | Destination | Protokoll |
|---|---|---|
| S3 | Linux NAS | NFS |
| S3 | Windows File Server | SMB |
| EFS | Linux NAS | NFS |
| FSx for Windows | Windows File Server | SMB |
| FSx for ONTAP | Beliebig | NFS oder SMB |
Mindestens 120% des Quell-Datenvolumens provisionieren:
NFS Exports oder SMB Shares vor dem Start der Migration einrichten. Zugriff von der Maschine testen, die den Transfer ausführen wird:
# NFS Mount testen
mount -t nfs dein-nas:/export /mnt/test
touch /mnt/test/write-test && rm /mnt/test/write-test
# SMB Mount testen
mount -t cifs //dein-nas/share /mnt/test -o username=admin
touch /mnt/test/write-test && rm /mnt/test/write-test
aws s3 sync s3://dein-bucket /mnt/nas-ziel/ \
--no-progress \
--storage-class STANDARD
Pro: Einfach, integriert. Contra: Single-threaded, kein Verifizierungsreport, kein Cross-Protokoll-Support.
AWS DataSync kann von S3 oder EFS auf On-Premises-NFS/SMB-Shares transferieren via DataSync Agent in deinem Rechenzentrum.
Pro: Von AWS gemanaged, guter Throughput. Contra: Erfordert Deployment einer DataSync-Agent-VM, kostet $0,0125/GB, kommt zu Egress-Kosten hinzu.
rclone sync s3:dein-bucket /mnt/nas-ziel/ \
--transfers 16 \
--checkers 32 \
--progress
Pro: Multi-threaded, unterstützt viele Backends. Contra: Kein NFS/SMB-Mount-Support (schreibt nur auf lokales Filesystem), keine Cross-Protokoll-Migration, limitierte Verifizierung.
Für große Datasets (50+ TB), Cross-Protokoll-Anforderungen (S3 zu SMB) oder Compliance-Anforderungen (prüfbare Verifizierung) ein spezialisiertes Migrationstool nutzen.
syncopio für AWS Repatriation
syncopio verbindet sich mit S3-kompatiblem Storage als Source und schreibt auf NFS- oder SMB-Destinations. Verteilte Worker parallelisieren den Transfer, und integrierte Checksum-Verifizierung erzeugt einen prüfbaren Report, der bestätigt, dass jede Datei intakt angekommen ist. Kein DataSync Agent nötig.
S3 ist Object Storage. NAS ist File Storage. Das sind fundamental verschiedene Konzepte, und die Übersetzung erfordert Entscheidungen.
S3 Object Keys wie projects/2026/report.pdf werden zu Verzeichnispfaden /projects/2026/report.pdf auf dem Filesystem. Die meisten Tools machen das automatisch, aber achte auf:
/ enden):*?" und andere| S3-Metadaten | NAS-Äquivalent | Anmerkungen |
|---|---|---|
| Content-Type | Dateiendung | Keine direkte Zuordnung |
| Last-Modified | mtime | Von den meisten Tools erhalten |
| x-amz-meta-* | Extended Attributes | Toolabhängig |
| Storage Class | N/A | Nicht anwendbar auf NAS |
| Object Tags | N/A | Kein Filesystem-Äquivalent |
| ACL | POSIX Permissions / NTFS ACL | Erfordert explizites Mapping |
S3 nutzt IAM Policies und Bucket ACLs. NAS nutzt POSIX Permissions (NFS) oder NTFS ACLs (SMB). Es gibt keine automatische Übersetzung. Du musst entscheiden:
Für die meisten Repatriations ist ein einheitliches Permission-Set (z. B. 755 für Verzeichnisse, 644 für Dateien, im Besitz eines Service-Accounts) der einfachste Ansatz.
Niemals Cloud Storage abschalten, bevor die Verifizierung abgeschlossen ist.
Verifizierung nicht überspringen
Der häufigste Repatriation-Fehler: Cloud Storage abschalten, bevor bestätigt ist, dass jede Datei korrekt transferiert wurde. S3 Bucket behalten, bis du einen verifizierten, checksummed Report hast, der 100% Integrität zeigt.
Statt sofort zu löschen, eine Lifecycle Policy setzen, die Objects für 30 Tage nach Glacier Deep Archive verschiebt, dann löscht. Das gibt dir ein Sicherheitsnetz zu minimalen Kosten ($0,00099/GB/Monat).
{
"Rules": [
{
"ID": "PostMigrationCleanup",
"Status": "Enabled",
"Transitions": [
{
"Days": 0,
"StorageClass": "DEEP_ARCHIVE"
}
],
"Expiration": {
"Days": 30
}
}
]
}
| Fehler | Konsequenz | Prävention |
|---|---|---|
| Egress-Kosten nicht einplanen | Rechnungsschock ($90/TB) | Gesamt-Egress vor Start berechnen |
| Glacier Restore-Zeit vergessen | Migration um Stunden/Tage verzögert | In Batches wiederherstellen, früh anfangen |
| Single-threaded Transfer | Wochen statt Tage | Parallele Transfers nutzen |
| Keine Verifizierung | Stiller Datenverlust | Jede Datei checksummen vor Decommission |
| S3 vor Verifizierung löschen | Datenverlust bei fehlenden Dateien | Source 30+ Tage nach Cutover behalten |
| Dateinamen-Beschränkungen ignorieren | Dateien mit :*? scheitern auf NTFS/SMB | Pre-Scan auf illegale Zeichen |
| Falsche NFS/SMB-Permissions | User von ihren Dateien ausgesperrt | Zugriff mit echten User-Accounts testen |