JBOD? Spanned Volume? Big? Häh?

Jotadog

Enthusiast
Thread Starter
Mitglied seit
07.04.2007
Beiträge
179
Hallo,

nach meinen bisherigen Recherchen gibt es wohl verschiedene Namen für eine Funktion, nämlich mehrere Festplatten zu einer großen logischen Festplatte zusammenzufassen.
Bisher bin ich davon ausgegangen dass in so einem logischen Volume eine beliebige Platte ausfallen kann, die Daten auf dieser dann zwar verloren sind, aber alle anderen Platten unberührt bleiben.
Im Technet Artikel zum Spanned Volume steht allerdings dass beim Verlust eines einzelnen Laufwerks die kompletten Daten verloren sind.

Mein Plan war eigentlich mir eine 8-Bay RAID-Station | SHARKOON Technologies GmbH zuzulegen und darauf ein Software-Windows-JBOD (Spanned Volume) zu legen, aber wenn ich mir damit die Ausfallwahrscheinlichkeit verachtfache lasse ich das lieber. Zu den JBOD bzw. "BIG" Konfigurationen der ganzen Gehäusehersteller findet man leider nicht viel Infos, daher die Frage an euch: Gibt es so eine Festplattenkonfiguration? Mehrere Festplatten zusammenfassen ohne erhöhte Ausfallgefahr?

Gruß,
Dominik
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
nach meinen bisherigen Recherchen gibt es wohl verschiedene Namen für eine Funktion, nämlich mehrere Festplatten zu einer großen logischen Festplatte zusammenzufassen.
Bisher bin ich davon ausgegangen dass in so einem logischen Volume eine beliebige Platte ausfallen kann, die Daten auf dieser dann zwar verloren sind, aber alle anderen Platten unberührt bleiben.
Im Technet Artikel zum Spanned Volume steht allerdings dass beim Verlust eines einzelnen Laufwerks die kompletten Daten verloren sind.
Absolut richtig, das Ganze nennt sich RAID0 und wenn eine Festplatte darin verreckt sind alle Daten futsch. Daher würde ich das keinem Empfehlen.

JBOD hat leider mehrere verschiedene Definitionen darunter versteht jeder Hersteller was anderes. Wörtlich heißt es einfach nur "Just a Bundel of Disks". Was aber nicht heißt dass diese auch als ein Volume dargestellt werden.
Lese dir die verschiedenen Bedeutungen von JBOD am besten mal im Wiki durch RAID
 
Stell es dir so vor, als würde das Dateisystem statt z.B. 5 100GB HDDs eben eine einzige 500 GB HDD zu Gesicht bekommen. Da es nichts davon weiß, dass das ja eigentlich mehrere Platten sind, wird es natürlich auch nicht darauf achten, wichtige Informationen (z.B. welche Datei ist in welchem Block?) auch so abzulegen, dass eine HDD ausfallen kann. Der Unterschied zu RAID-0 besteht darin, dass die Daten nicht auch noch zerstückelt werden, sondern nur die Festplatten aneinandergehängt.

Gegenmaßnahmen bestehen entweder darin, ein Dateisystem zu verwenden, dass sowas ähnliches wie JBOD macht bzw. sich über mehr als eine HDD erstrecken kann (ZFS, BTRFS...) oder auf jedem HDD ein eigenes Dateisystem anlegt und diese in einer Art "union mount" verbindet (Windows 7/8 "Bibliotheken", Liquesce, DriveBender, mhddfs + co). Letztere Lösung hat allerdings die Einschränkung, dass du dann nicht größere Dateien als der größte freie Speicherplatz einer der Poolplatten erstellen kannst - im Beispiel mit 5 leeren 100GB HDDs z.B. kanst du dann kein 200GB Backup speichern, außer du lässt die Backupsoftware das Archiv in mind. 2 100GB Teile splitten.

Bei 8 HDDs solltest du übrigens auch vielleicht mal über Ausfälle und "Bitrotting" nachdenken.
 
... Gibt es so eine Festplattenkonfiguration? Mehrere Festplatten zusammenfassen ohne erhöhte Ausfallgefahr?...


gibts, aber so etwas nennt man ein redundantes Raid
ein redundantes Raid (raid-10, raid-5, raid-6, etc.) fasst Festplatten zusammen und stellt so eine einheitliche Speicherfläche (ein virtuelles Laufwerk) dar, die nicht zerstört wird, wenn die Ausfälle eine bestimmte Anzahl von Festplatten nicht überschreitet

man kann Festplatten auf verschiedene Weise zu einer virtuellen Platte zusammenfassen, durch Striping oder durch einfaches Hintereinanderhängen der einzelnen Speicherflächen der einzelnen Platten, letzteres macht JBOD
damit gibt es auch bei sog. JBOD eine Abstraktionsschicht zwischen der Festplattenhardware und dem OS so, dass das OS nur eine einheitliche Disk sieht (die bloss intern anders organisiert ist als raid), und natürlich gibt es damit auch nur eine Verzeichnisstelle, ein solcher Verbund ist nicht redundant und zerstört, wenn ein Teil der Fläche (eine Platte) ausfällt (obwohl die Daten auf den anderen Teilen unterhalb der OS-Ebene mit Hexeditoren und Spezialprogrammen noch auszulesen sind

darüberhinaus scheint es "JBOD's" zu geben, bei denen das OS Durchgriff auf die einzelnen Platten hat
k.A. warum auch solche Enclosures mit Backplane und einer gewissen Anzahl Platten manchmal ebenfalls als JBOD angesprochen werden
 
Vielleicht habe ich mich etwas Missverständlich ausgedrückt. Mir sind sehr wohl die Begrifflichkeiten sowie jegliche Raidlevel und deren Funktionsweißen bekannt.
Mir geht es nun darum 8 Festplatten an mein System anzuschliessen ohne die Festplatten in den PC einbauen zu müssen, sprich ohne Raidcontroller.
Die "coolste" Lösung wäre natürlich gewesen über o.g. Gehäuse die Festplatten ans OS weiterzureichen und da ein Softwareraid drauf zu machen. Da sich dadurch aber wie bereits erläutert die Ausfallsicherheit enorm verschlechtert ist das keine Option mehr. Es sei denn hier gibt es Personen die Gegenteiliges zum Spanned Volume aus Redmond sagen können.

Edit: Um es nochmal explizit zu erwähnen, im Prinzip ist mir die Sicherheit der Daten nicht so wichtig, mir geht es nur darum die Ausfallwahrscheinlichkeit einer Single-Platte nicht auch noch zu erhöhen und nicht 8 verschiedene Laufwerke in Windows benutzen zu müssen.
 
Zuletzt bearbeitet:
Lese dir den Wiki Link mal genau durch. Habe ich gerade nochmal getan und dort steht folgendes
Span = NRaid
NRAID zum Thema ausfallsicherheit:
Da es bei dem zugrunde liegenden linear mode keine Stripes gibt, wird bei einem solchen Verbund erst die erste Festplatte mit Daten gefüllt und erst dann, wenn weiterer Platz benötigt wird, kommt die zweite Platte zum Einsatz. Reicht auch diese nicht aus geht es falls vorhanden auf die nächste Platte. Folglich gibt es bei einem Ausfall einer Platte zwei Möglichkeiten: Einmal dass diese (noch) keine Daten enthielt, dann gehen – je nach Implementierung der Datenwiederherstellung – möglicherweise auch keine Daten verloren. Zum Anderen kann die defekte Platte bereits Daten enthalten haben, dann hat man auch hier den Nachteil, dass der Ausfall der einzelnen Platte den gesamten Verbund beschädigt. Das fehlende Striping erleichtert aber auch das Wiederherstellen einzelner nicht betroffener Dateien. Im Unterschied zu RAID 0 führt der Ausfall einer Platte hier also nicht unbedingt zu einem kompletten Datenverlust, zumindest solange sich die Nutzdaten komplett auf der noch funktionierenden Platte befinden.
Quelle: RAID
Am besten du ließt es dir einfach wirklich mal durch vielleicht weißt du dann auch über die Funktionsweisen der einzelnen RAIDs bescheid ...
 
Woher hast du die Information dass ein Microsoft Spanned Volume NRAID entspricht?
 
Woher hast du die Information dass ein Microsoft Spanned Volume NRAID entspricht?


weil MS für "übergreifende Volumes" zum einen Merkmale, die für JBOD (= NRaid) zutreffen, angibt (insbesondere Datenverlust des gesamten JBOD bei Ausfall einer Platte daraus) und zum anderen davon "Stripsetvolume" (= raid-0) unterscheidet (und andererseits natürlich noch raid-5)

aber noch mal allgemein,
immer, wenn mehrere Platten zu einem einheitl. Verbund/log. Disk/virtuellen Disk zusammengefasst werden (egal wie das nun intern organisiert sein mag, per Aneinanderhängen = JBOD oder Striping = raid), immer dann vervielfacht sich natürlich die Chance auf Verlust des gesamten Verbunden entsprechend der Anzahl der an dem Verbund beteiligten Platten
werden 8 Platten zu einem Verbund zusammengafasst, dann besteht zunächst einmal eine Achtfach-Chance auf Verlust des gesamten Verbundes.
Genau dies ist bei JBOD (aneinanderhängen) und raid-0 (reines striping) der fall, egal ob das rein per Software (OS) oder coprozessor-gestützt (hardware-controller) realisiert wird und diese erhöhte Ausfallwahrscheinlichkeit zusammengefasster virtueller Laufwerke kann nur etwas abgemildert werden durch Redundanz-Maßnahmen (wie bei raid-5, raid-6, etc.), kostet aber Speicherplatz

die Alternative, einzelne Platten im OS zu verwalten, erscheint nicht so attraktiv, aber es käme schon darauf an, was die Anwendung ist
es ist ja durchaus so, dass es Anwendungen gibt, die gewisse Inhalte von Einzellaufwerken für ihren Zweck quasi virtuell zusammenführen, ohne zuvor die Laufwerke (wie raid oder jbod) zu einem logischen Laufwerk zusammenfassen zu müssen
ich meine hiermit z.B. die Bibliotheken in Windows oder auch das Mediacenter stellt Inhalte verschiedener Laufwerke einheitlich dar und sicher gibt es noch weitaus mehr solcher Software vor allem aus dem Mediabereich
wäre also vielleicht doch eine Überlegung wert, ob man wegen seiner Anwednung evtl. doch nicht unbedingt ein virtualisiertes großes Laufwerk benötigt
 
Zuletzt bearbeitet:
immer, wenn mehrere Platten zu einem einheitl. Verbund/log. Disk/virtuellen Disk zusammengefasst werden (egal wie das nun intern organisiert sein mag, per Aneinanderhängen = JBOD oder Striping = raid), immer dann vervielfacht sich natürlich die Chance auf Verlust des gesamten Verbunden entsprechend der Anzahl der an dem Verbund beteiligten Platten
werden 8 Platten zu einem Verbund zusammengafasst, dann besteht zunächst einmal eine Achtfach-Chance auf Verlust des gesamten Verbundes.
Genau dies ist bei JBOD (aneinanderhängen) und raid-0 (reines striping) der fall, egal ob das rein per Software (OS) oder coprozessor-gestützt (hardware-controller) realisiert wird und diese erhöhte Ausfallwahrscheinlichkeit zusammengefasster virtueller Laufwerke kann nur etwas abgemildert werden durch Redundanz-Maßnahmen (wie bei raid-5, raid-6, etc.), kostet aber Speicherplatz

Ich weiß nicht ob hier Informationen übersehe, aber warum genau sich die Ausfallwahrscheinlichkeit erhöht ist mir absolut Schleierhaft.
Klar mit den momentan gegebenen Informationen ist das so, aber warum es diese technische Limitation gibt will mir nicht in den Kopf.
Nach meinem technischen Verständnis muss es doch Softwaretechnisch super einfach zu lösen sein einfach die Dateisysteme der Einzelplatten beizubehalten und sozusagen eine "Logik" darüber zu legen die Entscheidet auf welche Platte nun die Datei kommt. Ob die Logik dass nun Roundrobinmäßig, der Reihe nach oder einfach zuerst eine Platte komplett voll macht ist mir dabei erstmal egal.
 
wenn 8 Platten einzeln geführt werden, dann bestehen zwar auch 8 Chancen, dass überhaupt irgendwas ausfällt,
aber jede Chance betrifft nur die Speicherfläche einer Platte, zb. 2 TB
werden die 8 Platten aber durch eine logische Verbindungstechnik wie Raid-0 (striping) oder jbod (aneinanderhängen) als eine grosse Platte/Speicherfläche geführt, dann führt aufgrund dieser Datenorganisation der Ausfall eines Teils der Großen Speicherfläche (also einer Platte) zum Verlust der gesamten Speicherfläche, man verliert also nicht nur 2 TB sondern 16 TB durch Ausfall einer einzigen Platte, und für den Ausfall einer einzigen von 8 Platten gibt es 8 Chancen
 
werden die 8 Platten aber durch eine logische Verbindungstechnik wie Raid-0 (striping) oder jbod (aneinanderhängen) als eine grosse Platte/Speicherfläche geführt, dann führt aufgrund dieser Datenorganisation der Ausfall eines Teils der Großen Speicherfläche (also einer Platte) zum Verlust der gesamten Speicherfläche, man verliert also nicht nur 2 TB sondern 16 TB durch Ausfall einer einzigen Platte, und für den Ausfall einer einzigen von 8 Platten gibt es 8 Chancen

Ja und eben das ist nicht logisch, wie in meinem vorherigen Post aufgeführt.
Ich habe 8 Schubladen, lege eine Banane in Schublade 1, Schublade 7 brennt ab, aber das juckt doch die Banane in Schublade 1 nicht.
 
Ja und eben das ist nicht logisch, wie in meinem vorherigen Post aufgeführt.
Ich habe 8 Schubladen, lege eine Banane in Schublade 1, Schublade 7 brennt ab, aber das juckt doch die Banane in Schublade 1 nicht.

aber die banane landet bei striping-raid eben nicht in einer Schublade, sondern wird in Scheibchen geteilt (stripes, chunks von zb. 256 KB) und landet so auf allen Platten
der Vorteil dabei, alle Platten können gleichzeitig lesen/schreiben, und brauchen (theoretisch) nur 1/8 der Zeit, die eine Platte allein zum lesen/schreiben benötigt
das risiko dabei, fehlt ein daten-scheibchen, weil eine Platte ausfiel, dann ist die ganze banane/datei hin
und da so mit allen dateien verfahren wird ist dann natürlich nicht nur eine datei hinüber, sondern überhaupt alle Daten, die auf dem Verbund waren

solche Plattenverbünde (raid, simple storage spaces, jbod etc.) sind wie Kletter-Seilschaften
wir haben 8 Kletterer, jeder wiegt 80 KG und verwendet Kletterhaken, die 90 KG, oder sagen wir 100 KG aushalten
nun begeben sie sich, jeder mit seinen 100KG-Haken, in die Seilschaft
es ist klar, was passiert, wenn einer vom anderen mit dessen Haken allein gehalten werden muss, der Haken bricht und dann hängen am nächsten 100KG-Haken schon 240 KG usw.
es ist eben so, dass 8 Platten, die im Verbund verwendet werden, 8fach sicherer sein müssten, es aber eben nicht sind
jede Platte ist nur so Ausfall-sicher wie sie ist,
ok es gibt noch spezielle raid-edition platten, nearline/enterprise platten, die von der MTBF wenigsten etwas sicherer als normale Platten sind, aber immerhin von der Lesefehlerrate 10mal sicherer als Normalplatten sind, im Fall von nearline-platten, und sogar 100mal sicherer sind als Normalplatten im Falle von Enterprise Platten wie savvio und cheetah
 
oder auf jedem HDD ein eigenes Dateisystem anlegt und diese in einer Art "union mount" verbindet (Windows 7/8 "Bibliotheken", Liquesce, DriveBender, mhddfs + co).

Hast du da Erfahrungen was die Zuverlässigkeit bzw. Risiken dieser Systeme angeht?

---------- Post added at 23:43 ---------- Previous post was at 23:41 ----------

aber die banane landet bei striping-raid eben nicht in einer Schublade, sondern wird in Scheibchen geteilt

Schon klar, aber wir reden hier von Spanning!?
Edit: Und du sprichst von JBOD als wäre es Striping? Diese Information konnte ich nirgends finden, laut allen für mich aufsuchbaren Infos ist ersichtlich dass JBOD die Daten nicht verteilt.
 
Zuletzt bearbeitet:
...Schon klar, aber wir reden hier von Spanning!?
Edit: Und du sprichst von JBOD als wäre es Striping? Diese Information konnte ich nirgends finden, laut allen für mich aufsuchbaren Infos ist ersichtlich dass JBOD die Daten nicht verteilt.

jbod/übergreifendes Volume striped die Daten nicht, das stimmt, sondern schreibt sie in einem auf eine Platte,
aber dennoch gibt es eine virtuelle Organisation zu einem Verbund, der nur ein Verzeichnis hat
und das ist der Grund, weswegen jbod-platten normalerweise einzeln nicht einfach woanders einzulesen sind
und Microsoft jedenfalls warnt auch ausdrücklich bzgl. übergreifenden Volumes, dass der Ausfall einer Platte des Verbundes zum Verlust der Daten des gesamten Verbunden (also aller beteiligten Platten) führt,
das gibt natürlich die Sicht des Betriebssystems wieder, die Daten der intakten Platten sind aber (quasi unterhalb der OS-Ebene, die den Verbund geführt hat) noch soweit intakt (und könnten zb. mit Spezialttools evtl. noch ausgelesen werden)
 
Ganz einfach, bei 8 einzelnen Platten hast du 8 unabhängige Dateisysteme, mit jeweils eine eigenen Dateisystemverwaltung (MFT bei NTFs)
Wenn du diese 8 Platten zu einem "Spanned Volume" zusammenfast, hast du nur ein Dateisystem mit genau einer Dateisystemverwaltung! Da die MFT bei NTFS über das gesamte Laufwerk verteilt angelegt wird, reicht es, wenn eine Platte ausfällt, dann ist die MFT beschädigt - zumeist irreparabel.

Das man die Daten auf den intakten Platten zum Teil mit Datenrettungssoftware retten kann steht auf einem anderen Blatt und ist nicht Sicherzustellen.

Wenn du nicht mit Laufwerksbuchstaben agieren willst, gibt es noch die Möglichkeit die einzelnen Laufwerke in die Verzeichnisstruktur (Mount-points) reinzuhängen - du hast aber dann 8 Verzeichnisse, die jeweils 1 Laufwerk repräsentieren.
 
Hast du da Erfahrungen was die Zuverlässigkeit bzw. Risiken dieser Systeme angeht?
DriveBender funktioniert bei mir bisher sehr gut, von mhddfs, greyhole und anderen Linuxgeschichten habe ich auch Gutes gehört (ich mag mir nur Samba im Moment nicht antun, daher läuft mein Server derzeit auf Windows 2012), Liquesce kämpft wohl mit Dokan (die Bibliothek um FUSE auf Windows zu realisieren) ein bisschen herum und PoolIt sowie die Poolingfunktion von FlexRAID habe ich noch nicht getestet - aber generell funktionieren da alle Lösungen ähnlich.

Ein kleiner Nachteil bei DriveBender ist, dass die Ordner auf der HDD da eine Ebene tiefer gelegt werden. Wenn du z.B. "D:\Meinordner" hattest, dann die Platte zu einem Pool hinzufügst und später wieder dort rausrupfst und auf einem anderen PC anschaust, siehst du stattdessen den Ordner "D:\{123456-ABCD-....}\Meinordner" und noch ein paar Dateien die Drivebender angelegt hat. Leicht unschön, aber verschmerzbar, besonders da man da im normalen Betrieb eh nie zu Gesicht bekommt. Ansonsten scheint das zumindest bei mir recht gut zu klappen und wird auch derzeit aktiv weiterentwickelt. So wie's aussieht werde ich mal die paar Euro investieren.

Zum Vergleich mit der Banane:
Normale Dateisysteme: Du willst eine Banane ablegen und sagst "Banane in Lade 1 von 8" - dort landet sie auch.
Pool aus normalen Dateisystemen: Du willst eine Banane ablegen und sagst "Banane in die Lade" - der Pooltreiber sucht dann eine möglichst leere Lade und legt sie dort ab. Du kannst auch jede Lade einzeln anschauen, ob die Banane drinnen ist.
RAID-0: Du willst eine Banane ablegen und sagst "Banane in die Lade" - der RAIDtreiber schneidet die Banane in Scheiben und verteilt die gleichmäßig auf die 8 Laden. Wenn du in eine Lade schaust, kannst du nicht genau sagen, ob das nun Scheibe 17 von Banane 3 oder Scheibe 48 von Banane 15 ist.
JBOD: Du willst eine Banane ablegen und sagst "Banane in Lade" - das Dateisystem glaubt es existiert nur eine einzige große Lade und legt die Banane darin ab, in Wirklichkeit kommt dann der JBODtreiber, schnappt sich die Banane und steckt sie wohin auch immer es gerade passt (in eine Lade oder auch so, dass die Hälfte in einer Lade landet und die 2. Hälfte schon in der nächsten). Willst du nun eine Lade anschauen, hast du darin kein wirkliches Dateisystem, sondern nur einen großen Haufen Datenmüll (nicht so schlimm wie beim RAID-0, aber immer noch böse) der ja eben eigentlich nur Teil eines viel größeren Dateisystems ist.

Es ist also vermutlich einfacher, Daten von einem JBOD wiederherzustellen, aber da das Dateisystem ja nicht einmal weiß, wo eine Platte anfängt und die nächste aufhört kann es sein, dass da trotzdem so einige Dateien kaputt werden, besonders wenn man Fragmentierung einbezieht. Bei RAID-0 hat man recht schnell hohe Chancen Teile aus allen Dateien zu verlieren, aber eben auch bein reinem Aneinanderhängen von Daten kann's zu Problemen kommen. Außerdem ist im schlimmsten Fall schon mal das Journal oder die MFT auf der kaputten Platte... ist also eine von 8 Platten kaputt, ist im worst-case auch alles andere nur mehr Datenmüll, weil man nicht mehr weiß wo welche Datei anfängt.
 
Zum Vergleich mit der Banane:
Normale Dateisysteme: Du willst eine Banane ablegen und sagst "Banane in Lade 1 von 8" - dort landet sie auch.
Pool aus normalen Dateisystemen: Du willst eine Banane ablegen und sagst "Banane in die Lade" - der Pooltreiber sucht dann eine möglichst leere Lade und legt sie dort ab. Du kannst auch jede Lade einzeln anschauen, ob die Banane drinnen ist.
RAID-0: Du willst eine Banane ablegen und sagst "Banane in die Lade" - der RAIDtreiber schneidet die Banane in Scheiben und verteilt die gleichmäßig auf die 8 Laden. Wenn du in eine Lade schaust, kannst du nicht genau sagen, ob das nun Scheibe 17 von Banane 3 oder Scheibe 48 von Banane 15 ist.
JBOD: Du willst eine Banane ablegen und sagst "Banane in Lade" - das Dateisystem glaubt es existiert nur eine einzige große Lade und legt die Banane darin ab, in Wirklichkeit kommt dann der JBODtreiber, schnappt sich die Banane und steckt sie wohin auch immer es gerade passt (in eine Lade oder auch so, dass die Hälfte in einer Lade landet und die 2. Hälfte schon in der nächsten). Willst du nun eine Lade anschauen, hast du darin kein wirkliches Dateisystem, sondern nur einen großen Haufen Datenmüll (nicht so schlimm wie beim RAID-0, aber immer noch böse) der ja eben eigentlich nur Teil eines viel größeren Dateisystems ist.


Welchem Modi entspricht das?

Der Vergleich ist auf jedenfall passend. Ich verstehe aber so recht das Problem des TEs nicht...
Es ist doch schon rein vom theoretischen Denken her vollkommen logisch, das eine Banane, die in die gemeinsame Lade gelegt wird, inten dann vom Controller/OS verteilt auf einen freien Block wird, unter Umständen gänzlich weg ist (genau so wie alle anderen Bananen), wenn die Platte ausfällt, wo die Zuordnungen abgelegt wurden.
Schon allein aus Fragmentierungssicht (was bei viel Datenbewegung durchaus passieren wird) geht das schon logisch nicht.
Mir wäre aus dem Hut keine Möglichkeit bei MS mit Boardmitteln bekannt, welches ein logisches verbinden der einzelnen Volumes der jeweiligen Platten so händelt, das explizit die jeweiligen Daten immer vollkommen gänzlich auf je eine ganze Disk geschrieben werden.

@Jotadog
ich denke dein Verständnisproblem liegt einfach daran, das dir so wohl der Umstand entgangen ist, das beim vorhalten von Daten nicht nur die Daten selbst wichtig sind, sondern auch die Informationen, die nötig sind, um die geschriebenen Datenblöcke auch wieder zusammen zu bringen. Fehlt dir letztere Information, so ist im schnlimmsten Fall nur noch ein riesen Speicherbereich vorhanden, wo viele viele Nullen und Einsen stehen. Ohne Zuordnung zueinander. Mehr oder weniger ohne logik usw.
Du hast zwar den Inhalt vieler Dateien quasi im Klartext noch vorliegen, aber dir fehlt schlicht die Information, welche sagt, Datei 1 heist xxx, Datei 1 hat Typ jpg, der Datenblock von Datei 1 fängt in Sektor 0815 an und hört in Sektor 4711 auf.


Es gibt beispielsweise spezielle Datenrettungstools, welche die Möglichkeit bieten, den Datenbereich abzusuchen. Und man kann mit nem vollständigen Scan beispielsweise die Files selbst widerherstellen (rein den Inhalt)
Was aber beispielsweise zum Teil nicht geht, sind Dateinamen. Denn diese stehen ggf. an einem anderen Ort und liegen dann nicht im Bereich der Daten selbst.

Es ist also wichtig, sich im Vorfeld Gedanken zu machen, wie man den HDD Verbund organisiert.
Willst du erhöhte Verfügbarkeit (genau das willst du scheinbar), so benötigst du eine Technik, die dir Redundanzen bereit stellt. Und das möglichst so, das es wurscht ist, welcher Teil ausfällt... Beispielsweise ein Raid 1 oder 10. Genau so wie ein Raid 5 oder 5. Lässt sich alles auch in Windows via Software bereit stellen (ist nur recht lahm)
Nebenbei sind noch weitere Techniken genannt (wie oben schon erwähnt wurde) die mit anderen Mitteln arbeiten, ggf. weniger oder mehr Platz für die Redundanzen einbüßen usw.
 
Welchem Modi entspricht das?

DriveBender, mhddfs... eventuell auch BTRFS/ZFS, da erledigt das eben das Dateisystem selber. Bei Windows 7 Bibliotheken kann man glaube ich auch reinspeichern, aber ich habe noch nicht davon gelesen, dass die wirklich wer einsetzt, wohl auch weil man die nicht explizit als Ordner ansprechen kann und die daher wohl auch etwas schwer in Programmen ("Meine Videos liegen im Pfad...") verwenden kann. Außerdem weiß ich nicht ob und wie Windows da entscheidet, was wohin kommt. Das wäre dann aber die einzige Methode (Storage Spaces sind so ähnlich wie RAID, nur mit dem Vorteil, dass man unterschiedlich große Platten verwenden kann) die ich mit Windows Bordmitteln kenne um Ordner zu "verbinden".
 
Im Prinzip ist mir der Grund schon bewusst warum sich die Spanned Volumes so verhalten wie sie es tun.
Mir ist aber nicht klar warum sowas ins OS implementiert wird und vorallem, warum nicht schon längst eine bessere Lösung geschaffen wurde.

Wie auch immer, in diesem Fall werde ich dann wohl auf DriveBender zurückgreifen.
 
es gab ja auch mal einen Lösungsversuch von microsoft (whs version 1), mit der ms selbst aber nicht so ganz zufrieden war, besonders, was das Verhalten in Last-Situationen anging und das Balancing
whs v1 verwendete eine Art jbod und dennoch konnten die Einzelplatten woanders gelesen werden, aber microsoft hat die Details dieser Lösung nie veröffentlicht
kannst ja von den Erfahrungen mit DriveBender mal was hören lassen, Handling, Zuverlässigkeit, Performance-Eindrücke wären interessant

im Moment verzichte ich in meinem server für die größeren Datenbestände (wie Filme, Musik, etc) noch auf jegliche Zusammenfassung von Einzelplatten per OS oder Raid-controller,
Performance-Nachteile bei meinen Anwendungsfällen (zb. streaming) konnte ich noch nicht ausmachen, auch nicht bei Mehrfachzugriff
 
Probleme gibt's besonders dann, wenn schon Daten vorhanden sind (D:\Data.txt und E:\Data.txt), unterliegende Dateisysteme (die ja nicht die gleichen sein müssen!) unterschiedliche Beschränkungen haben (FAT32 4 GB Dateigröße...), User glauben, sie können jetzt jeden USB-Stick und CF-Karte da zusätzlich einhängen.

Rein lesend wäre es ja noch machbar, aber sobald man da drauf schreiben will, wird's hässlich. Ein Vergleich (von 2009) zu diversen Techniken in die Richtung ist z.B. auf Union mount workshop notes [LWN.net] zu finden (Linuxspezifisch). Wenn's aber nicht mal Linux ordentlich hinbekommt, wie soll's dann Microsoft schaffen! :p
 
Das kann Windows schon seit zig Jahren (in Ordner mounten) - allerdings hat man da nicht den Vorteil eines Union mount. Wenn also ein Laufwerk voll ist, wird nicht am nächsten weiter gemacht, sondern man erhält eben einen Fehler ("D:\Videos ist voll" obwohl D:\Musik noch 50 GB Platz hat). Das ist so wie unter Linux/Unix wo man auch in Ordner und nicht auf Buchstaben mountet (/media/HDD1/Videos und /media/HDD2/Musik).

Du kannst auch Truecryptvolumen mit Drivebender, Liquesce + co. verbinden oder eben nebeneinander in einen Ordner mounten. Wenn aber ein Container voll ist, wird wie gesagt im letzteren Fall nichts mehr gehen.
 
Du kannst auch Truecryptvolumen mit Drivebender, Liquesce + co. verbinden oder eben nebeneinander in einen Ordner mounten.
Schon, bloß habe ich dann das Problem dass ich zwar alles in einem LW habe, aber 8x Passwörter nach der Anmeldung eingeben muss.
 
TrueCrypt - Free Open-Source Disk Encryption - Documentation - Command Line Usage - mit Passwortcache kein Problem (wenn du ein sicheres Passwort verwendest, kannst du das auch gleich für alle 8 Platten verwenden). Passwort eingeben müsstest du aber ohnehin in jedem Fall.

Möglich wäre es noch, Truecrypt beizubringen Container zu splitten (container.tc.1, container.tc.2 etc.). Dazu müsstest du aber deren Code ändern und die Lizenz dazu ist nicht ohne... und der Aufwand für sowas liegt vermutlich weit über dem Nutzen für dich.
 
im Moment verzichte ich in meinem server für die größeren Datenbestände (wie Filme, Musik, etc) noch auf jegliche Zusammenfassung von Einzelplatten per OS oder Raid-controller,
Performance-Nachteile bei meinen Anwendungsfällen (zb. streaming) konnte ich noch nicht ausmachen, auch nicht bei Mehrfachzugriff

Ich nutze beispielsweise in meinem Backup-Filer alle möglichen Single Disks, die noch so rumflogen. Von kleinen 160GB Disks bis größeren 500GB Disks usw.
Dazu nutze ich die Softwareraid 5 Methoden von Windows. Geht zwar nicht extrem gut, aber halbwegs performant, wenn die CPU fix genug ist. Datenraten von 60-80MB/sec sind keine Seltenheit sequenziel schreibend. Die lahmsten Platten schaffen da beispielsweise allein nur ~40MB/sec :fresse:
Vorteil bei der Softwareversion, ich hab die Disks mittlerweile so verteilt, das ich den Platz möglichst effektiv aufgeteilt habe. Sprich die 160GB Platten nutze ich beispielsweise komplett. Genau so wie ein 160GB Teil auf der 500er Platte liegt usw. So bleibt hinten rum nur ein kleiner rund 180GB Part übrig, der aktuell ungenutzt rumliegt bzw. als Singlespace ohne Redundanz vorhanden ist.

Da die Kiste nur meine Backups hält, ist das für mich vollkommen ausreichend ;)
Auch wenn es mittlerweile reichlich knapp vom Platz her wird muss ich sagen... Dank neuer DSRL werden die Fotos immer größer :fresse:
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh