Beiträge von bafh

Theoretisch müssten die Daten noch da sein, da ja noch 3 der 4 HDDs vorhanden waren/sind. Ich habe die HDDs in der Zwischenzeit ausgebaut, 4 neue eingebaut und ein Restore ausgeführt. Der Tausch der HDDs hängt mit dem Alter (3 Jahre) zusammen.

Hallo,

ich habe versehentlich HDD2 aus einem (fehlerfreien) RAID5 mit 4 Festplatten (TS459U+) ausgebaut, als ich selbige HDD aus dem darüber liegenden NAS (TS419) ausbauen wollte. Nachdem ich den Fehler sofort bemerkt habe und das auch in der Weboberfläche gesehen habe steckte ich die HDD wieder ein, worauf ein Rebuild eingeleitet wurde. Etwa 30 Stunden später kam es zu einem Stromausfall

Nach einem Neustart des Geräts wurden alle 4 HDDs (3 TB als HDD1 (ist mal als Ersatz für eine 2 TB gekommen), 2 TB sonst) gefunden, die Freigaben waren im Windows Explorer sichtbar, jedoch war das RAID "nicht aktiv". Ich bin dann gemäß Anleitung des Support vorgegangen:

mdadm -S /dev/md0/etc/init.d/services.sh stopumount /dev/md0mdadm -CfR –assume-clean /dev/md0 -l 5 -n 4 /dev/sda3 missing /dev/sdc3 /dev/sdd3

Der Versuch das RAID anschließend zu mounten schlägt jedoch fehl. Zunächst hatte ich folgendes Problem:

[~] # mount /dev/md0 /share/MD0_DATA -t ext4mount: wrong fs type, bad option, bad superblock on /dev/md0,       missing codepage or other error       In some cases useful info is found in syslog - try       dmesg | tail  or so

[~] # dmesg | tail[71292.998350]  disk 0, o:1, dev:sda3[71292.998355]  disk 2, o:1, dev:sdc3[71292.998360]  disk 3, o:1, dev:sdd3[71292.998431] md0: detected capacity change from 0 to 5996376686592[71306.671145]  md0: unknown partition table[71391.235477] EXT4-fs (md0): bad geometry: block count 1463959200 exceeds size of device (1463959152 blocks)[71450.095364] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (240) [~] # e2fsck /dev/md0e2fsck 1.41.4 (27-Jan-2009)/dev/md0: recovering journalThe filesystem size (according to the superblock) is 1463959200 blocksThe physical size of the device is 1463959152 blocksEither the superblock or the partition table is likely to be corrupt!answer=1

Der Support hat an dieser Stelle auf das Backup verwiesen. Ich habe testweise das NAS noch einmal neu gestartet und noch einmal versucht das RAID zu mounten:

mount /dev/md0 /share/MD0_DATA -t ext4

Der Befehl wird aktuell noch ausgeführt...

Auf dem RAID liegen etwa 4,5 TB Daten, von denen leider nur 3,9 TB gesichert sind. Die versehentlich nicht gesicherten Daten würden mich nicht umbringen aber es wäre höchst ärgerlich diese zu verliegen. Von daher würde ich diese verständlicherweise gerne retten!

Was kann/sollte ich noch tun um wieder Herr über meine Daten zu werden?

LG, Martin

Also weitergesponnen:

7 iSCSI Targets für die Images (6* 0,25 TB + 2 TB = 3,5 TB) erstellen. Anschließend erstelle ich mit dem Rest (ca. 2 TB) ein Volume, auf welches via Netzwerk kollektiv zugegriffen werden kann.

Sollte ich zur Ausnutzung des blockbasierten Zugriffs bei der Image-Erstellung mit einem zweiten (unmanaged) Switch ein zweites Netzwerk aufbauen, welches nur für iSCSI verwendet wird? Adresszuweisung per DHCP, anderer Adressbereich, kein DNS, kein Gateway!?

192.168.0.x <- LAN (DHCP, DNS, WINS etc. funktioniert alles wunderprächtig)
192.168.1.x <- iSCSI (neu: nur DHCP, Ansteuerung per IP ohne Aufnahme ins DNS)

Martin

Hey,

ich wollte nicht sagen, dass keine weiteren Ausgaben getätigt werden dürfen, sondern nur, dass diese nicht überhand nehmen sollten. Wenn ein neuer Switch her muss ist das so - ich würde nur ungern mehr als 500 € ausgeben. Würden folgende Modelle die Anforderungen genügen:

Level One GSW-2692
http://www.level-one.de/levelo…d&cat=7016&model=GSW-2692

Longshine LCS-GS9428
http://www.longshine.de/longsh…bit/GS9428/GS9428_ger.pdf

Ansonsten werde ich am WE mal die Direktverbindung per iSCSI testen. Scheinbar ist die Einrichtung mehrerer Targets (für jeden Client eins) mit Anbindung über den Server eine gute Wahl. Wenn ich nun den Server direkt per 2 GBit mit dem NAS verbinde fällt zwar der direkte Zugriff weg, aber das ist durchaus tragbar - schließlich ist dies ja nur ein zu ändernder Pfad.

Martin

Guten Abend,

ich habe ein TS-419U mit 4* 2 TB als RAID5. Dieses habe ich in unsere Netzwerk Domäne (Windows 2003 Server mit AD, 6 Clients) aufgenommen. Die Einrichtung von Freigaben etc. hat auch wunderbar funktioniert und klappt. Für die Anbindung nutze ich eine Netzwerkkarte. Das gesamte Netzwerk hat ausnahmslos 1 GBit, der Switch unterstützt kein Trunking.

Die im laufenden Betrieb zu transferierenden Datenmengen belaufen sich auf 5 - 10 GB im Laufe eines Tages, dies ist folglich zu vernachlässigen und nicht zeitkritisch. Dazu kommen aber TrueImage-Abbilder, wofür durchschnittlich bis zu 10 GB je Client und 100 GB für den Server anfallen. Ein vollständiges Image des Servers belegt etwa 700 GB, die der Clients zwischen 30 und 70 GB. Zwecks Einsparung von Energie werden die Clients nach Arbeitsende ausgeschaltet. Die Images werden (mit Ausnahme des Servers) morgens bei Arbeitsbeginn automatisch erstellt - verständlicherweise sollte dieser Prozess (auch wenn er im Hintergrund abläuft) in möglichst kurzer Zeit abgeschlossen werden. Aufgrund von Gleitzeit ist davon auszugehen, dass 2-3 Clients gleichzeitig Images erstellen.

Jedoch würde ich gerne die Performance verbessern Ich habe gesehen, dass das NAS iSCSI unterstützt und sehe folgende Möglichkeiten:

Bis auf eine Ausnahme verfügen alle Rechner über 2 (onBoard) Gigabit LAN-Karten, der letzte könnte noch eine Zweite verpasst bekommen. Somit könnte mittels den jeweils ungenutzten Karten ein iSCSI-Netzwerk aufgebaut werden. Nach meinen Informationen müsste hierfür je Client ein Target eingerichtet werden. Diese sollten je Client 250 GB und für den Server 2 TB groß sein, der Rest sollte weiterhin über das AD gemeinsam erreichbar sein. Eine ordnungsgemäße Netzwerkverkabelung ist vorhanden.

Im Server steckt eine Intel Pro/1000 PT Quad Port NIC mit derzeit 3 ungenutzten Ports. Von dieser sollte ich eine 2 GBit Netzwerkverbindung zum NAS aufbauen können oder eine 2 GBit iSCSI-Verbindung aufbauen können.

Welche dieser Möglichkeiten sind grundsätzlich realisierbar und welche ist in Punkto Geschwindigkeit und Administration die geeigneteste? Nach Möglichkeit sollen keine weiteren Investitionen getätigt werden müssen.

Vielen Dank für Anregungen!

Martin