Proton Drive: Kryptografisches Datenmodell und Sync-Betrieb

Proton Drive ist ein zentral betriebener Cloud-Dateispeicher, dessen Clients Inhalte und wesentliche Metadaten vor dem Upload verschlüsseln. Der Dienst verbindet Webzugriff, Desktop-Synchronisation, mobile Apps, Freigaben, Versionen und eine Kommandozeile mit einem Ende-zu-Ende-verschlüsselten Datenmodell. Die Supportübersicht nennt Web-, Windows-, macOS-, Android- und iOS/iPadOS-Zugriff; die offizielle Drive CLI ergänzt skriptbare Operationen auf Windows, macOS und Linux.

Für Admins ist Proton Drive weder ein klassisches Fileshare noch ein blosses Uploadportal. Ein autorisierter Client verwaltet Kontositzung und Schlüssel, löst einen verschlüsselten Baum auf, beobachtet lokale Änderungen, erzeugt Revisionen, verschlüsselt Blöcke und synchronisiert serverseitige Ereignisse zurück ins Dateisystem. Die Server bleiben für Verfügbarkeit, Autorisierung, Speicherquote, Versionen und Freigaben zuständig, ohne Dateiinhalt oder verschlüsselte Namen im Klartext verarbeiten zu können.

Die Erklärung folgt einer Datei vom Client über Schlüssel, verschlüsselte Blöcke und API bis zur serverseitigen Ablage. Sync, Freigaben, Versionierung, Diagnose und unabhängige Sicherung bauen auf diesem Datenweg auf.

Proton Drive speichert Daten zentral, verlagert Verschlüsselung und Signaturprüfung aber in vertrauenswürdige Clients. Der Artikel folgt einer Datei von der lokalen Änderung über Schlüsselhierarchie, Blöcke und Revision bis zu Sync, Freigabe und Wiederherstellung.

Architektur: zentraler Dienst, vertrauenswürdiger Client

Proton wählte einen zentralen Cloudspeicher statt eines Peer-to-Peer-Netzes. Server stellen API, Objektspeicher, Ereignisse, Membership, Quoten, Versionen und Verfügbarkeit bereit; Clients übernehmen Klartextverarbeitung und Kryptografie. Die Begründung für dieses Modell beschreibt Proton in der Einordnung zentraler und dezentraler Speicher.

Der technische Pfad hat sechs Ebenen:

1. Identität und Sitzung: Der Client authentisiert ein Proton-Konto, lädt verschlüsselte Adressschlüssel und entsperrt sie lokal.
2. Volume und Share: Ein Volume begrenzt den Speicherraum. Shares definieren Baumwurzeln, Mitglieder und Rechte.
3. Node und Link: Datei oder Ordner ist ein Node; der Link ordnet ihn in die verschlüsselte Hierarchie ein.
4. Revision und Block: Eine Datei kann mehrere Revisionen besitzen. Inhalt wird in Blöcke zerlegt und clientseitig verschlüsselt.
5. API und Objektspeicher: Der Client übermittelt verschlüsselte Metadaten, Schlüsselpakete, Manifeste und Blöcke über HTTPS.
6. Lokales Dateisystem: Desktopclients projizieren den Cloudbaum als Platzhalter oder lokale Datei, beobachten Änderungen und lösen Konflikte.

Das Proton-Drive-Sicherheitsmodell dokumentiert Volume, Share, Node, Link und hierarchische Schlüssel. Die Kryptografie-Aktualisierung von 2026 beschreibt zusätzlich Node, Revision, Block und Content-Key-Paket der gemeinsam genutzten Clientengine.

Datenmodell: Volume, Share, Node, Link und Revision

Ein Volume ist ein zugewiesener Speicherraum. Seine Standardfreigabe verweist auf die Wurzel des privaten Verzeichnisbaums. Weitere Shares können auf Dateien oder Ordner zeigen und Mitglieder mit Rollen verbinden. Ein Share ist deshalb gleichzeitig Zugriffspunkt und kryptografische Grenze.

Ein Node beschreibt Datei oder Ordner und trägt technische Attribute sowie kryptografisches Material. Ein Link positioniert den Node im Baum und verbindet ihn mit seinem Elternknoten. Für Dateien verwalten Revisionen aufeinanderfolgende Inhaltsstände; eine Revision referenziert verschlüsselte Blöcke. Die begriffliche Trennung erklärt wichtige Betriebsphänomene:

• Umbenennen ändert die verschlüsselte Baumbezeichnung, nicht zwingend den Dateiinhalt.
• Verschieben ändert Elternbezug und damit kryptografisch geschützte Linkinformationen.
• Ersetzen erzeugt eine Revision desselben Dateiobjekts, während «beide behalten» einen zweiten Node erzeugt.
• Teilen delegiert Zugriff auf eine Share-Wurzel, statt alle darunterliegenden Inhalte serverseitig zu entschlüsseln.
• Löschen verschiebt einen Eintrag zunächst in den Proton-Drive-Papierkorb; lokale Papierkörbe bilden einen separaten Zustand.

Die offizielle Versionsverwaltung beschreibt Replace, Keep both, Skip und das Wiederherstellen älterer Revisionen. Die Lösch- und Restore-Dokumentation erklärt den Unterschied zwischen Cloud-Papierkorb und lokalem Papierkorb.

Volume, Share, Node und Revision beschreiben, welches Objekt gespeichert wird. Die Schlüsselhierarchie erklärt anschliessend, wer Namen, Metadaten und Inhalt entschlüsseln und signieren kann.

Schlüsselhierarchie und OpenPGP

Schlüssel und Passphrasen werden auf dem Client erzeugt und nur verschlüsselt an den Server übertragen. Das Sicherheitsmodell verwendet mehrere Ebenen:

1. Eine Proton-Adresse besitzt ein asymmetrisches Schlüsselpaar.
2. Für einen Share wird eine zufällige Share-Passphrase und ein Share-Schlüssel erzeugt.
3. Die Share-Passphrase wird für jedes berechtigte Mitglied mit dessen Adressschlüssel verschlüsselt und signiert.
4. Jeder Datei- oder Ordner-Node besitzt Node-Schlüssel und Node-Passphrase.
5. Die Node-Passphrase wird mit dem Schlüssel des Elternordners beziehungsweise der Share-Wurzel geschützt.
6. Name und weitere Payloads werden in diesem hierarchischen Kontext verschlüsselt.
7. Dateiinhalte verwenden einen symmetrischen Content Key, dessen Schlüsselpaket durch den Node-Schlüssel geschützt wird.

OpenPGP dient dabei als Nachrichten- und Schlüsselpaketformat. Asymmetrische Kryptografie schützt die symmetrischen Sitzungsschlüssel; symmetrische Verschlüsselung verarbeitet die eigentlichen Daten effizient. Die normative Grundlage für OpenPGP bildet RFC 9580.

Proton beschreibt für neu erzeugte Dateien seit der Kryptografieumstellung v6-PKESK-Pakete, v2-SEIPD und AES-GCM. Das Schema einer Datei bleibt über ihre Revisionen gebunden: Ein Client muss beim Ersetzen das zum bestehenden Dateiobjekt passende Paketschema verwenden, sonst wird die Revision abgewiesen (Kryptografie-Aktualisierung). Das ist ein Interoperabilitätsgrund, Clients kontrolliert zu aktualisieren.

Verschlüsselt, signiert und serverlesbar

«Ende-zu-Ende-verschlüsselt» bedeutet nicht, dass der Server keinerlei Betriebsdaten sieht. Proton nennt in der Drive-Supportübersicht Dateiinhalt, Dateinamen und Ordnernamen als E2EE, weist aber zugleich darauf hin, dass bestimmte Felder wie die Dateigrösse serverlesbar bleiben, damit Funktionen wie Sortierung möglich sind.

Für ein Bedrohungsmodell werden Datenklassen getrennt:

Digitale Signaturen bestätigen Uploader und unveränderte Payloads. Die Signaturverwaltung erläutert OpenPGP-Signaturprüfung und Warnungen. Eine Signatur beweist nicht, dass der Inhalt harmlos oder fachlich richtig ist; sie belegt Herkunft beziehungsweise Unverändertheit im geprüften Schlüsselkontext.

Blöcke, Revisionen und Commitgrenze

Dateien werden clientseitig in Blöcke zerlegt. Der Client erzeugt oder übernimmt den Content Key, verschlüsselt die Blöcke, überträgt sie und veröffentlicht die Revision mit den zugehörigen kryptografischen Informationen. Der Server kann Blöcke speichern und ausliefern, ohne den Klartext zu kennen.

Der Uploadfortschritt ist noch kein fachlicher Commit. Ein Admin unterscheidet:

• lokale Datei vollständig gelesen,
• alle Blöcke verschlüsselt,
• alle Blöcke erfolgreich übertragen,
• Revision serverseitig angenommen,
• Eventcursor fortgeschrieben,
• Datei in einem zweiten Client auflösbar,
• Signatur und Inhalt beim Download verifiziert.

Bei grossen Downloads entschlüsselt und prüft der Client Daten lokal. Der Webclient nutzt für umfangreiche Daten einen Streamingpfad mit Service Worker, damit nicht das gesamte Archiv im Browserspeicher liegen muss; Proton beschreibt diesen Ablauf in Web-Download und Streaming.

Drive SDK und Clientaufbau

Die Clientlandschaft entstand ursprünglich aus plattformspezifischen Implementierungen. Das gemeinsame Drive SDK vereinheitlicht Konto-, API-, Cache-, Node-, Share-, Upload-, Download- und Kryptografiepfade. Der Quellcode liegt im offiziellen Proton Drive SDK Repository; der JavaScript-/TypeScript-Paketvertrag ist als @protontech/drive-sdk veröffentlicht.

Die offizielle GitHub-Organisation zeigt die wesentlichen Technologiestacks (ProtonDriveApps):

Der SDK-Ansatz reduziert unterschiedliche Kryptografie- und Dateiimplementierungen, hebt Plattformgrenzen aber nicht auf. Windows-Namensregeln, macOS-File-Provider-Verhalten, mobile Hintergrundlimits und Linux-Desktopintegration bleiben Aufgaben des jeweiligen Clients.

Die kryptografische API ist noch kein Dateisynchronisationsdienst. Der Desktop-Client beobachtet lokale und entfernte Änderungen, ordnet sie einander zu und entscheidet über Upload, Download oder Konflikt.

Desktop-Sync als Zustandsmaschine

Desktop-Sync hält keine einfache Bytekopie, sondern reconciliert zwei veränderliche Namensräume. Ein abstrahierter Zyklus lautet:

1. Lokalen Dateisystemzustand und Cloud-Eventcursor laden.
2. Lokale Änderungen, serverseitige Ereignisse und ausstehende Transfers ermitteln.
3. Namen und Plattformregeln normalisieren beziehungsweise Konflikte markieren.
4. Benötigte Schlüsselhierarchie und Nodes auflösen.
5. Upload, Download, Move, Delete oder Hydration planen.
6. Inhalt in Blöcken übertragen und Revision committen.
7. Lokale Platzhalter, Attribute, Cache und Cursor atomar fortschreiben.
8. Fehler mit stabilem Objektbezug erneut versuchen oder sichtbar eskalieren.

Der Syncstatus «synchronisiert» ist nur für den betrachteten Client und Cursor aussagekräftig. Ein zweiter Client, eine Freigabe oder ein getrenntes Backup liefert den stärkeren End-to-End-Nachweis.

On-Demand-Dateien und lokale Zustände

Windows und macOS stellen den Cloudbaum im Dateimanager dar, ohne alle Inhalte permanent lokal zu speichern. Die Windows-On-Demand-Dokumentation unterscheidet Available when online, Available on this device und Always available on this device. Die macOS-Anleitung kennt Online Only, temporär lokal und Make Available Offline.

Ein sichtbarer Dateiname beweist daher keine lokale Kopie. Für Backup, Antivirus, Indexer, Buildsystem oder Attachment-Workflow muss geklärt sein, ob die Datei:

• nur als Platzhalter existiert,
• beim Öffnen hydriert wird,
• vorübergehend lokal zwischengespeichert ist,
• ausdrücklich offline angeheftet wurde,
• lokal geändert, aber noch nicht hochgeladen ist,
• wegen eines Fehlers nur auf diesem Gerät liegt.

Das Verschachteln zweier On-Demand-Cloudclients im selben Baum ist riskant. Die Windows-Fehlerhilfe nennt Dateien eines anderen Cloudspeichers ausdrücklich als Problem, wenn sie nur online vorliegen. Ein Backupjob pinnt die Eingangsmenge lokal oder verwendet die offizielle CLI für explizite Transfers.

Konflikte, Namen und Mehrgerätebetrieb

Konflikte entstehen, wenn Client und Cloud denselben logischen Node unabhängig verändern oder die Zielplattform einen Namen nicht darstellen kann. Typische Klassen sind:

• parallele Inhaltsänderung derselben Revision,
• Delete gegen Modify,
• Rename gegen Move,
• Gross-/Kleinschreibung auf Plattformen mit anderer Case-Semantik,
• unter Windows unzulässige Zeichen oder reservierte Namen,
• gleichnamige Uploads mit Replace, Keep both oder Skip,
• Offlineänderung nach langem Eventrückstand,
• lokale Datei während des Transfers durch eine Anwendung gesperrt.

Proton dokumentiert, dass ein Konflikt eine umbenannte Datei oder neue Version erzeugen kann (Shared-with-me unter Windows). Die Windows-Fehlerhilfe beschreibt offene Dateien und unzulässige Namen (häufige Syncprobleme). Admins suchen nicht nur nach «Fehlern», sondern nach Konfliktkopien, ausstehenden Uploads und Dateien, die wegen Namensregeln nie in der Cloud ankamen.

Clientinventar, Binärdatei und Logs

Ein verwalteter Endpoint inventarisiert Plattform, Clientpaket, Signatur, Autostart, Konto, Syncwurzel, lokale Verfügbarkeit, freien Platz und Logpfad. Versionsnummern gehören in das Laufzeitinventar und nicht als statischer Artikelfakt.

Get-Process ProtonDrive -ErrorAction SilentlyContinue
Get-AuthenticodeSignature "$env:LOCALAPPDATA\Proton\Drive\ProtonDrive.exe"
Get-ChildItem "$env:LOCALAPPDATA\Proton\ProtonDrive\Logs"
proton-drive version

proton-drive version
file ./proton-drive
sha256sum ./proton-drive
ldd ./proton-drive

Get-Process prüft den Windows-Prozess; Get-AuthenticodeSignature die Codesignatur; Get-ChildItem inventarisiert Logs. Unter Unix identifiziert file das Binary, sha256sum seinen Hash und ldd dynamische Abhängigkeiten. Der unterstützte Logzugriff für Windows und macOS steht in Proton Drive Logs.

CLI: explizite Operation statt Hintergrund-Sync

Die Proton Drive CLI ist ein SDK-basierter Client für Windows, macOS und Linux. Anmeldung erfolgt per Browserflow; Sitzungen werden laut CLI-Einführung in Windows Credential Manager, macOS Keychain beziehungsweise libsecret gespeichert. Die CLI listet, lädt hoch und herunter, verwaltet Dateien, Papierkorb, Freigaben und Einladungen. Sie läuft als Einzeloperation und beendet sich danach.

Die wichtigste Betriebsgrenze ist ausdrücklich dokumentiert: Die CLI ersetzt keine Desktop-Sync-Engine. Ein geplanter Upload erkennt nicht automatisch Deletes, Renames, bidirektionale Konflikte oder den Erfolg auf einem zweiten Gerät. Wer die CLI als Backuptransport verwendet, implementiert Quellinventar, Richtung, Löschregel, Wiederholung, Exitcode, Zielverifikation und Aufbewahrung selbst.

proton-drive auth login
proton-drive filesystem list /my-files
proton-drive filesystem list /my-files --json | ConvertFrom-Json
proton-drive sharing status /my-files/Reports

proton-drive auth login
proton-drive filesystem list /my-files
proton-drive filesystem list /my-files --json | jq .
proton-drive sharing status /my-files/Reports

Alle CLI-Kommandos und Hilfen dokumentiert Using Proton Drive CLI. ConvertFrom-Json und jq verarbeiten maschinenlesbare Ausgabe. Automationen verlassen sich auf JSONfelder und Exitcode, nicht auf lokalisierte Bildschirmtexte.

Upload, Konfliktstrategie und Verifikation

Ein wiederholbarer Upload nennt lokale Quelle, Zielroot und Konfliktstrategie. Wildcards werden von der aufrufenden Shell expandiert und können unter Windows und Unix unterschiedliche Mengen liefern. Kritische Jobs erzeugen deshalb vorab ein Manifest mit Pfad, Grösse und Hash.

Get-ChildItem .\reports -File -Recurse |
  Get-FileHash -Algorithm SHA256 |
  Export-Csv .\reports-manifest.csv -NoTypeInformation
proton-drive filesystem upload .\reports\* /my-files/Reports --conflict-strategy skip
proton-drive filesystem list /my-files/Reports --json | Out-File .\drive-result.json

find ./reports -type f -print0 | sort -z | xargs -0 sha256sum > reports-manifest.sha256
proton-drive filesystem upload ./reports/* /my-files/Reports --conflict-strategy skip
proton-drive filesystem list /my-files/Reports --json > drive-result.json
jq . drive-result.json

Get-FileHash, Export-Csv, find, sort und xargs erzeugen die lokale Sollmenge. Die Providerliste beweist aber noch keine Inhaltsgleichheit. Für kritische Daten folgt ein Download in ein getrenntes Ziel und ein Hashvergleich.

Download und End-to-End-Abnahme

Ein Downloadtest verwendet einen neuen Zielpfad, damit keine vorhandene lokale Datei das Ergebnis verschleiert. Danach wird gegen das Quellmanifest geprüft. Bei mehreren Revisionen muss der Test festlegen, welche Revision erwartet wird.

New-Item -ItemType Directory .\restore-test
proton-drive filesystem download /my-files/Reports .\restore-test
Get-ChildItem .\restore-test -File -Recurse |
  Get-FileHash -Algorithm SHA256 |
  Export-Csv .\restore-manifest.csv -NoTypeInformation

mkdir -p ./restore-test
proton-drive filesystem download /my-files/Reports ./restore-test
find ./restore-test -type f -print0 | sort -z | xargs -0 sha256sum > restore-manifest.sha256
diff -u reports-manifest.sha256 restore-manifest.sha256

New-Item und mkdir erzeugen das isolierte Ziel; diff vergleicht Manifeste. Absolute oder unterschiedlich präfixierte Pfade werden vor dem Vergleich normalisiert.

Sharing an Konten und über öffentliche Links

Proton Drive kennt mindestens zwei Freigabemodelle:

• Mitgliedschaft/Einladung: Eine Person wird mit Viewer- oder Editorrolle Mitglied eines Shares. Die Share-Passphrase wird für den Adressschlüssel des Mitglieds verpackt.
• Öffentlicher Link: Ein Link erlaubt Zugriff ohne Proton-Konto. Ein Passwort schützt die Share-Passphrase; Link und Passwort bilden gemeinsam das Zugriffsgeheimnis.

Die Zugriffsverwaltung dokumentiert Rollen, Editor-Delegation, Widerruf und getrennte Einstellungen für E-Mail-Einladung und Public Link. Passwort und Ablaufdatum begrenzen Linkzugriff. Wird ein zufälliges Passwort als URL-Fragment mitgeschickt, sehen Browser und Empfänger den vollständigen Link; das Fragment wird zwar nicht als HTTP-Pfad an den Server gesendet, kann aber über Zwischenablage, Browserhistorie, Screenshots oder Endpointtelemetrie abfliessen.

Admins inventarisieren Owner, Share-Wurzel, Mitglieder, Rolle, Weitergaberecht, Public-Link-Status, Ablaufdatum und letzte Überprüfung. Ein Editor darf je nach Einstellung selbst teilen und Rechte ändern. Offboarding widerruft deshalb nicht nur das Konto, sondern prüft alle Shares und externen Links.

Versionen, Papierkorb und Backup

Versionshistorie speichert frühere Revisionen desselben Dateiobjekts. Eine wiederhergestellte Revision löscht neuere Versionen nicht automatisch. Papierkorb hält gelöschte Nodes bis zur endgültigen Löschung. Beide Funktionen sind wertvoll, bleiben aber innerhalb derselben administrativen und kryptografischen Ausfallbereich.

Sie schützen nicht zuverlässig gegen:

• Verlust oder Nichtwiederherstellbarkeit des Kontoschlüssels,
• fehlerhafte Rechte oder böswillige endgültige Löschung,
• Quoten-/Vertrags- und Providerereignisse,
• Fehler, die vor der ersten erfolgreichen Cloudrevision entstanden,
• unbemerkte Syncauslassungen,
• organisationsweiten Identitäts- oder Endpointkompromiss.

Ein unabhängiges Backup liest eine definierte Cloudmenge mit einem autorisierten Client aus, schreibt sie in ein getrennt verwaltetes Ziel, versieht sie mit Manifest, Aufbewahrung und unveränderbarer Historie und führt Restoretests durch. NIST SP 800-34 behandelt Backup, alternative Speicherung und Recoverytests als zusammenhängende Contingency-Planning-Kontrollen (NIST SP 800-34 Rev. 1). Grundlagen stehen unter Backup und Disaster Recovery und Storage.

Identität, Sitzung und Endpointvertrauen

Ende-zu-Ende-Verschlüsselung verschiebt Vertrauen vom Provider in Client, Konto und Endpoint. Wer das entsperrte Gerät, die Browsersitzung oder das Konto kontrolliert, kann im Namen des Benutzers entschlüsseln und Änderungen signieren. Deshalb gehören MFA, Hardware-Sicherheitsschlüssel, Geräteschutz, Sessionwiderruf, Clientherkunft und Schutz des lokalen Caches zusammen.

Das Bedrohungsmodell nennt unter anderem kompromittierte Geräte, Phishing und die Echtheit offizieller Clients als Grenzen. Die Quelloffenheit ermöglicht Codeprüfung, ersetzt aber nicht die Verifikation des tatsächlich ausgeführten Binaries und seines Updatepfads.

Malwareprüfung ist ebenfalls begrenzt: Die optionale Erkennung schädlicher Dateien vergleicht auf Wunsch einen Hash mit bekannten Malwarehashes. Sie entschlüsselt nicht serverseitig den gesamten Bestand, erkennt keine unbekannten Inhalte und ersetzt keinen Endpointsensor.

Passwortreset und Datenwiederherstellung

Kontowiederherstellung und Datenwiederherstellung sind verschiedene Vorgänge. Ein Passwortreset kann den Zugang zum Konto wiederherstellen, aber die bisherigen privaten Schlüssel zunächst unzugänglich machen. Proton Drive zeigt die alten Daten dann als gesperrt.

Die offizielle Drive-Datenwiederherstellung nennt vorheriges Passwort, Recovery Phrase oder Recovery File als Entsperrwege. Neue Uploads nach dem Reset können unter neuen Schlüsseln entstehen, während alter Bestand gesperrt bleibt; Fotos und Alben können einen zusätzlichen Zusammenführungsschritt benötigen.

Ein Organisations-Runbook dokumentiert daher:

• wer einen Passwortreset auslösen darf,
• welche Recoverymethoden vorher eingerichtet und getestet sind,
• wo Recovery Phrase oder File offline und zugriffsgeschützt liegen,
• wie alte und neue Schlüsselzustände erkannt werden,
• wie Shares und Mitglieder nach Recovery geprüft werden,
• wann ein gesperrtes Drive keinesfalls gelöscht werden darf.

«Unlock later» bewahrt die Chance auf spätere Recovery. «Delete locked drive» ist eine irreversible Datenlöschung und gehört nicht in eine unbestätigte Standardprozedur.

Sind Identität, Schlüssel und lokaler Zustand plausibel, folgt der Netzwerkpfad. Proxy, TLS, API-Endpunkte und blockierter Transfer müssen getrennt vom kryptografischen Datenmodell geprüft werden.

Netzwerkpfad und Transportdiagnose

HTTPS schützt den Transport zwischen Client und Proton-API beziehungsweise Speicherendpunkten. Es ersetzt die Ende-zu-Ende-Verschlüsselung nicht, schützt aber Sitzungs- und Betriebsmetadaten, Endpunktidentität und Verfügbarkeit. Proxy, DNS-Filter, TLS Inspection, VPN, MTU oder instabile Verbindungen können Control-Plane-Requests und Blocktransfers unterschiedlich beeinträchtigen.

Resolve-DnsName drive.proton.me
Test-NetConnection drive.proton.me -Port 443
curl.exe -sS -D - -o NUL https://drive.proton.me/
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 443

getent ahosts drive.proton.me
curl -sS -D - -o /dev/null https://drive.proton.me/
ss -ntp state established '( dport = :443 )'
openssl s_client -connect drive.proton.me:443 -servername drive.proton.me -brief

Resolve-DnsName und getent prüfen Namensauflösung; Test-NetConnection TCP 443; curl HTTP und Redirects; Get-NetTCPConnection beziehungsweise ss aktive Verbindungen; openssl s_client TLS und SNI. Der Test gegen die Webdomain beweist nicht, dass jeder API-/Blockendpunkt erreichbar ist; die Clientlogs liefern die tatsächlich fehlgeschlagene Ziel- und Requestklasse.

Beobachtbarkeit und Diagnosekette

Eine sinnvolle Diagnose beginnt am fachlichen Objekt:

1. Konto, Share, logischer Pfad und betroffener Client bestimmen.
2. Lokalen Zustand unterscheiden: Platzhalter, hydriert, gepinnt, verändert, gesperrt oder fehlerhaft.
3. Aktivitätsansicht und Logs auf Node-/Revision-/Transferbezug prüfen.
4. Freien lokalen Platz und Cloudquote kontrollieren.
5. Namens- und Pfadkompatibilität prüfen.
6. DNS, TCP, TLS und Proxy/VPN anhand des echten Endpunkts prüfen.
7. Signatur-, Entschlüsselungs- und Schlüsselwarnungen getrennt von Transportfehlern behandeln.
8. Datei mit der offiziellen CLI oder einem zweiten Client listen beziehungsweise herunterladen.
9. Downloadhash und erwartete Revision vergleichen.
10. Erst danach Pause/Resume, Reauthentisierung, Update oder Cacheeingriff erwägen.

Die Windows-Syncfehler nennen Fortschritt, offene Dateien, weitere Cloudclients, Pause/Resume, Namensregeln und Netzwerk. Diese Benutzerhilfen werden im Adminbetrieb mit Objektinventar und End-to-End-Verifikation ergänzt. Allgemeine Methodik steht unter Troubleshooting.

Leistungs- und Kapazitätsmodell

Die Kosten entstehen nicht nur aus übertragenen Bytes. Viele kleine Dateien erzeugen pro Node Schlüssel-, Metadaten-, API- und Signaturarbeit. Tiefe Bäume erfordern wiederholte Hierarchieauflösung. Ein grosser Dateiinhalt lässt sich dagegen in parallelen Blöcken effizienter verarbeiten. Proton weist in der Windows-Fehlerhilfe darauf hin, dass viele kleine oder tief verschachtelte Dateien langsamer synchronisieren können als eine gleich grosse Einzeldatei.

Kapazitätsplanung berücksichtigt:

• Cloudquote einschliesslich Versionen und Papierkorb,
• lokale Offline- und Cachezustände,
• temporären Platz für Upload, Download und Konfliktkopien,
• CPU für Kryptografie und Hashing,
• Dateianzahl und Baumtiefe,
• Ereignisrückstand nach Offlinezeiten,
• Fair-Use-/Drosselverhalten bei automatisierten Transfers.

Die CLI-Einführung warnt davor, unveränderte Daten wiederholt vollständig hochzuladen, und verweist auf Fair Use (Proton Drive CLI). Ein geplanter Job pflegt daher ein eigenes Quellmanifest oder prüft Zielzustand, statt jeden Lauf als Vollupload zu behandeln.

Betrieb mit Windows, macOS und Linux

Windows und macOS bieten Dateimanagerintegration und Hintergrund-Sync. Mobile Apps verwalten Upload, Download, Offlineobjekte und Fotos, sind aber kein identischer Ersatz für einen Desktop-Filesystemdienst. Die offizielle CLI macht Datei- und Sharingoperationen auf allen drei Desktopbetriebssystemen skriptbar.

Im Juni 2026 veröffentlichte Proton die CLI und bezeichnete eine vollwertige Linux-Desktopanwendung mit Hintergrund-Sync als separates, noch in Arbeit befindliches Vorhaben (CLI-Ankündigung). Diese historische Abgrenzung bleibt wichtig: Selbst wenn sich die Plattformpalette weiterentwickelt, werden CLI-Operation, Mount und bidirektionale Sync-Engine nicht gleichgesetzt. Für den jeweiligen Rollout wird die Release-Notes-Seite als zeitabhängige Quelle geprüft.

In Serverjobs läuft Browserauthentisierung kontrolliert und das resultierende Sitzungstoken im Betriebssystem-Secretspeicher eines dedizierten Servicekontos. Ein headless Job erhält kein persönliches Homeverzeichnis eines Admins. Exitcode, JSONresultat, Quellmanifest und Zielverifikation werden aufbewahrt; Secrets und Freigabelinks werden aus Logs entfernt.

Versionen und Papierkorb schützen vor einzelnen Bedienfehlern, ersetzen aber kein unabhängiges Recovery. Das Runbook muss Konto, Schlüsselzugriff, lokale Daten und verifizierten Export gemeinsam behandeln.

Backup- und Recovery-Runbook

Proton Drive kann Ziel einer Sicherungskopie sein, bleibt aber kein Ersatz für ein Recoverydesign. Ein belastbares Runbook umfasst:

1. Quellmenge und Source of Truth definieren.
2. Lokale On-Demand-Daten vor dateibasiertem Backup vollständig hydrieren oder direkt per CLI exportieren.
3. Dateimanifest mit Pfad, Grösse und Hash erzeugen.
4. Upload mit expliziter Konflikt- und Löschregel ausführen.
5. CLI-Exitcode und Zielauflistung archivieren.
6. Stichprobe oder vollständigen Download in einen isolierten Pfad durchführen.
7. Hashes und erwartete Revisionen vergleichen.
8. Freigaben, Versionierung, Papierkorb und Aufbewahrung dokumentieren.
9. Proton-Konto- und Datenrecovery getrennt testen.
10. Unabhängige zweite Kopie ausserhalb derselben Konto- und Providerdomäne behalten.

RPO bezieht sich auf die letzte nachweislich in Proton commitete und verifizierte Revision, nicht auf den Zeitpunkt des lokalen Dateischreibens. RTO umfasst Kontozugang, Schlüsselentsperrung, Listing, Download, Entschlüsselung, Bandbreite und Zielwiederherstellung.

Technische Geschichte

Proton entwickelte Drive als Ergänzung des verschlüsselten Proton-Ökosystems. Das 2020 veröffentlichte Sicherheitsmodell etablierte zentralen Speicher mit clientseitiger OpenPGP-Schlüsselhierarchie, verschlüsselten Namen, Node-Bäumen, Shares, signierten Blöcken und Linkfreigaben. Web- und Mobileclients kamen vor den Desktop-Sync-Clients; Version History wurde 2023 als eigener Revisionspfad eingeführt (Einführung der Versionshistorie).

Windows und macOS ergänzten Hintergrund-Sync und On-Demand-Dateien mit plattformspezifischer Explorer-/Finderintegration. Die getrennten Implementierungen führten schrittweise zum gemeinsamen Drive SDK. Proton beschrieb Anfang 2026 den SDK-Rollout über Web, Windows, macOS, Android und iOS (SDK-Entwicklung).

Im Juni 2026 folgten zwei technische Schritte: eine gemeinsame Kryptografieumstellung auf v6 PKESK, v2 SEIPD und AES-GCM für neue Dateiobjekte sowie die SDK-basierte CLI für Windows, macOS und Linux. Damit wurde ein offiziell skriptbarer Zugriff möglich, ohne die kryptografische Clientlogik nachzubauen. Die Architektur bleibt trotzdem clientzentriert: Server speichern und koordinieren, autorisierte Clients entschlüsseln, signieren und reconciliieren.

Admin-Checkliste

Bei clientseitig verschlüsseltem Speicher müssen Datenmodell, Schlüssel, Synchronisation und unabhängige Sicherung gemeinsam verstanden werden. Die Checkliste verdichtet diese Punkte für die Betriebsfreigabe.

• Datenmodell: Volume, Share, Node, Link, Revision und Block auseinanderhalten.
• Kryptografie: Adress-, Share-, Node- und Content-Key-Kontext sowie Paketschema dokumentieren.
• Metadaten: E2EE-Felder und serverlesbare Betriebsfelder im Bedrohungsmodell trennen.
• Clients: Plattform, Technologie, SDK, Dateisystemintegration, Binärsignatur und Logpfad inventarisieren.
• Sync: lokalen Zustand, Eventcursor, Konfliktkopien, Namen und ausstehende Transfers beobachten.
• CLI: explizite Dateioperation nicht als permanente Sync- oder Backupengine behandeln.
• Sharing: Owner, Mitglieder, Rollen, Editor-Delegation, Public Link, Passwort und Ablauf prüfen.
• Recovery: Kontopasswort, Datenentsperrung, Recovery Phrase/File und Sharezugriff getrennt testen.
• Backup: unabhängige Kopie, Manifest, Versionierung und Restore-Download vorhalten.
• Abnahme: Datei auf zweitem Client oder isoliertem Download entschlüsseln, signatur- und hashgeprüft öffnen.