Obsidian und iCloud unter Windows: Wenn die Synchronisation hängen bleibt

Aktualisiert am 4. August 2026 / in Digitale Archive

Ein Obsidian-Vault lässt sich über iCloud Drive zwischen Windows, iPhone und iPad bereitstellen. Kritisch wird es, wenn iCloud unter Windows dauerhaft bei wenigen Objekten stehen bleibt. Dieser Praxisbericht zeigt an einem realen Fall, warum vor einer Reparatur eine unabhängige Sicherung nötig ist und weshalb grüne Haken allein keine Vollständigkeit beweisen.

Kurz gesagt

Eine Synchronisationsanzeige beschreibt die Arbeit eines Programms. Sie beweist nicht automatisch, dass der fachlich richtige und vollständige Obsidian-Bestand vorliegt.

Der sichere Ablauf lautet:

1. Obsidian schließen und weitere Änderungen stoppen.
2. Den gesamten Vault außerhalb des synchronisierten Ordners sichern.
3. Dateizahl und Gesamtgröße der Sicherung kontrollieren.
4. Zuerst nur den iCloud-Drive-Prozess neu starten.
5. Einen tieferen Index-Neuaufbau nur mit vollständiger Sicherung durchführen.
6. Danach Dateien, Pfade und Prüfsummen mit der Sicherung vergleichen.
7. Erst nach dieser Prüfung normal weiterarbeiten.

Das konkrete Fehlerbild

Die iCloud-App unter Windows meldete, dass einige Objekte nicht synchronisiert werden konnten. Der Fortschritt blieb bei „Upload: 48 Objekte von 51“ stehen. Ein normaler Neustart des iCloud-Drive-Prozesses baute die Warteschlange neu auf, doch anschließend blieben erneut drei Objekte übrig.

Im Protokoll erschienen unter anderem sinngemäß diese Meldungen:

• Der Inhalt wurde während der Uploadvorbereitung verändert.
• Ein übergeordneter Ordnereintrag fehlte in der lokalen Datenbank.
• Ein verlorenes Objekt wurde gefunden.
• Eine Datei befand sich im Zustand „nicht unterstützt“ und „inaktiv“.

Das Problem war damit enger eingegrenzt: Nicht der gesamte Vault war unbrauchbar. Ein Dateieintrag und seine frühere Ordnerzuordnung waren zwischen lokalem Dateisystem, iCloud-Datenbank und Cloud-Bestand nicht mehr konsistent.

Warum wenige Dateien entscheidend sein können

Ein Vault besteht nicht nur aus geöffneten Markdown-Dateien. Auch Anhänge, Vorlagen, Konfigurationen und Werkzeugdokumentationen gehören zum Arbeitsbestand. Schon wenige fehlende Dateien können tote Links oder unvollständige Abläufe verursachen.

Wenn der Zähler über längere Zeit unverändert bleibt, sollte deshalb nicht parallel weitergearbeitet werden. Im konkreten Fall wurden Obsidian und alle Werkzeuge geschlossen, die im Vault Dateien erzeugen konnten. Ein kurzzeitiger Fehler rechtfertigt noch keinen tiefen Eingriff; erst ein reproduzierbarer Stillstand führt zum nächsten Schritt.

Ein synchronisierter Arbeitsordner ist ein beweglicher Bestand. Vor einer Reparatur braucht er einen ruhenden, unabhängigen Vergleichsstand.

Der wichtigste Schritt: eine unabhängige Sicherung

Vor dem Neustart eines Synchronisationsindexes wurde der vollständige Obsidian-Vault in einen neuen Ordner außerhalb von iCloud kopiert. Entscheidend war, nicht nur einige auffällige Dateien zu sichern.

Anschließend wurden Quelle und Sicherung anhand von vier Punkten verglichen:

• Anzahl der Dateien
• Summe der Dateigrößen
• Lesbarkeit kritischer Dateien
• SHA-256-Prüfsumme der konkret auffälligen Bilddatei

Für eine einfache Bestandskontrolle unter PowerShell eignen sich beispielsweise folgende Befehle. Die Pfade müssen vor der Ausführung bewusst an die eigene Umgebung angepasst werden:

$vault = "D:\Pfad\zum\Obsidian-Vault"
$files = Get-ChildItem -LiteralPath $vault -Recurse -File -Force
$files.Count
($files | Measure-Object -Property Length -Sum).Sum

Eine einzelne kritische Datei lässt sich so prüfen:

Get-FileHash -LiteralPath "D:\Pfad\zur\Datei.png" -Algorithm SHA256

Eine Prüfsumme beweist keine fachliche Richtigkeit. Sie belegt aber, ob zwei Dateikopien binär identisch sind. Der Unterschied zwischen Backup und Integritätsprüfung wird im Fachartikel Bit-Rot, Prüfsummen und regelmäßige Datenmigration ausführlicher erklärt.

Vom einfachen Neustart zum Index-Neuaufbau

Die Reparatur wurde bewusst gestuft durchgeführt.

Stufe 1: iCloud Drive neu starten

Zuerst wurde ausschließlich der laufende iCloud-Drive-Prozess beendet und neu gestartet. Andere Apple-Dienste, Obsidian und die Dateien selbst blieben unangetastet.

Danach bewertete iCloud die Warteschlange neu. Aus dem großen Zähler wurde eine kleinere Restmenge. Viele Dateien waren also bereits in Ordnung; der verwaiste Eintrag blieb jedoch bestehen.

Stufe 2: lokalen Index neu aufbauen

Erst nach der vollständigen Sicherung wurde der lokale iCloud-Drive-Index separat gesichert und neu erzeugt. Dabei verschwand der lokale iCloud-Baum vorübergehend und wurde aus dem Cloud-Bestand neu registriert.

Dieser Eingriff ist riskant: Lokal noch nicht hochgeladene Dateien oder Löschungen können vom Serverstand abweichen. Deshalb enthält der Artikel bewusst keine pauschale Löschanweisung für Datenbankdateien. Speicherorte und Verhalten können sich ändern; ein Index-Neuaufbau braucht immer einen geprüften Rückweg.

Grüne Haken waren noch nicht das Ende

Nach dem Neuaufbau erschienen die Ordner wieder und der Explorer zeigte grüne Haken. Der Vergleich mit der Sicherung zeigte trotzdem:

• gleiche Gesamtzahl von Dateien,
• aber vier Pfade nur im neuen Cloud-Stand,
• und vier andere Pfade nur in der Sicherung.

Die gleiche Dateizahl hatte zwei unterschiedliche Bestände verdeckt. Einige ältere Serverdateien waren zurückgekehrt, während vier lokale Dateien fehlten. Diese wurden aus der Sicherung wiederhergestellt. Zurückgekehrte Dateien blieben unangetastet, weil eine technische Abweichung keine automatische Löschentscheidung rechtfertigt.

Zum Abschluss wurden alle 851 gemeinsamen Dateien per SHA-256 miteinander verglichen. Das Ergebnis war eindeutig:

• 851 gemeinsame Dateien,
• 851 identische Prüfsummen,
• keine inhaltliche Abweichung,
• kein Lesefehler.

Erst damit war der Arbeitsbestand belastbar bestätigt.

Was grüne Haken wirklich aussagen

Ein grüner Haken zeigt den technischen Status des Synchronisationsdienstes. Er beantwortet aber nicht diese fachlichen Fragen:

• Ist dies die erwartete Fassung?
• Fehlt eine Datei, die nur lokal vorhanden war?
• Ist eine ältere Serverdatei zurückgekehrt?
• Stimmen Anhänge und interne Verweise?
• Ist der gesamte Vault mit dem Vergleichsstand identisch?

Die gleiche Unterscheidung gilt auch beim Löschen. Der Artikel iCloud Drive: Wenn gelöschte Dateien unter Windows wieder auftauchen erklärt, warum lokale Entfernung, Cloud-Löschung und erneut geladene Dateien nicht dasselbe sind.

iCloud, Nextcloud oder Obsidian Sync?

Der Vorfall führte zur Frage, ob künftig iCloud, Nextcloud oder ein spezialisierter Dienst genutzt werden sollte. Entscheidend sind die Rollen:

• iCloud Drive passt in eine Apple-geprägte Umgebung und bindet Windows ein.
• Nextcloud kann in einem Windows-zentrierten Ablauf mehr sichtbare Aktivitäts- und Konfliktinformationen bieten; der Zugriff muss auf allen Geräten getestet werden.
• Obsidian Sync ist auf Vaults zugeschnitten, bleibt aber ein zusätzlicher Dienst.

Unabhängig vom Werkzeug gelten drei Regeln:

1. Niemals zwei Synchronisationsdienste gleichzeitig denselben Vault verwalten lassen.
2. Synchronisation nicht mit Backup verwechseln.
3. Vor einer Migration einen kleinen Test-Vault in beide Richtungen prüfen.

Wer einen Anbieterwechsel vorbereitet, braucht außerdem eine Cloud-Exit-Strategie. Der Vault muss als normaler Dateibestand vollständig exportiert, gelesen und unabhängig gesichert werden können.

Praxis-Checkliste

Vor der Reparatur:

• Obsidian und schreibende Hilfswerkzeuge schließen
• Stillstand über einen angemessenen Zeitraum beobachten
• vollständigen Vault außerhalb der Synchronisation sichern
• Dateizahl und Gesamtgröße dokumentieren
• kritische Dateien öffnen und Prüfsummen bilden

Nach der Reparatur:

• Synchronisation vollständig auslaufen lassen
• nicht allein auf grüne Haken vertrauen
• relative Pfade zwischen Vault und Sicherung vergleichen
• fehlende und zurückgekehrte Dateien getrennt beurteilen
• gemeinsame Dateien stichprobenartig oder vollständig hashen
• erst danach die normale Bearbeitung fortsetzen

Grenzen des beschriebenen Verfahrens

Der Index-Neuaufbau war eine kontrollierte Einzelfallmaßnahme. Er ist unnötig, wenn ein normaler Neustart oder ein automatischer Wiederholungsversuch hilft, und ersetzt weder Backup noch Versionshistorie. Auch ein vollständiger Hashvergleich erkennt keine fachlich falsche Änderung, wenn sie bereits in beiden Kopien enthalten ist.

Originale Bildschirmfotos wurden nicht verwendet, weil sie persönliche Kontodaten und interne Pfade enthielten. Die neutrale Skizze zeigt die Methode ohne unnötige Betriebsinformationen.

Fazit

Der festgefahrene Obsidian-Abgleich war technisch reparierbar. Entscheidend war aber nicht der Neustart allein, sondern die Reihenfolge: Arbeit stoppen, vollständig sichern, gestuft reparieren und anschließend den Inhalt beweisen.

Die wichtigste Praxisregel lautet:

Ein grüner Haken bestätigt einen technischen Status. Die Vollständigkeit eines digitalen Archivs bestätigt erst der kontrollierte Vergleich.