---
title: "Große File-Migration mit rclone-Bridge"
description: Konkrete Vorlage für die Migration großer Dateibestände auf einen STACKIT File Storage Share mit rclone als Bridge, wenn duale NFS-Mounts nicht gehen.
sidebar:
  badge:
    text: "STACKIT"
    variant: success
scfAsset:
  managed: false
  category: "runbook"
  external: false
  tags: ["design-and-mobilize", "use-cases", "replatform", "file-data", "file-service", "rclone", "bridge"]
  maintainers:
    - user: "lukas.weberruss"
      role: true
      website: true
source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/runbook-file-migration-rclone-bridge/"
source_file: "docs/de/migration/assetcontainer/stackit/runbook-file-migration-rclone-bridge.mdx"
---

## Use Case

- **Kategorie:** Migration großer Dateibestände
- **Ziel:** STACKIT File Service
- **Methode:** rclone-Transferpfad, wenn kein direkter dualer NFS-Mount verfügbar ist

## Netzwerk- und Architektur-Rahmenbedingungen (validiert)

- **rclone hebt die privaten SFS-Zugriffsregeln nicht auf:** Auch mit rclone bleibt der Ziel-SFS-Share NFS-basiert und netzwerkbeschränkt durch SNA-Routing und ACL-/Export-Policies. Siehe <LinkChip href="https://docs.stackit.cloud/products/storage/file-storage/basics/concepts/">File-Storage-Konzepte</LinkChip> und <LinkChip href="https://docs.stackit.cloud/products/storage/file-storage/basics/mounting-resource-pools-and-shares/">Resource Pools und Shares mounten</LinkChip>.
- **Bridge-Host muss beidseitig erreichbar sein:** Der Transfer-Host muss Quelle und Ziel unter dem tatsächlichen Netzwerkmodell erreichen, nicht nur theoretisch.
- **Anbieter-Realität ist anderswo ähnlich:** Private File-Share-Dienste anderer Anbieter (zum Beispiel AWS EFS) sind by default ebenfalls nicht Internet-exponiert, private Konnektivität ist für Migrationspfade also erforderlich. Siehe <LinkChip href="https://docs.aws.amazon.com/efs/latest/ug/network-access.html">AWS EFS network access</LinkChip>.

## Verbindliche Voraussetzungen

- **Ziel-Erreichbarkeit vom Bridge-Host:** Der Bridge-Host kann den Ziel-SFS-Share über private Konnektivität im zugehörigen SNA-Scope mounten.
- **Quell-Erreichbarkeit vom Bridge-Host:** Der Bridge-Host erreicht den Quell-Endpunkt (Internet, privates Netz oder VPN-angebunden).
- **Endpunkt-Zugriff validiert:** Die Migrationsumgebung kann sowohl Quell- als auch Ziel-Endpunkte erreichen.
- **Protokoll-Mapping validiert:** Für jede Seite ist eine rclone-Backend-Konfiguration verfügbar.
- **Credential-Governance definiert:** Verantwortlichkeiten für Secret-Ablage und Rotation sind zugewiesen.
- **Konsistenzfenster vereinbart:** Initial-Copy-, Inkremental-Sync- und finale Freeze-Fenster sind freigegeben.

## Nicht geeignet, wenn

- **Keine sichere Bridge existiert:** Eine konforme Ausführungsumgebung erreicht nicht beide Endpunkte.
- **Ziel-SFS nicht privat erreichbar ist:** Keine Route vom Bridge-Host zum SNA-angebundenen SFS verfügbar.
- **Unkontrollierte Quell-Änderungen:** Eine schreibintensive Quelle kann kein finales Konsistenzfenster bieten.

## VPN-Machbarkeit

- **VPN ist ein valider Bridge-Enabler:** VPN kann den fehlenden privaten Pfad zwischen quellseitigen Netzen und SNA-Ressourcen bereitstellen.
- **VPN-Scope ist Site-to-Site:** STACKIT VPN ist Site-to-Site und SNA-basiert; das Bridge-Design muss also Netz-zu-Netz-Konnektivität nutzen, keine Point-to-Site-Annahmen. Siehe <LinkChip href="https://docs.stackit.cloud/products/network/connectivity-hybrid-multi-cloud/vpn/basics/product-overview/">STACKIT VPN Produktübersicht</LinkChip>.
- **Routing- und Policy-Checks sind Pflicht:** Routen-Austausch und Security-Regeln für den Data-Plane-Traffic vor dem Produktions-Sync bestätigen.

## Wann diese Variante wählen

- **rclone-Bridge wählen, wenn:** Duales NFS-Mounting auf einem Host nicht machbar ist, aber ein kontrollierter Bridge-Host sowohl Quelle als auch SFS-Ziel erreicht.
- **rclone-Bridge nicht wählen, wenn:** Keine einzelne sichere Ausführungsumgebung beide Endpunkte mit der nötigen Bandbreite und Stabilität erreicht.
- **Alternative:** Das [NFS-und-fpsync-Runbook](/de/migration/assetcontainer/stackit/runbook-file-migration-nfs-fpsync/) verwenden, wenn direktes duales NFS-Mounting möglich ist.

## Ausnahme-Variante: Quellseitiger Transfer-Host mit Internet-SFTP-Relay

Diese Variante nur nutzen, wenn duales NFS-Mounting auf einer Migrations-VM nicht machbar ist.

Wenn eine Migrations-VM in STACKIT platziert werden kann und Quelle wie Ziel über private Konnektivität gemountet werden können (inklusive Site-to-Site-VPN zur Quelle), ist das [NFS-und-fpsync-Runbook](/de/migration/assetcontainer/stackit/runbook-file-migration-nfs-fpsync/) zu bevorzugen.

```d2
style.font-size: 22
direction: right

AWS: "AWS" {
  grid-columns: 2
  EFS: "EFS-Share"
  EC2: "EC2-Transfer-Host" {
    icon: ../../../../../../../../../libs/ui/figma-assets/architecture-symbols/src/lib/assets/computing/virtual-machine.svg
  }
}

Internet: "Internet" {
  icon: ../../../../../../../../../libs/ui/figma-assets/architecture-symbols/src/lib/assets/networking/ip.svg
}

STACKIT: "STACKIT" {
  grid-columns: 2
  Jump: "Jump-Host (Public IP + SNA-NIC)" {
    icon: ../../../../../../../../../libs/ui/figma-assets/architecture-symbols/src/lib/assets/computing/virtual-machine.svg
    link: https://docs.stackit.cloud/products/compute-engine/server/
  }
  SNA: "SNA" {
    grid-columns: 2
    RT: "Routing-Tabellen"
    SFS: "STACKIT File Storage Share" {
      icon: ../../../../../../../../../libs/ui/figma-assets/architecture-symbols/src/lib/assets/computing/file-storage.svg
      link: https://docs.stackit.cloud/products/storage/file-storage/
    }
  }
}

AWS.EFS -> AWS.EC2: "NFS"
AWS.EC2 -> Internet: "SSH/SFTP"
Internet -> STACKIT.Jump: "SFTP"
STACKIT.Jump -> STACKIT.SNA.RT: "NFS über SNA"
STACKIT.SNA.RT -> STACKIT.SNA.SFS: "gerouteter Pfad"

# Invisible edges to stabilize center alignment of outer blocks.
AWS -> Internet: { style.opacity: 0 }
Internet -> STACKIT: { style.opacity: 0 }
```

- **Ablauf:** AWS EFS -> AWS EC2 (NFS-Mount) -> Internet (SSH/SFTP) -> STACKIT-Jump-Host -> SFS (NFS-Mount).
- **Tooling:** Auf AWS EC2 `rclone` mit einem SFTP-Remote auf den STACKIT-Jump-Host verwenden, alternativ `rsync`/`scp` über SSH.
- **Validierungsbedingungen:** Der Jump-Host erreicht SFS, der SFTP-Ingress ist kontrolliert, der Durchsatz ist realistisch, Integritätschecks sind deterministisch und der SFTP-Zielpfad mappt eindeutig auf den gemounteten SFS-Pfad.

## Durchsatz- und Parallelitäts-Tuning

- **Transfer-Parallelität:** Gleichzeitige Dateitransfers mit `rclone --transfers <parallelism>` erhöhen.
- **Metadaten-/Check-Parallelität:** Listing- und Vergleichsarbeit mit `--checkers <parallelism>` skalieren, um Metadaten-Engpässe zu vermeiden.
- **SFTP-Backend-Tuning:** Für SFTP-lastige Pfade backend-spezifische Optionen wie SFTP-Concurrency und Chunk-Größe anhand der Server-Fähigkeiten bewerten.
- **Qualität des Netzwerkpfads:** Latenz, Paketverlust und MTU zwischen Quell-Transfer-Host und STACKIT-Jump-Host stabilisieren.
- **Verschlüsselungs-Overhead:** SSH-/SFTP-Verschlüsselung kann auf beiden Seiten CPU-gebunden werden; CPU-Reserven auf EC2 und Jump-Host beim Skalieren der Transfers validieren.
- **NFS-Zielpfad-Tuning:** NFS-Mount-Verhalten auf dem Jump-Host tunen (`rsize`, `wsize` und `nconnect` wo unterstützt), weil die finalen Schreibzugriffe über NFS auf SFS gehen.
- **Dateigrößen-Profil beachten:** Große Dateien profitieren meist von Transfer-Parallelität; hohe Anzahlen kleiner Dateien erfordern oft stärkeres Checker-/Listing-Tuning.
- **Messdisziplin:** Effektive MB/s, Dateien/s, Retries, Transferfehler und CPU-Last nach jeder Tuning-Änderung erfassen.

## Umsetzungsvorlage

### Phase 1: Transfer-Bridge aufbauen

1. Migrations-Host vorbereiten und sichere Credential-Injection einrichten.
2. rclone-Remotes für Quelle und Ziel konfigurieren.
3. Dry-Run und Baseline-Performance-Sampling durchführen.

### Phase 2: Kontrollierte Kopie und Sync

1. Initiale Kopie mit kontrollierter Parallelität fahren.
2. Inkrementelle Sync-Zyklen fahren und Fehler-Logs prüfen.
3. Retries verfolgen und ungelöste Transferfehler klassifizieren.

### Phase 3: Finalisierung

1. Finales Quell-Freeze-Fenster auslösen.
2. Finalen Sync und Integritätschecks fahren.
3. Handover an den konsumierenden Workload freigeben und Logs archivieren.

## Validierungscheckliste

- **Transfer-Vollständigkeit:** Datei-Anzahl- und Größen-Parität validiert.
- **Integritäts-Stichprobe:** Hash-Vergleichs-Stichprobe abgeschlossen.
- **Fehlerbehandlungs-Nachweis:** Fehlgeschlagene Transfers geprüft und gelöst oder freigegeben.
- **Security-Nachweis:** Credential- und Zugriffs-Logs dokumentiert.