Datentransfer RAID1 zu RAID1 - wie am sinnvollsten

Dig.Minimalist

Lt. Commander
Registriert
Jan. 2008
Beiträge
1.067
Hallo,

ich habe derzeit ein RAID1 Verbund mit 2x4TB. Diese sind in den Hot-Swap Bays meines Corsair Carbide 540 eingebaut.

Nun wird langsam die HDD voll und ich möchte mir ein größeres RAID1 zulegen. Wie transferiere ich die Daten am sinnvollsten?

meine -theoretische- Überlegung:
  • eine der aktuellen RAID1 HDDs abstöpseln und an einen anderen SATA port anschliessen
  • Schauen ob Daten auf beiden Platten vorhanden sind
  • zweite HDD abstöpseln und weglegen
  • beide neuen HDDs anschließen und RAID1 erstellen
  • Daten von der alten HDD auf das neue RAID1 kopieren

Ist das die korrekte Vorgehensweise?
 
Naja, ganz verwegener Vorschlag:

- aktualisier dein Backup
- steck die neuen Platten ein und mach dein Raid
- spiel den Backup zurück?

Oder hast du ernsthaft keinen Backup??
 
Hi

Naja Theoretisch ist das machbar. Jedoch wird dein RAID erst mal in dieser Grösse bleiben.

Du kannst dies (wenn eine Virtuelle Disk vorhanden ist) relativ bedenkenlos anschliessend erweitern.
Sind die Daten jedoch auf der Physischen Disk, wirst du eher Probleme bekommen.

Mein Tipp für dich:
Kauf dir eine Externe Grosse Disk (oder Online oder verschiede Geräte), sprich:
Sichere deine Daten, bau ein neues RAID auf (mit der neuen Grösse) und schreib die Daten wieder rein.

Alles andere finde ich Persönlich ein Bastel.
 
d2boxSteve schrieb:
Naja, ganz verwegener Vorschlag:

- aktualisier dein Backup
- steck die neuen Platten ein und mach dein Raid
- spiel den Backup zurück?

Oder hast du ernsthaft keinen Backup??

100% agree.
Genau so macht man das.
Wenn die Daten so wichtig sind dass du sie redundant vorhalten musst dann ist es absolut sträflich hier kein Backup zu haben.
Dann lieber auf das RAID1 verzichten und Backups machen.
 
warum leute alles kompliziert machen versteh ich nciht...

dein jetziges raid entfernen und das neue mit den HDD's machen.
nimm eine der alten HDD's und steck sie an und zieh einfach die daten wieder auf das neue raid :freak:

kein backup kein nichts läuft ja dan alles
 
Ein RAID ohne Backup ist trotzdem Schwachsinn! Die Daten sind so wichtig, dass sie 24/7 hochverfügbar sein müssen (RAID), aber wenn der Controller abkackt, der Blitz in der Nachbarschaft einschlägt, oder jemand aus Versehen Strg-a Entfernen drückt, dann hat man keinerlei Sicherung? Das passt nicht zusammen!

Man kann ein Backup ohne RAID haben, das ist sinnvoll. Wenn man ein RAID hat, muss aber auf jeden Fall mindestens ein Backup da sein, sonst hat man das Prinzip nicht verstanden!
 
highks schrieb:
Ein RAID ohne Backup ist trotzdem Schwachsinn! Die Daten sind so wichtig, dass sie 24/7 hochverfügbar sein müssen (RAID), aber wenn der Controller abkackt, der Blitz in der Nachbarschaft einschlägt, oder jemand aus Versehen Strg-a Entfernen drückt, dann hat man keinerlei Sicherung? Das passt nicht zusammen!

Man kann ein Backup ohne RAID haben, das ist sinnvoll. Wenn man ein RAID hat, muss aber auf jeden Fall mindestens ein Backup da sein, sonst hat man das Prinzip nicht verstanden!

Richtig.... aber du hast nicht verstanden das es nicht um ein backup geht sondern um das WIE er am einfachsten bzw. am besten sein Raid wieder zu gange bekommt
 
Ob und wie du im laufenden Betrieb migrieren kannst, sind noch ein paar Infos durch den TE nötig.
  • Hängen die Platten in den Einschüben direkt am Board oder einen dedizierten Raid-Controller?
  • "Fake"-Raid per Bios/Board eingerichtet oder Software-Raid per OS?
  • Welches OS?

Bei einem Linux beispielsweise und einem per mdadm angelegten Raid hast du mehrere Optionen:
Entweder: Einbau der zwei neuen Platten, weiteres Raid 1 darauf anlegen und dann entweder per dd die Daten von alt auf neu kopieren und anschließend das Dateisystem auf dem neuen Raid vergrößern oder direkt neues/großes Dateisystem auf neuem Raid anlegen und Daten per rsync o.ä. migrieren.
Oder: Eine Platte entfernen, neue große Platte rein, Rebuild abwarten. Zweite alte Platte raus, zweite neue Platte rein, erneuten Rebuild abwarten und dann das Dateisystem vergrößern.

Sollte aber vermutlich mit einem Software-Raid unter Windows ähnlich funktionieren wobei ich da nicht 100%ig weiß ob man ein Raid nachträglich vergrößern kann.
Zu bevorzugen wäre stets die erste Variante, da so keine zwei Rebuilds notwendig sind und die Daten somit weniger gefährdet sind. Variante zwei ist halt für den Fall, dass du keine weiteren zwei SATA Ports frei hast.
So oder so ist natürlich wie bereits erwähnt ein Backup sinnvoll.
 
Ob eine einzelne Platte des RAID einfach so auslesbar ist, hängt vom RAID ab. Bei denen die ihre RAID Metadaten am Anfang der Platten ablegen, wird dies nicht funktionieren, zumindest nicht an einem anderen Controller bzw. wenn der Controller nicht mehr im RAID Modus läuft und in jedem Fall hat man dann ein RAID 1 welches degraded ist.

RAID 1 sind aber auch keine Snapshots, denn RAID Controller die ihre Sache ernst nehmen, begreifen ein RAID als Volumen dessen Daten konsistent sein müssen. Spätestens wenn dann ohne eine der HDDs des RAIDs während die andere nicht vorhanden ist etwas geschrieben wird, hat man ein Problem. Ich weiß nicht mehr ob hier oder in einem anderen Forum, aber irgendwo war mal ein Thread, da hatte einer einen hochwertigen RAID Controller und zwei Platten im RAID 1 und hat sich beschwert, dass es nicht funktionieren würde. Er hat folgenden Test gemacht:
1. RAID 1 eingerichtet und (meine ich) Windows installiert
2. HDD 1 abgezogen und getestet, Windows hat normal gebootet, wurde wieder runtergefahren.
3. HDD 1 wieder eingesteckt und dafür HDD 2 entfernt.
4. Rechner hat nicht gebootet und darin hat er einen Fehler gesehen.

Das war aber kein Fehler, das war ein Profi-RAID Controller und kein Billig-Spielzeug RAID Controller, der einfach nur spiegelt. Der Profi-RAID Controller hat gemerkt, dass das RAID nach den Abziehe von HDD 1 degradiert war und da sein Inhalt überschrieben worden ist, weil Windows wie jedes OS ja auch Logs führt und damit immer auch auf sein Systemlaufwerk schreibt. Damit entsprechen nur noch die Daten auf HDD2 den aktuellen Zustand des RAIDs. Durch den direkten Tausch der beiden HDDs gab es nun diesen aktuellen Zustand nicht mehr, da die HDD2 auf der er gespeichert war, ja nicht eingebaut war und HDD1 die letzten Änderungen nicht kannte, der Controller hat das RAID also als defekt gesperrt und das war richtig.

Warum war es richtig? Nun hier hätte bei einem einfach RAID Controller der sowas nicht beachtet und wie der Type sie wohl auch nur kannte, der Rechner auch im Schritt 4 gebootet, eben ohne die Änderungen vom letzten Booten, den z.B. den Eintrag Windows hat um 11:30 gebootet der nur auf HDD2 stand. Dann wäre auf HDD 1 nun z.B. 11:45 als letzter Zeitpunkts des Bootens vermerkt. Was kommt raus, wenn man nun beide HDD bei so einem RAID wieder einbaut? Hängt davon ab, ob die Datei von der einen oder von der anderen Platte gelesen wird. Die Daten stimmen auch beiden Platten nicht überein und das fällt bei solche Billiglösung auch nicht gleichen auf, den RAID lesen immer nur von einer Platten und erst wenn es dort einen Lesefehler gibt, von der anderen. Beide Daten sind aber korrekt lesbar, weichen aber voneinander ab und das darf eben bei Enterprise RAIDs nie passieren, da können wichtig Daten drauf liegen und bei einem Abgleich kann dann auch nicht mehr sagen, welche korrekt sind.

Daher wäre der korrekte Test in dem Fall gewesen, den Schritt 3. so zu gestalten, dass man erst die HDD 1 wieder einfügt, dem RAID Controller Zeit gibt das Resync der Daten von HDD 2 auf HDD 1 abzuschließen und dann erst HDD 2 zieht. Dann hätte HDD 1 den korrekten Datenstand des RAIDs enthalten und es hätte funktioniert. Hoffentlich wurde nun verständlich was ich damit sagen will, wenn ich sage, dass ein RAID eben ein logisches Volumen und mehr als nur die Summe der Platte ist und wieso es gut ist, wenn ein Controller das auch so handhabt.
 
Zurück
Oben