Raid 0 von 3 auf 4 HD on the fly erweiterbar?

[nac_ch]

Kann ich bei einer CS 407e aktuell mit drei Festplatten anfangen ein Raid 0 zu machen und später eine vierte Festplatte in das Raid 0 zufügen, ohne das aktuelle Raid neu zu konfigurieren? (sprich Daten auch neu zu überspielen). Bei Raid 5 kann die CS das ja. Bei Raid 0 habe ich die Info nicht gefunden ob das geht.

 

[Trolli]

Soweit ich weiss, geht das wohl nur bei Raid-5.

Trolli

 

[Supaman]

Kann ich bei einer CS 407e aktuell mit drei Festplatten anfangen ein Raid 0 zu machen und später eine vierte Festplatte in das Raid 0 zufügen, ohne das aktuelle Raid neu zu konfigurieren? (sprich Daten auch neu zu überspielen). Bei Raid 5 kann die CS das ja. Bei Raid 0 habe ich die Info nicht gefunden ob das geht.

raid-0 über 4 platten ist absolut sinnfrei. es bringt dir keinen geschwindigkeitsvorteil, da das netzwerk der flaschenhals ist. und wenn eine platte mal rumzickt oder ausfällt, sind alle daten weg. dann lieber raid-5 benutzen oder unabhängige einzelene volumes erstellen, die kannst du auch per über die konsole ineinander mounten so das du in der verzeichnistruktur der ersten platte die anderen einbinbdest.

 

[nac_ch]

raid-0 über 4 platten ist absolut sinnfrei. es bringt dir keinen geschwindigkeitsvorteil, da das netzwerk der flaschenhals ist.

Sinnfrei jein... Erklärung unten. Dass es keinen Geschwindigkeitsvorteil bringt ist mir klar, um das gehts mir nicht.

und wenn eine platte mal rumzickt oder ausfällt, sind alle daten weg.

Ist mir egal, es sind "Kopien" wenns Probleme mit den HD gibt wird ausgetauscht, formatiert und die Daten zurückgespielt.

oder unabhängige einzelene volumes erstellen, die kannst du auch per über die konsole ineinander mounten so das du in der verzeichnistruktur der ersten platte die anderen einbinbdest.

Gut, das kann ich bspw. machen wenn ich mit einem Linux auf diese Syno zugreife. Wenn ich aber mit Windows u.ä. darauf zugreife, sehe ich mal nur die Freigaben und kann nicht direkt auf die gesamte Verzeichnisstruktur des Synos der unterschiedlichen Volumen zugreifen.
Wenn ich jetzt die Mountstruktur direkt im Syno anpasse (oder wohl besser gesagt erweitere, in dem ich die Volumes zusätzlich zusammenhänge) schaffe ich mir da keinerlei Probleme mit den Funktionalitäten der Synosoftware?
Darüber hinaus gefällt mir die Lösung auch nicht, da ich dann jeweils 4 Volumen a 1TB habe und dann wird wieder das übliche passieren, ein Volumen wird schneller voll, während das andere halb leer ist und ich müsste die Ordnerstruktur wieder anpassen. Ich will das Raid 0 machen, weil ich gerne einen grossen Block a 4TB freien Speicher haben möchte.

 

[Supaman]

Ist mir egal, es sind "Kopien" wenns Probleme mit den HD gibt wird ausgetauscht, formatiert und die Daten zurückgespielt.

damit meine ich, das nicht die daten einer platte futsch sind, sondern vom allen 4 platten. nur das du dir darüber vorher im klaren bist

 

[nac_ch]

damit meine ich, das nicht die daten einer platte futsch sind, sondern vom allen 4 platten. nur das du dir darüber vorher im klaren bist

Ich kann Raid nicht nur buchstabieren, habe schon verschiedenste in unterschiedlichen Konstellationen gebaut. Mir ist klar, was ich damit mache.
Aber dein Ansatz mit dem mounten ist ja nicht uninteressant, aber hast du eine Antwort auf die Frage, ob ich sowas innerhalb vom Syno machen kann, um im Prinzip eine entsprechend zusammengeschusterte Sambafreigabe zu bekommen, unter der alle Volumes zusammengehängt sind?
Es bleibt dann zwar noch das Thema mit den 4 Blöcken a 1TB, welche ich nicht mag, aber es wäre natürlich eine Erhöhung der Datensicherheit und vor allem einfachere Reparatur, wenn mal eine Platte ausfällt muss ich nicht die 4TB zurückschreiben etc.

 

[ag_bg]

Wenn ich das richtig verstanden habe, dann willst du nur eine einzige Freigabe sichtbar auf deinem Windowssystem haben und das geht ohne Probleme mit einem direkten mounten innerhalb der DS. Dazu mußt du auf einer Festplatte deine 1. Ordnerstrukturebene anlegen und kannst dann die entsprechenden anderen Festplatten mit diesen Ordner "verknüpfen" (mounten). Da du ja ohnehin irgendeine Struktur haben wirst, ist dass die dem RAID 0 vorzuziehende Lösung, da du beim Verlust von einer Platte nur diesen Datensatz und eben keinen anderen (mehr) verlierst. Die Realisierung würde dann so wie hier von Supaman beschrieben erfolgen:
http://www.synology-forum.de/showpost.html?p=5771&postcount=5
Solltest du z.B. meinen, dass dir eine Partition mit 1TB nicht ausreicht, so kannst du ja z.B. auch eine RAID 0 mit 2 Platten erstellen, mit dem Risiko des Datenverlustes beim Crash einer, und eben diese in einen Ordner auf Platte 3 mounten, genauso wie die 4. alleine. Vorteil dieser Lösung ist eben der nur partielle Verlust der Daten.

best regards

 

[nac_ch]

Wenn ich das richtig verstanden habe, dann willst du nur eine einzige Freigabe sichtbar auf deinem Windowssystem haben und das geht ohne Probleme mit einem direkten mounten innerhalb der DS.

Ja das ist der eine Teil der Anforderung. Und genau das mit dem mounten meinte ich.

Solltest du z.B. meinen, dass dir eine Partition mit 1TB nicht ausreicht, so kannst du ja z.B. auch eine RAID 0 mit 2 Platten erstellen, mit dem Risiko des Datenverlustes beim Crash einer...

Für die komplette Struktur brauche ich eh mehr als 1TB. Aber die Unterordner wachsen unterschiedlich an, deshalb mache ich das ganze in einem Block. Klar steigt das Ausfallrisiko. Auch wenn Unerfahrene das mit Raid 0 besser sein lassen finde ich teils die Warnungen etwas übertrieben. Egal wie ich meine Daten speichere, ob auf eine HD oder auf einen Verbund, ein Backup ist Pflicht. Raid 1 oder 5 helfen nur, wenn mal eine HD abraucht.

 

[ag_bg]

Für die komplette Struktur brauche ich eh mehr als 1TB. Aber die Unterordner wachsen unterschiedlich an, deshalb mache ich das ganze in einem Block.

Ich würde mir an deiner Stelle Gedanken machen, wie groß die Blöcke in den Unterordnern werden und mit einem Faktor von meinetwegen 1.2 eben ein RAID 0 (Das wären schliesslich schon 2TB) anlegen für den großen Unterordner, wenn dies unabdingbar ist, aber eben auch nicht mehr, da mir z.B. meine verlorene Zeit für das restoren im Falle eines Ausfalls einfach zu schade ist, als dass ich mich damit beschäftigen möchte. Leider bietet die DS ja nicht eine ähnliche Lösung wie Windows mit den dynamischen Laufwerken an, mit welchen man eben die nicht steigende Ausfallwahrscheinlichkeit mit gleichzeitiger höherer Datenspeichergröße verbinden kann (Aber wer weiss, vielleicht bieten sie mal eine Art JBOD an, welches das in ähnlicher Weise umsetzt. Wichtig ist am Ende, dass sich jeder über die etwaigen Folgen im Klaren ist und entsprechend seiner Präferenzen agiert.

best regards

 

[itari]

Die Antwort auf die dynamische Plattenplatz-Verwaltung gibt es unter Linux und anderen Unixen schon eine Weile. Sie heißt LVM (Logical Volume Manager) und geht noch ein wenig über das von MS hinaus. Vielleicht findet der LVM ja irgendwann auch die DS (oder umgekehrt ).

itari

 

[nac_ch]

Ich würde mir an deiner Stelle Gedanken machen, wie groß die Blöcke in den Unterordnern werden und mit einem Faktor von meinetwegen 1.2

Die Grösse wächst leider sehr variabel, das kann ich nur schlecht vorausahnen.

da mir z.B. meine verlorene Zeit für das restoren im Falle eines Ausfalls einfach zu schade ist, als dass ich mich damit beschäftigen möchte.

Ich habe Ultrium 2 mit 200GB Tapes, ich muss im WC 20 Tapes zurückspulen, das geht nebenher über 2 Tage ohne grossen Aufwand.
Der Aufwand mein Syno zu rekonfigurieren ist da eher höher, respektive zeitintensiver, wenn ich wieder umstelle und auch Daten schieben muss.

(Aber wer weiss, vielleicht bieten sie mal eine Art JBOD an, welches das in ähnlicher Weise umsetzt.

Ja das wäre schön... und müsste eigentlich auch vernünftig umsetzbar sein. Wenn es Platzmässig ausreichen würde, würde ich ein Raid 5 machen. Aber dann wirds zu klein. Ist schon mit den 4TB knapp. Freue mich schon auf die neuen 1.5TB Platten...

Wichtig ist am Ende, dass sich jeder über die etwaigen Folgen im Klaren ist und entsprechend seiner Präferenzen agiert.

Das ist richtig.