In einigen Artikeln habe ich bereits über meine Erfahrungen mit dem Windows Storage Pool berichtet.

Hier möchte ich ein Phänomen beschreiben, welches mich zum Umdenken bewegt hat.

Der Hauptgrund für den Einsatz von Storage Pools war in der Vergangenheit die Flexibilität und der Schutz vor dem Ausfall einzelner oder sogar mehrerer Datenträger. Der größte Nachteil war die schlechte Performance. Vor allem beim Verschieben größerer Fotoprojekte nach der Bearbeitung war eine Schreibrate von 15 bis 20 MByte/s eine Geduldsprobe.

Das Problem

Bisher habe ich Storage Pools auch auf einzelnen Festplatten genutzt um flexibel weitere Partitionen nutzen zu können. Jede Partition (bzw. jeder Storage Space) hat die gleiche Größe wie der Datenträger selbst und so kann trotz Bitlocker die tatsächlich genutzte Größe der Partitionen den aktuellen Bedürfnissen angepasst werden. Normalerweise geschieht dies ohne großen Overhead. Normalerweise!

Trotz vieler Aufräumaktionen und umfangreicherer Auslagerung von der HDD auf die SSD bekam ich häufiger Warnungen, dass die HDD voll sei.

Ein Vergleich der angegebenen Nutzung der verwendeten Poolkapazität mit der Größe der Dateien ergab ein stolzes Delta von über 300 GB (laut ChatGPT hätte das als Stapel Disketten eine Höhe der zehnfachen Entfernung von der Erde zum Mond, aber da ist calc.exe zuverlässiger).

Beim großen Storage Pool auf dem Server habe ich bei keinem der Storage Spaces eine signifikante Diskrepanz ermittelt. Dennoch ist eine solche Situation auch dort in Zukunft nicht auszuschließen.

Lösungsversuche

Als erstes habe ich es über die Laufwerksoptimierung von Windows probiert. Die Speicherplatzeffizienz war tatsächlich verbesserungswürdig.

Als zweites Tool kam SmartDefrag zum Einsatz. Die tolle Grafik weckte romantische Erinnerungen an Zeiten in denen Defragmentieren noch wichtig war. Gebracht hat es nichts.

Danach etwas Powershell und ChkDsk auf das Problem werfen war ebenso sinnlos wie der Wise Disk Cleaner.

Der Zwischenstand war übrigens ein noch größerer Speicherplatzverbrauch als zuvor. Der gedachte Diskettenstapel war also weiter angewachsen.

Die Lösung

Eine schnelle Lösung war das Neuerstellen des Storage Space inkl. der Neueinrichtung von Bitlocker.

Leider habe ich bei der Bitlocker-Verschlüsselung den Wiederherstellungsschlüssel im Microsoft-Konto gespeichert. Ein einziger falscher Klick reicht für diesen Fehler. Aber zum Glück kann man diesen Schlüssel unter https://account.microsoft.com/devices/recoverykey wieder aus dem Konto entfernen.

Am Ende war der Speicher endlich verfügbar und mit den gewonnenen Reserven werde ich hoffentlich die HDD bis zum Lebensende des Laptops nutzen können.

Die Differenz von nur 200 GB statt der versprochenen 300 GB ergibt sich daraus, da ich vor dem Screenshot viele Daten von der SSD wieder auf die HDD zurückgeholt habe.

Hinterher ist man immer schlauer

Im Nachhinein habe ich natürlich auch ChatGPT gefragt was in einem solchen Fall zu tun ist. Als sechste Option wird mir auch hier die Neuerstellung des Storage Space vorgeschlagen. Die anderen fünf Optionen sind in meinem Fall nur teilweise hilfreich:

• Versteckte Dateien suchen
• Papierkorb leeren
• Schattenkopien anpassen
• Konfiguration überprüfen
• Storage Space reparieren

Die oben versuchten Ansätze werden so aber nicht vorgeschlagen. Vielleicht waren meine Ideen von vornherein zum Scheitern verurteilt? ChatGPT ist sich da sicher: „Beachten Sie jedoch, dass ChkDsk und Defragmentierung keine direkten Lösungen für das Problem sind, wenn der Storage Space mehr Speicherplatz verbraucht als die tatsächlich gespeicherten Daten.“ 😞

Neue Gesamtbetrachtung des Storage Pool

Im Rahmen der Konfiguration meines neuen Servers (als Konsequenz aus dem Brand) habe ich zunächst eine Konfiguration mit denselben HDD aus dem Altsystem und damit einer vollständigen Übernahme des Storage Pool in Erwägung gezogen. Die Preise für AM5-Mainboards mit acht oder mehr SATA-Ports im Vergleich zu sechs Stück gaben mit Anstoß zu einer Neubetrachtung. Auf meine beiden PCI-SATA/RAID-Karten, bzw. neuere Versionen davon wollte ich zukünftig verzichten um eine stabilere Hardware-Plattform ohne Sonderlocken zu haben.

Mit etwas Excel erstellte ich einen Migrationsplan von den Storage Spaces auf einzelne HDDs. Durch den Verzicht auf Parität würde der Speicherbedarf um 33% sinken und die frei gewordenen HDDs könnten als ausgelagertes Backup die Verfügbarkeit (anders) sicherstellen. Durch die Auslagerung hätte ich eine schlechtere RPO und mehr Probleme falls ein Laufwerk ausfällt, aber durch die Auslagerung aller Daten (vorher nur die wichtigen) in einen anderen Brandabschnitt wäre ich hier besser aufgestellt. Diese Abwägung war für mich soweit plausibel und konsistent zu meinen Backup-Erwägungen und -Erfahrungen.

Soweit die Theorie.

Schnell zurück zum Storage Pool

Wie das Leben so spielt, entdeckte ich bei der Überprüfung des Innenlebens des alten Servers vor dem Aufbau des neuen ein kleines Problem: Eine HDD – leider meine neuste und bis dato größte (14 TB) – hat ein nicht unerhebliches mechanisches Problem. Aus einen mir unbekannten Grund ist die SATA-Stromversorgung beschädigt und ein Teil des Steckers (die Kunststoffschiene auf der die Stromkontakte sitzen) ist abgebrochen und steckt in der Kabelbuchse fest.

Die gute Nachricht vorweg: die HDD läuft bei Verwendung dieses Steckers problemlos.

Dennoch hat dieser Defekt meinen Migrationsplan durcheinandergeworfen. Ich wollte vermeiden eine zusätzliche HDD zu kaufen, obwohl ich diese defekte HDD nicht mehr als primären Datenspeicher nutzen kann. Auch der Migrationsplan weg von den Storage Spaces setzt voraus, dass durch Verschieben immer genug Speicherplatz frei wird, um dem Storage Pool anschließend eine HDD zu entfernen. Dieser Plan steht ohne die größte HDD nun auch wackeligen Beinen.

Auch die Frage, was aus der HDD wird, war nicht einfach zu beantworten. Die Antwort war am Ende: In einem Storage Pool macht eine einzelne HDD mit einer erhöhten Ausfallwahrscheinlichkeit am wenigsten Probleme. Also nutze ich den Storage Pool etwas reduziert weiter.

Das Ende vom Lied – ein bisschen Storage Pool und ein bisschen Frieden

Jetzt habe ich auf dem neuen Server nur HDD ohne Storage Pool, aber ein Teil des ausgelagerten Backup nutzt weiterhin den alten Storage Pool (mit drei statt acht HDD). Aktuell habe ich noch das Problem, dass ich die vierte Platte nicht entfernen kann und ChatGPT halluziniert sich wieder Powershell-Cmdlets zum Entfernen, die Microsoft noch nicht eingeführt hat.

Seit der Umstellung liegt die Schreibgeschwindigkeit von großen Datenmengen stabil über 100 MByte/s, was aber auch am neuen Server liegen kann (es ist einiges passiert in den 15 Jahren seit der Anschaffung des Vorgängers).

Ich verwende weiterhin Storage Pools, aber die Einzelfallüberlegungen sind um einige Erfahrungen reicher.