In einem Thread vom September 2025 wurde berichtet, dass die JBOD-Option in ZimaOS 1.4.4 und 1.5.0 sichtbar, aber nicht auswählbar war. Eine offizielle Antwort von Zima bestätigte, dass die Implementierung Probleme bei der Benutzerfreundlichkeit aufwies, und erklärte, dass Nutzer vorübergehend eine ältere Version verwenden oder auf eine erneute Implementierung der Funktion warten könnten.
Diese Antwort sollte nicht als aktuelle Empfehlung übernommen werden. In der aktuellen ZimaOS-Dokumentation wird JBOD wieder als verfügbare Speicherkonfiguration aufgeführt.
Was in ZimaOS 1.4.4 und 1.5.0 zutraf
In den gemeldeten Versionen konnte der Nutzer JBOD auf dem Bildschirm zur Speichereinrichtung nicht auswählen. Die offizielle Antwort stufte dies als Problem der Produktbenutzerfreundlichkeit ein, nicht als fehlerhafte, datenträgerspezifische Konfiguration.
Was jetzt anders ist
Die aktuelle Dokumentation zu den aktuellen ZimaOS-RAID-Optionen beschreibt JBOD neben RAID 0, RAID 1, RAID 5 und weiteren Speicheroptionen. JBOD wird darin als Möglichkeit definiert, mehrere Datenträger zu einem zusammenhängenden Volume zu verbinden. Außerdem wird betont, dass JBOD keine Redundanz nach dem Vorbild von RAID bietet.
Das bedeutet, dass die alte Vorgehensweise – eine ältere ZimaOS-Version zu installieren, nur um JBOD wieder nutzen zu können – für ein aktuelles System nicht die Standardempfehlung sein sollte.
Wann JBOD sinnvoll ist
JBOD ist nützlich, wenn Speicherkapazität und Einfachheit wichtiger sind als Redundanz. Mehrere Datenträger lassen sich kombinieren, ohne eine vergleichbare Kapazität für Spiegel- oder Paritätskopien aufzuwenden.
Der Kompromiss ist wichtig: JBOD ist keine Backup-Strategie. Wenn die Daten wichtig sind, sollten unabhängige Backups vorhanden sein, anstatt davon auszugehen, dass ein JBOD-Volume mit mehreren Datenträgern vor einem Laufwerksausfall schützt.
Wenn JBOD weiterhin nicht verfügbar ist
- Bestätige die installierte ZimaOS-Version.
- Prüfe, ob die Datenträger bereits einem anderen Pool oder Dateisystem zugewiesen sind.
- Sieh dir die aktuellen Optionen zur Speichereinrichtung an, statt der versionsspezifischen Umgehungslösung aus dem Jahr 2025 zu folgen.
- Führe kein Downgrade eines Produktivservers für Speicher durch, nur weil ein älterer Forenbeitrag ein vorübergehendes Problem bei der Implementierung beschrieben hat.
Aktueller Kontext zu JBOD und Datenschutz
Der Wiederherstellungsablauf für RAID 1 ist ein hilfreicher Vergleich, weil er zeigt, wie eine auf Redundanz ausgerichtete Wiederherstellung aussieht, wenn Daten wichtig sind. Die Änderungen in ZimaOS 1.5 liefern Versionskontext zu den Speicheränderungen in ZimaOS. Die ZimaOS-Cloud-Integration ist relevant, wenn entschieden werden soll, welche Daten in einem Pool ohne Redundanz zusätzlich an einem anderen Ort vorhanden sein sollten.
Seagates JBOD-Definition erklärt, dass JBOD Kapazitäten zusammenfassen kann, aber keine integrierte Redundanz nach dem Vorbild von RAID bietet. QNAPs Beschreibung des JBOD-Verhaltens stellt lineares JBOD ebenfalls als kombinierte Kapazität ohne Schutz vor Laufwerksausfällen dar. Diese Definitionen unterstreichen den entscheidenden praktischen Punkt: Eine aktuelle JBOD-Option kann für zusätzliche Kapazität sinnvoll sein, sollte aber nicht als Schutz für unersetzliche Daten dargestellt werden.
Fazit
Der Community-Beitrag beschrieb zutreffend ein vorübergehendes JBOD-Problem in ZimaOS 1.4.4/1.5.0. Die aktuelle ZimaOS-Dokumentation führt JBOD inzwischen wieder als unterstützte Option auf. Daher sollten aktuelle Hinweise zur Speicherkonfiguration befolgt und die ältere Downgrade-Empfehlung als historischer Versionskontext betrachtet werden.
