Bash + rclone · OneDrive ↔ Google Drive · Open-Source-Betriebsleitfaden

Cloud-Übertragung nur per Kopie mit Bash und rclone

rclone beherrscht bereits Cloud-Paginierung, Wiederholungsversuche, fortsetzbare Übertragungen und anbieterspezifische Hashwerte. Die technische Aufgabe besteht darin, diese Grundbausteine in einen ausfallsicheren, kapazitätsbewussten Betriebsablauf einzubetten.

Aktualisiert ; 20 Min. Lesezeit.

Kurzantwort

FileArk ist die einfachere verwaltete Lösung für große oder unbeaufsichtigte Migrationen: Es führt die Übertragung online aus, wurde mit Datenmengen von mehreren Terabyte getestet und prüft jedes Ergebnis vor dem Abschluss. Für Administratoren, die den Datenpfad über die Shell steuern möchten, kopiert dieser MIT-lizenzierte Bash-Wrapper begrenzte Batches über einen lokalen Zwischenspeicher, verifiziert beide Übertragungsabschnitte Byte für Byte und löscht niemals Quelldateien.

Warum rclone einbinden, statt jeden Anbieter-Client neu zu entwickeln?

rclone bietet einem Shell-Workflow eine ausgereifte Abstraktion der Anbieter, OAuth-Konfiguration, Paginierung, Wiederholungslogik, fortsetzbare Übertragungen, Steuerung der Parallelität sowie Befehle für Inventarisierung und Überprüfung. Der Wrapper kann sich daher auf die unveränderlichen Regeln der Migration konzentrieren: ausschließlich kopierende Befehle, begrenzte lokale Zwischenspeicherung, Kapazitätsreserven, deterministische Dateilisten und dauerhaft gespeicherter Fortschritt.

Dadurch läuft der Auftrag nicht automatisch ab. Die ausführende Person bleibt für die Remote-Konfiguration, die Token-Sicherheit, die Netzwerkverfügbarkeit, die Prozessüberwachung, den lokalen Datenträger, die Protokolle, Anbieterlimits, die Prüfung fehlgeschlagener Objekte und die Abnahme des Ziels verantwortlich. FileArk richtet sich an Nutzer, die diesen Ablauf als verwalteten Online-Workflow statt auf ihrem Arbeitsplatzrechner oder Server ausführen lassen möchten.

Das Skript ruft ausdrücklich niemals rclone move, sync, delete, purge oder rmdirs auf. Es verwendet lsf und about zur Ermittlung, copy für jeden Übertragungsabschnitt und check --download für die vollständige Byte-Überprüfung. Entfernt wird ausschließlich eine verifizierte Datei aus dem lokalen Zwischenspeicherverzeichnis.

Bash-Version und MIT-Lizenz herunterladen

Übertragungsprogramm für Bash und rclone herunterladen
Ein ausschließlich kopierender Wrapper mit Batch-Limits, lokalen und zielseitigen Reserven, vollständiger Byte-Überprüfung, Checkpoints, Wiederholungssteuerung und einer Demo ohne Netzwerkzugriff.
fileark-cloud-transfer.sh · Bash 4+ · rclone · jq · MIT-Lizenz

MIT-Lizenz herunterladen
Lizenzhinweis für beide Skripte von FileArk zur manuellen Übertragung.
LICENSE-fileark-cloud-transfer.txt · MIT · Klartext

Netzwerkfreie Demo für Administratoren ausführen

Terminal mit dem Cloud-Übertragungsskript von FileArk für Bash und rclone im Demomodus
Die Demo zeigt einen einzelnen begrenzten Batch, der beide Prüfgrenzen durchläuft. Sie prüft weder die rclone-Konfiguration noch stellt sie eine Verbindung zu einer Cloud her oder schreibt Daten in ein Remote-Ziel.

Die Demo kann gefahrlos ausgeführt werden, bevor rclone oder jq installiert ist, da die Argumentverarbeitung vor den Abhängigkeitsprüfungen beendet wird. Die Ausgabe nennt die untersagten destruktiven Vorgänge, zeigt beide Kapazitätsreserven und endet mit der Anzahl der Löschungen an der Quelle.

Download prüfen und einem Smoke-Test unterziehen
chmod +x fileark-cloud-transfer.sh
bash -n fileark-cloud-transfer.sh
./fileark-cloud-transfer.sh --demo
./fileark-cloud-transfer.sh --help

Erforderliche Administrationswerkzeuge installieren und konfigurieren

Installieren Sie anhand der offiziellen Anleitung eine aktuelle Version von rclone und installieren Sie jq über die Paketverwaltung Ihres Betriebssystems. Bash 4 oder neuer ist erforderlich, da der Wrapper eine strikte Fehlerbehandlung und moderne bedingte Ausdrücke verwendet.

Führen Sie rclone config aus und erstellen Sie zwei unabhängig benannte Remotes, beispielsweise onedrive: und gdrive:. Geben Sie Ihre eigene Client-ID und Ihr eigenes Client-Secret des Anbieters ein, wenn Richtlinien oder Ratenlimits dedizierte OAuth-Anwendungen erfordern. rclone speichert OAuth-Token in seiner Konfigurationsdatei. Schützen Sie diese Datei mit restriktiven Berechtigungen und bündeln Sie sie niemals mit dem Skript.

Überprüfen Sie jedes Remote mit einem schreibgeschützten Auflistungs- und Kontingentbefehl, bevor Sie den Wrapper ausführen. Verwenden Sie Pfade wie onedrive:Department/Archive, wenn nur ein Teilbaum einbezogen werden soll.

Beide Remotes konfigurieren und prüfen
rclone version
rclone config
rclone lsd onedrive:
rclone lsd gdrive:
rclone about onedrive: --json | jq
rclone about gdrive: --json | jq

Vor der Übertragung von Bytes ein deterministisches Inventar fixieren

Der Wrapper verwendet rclone lsf rekursiv mit einem expliziten Tabulator als Trennzeichen und dem Format sp. Dadurch wird zuerst die Größe und dann der Pfad ausgegeben. Er prüft, ob jede Größe numerisch und jeder Pfad relativ ist, und schließt anschließend Pfade aus, die bereits im verifizierten Checkpoint enthalten sind.

Die Bash-Version lehnt Dateinamen ab, die Tabulatoren, Wagenrückläufe oder Zeilenumbrüche enthalten, da zeilenumbruchgetrennte --files-from-raw-Listen sie nicht eindeutig darstellen können. Verwenden Sie die Python-Version oder ein speziell dafür entwickeltes Inventarformat, wenn solche Namen vorhanden sind.

Ein pfadbasierter Checkpoint ist bewusst einfach und leicht überprüfbar. Er setzt voraus, dass die Quellpfade während des Durchlaufs unverändert bleiben. Sperren Sie nach Möglichkeit Schreibzugriffe auf die Quelle oder erstellen Sie das Inventar neu und gleichen Sie es ab, wenn gleichzeitige Änderungen zu erwarten sind.

Vom Wrapper verwendeter Grundbefehl für die Inventarisierung
rclone lsf "$SOURCE" \
  --recursive \
  --files-only \
  --format "sp" \
  --separator 
    
  

\t' > "$inventory"

Abbrechen, bevor ein Batch die Reserve beansprucht

Die lokal freien Bytes werden mit df für das Dateisystem des Zwischenspeichers ermittelt. Die freien Bytes am Ziel stammen aus rclone about --json: Das Skript verwendet free, sofern dieser Wert verfügbar ist, andernfalls total minus used. Es prüft vor Beginn die insgesamt ausstehende Datenmenge und vor jedem Batch erneut die lokale sowie die zielseitige Kapazität.

Einige Anbieter oder Kontotypen stellen über rclone keine endliche Quote bereit. Der Wrapper weist auf diese Einschränkung hin und fährt unter Durchsetzung der Anbietervorgaben fort. Betrachten Sie dies als Überwachungsanforderung und nicht als Nachweis für ausreichenden Speicherplatz.

Das Batch-Limit ist keine feste Obergrenze für ein einzelnes Objekt. Eine einzelne Datei, die größer als der konfigurierte Batch ist, kann einen eigenen Batch bilden. Daher muss der freie lokale Speicherplatz für die größte Datei zuzüglich der Reserve ausreichen. Bei der vollständigen Zielüberprüfung werden Bytes vom Ziel gelesen, in der rclone-Version wird jedoch keine zweite lokale Kopie gespeichert.

Beide Seiten der lokalen Staging-Grenze überprüfen

Jeder Batch durchläuft zwei unabhängige Übertragungsabschnitte. Zuerst kopiert rclone die ausgewählten Quellpfade mit --ignore-existing in den lokalen Zwischenspeicher. Anschließend liest check --download beide Seiten und vergleicht den tatsächlichen Inhalt. Danach kopiert rclone diese zwischengespeicherten Pfade zum Ziel und wiederholt dieselbe vollständige Byte-Überprüfung.

--ignore-existing sorgt dafür, dass unterbrochene Durchläufe keine Daten zerstören: Ein vorhandenes Objekt wird nicht überschrieben. Die Überprüfung muss dennoch erfolgreich sein, bevor der Pfad in den Checkpoint aufgenommen werden kann. Wenn das vorhandene Ziel abweicht, schlägt rclone check fehl und die strikte Bash-Fehlerbehandlung beendet den Durchlauf.

Die Verwendung von --download ist langsamer und verursacht ausgehenden Datenverkehr beziehungsweise Lesevorgänge beim Anbieter. Dafür sind Sie nicht allein darauf angewiesen, dass zwei Anbieter einen gemeinsamen Hash-Algorithmus bereitstellen. Der Befehl verändert keine der beiden Seiten.

Die zwei Kopier- und Übertragungsabschnitte mit Überprüfung
rclone copy "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" --one-way --download

rclone copy "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" --one-way --download

Übertragung von OneDrive zu Google Drive mit begrenztem Staging-Speicher ausführen

Das Beispiel lässt 15 GiB des lokalen Datenträgers unberührt, hält 10 GiB in Google Drive frei, begrenzt einen normalen Batch auf 8 GiB oder 200 Dateien und verwendet vier parallele Übertragungen. Die Zielinhalte werden in einen neuen, mit einem Datum versehenen Ordner geschrieben.

Verwenden Sie zuerst --dry-run. Damit werden der Quellbestand erfasst und die Zielquote vorab geprüft, ohne Daten herunter- oder hochzuladen. Der Wrapper gibt die Gesamtzahl der noch zu übertragenden Bytes aus. Gleichen Sie diese vor dem ersten tatsächlichen Batch mit dem Umfang Ihrer Migration ab.

Vorabprüfung durchführen, dann denselben Umfang ausführen
./fileark-cloud-transfer.sh \
  --source onedrive: \
  --destination gdrive: \
  --destination-folder "OneDrive archive 2026-07-25" \
  --staging-dir /srv/fileark-staging \
  --state-file ./onedrive-to-google-verified.txt \
  --batch-gib 8 \
  --batch-files 200 \
  --local-reserve-gib 15 \
  --destination-reserve-gib 10 \
  --transfers 4 \
  --checkers 8 \
  --dry-run

# Remove only --dry-run after reviewing the preflight.

Richtung umkehren, ohne den Status wiederzuverwenden

Der Wrapper ist anbieterneutral, da rclone die Remote-Adapter bereitstellt. Tauschen Sie die Remote-Argumente aus, um Google Drive nach OneDrive zu kopieren, und verwenden Sie für diesen Durchlauf einen neuen Zielordner, einen neuen Pfad für den lokalen Zwischenspeicher und eine neue Checkpoint-Datei.

Google-eigene Formate wie Docs, Sheets und Slides sowie andere virtuelle Formate erfordern eine Exportkonfiguration in rclone und eine sorgfältige Prüfung. Überprüfen Sie die exportierten Dateierweiterungen und das Konvertierungsverhalten anhand eines Testdatensatzes. Beim Kopieren per Shell bleiben der Bearbeitungsverlauf für die Zusammenarbeit in Google, Verknüpfungen, Berechtigungen und Microsoft-spezifische Metadaten nicht erhalten.

Google Drive zu OneDrive
./fileark-cloud-transfer.sh \
  --source gdrive: \
  --destination onedrive: \
  --destination-folder "Google archive 2026-07-25" \
  --staging-dir /srv/google-staging \
  --state-file ./google-to-onedrive-verified.txt \
  --batch-gib 8 \
  --local-reserve-gib 15

Checkpoint erst nach der Überprüfung des Ziels setzen

Nachdem die Zielprüfung erfolgreich beendet wurde, hängt der Wrapper jeden relativen Pfad an einen Klartext-Checkpoint an. Anschließend löscht er die betreffende Datei aus dem lokalen Zwischenspeicher und entfernt leere lokale Verzeichnisse. Das Quell-Remote bleibt unverändert.

Während eines Durchlaufs wird der Checkpoint ausschließlich ergänzt und lässt sich mit Standardwerkzeugen leicht prüfen. Bewahren Sie ihn zusammen mit der Befehlszeile, der rclone-Version, dem Konfigurationsfingerabdruck, dem Inventar, den Protokollen, Zeitstempeln und Abnahmevermerken auf. Bearbeiten Sie ihn nicht, um einen Fehler zu unterdrücken, es sei denn, die Zieldatei wurde unabhängig überprüft.

Ein einfacher pfadbasierter Checkpoint kann ein Quellobjekt nicht erkennen, dessen Inhalt sich ändert, ohne dass sich der Pfad ändert. Setzen Sie bei veränderlichen Datensätzen Schreibvorgänge aus, erfassen Sie Anbieter-IDs und Änderungsmetadaten separat oder verwenden Sie den strengeren ID- und Größen-Checkpoint der Python-Version. Nutzen Sie für regulierte oder kollaborative Migrationen einen verwalteten Workflow mit ausdrücklicher Änderungskontrolle.

Jeden Exit-Code ungleich null als ungeklärten Batch behandeln

  • Der strikte Modus beendet das Skript, wenn ein Befehl oder eine Pipeline fehlschlägt oder eine nicht gesetzte Variable verwendet wird; das temporäre Inventarverzeichnis wird automatisch entfernt.
  • rclone wiederholt vorübergehend fehlgeschlagene Übertragungen. Dauerhafte Berechtigungs-, Kontingent-, Netzwerk-, Konflikt- oder Integritätsfehler stoppen jedoch den Batch.
  • Zwischengespeicherte Dateien ohne Checkpoint bleiben zur Prüfung verfügbar. Bei einem identischen erneuten Durchlauf wird --ignore-existing verwendet, bevor ihre Bytes geprüft werden.
  • Eine abweichende Zieldatei wird niemals überschrieben. Beheben Sie den Konflikt oder wählen Sie ein leeres Zielstammverzeichnis.
  • Wandeln Sie einen fehlgeschlagenen Kopiervorgang nicht in rclone sync oder move um. Diese Befehle folgen anderen Löschregeln.
  • Bewahren Sie Protokolle und Checkpoint auf, bis die manuelle Abnahme des Ziels abgeschlossen ist.

Den Host absichern, der zur Datenebene wird

Der Staging-Host enthält vorübergehend lesbare Kopien der Quelldaten und OAuth-Aktualisierungstoken. Verwenden Sie eine vollständige Festplattenverschlüsselung, restriktive Dateiberechtigungen, ein dediziertes Betriebssystemkonto, gepatchte Abhängigkeiten, kontrollierten Administratorzugriff und eine Richtlinie für verschlüsselte Backups, durch die Staging-Inhalte nicht unerwartet aufbewahrt werden.

Vermeiden Sie Geheimnisse in der Befehlszeile, da sie über Prozesslisten und den Shell-Verlauf offengelegt werden können. Die geschützte Konfiguration von rclone kann gespeicherte Token unkenntlich machen, ersetzt aber nicht die Sicherheit des Hosts. Entfernen Sie Token-Daten und Überreste des lokalen Zwischenspeichers nach der Abnahme der Migration gemäß Ihrer Aufbewahrungsrichtlinie.

Überwachen Sie die Audit-Protokolle des Anbieters, ausgehenden Netzwerkverkehr, Datenträgerzustand, verfügbare Inodes, Prozessstatus und rclone-Ausgabe. Ein geöffnetes Terminal ist keine Prozessüberwachung. Verwenden Sie einen genehmigten Dienstmanager oder Terminal-Multiplexer und speichern Sie Protokolle dauerhaft.

Die Migration mit Nachweisen abschließen – nicht nur mit einem erfolgreichen Befehl

  • Archivieren Sie das fixierte Inventar, den exakten Befehl, die Prüfsumme des Skripts, die rclone-Version, den Fingerabdruck der Remote-Konfiguration und den verifizierten Checkpoint.
  • Gleichen Sie die Anzahl der Dateien und die bekannten Bytewerte nach Ordnern ab, nicht nur für das gesamte Laufwerk.
  • Öffnen Sie eine risikobasierte Stichprobe aus großen, kleinen, alten, neuen, archivierten, konvertierten und tief verschachtelten Dokumenten sowie Dokumenten mit Unicode-Zeichen.
  • Testen Sie den Zugriff auf das Ziel mit repräsentativen Benutzerkonten und richten Sie erforderliche Freigaben separat neu ein.
  • Prüfen Sie übersprungene Pakete, Verknüpfungen, Links, native Dokumente, Konflikte und Anbieterwarnungen.
  • Planen Sie einen Übergangszeitraum ein, in dem die Quelle weiterhin verfügbar bleibt, und holen Sie vor jeder späteren Entscheidung über Aufbewahrung oder Löschung die ausdrückliche Zustimmung des Eigentümers ein.

Häufig gestellte Fragen

Warum verwendet das Bash-Skript rclone copy statt sync?

Beim Kopieren werden weder Quellobjekte gelöscht noch Zielobjekte entfernt, die in der Quelle nicht vorhanden sind. Die Synchronisierung folgt anderen Abgleichs- und Löschregeln und ist daher bewusst nicht Teil dieses Workflows.

Verändert rclone check --download eine der beiden Clouds?

Nein. Der Befehl liest und vergleicht Dateiinhalte. Das Skript verwendet ihn nach jedem Kopierschritt, sodass ein Pfad erst dann in einem Checkpoint erfasst wird, wenn die Bytes am Ziel mit den zwischengespeicherten Bytes übereinstimmen.

Was geschieht, wenn das Ziel bereits eine Datei enthält?

Beim Kopieren wird --ignore-existing verwendet, anschließend erfolgt eine vollständige Byte-Überprüfung. Ein identisches Objekt kann die Prüfung bestehen; bei einem abweichenden Objekt schlägt sie fehl. Das Skript überschreibt die konfliktbehaftete Datei niemals.

Kann das Skript Dateien verarbeiten, die größer als ein Batch sind?

Ja. Eine einzelne übergroße Datei bildet einen eigenen Batch. Das Staging-Dateisystem muss über genügend Speicherplatz für diese Datei und die konfigurierte lokale Reserve verfügen.

Werden damit Berechtigungen, Versionen oder cloudnative Daten zur Zusammenarbeit migriert?

Nein. Über rclone werden Dateiinhalte und Pfade kopiert. Zugriffskontrollen, Versionen, Labels, Kommentare, Verknüpfungen, Links, Aufbewahrungsregeln und anbieterspezifisches Verhalten müssen separat geplant und überprüft werden.

Für diese Anleitung verwendete offizielle Ressourcen

Anleitung lesen