Rclone: Remotes, Datenvergleich und VFS-Betrieb

Rclone ist ein quelloffenes Datenbewegungswerkzeug für lokale Dateisysteme, Netzwerkprotokolle, Cloudlaufwerke und Objektspeicher. Die Rclone-Projektseite beschreibt es als Kommandozeilenprogramm zur Verwaltung von Dateien auf Cloudspeichern. Es bietet diesen Systemen eine gemeinsame Oberfläche für Listing, Kopie, Synchronisation, Verifikation, Mount, Verschlüsselung und Servicezugriff. Diese Einheitlichkeit ist nützlich, darf aber nicht mit einheitlicher Speichersemantik verwechselt werden: Hashes, Änderungszeiten, Gross-/Kleinschreibung, leere Verzeichnisse, Metadaten, serverseitige Kopien und Konsistenz unterscheiden sich je Backend.

Für Admins ist rclone kein «Cloud-Explorer», sondern eine Datenpipeline. Ihre Korrektheit hängt von Quelle und Ziel, Richtung, Vergleichskriterium, Filtermenge, Löschregel, Retryzustand, Credentials, Backendfähigkeiten und abschliessender Verifikation ab. Ein Prozess kann mit 100 Prozent übertragenen Bytes trotzdem fachlich falsch sein, wenn er den falschen Namespace, eine veraltete Listingansicht oder eine unvollständige Filtermenge verwendet.

Die Erklärung folgt einem rclone-Befehl von Quelle und Remote über Vergleich, Checker und Transfers bis zum Backend. Filter, Crypt, VFS, Automatisierung, Sicherheit und Verifikation werden danach entlang desselben Jobwegs erklärt.

Rclone übersetzt ein einheitliches Datei- und Verzeichnismodell in die APIs sehr unterschiedlicher Speicherdienste. Der Artikel beginnt deshalb bei Remote und Backendfähigkeiten, behandelt danach Kopiersemantik und Verifikation und endet bei Mount, Sicherheit und Recovery.

Architektur: Kommando, Dateisystemmodell und Backend

Das in Go geschriebene Programm verbindet mehrere Schichten:

1. Kommando und Jobdefinition: copy, sync, move, check, bisync, mount, serve oder ein RC-Aufruf definieren Richtung und Operation.
2. Filter und Vergleich: Pfadregeln, Grösse, Änderungszeit, Hash, Metadata und Flags bestimmen die betrachtete Objektmenge und Gleichheit.
3. Transferengine: Lister, Checker und Transferworker planen Operationen, begrenzen Parallelität und sammeln Fehler.
4. Fs/Object-Schnittstellenmodell: Rclone modelliert Verzeichnisse, Objekte und optionale Backendfeatures über gemeinsame Go-Schnittstellen.
5. Backendadapter: S3, SFTP, WebDAV, Drive, OneDrive, lokale Dateisysteme und weitere Dienste übersetzen den Vertrag in ihre APIs.
6. Transport und Provider: HTTP/TLS, SSH/SFTP oder lokaler I/O treffen auf Rate Limits, Konsistenz, Versionierung und Providerpolicy.

Die offizielle Backendübersicht zeigt explizit, welche Systeme Hashes, ModTime, case-insensitive Namen, Duplikate, MIME-Typen und Metadaten unterstützen (Overview of cloud storage systems). Der Quellbaum trennt Backends, Kommandos und das gemeinsame fs-Schnittstellenmodell; offizielle Builds bündeln die ausgewählten Adapter in ein Binary (rclone source repository, Install from source).

Remote-Syntax und Namespace

Ein konfiguriertes Remote wird als name:pfad angesprochen. Der Doppelpunkt trennt den Remotenamen vom Pfad; ein lokaler Pfad ohne Remotepräfix verwendet das Local-Backend. Connection Strings wie :sftp,host=example.net:/data können ein Backend ohne gespeicherten Remotenamen instanziieren. Diese Flexibilität erhöht zugleich das Risiko, dass ein Tippfehler einen lokalen statt entfernten Pfad bezeichnet (Rclone documentation – remotes).

Rclone überträgt bei Verzeichniskommandos den Inhalt des Quellpfads, nicht automatisch den Namen des Quellverzeichnisses. Die Semantik entspricht dem bei rsync vertrauten abschliessenden Slash. Quelle, Ziel und erwarteter Zielbaum werden deshalb im Runbook als konkrete Beispiele festgehalten (rclone copy).

rclone version
rclone config file
rclone listremotes --long
rclone backend features archive:
rclone about archive:

rclone version
rclone config file
rclone listremotes --long
rclone backend features archive:
rclone about archive:

rclone version identifiziert Binary, Betriebssystem und Build; rclone config file zeigt die tatsächlich geladene Konfiguration; rclone listremotes inventarisiert Remotes; rclone backend features liefert die Fähigkeiten des aufgelösten Backends; rclone about fragt Kapazitätsinformationen ab, sofern der Dienst sie anbietet.

Backendfähigkeiten und durchscheinende Unterschiede

Die gemeinsame Oberfläche kann nur Fähigkeiten nutzen, die das Backend oder ein Wrapper bereitstellt. Wichtige Unterschiede sind:

Die Support-Tiers bewerten Backends anhand von Tests und Fähigkeiten, nicht anhand eines pauschalen Funktionsversprechens (Backend Support Tiers). Provider- und Backenddokumentation gehören daher zur Jobdefinition. Ein S3-kompatibler Dienst kann andere Multipart-, Hash- oder Server-Side-Copy-Grenzen besitzen als ein anderer S3-Anbieter.

Konfiguration, Credentials und Auflösungsreihenfolge

rclone.conf speichert Remotedefinitionen und häufig OAuth-Tokens oder Zugangsdaten. «Obscured» Passwortfelder sind keine sichere Verschlüsselung. Die gesamte Konfiguration kann mit einem Passwort verschlüsselt werden; für unbeaufsichtigte Jobs kann ein externes Password Command das Geheimnis aus einem Secret Store liefern (Configuration encryption, rclone config encryption).

Rclone kann Backendoptionen aus Kommandozeile, remote-spezifischen Environmentvariablen, backendweiten Variablen und Konfigurationsdatei beziehen. Die Prioritätsreihenfolge muss bei Services und Containern dokumentiert werden, weil eine geerbte Variable das erwartete rclone.conf überschreiben kann (Environment variables). Debuglogs zeigen aufgelöste Optionen, können aber sensible Endpunkte oder Pfade enthalten.

Admins schützen mindestens:

• rclone.conf und dessen Dateirechte;
• Config-Passwort beziehungsweise Password Command;
• OAuth-Refresh-Tokens, Client Secrets, Access Keys und SSH Private Keys;
• Crypt-Passwort und optionalen Salt;
• Servicekonto-, Bucket- und Folderberechtigungen;
• Filter- und Jobdefinitionen als Teil der Change Control.

Ein Konfigurationsbackup ohne Entschlüsselungsgeheimnis ist kein getestetes Recovery. Umgekehrt darf eine verschlüsselte Konfiguration mit schwachem Passwort nicht öffentlich abgelegt werden.

Sind Remote, Namespace und Zugangsdaten geklärt, entscheidet der gewählte Befehl über die Datenwirkung. Besonders sync ist keine harmlose Kopie, sondern setzt eine Seite als gewünschte Wahrheit durch.

Copy, Sync und Move: Richtung ist Policy

rclone copy kopiert neue oder unterschiedliche Dateien in das Ziel und löscht dort keine zusätzlichen Objekte. rclone sync macht das Ziel zur Abbildung der Quelle und kann dafür Zielobjekte löschen. rclone move kopiert beziehungsweise verschiebt und entfernt die Quelle erst nach erfolgreicher Dateioperation.

Diese Befehle sind nicht austauschbar:

rclone sync 'D:\Export' 'archive:current' `
  --dry-run --check-first --backup-dir 'archive:history/prechange' `
  --combined '.\sync-plan.txt' --log-level INFO --log-file '.\sync-dry-run.log'
if ($LASTEXITCODE -ne 0) { throw "rclone dry-run failed: $LASTEXITCODE" }
Get-Content '.\sync-plan.txt' | Group-Object { $_[0] } | Select-Object Name,Count

rclone sync /srv/export archive:current \
  --dry-run --check-first --backup-dir archive:history/prechange \
  --combined ./sync-plan.txt --log-level INFO --log-file ./sync-dry-run.log
test "$?" -eq 0 || exit "$?"
cut -c1 ./sync-plan.txt | sort | uniq -c

--dry-run verhindert Änderungen, beweist aber nur die zum Testzeitpunkt sichtbaren Listings und Optionen. --check-first trennt Vergleich und Transferphase. --backup-dir verschiebt überschriebene oder gelöschte Zielobjekte in einen separaten Pfad, sofern das Backend die nötige serverseitige Operation unterstützt (Global options – backup-dir and retries). Der Combined Report klassifiziert gleiche, fehlende, unterschiedliche und fehlerhafte Pfade.

Was bedeutet «identisch»?

Rclone überspringt Dateien standardmässig anhand von Grösse und Änderungszeit oder nutzt einen gemeinsamen Hash, wenn Kommando und Backend dies erlauben. Der genaue Fingerprint hängt von Fähigkeiten und Flags ab. --checksum, --size-only, --ignore-times, --update, --ignore-size, Metadatenoptionen und ModTime-Präzision verändern die Entscheidung (Overview – Hash and ModTime).

Ein providerseitiger ETag ist nicht universell ein Inhalts-MD5. Multipartupload, Verschlüsselung oder Providerimplementierung können seine Bedeutung verändern. Rclone verwendet die vom Backend explizit deklarierte Hashfähigkeit, nicht eine pauschale ETag-Annahme.

Zwischen case-sensitivem Linux und typischerweise case-insensitivem Windows können report.pdf und Report.pdf nicht verlustfrei abgebildet werden. Cloudlaufwerke können doppelte Namen oder eigene Objekt-IDs erlauben. Eine Vorprüfung auf Namenskollisionen und unerlaubte Zeichen ist deshalb Teil jeder Migration.

Transferengine, Parallelität und Pacer

Die Transferengine listet Quelle und Ziel, vergleicht Einträge, plant Checks und Transfers und führt Backendoperationen parallel aus. --checkers steuert parallele Prüfungen, --transfers die Übertragungen. --fast-list kann API-Aufrufe reduzieren, benötigt aber mehr Speicher, weil grosse Listings gesammelt werden (Rclone documentation – performance options).

Parallelität ist keine reine Geschwindigkeitsoption. Mehr Worker erhöhen offene Dateien, Memory, API-Requests, Multipartzustände und Providerdruck. Bei kleinen Objekten dominiert Listing-/Requestlatenz, bei grossen Objekten Bandbreite und Multipartkonfiguration. Cloud-zu-Cloud-Kopien können serverseitig bleiben oder über den rclone-Host laufen; das wird im Log und Backendfeature geprüft.

Backends implementieren Pacing für API-Rate-Limits. Low-Level-Retries behandeln einzelne Requests; High-Level-Retries wiederholen eine fehlgeschlagene Gesamtoperation. Erst der Schlussstatus entscheidet, ob vorherige Fehler erfolgreich kompensiert wurden (Retries). Ein Scheduler bewertet den Prozess-Exitcode und nicht das Auftreten des Wortes ERROR irgendwo im Log.

Filter definieren die Datenmenge

Include-, Exclude-, Size-, Age- und Files-from-Regeln bestimmen, welche Pfade sichtbar sind. Filter beziehen sich auf den angegebenen Root; ein Shellglob im Quellpfad ersetzt keine rclone-Filterregel. Die Reihenfolge von Include und Exclude kann relevant sein (Rclone Filtering).

Ändert sich ein Filter, ändert sich die fachliche Datenmenge. Bei sync können bisher sichtbare Objekte als gelöscht erscheinen; --delete-excluded ist besonders gefährlich. Filterdateien werden versioniert, gehasht und gemeinsam mit Dry-Run-Report und Jobdefinition freigegeben. Ein sicherer Test verwendet rclone ls oder lsf mit denselben Regeln, bevor ein schreibendes Kommando folgt.

Ein Exitcode ohne Übertragungsfehler beweist nur den Lauf, nicht die vollständige Gleichheit beider Bestände. check vergleicht Quellen und Ziele mit den Fähigkeiten des jeweiligen Backends.

Verifikation: Check statt Übertragungszähler

rclone check verändert keine Daten. Es vergleicht Grösse und gemeinsame Hashes, kann Reports für Matches, Unterschiede und fehlende Pfade erzeugen und mit --download Inhalte lesen, wenn kein gemeinsamer Remotehash existiert. Für Crypt existiert rclone cryptcheck, das Klartextquelle und verschlüsseltes Ziel geeignet vergleicht.

rclone check 'D:\Export' 'archive:current' `
  --combined '.\check-report.txt' --checkers 8 `
  --log-level INFO --log-file '.\check.log'
$code = $LASTEXITCODE
Get-Content '.\check-report.txt' | Group-Object { $_[0] } | Select-Object Name,Count
if ($code -ne 0) { throw "Integrity check failed: $code" }

rclone check /srv/export archive:current \
  --combined ./check-report.txt --checkers 8 \
  --log-level INFO --log-file ./check.log
code=$?
cut -c1 ./check-report.txt | sort | uniq -c
test "$code" -eq 0 || exit "$code"

Ein Hashvergleich beweist Gleichheit für den verwendeten Algorithmus und Namespace. Er beweist nicht automatisch ACLs, Retention, Providerobjektversionen, Verzeichnismetadaten oder fachliche Lesbarkeit. Für kritische Archive ergänzt ein Restoretest die technische Prüfung.

Crypt: Daten- und Namensverschlüsselung

Crypt ist ein Wrapperbackend über einem anderen Remote. Dateiinhalt wird mit NaCl SecretBox auf Basis von XSalsa20 und Poly1305 verschlüsselt; Dateinamen und Verzeichnisnamen werden standardmässig ebenfalls transformiert (Crypt backend). Der Provider sieht Ciphertext, Grössenmuster, Zugriffszeiten und Objektanzahl; Crypt ist daher Inhalts- und Namensschutz, keine vollständige Traffic- oder Metadatenanonymisierung.

Passwort und optionaler Salt werden in der Konfiguration nur «obscured» gespeichert, sofern nicht die gesamte Konfiguration verschlüsselt ist. Verlust beider Recoveryinformationen macht die Daten unlesbar. Vor Rotation oder Änderung der Namensverschlüsselung wird ein zweiter, lesender Remote gegen dieselben Daten getestet.

Crypt verändert Grössen und Hashmöglichkeiten. Ein normaler check zwischen Klartext und Ciphertext kann deshalb nicht einfach denselben Providerhash erwarten. cryptcheck oder ein kontrollierter Downloadpfad ist die richtige Prüfebene.

Kopierbefehle arbeiten explizit auf Objekten. Ein VFS-Mount muss daraus dagegen laufende Dateisystemoperationen nachbilden und braucht dafür Cache, Schreibmodus und klare Konsistenzannahmen.

VFS-Mount: Objektspeicher ist kein POSIX-Dateisystem

rclone mount stellt ein Remote über FUSE beziehungsweise WinFsp als Dateisystem dar. Die VFS-Schicht übersetzt Dateioperationen in Objektoperationen. Da Cloudobjekte gewöhnlich nicht in der Mitte geändert oder beliebig erweitert werden können, puffert oder ersetzt Rclone Objekte.

Vier Cachemodi bilden unterschiedliche Verträge:

Der Directory Cache hält Namen und Metadaten im Speicher. Externe Änderungen erscheinen erst über Polling oder nach Ablauf beziehungsweise Flush. Buffer ist pro geöffneter Datei; maximaler Memorybedarf wächst mit buffer-size × open files. Zwei Prozesse dürfen nicht denselben überlappenden VFS-Cache mit aktivem File Caching verwenden, weil dies Daten beschädigen kann (VFS file caching).

rclone mount crypt-archive: X: `
  --vfs-cache-mode writes --cache-dir 'D:\rclone-cache\archive' `
  --vfs-cache-max-size 100G --vfs-cache-min-free-space 20G `
  --log-file 'D:\Logs\rclone-mount.log' --log-level INFO

rclone mount crypt-archive: /mnt/archive \
  --vfs-cache-mode writes --cache-dir /var/cache/rclone/archive \
  --vfs-cache-max-size 100G --vfs-cache-min-free-space 20G \
  --log-file /var/log/rclone-mount.log --log-level INFO

Auf Windows stellt WinFsp die Dateisystembrücke bereit; auf Linux und anderen Unixsystemen verwendet Rclone FUSE. Ein Service wartet auf Netzwerk, Konfiguration und Mountbereitschaft, besitzt einen kontrollierten Unmountpfad und überwacht lokales Cachevolume. Container-Mounts benötigen zusätzliche Device- und Mount-Propagation-Rechte und vergrössern die Privilegienfläche (Rclone mount in Docker).

Bisync: zwei Quellen der Wahrheit

rclone bisync erkennt Änderungen auf beiden Seiten anhand gespeicherter Listings und überträgt Deltas bidirektional. Damit entsteht persistenter Jobzustand ausserhalb der Nutzdaten. Ein verlorenes oder inkonsistentes Arbeitsverzeichnis kann eine Resync-Phase erfordern.

Bisync besitzt Sicherheitsprüfungen für Erreichbarkeit und ungewöhnlich viele Löschungen. Filteränderungen verändern die sichtbare Datenmenge und erzwingen bewusst ein Resync. Wenn Anwendungen Inhalt ohne Änderung von Grösse und ModTime verändern, kann die Standarderkennung versagen. Bidirektionale Synchronisation wird daher nur eingesetzt, wenn Konfliktpolicy, Clock-/Timestampverhalten, Access Checks, Max-Delete, Arbeitsdateibackup und menschliche Auflösung dokumentiert sind.

Bisync ist kein Multi-Master-Dateisystem mit verteiltem Locking. Gleichzeitige Edits, Umbenennungen und Offlinephasen bleiben fachliche Konflikte.

Remote Control API, Metrics und Serve-Modi

Mit --rc oder rclone rcd öffnet Rclone eine HTTP-API. Sie kann Jobs starten, Remotes konfigurieren, lokale Dateien lesen oder schreiben und unter Umständen OS-Kommandos im Kontext des rclone-Benutzers ausführen. Die Dokumentation bewertet Zugriff auf RC deshalb als äquivalent zu Shellzugriff (Remote Control / API).

RC lauscht standardmässig lokal. Bei Netzwerkfreigabe sind starke Authentisierung, TLS oder ein geschützter Reverse Proxy, Firewallallowlist und minimale Prozessrechte erforderlich. --rc-no-auth gehört nicht auf ein erreichbares Interface. Der OpenMetrics-Endpunkt kann Transfer- und Jobmetriken exponieren; auch dort können Remotenamen und Pfade sensible Metadaten sein.

rclone rc core/version
rclone rc core/stats
$metrics = Invoke-WebRequest 'http://127.0.0.1:5572/metrics'
$metrics.StatusCode
$metrics.Content | Select-String 'rclone_' | Select-Object -First 20

rclone rc core/version
rclone rc core/stats
curl --silent --show-error --fail http://127.0.0.1:5572/metrics | grep '^rclone_' | head -n 20

Invoke-WebRequest und curl prüfen den lokalen HTTP-Endpunkt. rclone rc verwendet dieselbe API und übernimmt Authentisierungsparameter aus der Jobkonfiguration.

Rclone kann Remotes ausserdem über HTTP, WebDAV, SFTP, FTP, NFS, DLNA oder S3-kompatible Serve-Modi anbieten. Damit wechselt die Systemrolle vom Client zum Server. Listeneradresse, Authentisierung, Protokollsicherheit, VFS-Cache und Datenrechte werden dann wie bei einem eigenständigen Dienst gehärtet (Rclone serve).

Logging, Statistik und Exitcodes

Logs unterscheiden DEBUG, INFO, NOTICE und ERROR. Für Maschinenverarbeitung steht JSON-Logging zur Verfügung. Statistik zeigt Checks, Transfers, Fehler, Bytes, Geschwindigkeit und ETA. Ein kurzer Transferred-Zähler ist kein dauerhafter Auditnachweis; ein Job speichert Startzeit, Quell-/Zielroot, Filterhash, Rclone-Build, aufgelöste nicht-sensitive Optionen, Schlussstatistik und Exitcode.

Die dokumentierten Exitcodes unterscheiden Erfolg, Syntaxfehler, fehlende Pfade, temporäre, weniger schwere und fatale Fehler sowie erreichte Transfer- oder Zeitlimits (List of exit codes). --error-on-no-transfer kann einen erfolgreichen Lauf ohne Transfer gesondert signalisieren. Scheduler und Monitoring behandeln die Codes nach Jobtyp; ein erwartbar leerer Incremental-Job ist anders zu bewerten als ein ausgebliebener täglicher Export.

Ein High-Level-Retry kann frühe Fehlermeldungen erfolgreich beheben. Umgekehrt kann ein Prozess viel übertragen und am Ende wegen weniger ungelöster Objekte nonzero enden. Alarmiert wird auf Schlussstatus, Fehleranzahl, Retryerschöpfung, Jobdauer, fehlenden Heartbeat und Verifikationsresultat.

Sicherheit des Datenpfads

Rclone erbt die Rechte seines Prozesskontos und der Remotecredentials. Ein sync mit Delete-Rechten ist ein hochprivilegierter Löschagent. Least Privilege trennt lesende Quelle, schreibendes Ziel, Versionierungs-/Retentionrechte und administrative Bucketaktionen.

TLS-Zertifikatsprüfung bleibt aktiv. --no-check-certificate deaktiviert Ketten- und Hostnamenprüfung und ist laut Dokumentation nur für Tests bestimmt (TLS options). SFTP-Backends prüfen Host Keys mit einer gepflegten Known-Hosts- oder Fingerprintpolicy; APIendpunkte werden nicht durch unkontrollierte Proxies umgeleitet.

Filter, --backup-dir, Objektversionierung und Object Lock begrenzen unterschiedliche Risiken. Ein Backup-Verzeichnis im selben Konto schützt nicht vor Accountkompromittierung oder Provider-Löschung. Storage, Verschlüsselung und Härtung behandeln die darunterliegenden Kontrollflächen.

Die Diagnose trennt lokalen Pfad, Rclone-Filter, Backend-API, Authentisierung, Rate Limit und Netzweg. Nur so wird sichtbar, ob eine Datei nie ausgewählt, nicht übertragen oder vom Ziel anders dargestellt wurde.

Netzwerk- und Backenddiagnose

Eine rclone-Fehlermeldung kann aus Namensauflösung, TCP, TLS, Proxy, Providerauthentisierung, API-Rate-Limit, Backendübersetzung, lokalem Dateisystem oder Vergleichslogik stammen. Diagnose folgt dem Pfad:

1. Binary, Konfigurationspfad und aufgelösten Remotenamen bestätigen.
2. DNS, Port und TLS des konkreten Endpunkts prüfen.
3. rclone lsd oder lsjson als minimalen lesenden Backendtest verwenden.
4. Mit -vv Request-/Retryphase und Backendfeatures erfassen, ohne Secrets zu veröffentlichen.
5. Quelle/Ziel, Filter und Fingerprintentscheidung prüfen.
6. Schlussstatus, Exitcode und Provider-Auditlog korrelieren.

Resolve-DnsName $env:RCLONE_ENDPOINT
Test-NetConnection $env:RCLONE_ENDPOINT -Port 443
rclone lsd archive: -vv --dump headers --log-file '.\rclone-debug.log'
rclone lsjson archive:health --max-depth 1 --metadata

dig +short "$RCLONE_ENDPOINT"
nc -vz "$RCLONE_ENDPOINT" 443
openssl s_client -connect "$RCLONE_ENDPOINT:443" -servername "$RCLONE_ENDPOINT" -brief </dev/null
rclone lsd archive: -vv --dump headers --log-file ./rclone-debug.log
rclone lsjson archive:health --max-depth 1 --metadata

Resolve-DnsName, Test-NetConnection, dig, nc, openssl s_client, rclone lsd und rclone lsjson trennen Transport, Authentisierung, Listing und Objektsicht. Headerdumps werden vor Weitergabe auf Tokens, Signaturen, Cookies und Pfade geprüft. DNS, TCP, TLS und Troubleshooting vertiefen die Phasen.

Typische Fehlerbilder

Rclone meldet oft den Schritt, an dem ein Job sichtbar scheitert, nicht automatisch die ursprüngliche Ursache. Die Tabelle verbindet deshalb Symptom, wahrscheinlichen Auslöser und den Beleg, der die Vermutung bestätigt oder widerlegt.

Backup, Recovery und Reconciliation

Rclone ist häufig Teil eines Backups, aber selbst kein unveränderliches Backupmodell. sync repliziert Löschungen und Verschlüsselungsschäden. copy bewahrt zusätzliche Zielobjekte, kann aber bestehende Versionen überschreiben. Schutz entsteht durch Zielversionierung, Retention/Object Lock, getrennte Credentials, --backup-dir, unveränderliche Snapshots und Restoretests.

Zum Recoveryset gehören:

• freigegebenes rclone-Binary oder verifizierbares Releaseartefakt;
• verschlüsseltes rclone.conf plus getrenntes Entschlüsselungsgeheimnis;
• Providercredentials und deren Wiederbeschaffung;
• Crypt-Passwort und Salt;
• Job-, Filter- und Environmentdefinitionen;
• Bisync-Arbeitsdateien;
• nicht hochgeladene VFS-Cacheobjekte und ihre Zuordnung;
• Dry-Run-, Combined-, Check- und Exitcodereports;
• Versionierungs-, Retention- und Restoreverfahren des Ziels.

Ein Restore wird in einen getrennten Pfad ausgeführt und anschliessend mit Hash, Anzahl, Grösse, Metadatenstichprobe und Anwendungstest geprüft. Reconciliation vergleicht Source of Truth, Zielversionen, VFS-Writeback und Schedulerzustand. Backup und Disaster Recovery beschreibt RPO/RTO und Abnahme übergreifend.

Technische Geschichte

Nick Craig-Wood begann das Projekt mit einem ersten Commit im November 2012. Der Gründer dokumentierte diesen Ursprung zum vierzehnten Jahrestag und verlinkte den initialen Quellstand (Happy 14th Birthday rclone, initial commit).

Rclone übernahm die vertraute Richtungssyntax von rsync, ersetzte aber dessen blockbasierte Deltaannahmen durch Objekt- und Provideroperationen. Cloudspeicher bieten gewöhnlich keine serverseitige rsync-Rolling-Checksum-Schnittstelle; Rclone vergleicht vollständige Objekte anhand der verfügbaren Fingerprints und überträgt sie entsprechend.

Mit wachsender Backendzahl entwickelte sich das zentrale Fs/Object-Schnittstellenmodell samt optionaler Features. Crypt ergänzte clientseitige Verschlüsselung; Mount und VFS machten Objektspeicher für dateibasierte Anwendungen zugänglich; die Remote Control API wurde 2018 stark ausgebaut; Bisync ergänzte persistenten bidirektionalen Abgleich. Der Changelog dokumentiert diese Entwicklung und sicherheitsrelevante Korrekturen. Für den Betrieb bleibt er deshalb die zeitabhängige Ergänzung zu diesem Architekturartikel.

Die technische Linie bleibt konsistent: ein portables Go-Binary, viele eingebaute Backends, gemeinsame Befehle und explizit durchscheinende Providerunterschiede. Genau diese Unterschiede machen Rclone für Admins leistungsfähig und zugleich revisionsbedürftig.

Admin-Checkliste

Vor einem produktiven Job sind mindestens folgende Punkte belegt:

• Binaryherkunft, Konfigurationspfad und Remoteauflösung sind eindeutig.
• Quelle, Ziel, Richtung und erwarteter Zielbaum stehen im Runbook.
• Backendfeatures für Hash, ModTime, Case, Metadata, Copy/Move und Listing sind geprüft.
• Filterdatei und Jobparameter sind versioniert; Dry Run und Combined Report wurden abgenommen.
• Delete-, Max-Delete-, Backup-Dir-, Versionierungs- und Retentionpolicy passen zusammen.
• Credentials besitzen nur nötige Rechte; Config, Crypt-Passwort und Salt sind recoverbar.
• Transfers, Checkers, Pacer und Bandbreite respektieren Host und Provider.
• VFS-Cache besitzt eigenes Volume, Kapazitätsalarm, geordneten Stop und Writebackprüfung.
• RC/Serve lauscht nur kontrolliert und ist wie Shellzugriff geschützt.
• Erfolg wird über Schlussstatus, Exitcode, Checkreport und Restoretest belegt.