[Sammelthread] AMCC 3ware 9650SE PCI-e RAID-Controller (+ Kurz-Review)
- Ersteller DoubleJ
- Erstellt am
Könnten wir nicht die BBU woanders platzieren? Man muss die doch nicht auf dem Controller befestigen? Ich krieg demnächst noch nen N54L, dann schau ich mir das nochmal von innen an.
Das ist ein sehr Interessanter Gedanke!
Hab ich noch nicht drüber nachgedacht. Wenn der Server mal wieder offen ist, schaue ich mir das mal genauer an, wie und wo ich die BBU verlegen kann.
Könnte man sonst das Anschlusskabel der Zelle an sich kappen und verlängern?
Das gibt es sogar in verlängerter Form.
Heisst dann BBU-04 und das beinhaltet dann ein Zwischenkabel welches zwischen BBU Controller und der Batterie kommt und ein Slotblech wo die eigentliche Batterie draufgeclipst wird.
Nur habt Ihr dafür keinen Platz. Das Kabel würde Euch aber helfen.
Wobei ich eher denke, dass das nicht die Temps der Batterie sind, sondern die des Controllers.
Dieser sitzt auch genau über der ROC
Heisst dann BBU-04 und das beinhaltet dann ein Zwischenkabel welches zwischen BBU Controller und der Batterie kommt und ein Slotblech wo die eigentliche Batterie draufgeclipst wird.
Nur habt Ihr dafür keinen Platz. Das Kabel würde Euch aber helfen.
Wobei ich eher denke, dass das nicht die Temps der Batterie sind, sondern die des Controllers.
Dieser sitzt auch genau über der ROC
Kann man das Kabel solo bekommen? Google weiß es leider nicht.
Sehe es immer nur im Set mit der BBU 04.
Hat vllt einer noch eins über? :vrizz;
Sehe es immer nur im Set mit der BBU 04.
Hat vllt einer noch eins über? :vrizz;
Ich habe den LSI 3Ware 9650SE mit BBU in meinem N40L (3x Festplatten und 1 SSD verbaut) ohne irgendwelche Mods und bei mir ist die Batterie nie "high". Der N40L steht schlecht belüftet in einem Holzschrank in einer Ecke- prüf mal deine Aufstellung, entweder er bekommt nicht genug Luft oder wird die warme Luft nicht los
Wie lange läuft das bei dir schon so?
Bei mir ging das mit dem High Temps nämlich nicht von Anfang an los. Hat bestimmt ein halbes Jahr gedauert bis ich das Anfing...
Zuletzt bearbeitet:
Also hier geht er nur über 45 Grad wenn die Sharkoon Raid Box daneben ebenfalls in Betrieb geht. Andern falls liegt die Temperatur bei 42 Grad (normal).
Ich habe 3 Samsung HD204UI im RAID5, nun ist mir im Webinterface aufgefallen das alle 3 Platten mit unterschiedlicher Drehzahl arbeiten!?! (3600, 4500 & 5400 U/Min)
Das RAID wurde zum Zeitpunkt des Auslesens mit Daten befüllt.
Ist das normal?! Eigentlich sollten doch alle gleich schnell arbeiten, oder liegt das am Cacheverhalten vom Controller?
Das RAID wurde zum Zeitpunkt des Auslesens mit Daten befüllt.
Ist das normal?! Eigentlich sollten doch alle gleich schnell arbeiten, oder liegt das am Cacheverhalten vom Controller?
Mein Techniker aus der Servicewerkstatt verlängert mir nun das Anschlusslkabel der BBU. Problem gelöst...
synthauri
Enthusiast
Hi,
ich bin im Moment dabei, meinen WD30EZRX das ständige Parken der Köpfe zu unterbinden. Dazu musste ich die HDDs wieder an einen anderen Rechner anschließen, da es über den 3ware-Controller nicht ging (noch nicht einmal, wenn ich die HDDS als JBOD "durchschleife". Oder hat das jemand doch mit dem 3ware hinbekommen?
THX,
Synthauri
ich bin im Moment dabei, meinen WD30EZRX das ständige Parken der Köpfe zu unterbinden. Dazu musste ich die HDDs wieder an einen anderen Rechner anschließen, da es über den 3ware-Controller nicht ging (noch nicht einmal, wenn ich die HDDS als JBOD "durchschleife". Oder hat das jemand doch mit dem 3ware hinbekommen?
THX,
Synthauri
synthauri
Enthusiast
2938 load cycles seit dem 28.12.2012, als ich mir die Seagate ST3000DM001 eingebaut habe. Der Server läuft momentan noch 24/7, wird aber demnächst nur noch 1x nachts aus dem Standby hochfahren zwecks Mirroring des Hauptservers. Dann werden die load cycles kaum noch ansteigen, aber ich find es trotzdem krass. Bei den WD30EZRX habe ich es mit wdidle3 hinbekommen, die Parkerei zu deaktivieren. Mal schauen, ob das auch dauerhaft bleibt.
Wo kann ich eigentlich die load cycles auslesen? 
synthauri
Enthusiast
In jedem SMART-Tool, beispielsweise HD-Sentinel 
8-9 Monate, also auch im Sommer ohne Probleme
hatte den Controller vorher im alten Gehäuse (Minitower) offen verbaut und da hatte ich an heissen Tagen auch hin und wieder Hitzeprobleme mit der BBU- aber seit dem Umzug in den N40L ist alles gut- muss also an der Aufstellung bei dir liegen, nicht nur am Proliant
In jedem SMART-Tool, beispielsweise HD-Sentinel
Nachdem ich mal nachgeschaut habe wie wo was ist, komme ich mir nun ein wenig dumm vor
Danke nochmals dafür!
ECC-Error
Hallo
Ich und mein 9650SE-8LPML sind seit ein paar Tagen im kritischen Zustand
Angefangen hat es, als vor ein paar Tagen mein RAID6 auf degraded fiel, weil es bei zwei Platten einen Timeout gab. Der Server hatte auch automatisch rebootet. (Keine Ahnung, warum). Die beiden Disks werden aber wieder als OK (physikalisch) angezeigt und scheinen von den SMART-Werten nicht kritisch zu sein. (Werde sie beobachten und später vermutlich ersetzen)
Problematischer ist, dass eine 3. Platte zwar noch da ist, aber mit DEVICE-ERROR (ECC) sterbenskrank ist. Die SMART-Werte sind auch kritisch und täglich gehen weitere Sektoren verloren. Diese Platte MUSS dringend ersetzt werden. Aber dazu muss das RAID-Set wieder hergestellt werden.
Wegen dem ECC-Error macht der Rebuild-Prozess jedoch nicht mehr weiter.
Da meine Devise lautet "Sichern, was noch zu retten ist, BEVOR man was dran schraubt.", habe ich am Montag begonnen, die kompletten Daten (ca. 8 TB, wobei nur ein Bruchteil persönliche Daten sind) zu sichern. Da ich nicht genügend externe Platten hatte, musste ich noch welche kaufen und so hat sich der Sicherungsprozess etwas verzögert.
Habe alles mit einem robocopy-batch gemacht. (Windows 2008 R2 Server)
Natürlich habe ich die Sicherung nach der Priorität der Daten durchgeführt. (Wichtiges zuerst)
Als die absolut kritischen Daten gesichert waren, nutzte ich den Server auch sonst wieder aktiver. Jedoch meist nur lesend und ohne wirkliche Last. Selbst mein Outlook, dessen 1.5 GB PST auf dem Server liegt, habe ich nur kurz gestartet.
Gestern Abend war ich dann auch mit der kompletten Sicherung der weniger wichtigen Daten fertig, d.h. ich hatte 100% des RAID-Sets extern gesichert. Ein paar wenige (unwichtige) Daten konnten nicht mehr gelesen werden.
Bevor ich mich heute an das Rebuilden wagen wollte (mit der eingeschalteten Option ignoreECC=on), wollte ich noch die kritischen Daten erneut sichern, damit ich die paar geänderten Daten (vorallem auch meine Outlook-Datei) seit Montag auch auf der Sicherung hatte. Also nochmals die externe Platte vom Montag angehängt und gleiche robocopy-Batch gestartet. 99% der Files waren natürlich "same", wurden also nicht gesichert. Nur die paar, die geändert wurden.
Und jetzt kommts: Ausgerechnet bei meiner so wichtigen PST-Datei gabs nun CRC-Lesefehler (ab ca. 63% der Datei). Am Montag wurde die noch sauber gesichert.
Log vom Montag:
New File 1.5 g Outlook_hw.pst
Log von heute (hatte noch 5 retrys drin):
Newer 1.5 g Outlook_hw.pst
2013/01/17 12:55:12 ERROR 23 (0x00000017) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
Data error (cyclic redundancy check).
Das "beste" an dieser Sache ist, dass robocopy nach diesen LESEfehler die ZIELdatei auf der externen Festplatte GELÖSCHT hat!! Sie ist nicht mehr da! Für mich unverständlich, das so ein professionel eingesetztes Tool sich so verhalten kann. Ist doch das A und O jedes Kopier- oder Sicherungsprogramm, dass niemals eine Zieldatei überschrieben werden darf, solange nicht die Source-Datei KOMPLETT gelesen werden konnte.
Nach diesem Schock suchte ich nach einer älteren Datensicherung (ja, ich bin etwas sicherungsfaul) und fand glücklicherweise sogar eine Komplettsicherung (inkl. dieser Outlook-Datei) vom Oktober 2012. Also Disk angehängt und Datei gesucht....sie fehlt auch hier! wtf?? Dann ein Blick in das alte Log:
Newer 1.4 g Outlook_hw.pst
2012/10/14 19:44:43 ERROR 33 (0x00000021) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
The process cannot access the file because another process has locked a portion of the file.
Irgendwie hatte ich das damals völlig übersehen, da ich das Log nur kurz gecheckt hatte. Offenbar lief noch Outlook oder sonst ein Prozess. Keine Ahnung. Auf jeden Fall ist nun die Datei auch auf dieser Sicherung nicht vorhanden. Von 7 TB Daten habe ich ca. 99.9% aller Daten zweimal gesichert - und trotzdem fehlt mir nun die Outlook-Datei.
Ich weiss, ich kann niemanden ausser mir selber einen Vorwurf machen. Wichtige Daten müssen REGELMÄSSIG gesichert werden. Seit 2 Wochen habe ich sogar ein Crashplan+ Online Abo. Ausser Tests habe ich es aber noch nicht konfiguriert. (Also leider noch keine persönlichen Daten drauf)
Zurzeit läuft nun der Rebuild. Irgendwie hoffe ich, dass nach dem Rebuild meine (defekte) Outlook-Datei zumindest wieder gelesen (sprich kopiert) werden kann, damit ich dann mal ein PST-Repair versuchen kann.
Leider habe ich auch einige Forenbeiträge gelesen, wo nach einem Rebuild mit aktiviertem ignoreECC das ganze RAID-Set korrupt war.
Zurzeit kann ich noch auf die Daten zugreifen. Aber irgendwie möchte ich noch das kleine Zeitfenster nutzen, um evtl. die Outlook-Datei noch im jetzigen Zustand wegkopieren zu können.
xcopy /c hat leider nichts gebracht, obwohl mit dem Parameter eigentlich Fehler ignoriert werden sollen.
Hat jemand einen Tip, wie man eine korrupte Datei wegkopieren kann (soviel davon halt in guten Sektoren liegt)? Oder ist es chancenlos?
Und passt mit dem robocopy-Befehl auf, wenn ihr bestehende Daten aktualisieren wollt (Differential).
Hallo
Ich und mein 9650SE-8LPML sind seit ein paar Tagen im kritischen Zustand
Angefangen hat es, als vor ein paar Tagen mein RAID6 auf degraded fiel, weil es bei zwei Platten einen Timeout gab. Der Server hatte auch automatisch rebootet. (Keine Ahnung, warum). Die beiden Disks werden aber wieder als OK (physikalisch) angezeigt und scheinen von den SMART-Werten nicht kritisch zu sein. (Werde sie beobachten und später vermutlich ersetzen)
Problematischer ist, dass eine 3. Platte zwar noch da ist, aber mit DEVICE-ERROR (ECC) sterbenskrank ist. Die SMART-Werte sind auch kritisch und täglich gehen weitere Sektoren verloren. Diese Platte MUSS dringend ersetzt werden. Aber dazu muss das RAID-Set wieder hergestellt werden.
Wegen dem ECC-Error macht der Rebuild-Prozess jedoch nicht mehr weiter.
Da meine Devise lautet "Sichern, was noch zu retten ist, BEVOR man was dran schraubt.", habe ich am Montag begonnen, die kompletten Daten (ca. 8 TB, wobei nur ein Bruchteil persönliche Daten sind) zu sichern. Da ich nicht genügend externe Platten hatte, musste ich noch welche kaufen und so hat sich der Sicherungsprozess etwas verzögert.
Habe alles mit einem robocopy-batch gemacht. (Windows 2008 R2 Server)
Natürlich habe ich die Sicherung nach der Priorität der Daten durchgeführt. (Wichtiges zuerst)
Als die absolut kritischen Daten gesichert waren, nutzte ich den Server auch sonst wieder aktiver. Jedoch meist nur lesend und ohne wirkliche Last. Selbst mein Outlook, dessen 1.5 GB PST auf dem Server liegt, habe ich nur kurz gestartet.
Gestern Abend war ich dann auch mit der kompletten Sicherung der weniger wichtigen Daten fertig, d.h. ich hatte 100% des RAID-Sets extern gesichert. Ein paar wenige (unwichtige) Daten konnten nicht mehr gelesen werden.
Bevor ich mich heute an das Rebuilden wagen wollte (mit der eingeschalteten Option ignoreECC=on), wollte ich noch die kritischen Daten erneut sichern, damit ich die paar geänderten Daten (vorallem auch meine Outlook-Datei) seit Montag auch auf der Sicherung hatte. Also nochmals die externe Platte vom Montag angehängt und gleiche robocopy-Batch gestartet. 99% der Files waren natürlich "same", wurden also nicht gesichert. Nur die paar, die geändert wurden.
Und jetzt kommts: Ausgerechnet bei meiner so wichtigen PST-Datei gabs nun CRC-Lesefehler (ab ca. 63% der Datei). Am Montag wurde die noch sauber gesichert.
Log vom Montag:
New File 1.5 g Outlook_hw.pst
Log von heute (hatte noch 5 retrys drin):
Newer 1.5 g Outlook_hw.pst
2013/01/17 12:55:12 ERROR 23 (0x00000017) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
Data error (cyclic redundancy check).
Das "beste" an dieser Sache ist, dass robocopy nach diesen LESEfehler die ZIELdatei auf der externen Festplatte GELÖSCHT hat!! Sie ist nicht mehr da! Für mich unverständlich, das so ein professionel eingesetztes Tool sich so verhalten kann. Ist doch das A und O jedes Kopier- oder Sicherungsprogramm, dass niemals eine Zieldatei überschrieben werden darf, solange nicht die Source-Datei KOMPLETT gelesen werden konnte.
Nach diesem Schock suchte ich nach einer älteren Datensicherung (ja, ich bin etwas sicherungsfaul) und fand glücklicherweise sogar eine Komplettsicherung (inkl. dieser Outlook-Datei) vom Oktober 2012. Also Disk angehängt und Datei gesucht....sie fehlt auch hier! wtf?? Dann ein Blick in das alte Log:
Newer 1.4 g Outlook_hw.pst
2012/10/14 19:44:43 ERROR 33 (0x00000021) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
The process cannot access the file because another process has locked a portion of the file.
Irgendwie hatte ich das damals völlig übersehen, da ich das Log nur kurz gecheckt hatte. Offenbar lief noch Outlook oder sonst ein Prozess. Keine Ahnung. Auf jeden Fall ist nun die Datei auch auf dieser Sicherung nicht vorhanden. Von 7 TB Daten habe ich ca. 99.9% aller Daten zweimal gesichert - und trotzdem fehlt mir nun die Outlook-Datei.
Ich weiss, ich kann niemanden ausser mir selber einen Vorwurf machen. Wichtige Daten müssen REGELMÄSSIG gesichert werden. Seit 2 Wochen habe ich sogar ein Crashplan+ Online Abo. Ausser Tests habe ich es aber noch nicht konfiguriert. (Also leider noch keine persönlichen Daten drauf)
Zurzeit läuft nun der Rebuild. Irgendwie hoffe ich, dass nach dem Rebuild meine (defekte) Outlook-Datei zumindest wieder gelesen (sprich kopiert) werden kann, damit ich dann mal ein PST-Repair versuchen kann.
Code:
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-6 REBUILDING 23%(A) - 256K 9313.17 RiW ON
VPort Status Unit Size Type Phy Encl-Slot Model
------------------------------------------------------------------------------
p0 OK u0 1.82 TB SATA 0 - WDC WD20EADS-32R6B0
p1 OK u0 1.82 TB SATA 1 - WDC WD20EARS-00S8B1
p2 OK u0 1.82 TB SATA 2 - WDC WD20EADS-32R6B0
p3 DEGRADED u0 1.82 TB SATA 3 - WDC WD20EADS-00S2B0
p4 DEGRADED u0 1.82 TB SATA 4 - WDC WD20EADS-00S2B0
p5 DEVICE-ERROR u0 1.82 TB SATA 5 - WDC WD20EADS-00R6B0
p6 OK u0 1.82 TB SATA 6 - WDC WD20EADS-32R6B0Leider habe ich auch einige Forenbeiträge gelesen, wo nach einem Rebuild mit aktiviertem ignoreECC das ganze RAID-Set korrupt war.
Zurzeit kann ich noch auf die Daten zugreifen. Aber irgendwie möchte ich noch das kleine Zeitfenster nutzen, um evtl. die Outlook-Datei noch im jetzigen Zustand wegkopieren zu können.
xcopy /c hat leider nichts gebracht, obwohl mit dem Parameter eigentlich Fehler ignoriert werden sollen.
Hat jemand einen Tip, wie man eine korrupte Datei wegkopieren kann (soviel davon halt in guten Sektoren liegt)? Oder ist es chancenlos?
Und passt mit dem robocopy-Befehl auf, wenn ihr bestehende Daten aktualisieren wollt (Differential).
Hallo,
es ist vollkommen normal, das ein Kopier-Tool (und nichts anders ist Robocopy in meinen Augen) die Zieldatei überschreibt, bevor diese von der Quelle zu 100% sauber übertragen wurde.
Das macht der normale Copy-Befehl genau so. Versuche eine Zieldatei mit einer geänderten Quelldatei per Copy Befehl zu überschreiben (aus Windows heraus mit "Kopieren", "Einfügen".
Bestätige die Warnung, das die Zieldatei überschrieben wird mit "ja". Nun während dem Kopiervorgang diesen Abbrechen, voila, die Zieldatei ist futsch. Ist ja auch klar!
Das ist definitiv ein typischer Anwenderfehler gewesen, den Du da begangen hast. Gerade in einem Fall wie diesem nimmt man nicht Robocopy oder sonst ein Kopier-/ Sync-Tool, sondern sichert explizit die einzelnen Dateien (wie z.B Deine PST) per Hand in ein Extra Verzeichnis, so das die vormals gesicherte Datei erhalten bleibt - egal was bei dem erneuten Kopiervorgang passiert.
es ist vollkommen normal, das ein Kopier-Tool (und nichts anders ist Robocopy in meinen Augen) die Zieldatei überschreibt, bevor diese von der Quelle zu 100% sauber übertragen wurde.
Das macht der normale Copy-Befehl genau so. Versuche eine Zieldatei mit einer geänderten Quelldatei per Copy Befehl zu überschreiben (aus Windows heraus mit "Kopieren", "Einfügen".
Bestätige die Warnung, das die Zieldatei überschrieben wird mit "ja". Nun während dem Kopiervorgang diesen Abbrechen, voila, die Zieldatei ist futsch. Ist ja auch klar!
Das ist definitiv ein typischer Anwenderfehler gewesen, den Du da begangen hast. Gerade in einem Fall wie diesem nimmt man nicht Robocopy oder sonst ein Kopier-/ Sync-Tool, sondern sichert explizit die einzelnen Dateien (wie z.B Deine PST) per Hand in ein Extra Verzeichnis, so das die vormals gesicherte Datei erhalten bleibt - egal was bei dem erneuten Kopiervorgang passiert.
Naja, bin nicht ganz deiner Meinung. Klar, im Nachhinein kann man jeden Fehler mit einer noch sicheren Variante erklären. ("Hätte man dies, hätte man das...")
Ich habe ja die ganzen Daten auf (neue) externe 3TB Platten gesichert. Und gerade robocopy zählt als sehr sichere und schnelle Variante, um eine solch grosse Datenmenge zu kopieren.
Natürlich hätte ich das PST einzeln woanders hinkopieren können, dann noch das wichtige File XY usw. irgendwann ist es bei dieser Datenmenge einfach mühsam, und man erstellt sich eben einen Robocopy-Job.
Die erste Sicherung vom Montag hat ja auch wunderbar geklappt. Fühlte mich ab diesen Zeitpunkt wieder sicher und habe das RAID-Set schon abgeschrieben. (Sprich: ob Rebuild oder neu erstellen wäre egal gewesen)
Mein Fehler war heute, dass ich nochmals den Robocopy-Batch gestartet habe. Aber ehrlich...überall findet man tolle Beispiele, wie man genau so seine Daten regelmässig sichern kann. Auch als differential. Ich habe sogar einige Tests vorher mit Robocopy gemacht, um zu sehen, wie er auf geänderte/neue Files reagiert. Alles war für mich okay.
Und da ich nicht genau wusste, welche von den Daten in den letzten Tagen geändert wurden (meine Freundin griff auch noch auf den Server zu, obwohl ich es ihr in den letzten Tagen mehr oder weniger untersagt hatte), war ein kompletter Robocopy (über die alte Sicherung) für mich einfach logisch.
a) wusste ich nicht, dass das PST-File seit ungefähr gestern Abend korrupt ging (gestern konnte ich ja noch normal drauf zugreifen)
b) bin ich nicht davon ausgegangen, dass robocopy bei Lesefehler die Zieldatei entfernt. Für mich war ein Überspringen (nach x Retries) das erwartete Verhalten.
Ja, jetzt weiss ich es besser und werde wohl bei der nächsten Sicherung noch einen grösseren Aufwand betreiben (müssen), obwohl vermutlich nie mehr genau so ein dummer Zustand passieren wird.
Vielleicht hat mich auch noch die andere Komplettsicherung vom Oktober 12 in einer falschen Sicherheit gewogen, sodass ich heute nicht 100% dem Safety First Prinzip gefolgt bin.
Egal, ich habe Fehler begangen und musste was daraus lernen.
Anderer Ansatzpunkt: Auf der externen Platte, bei der robocopy heute mein PST-File gelöscht hat, könnte man doch mit einem Recovery-Tool dieses versuchen, zu retten? Schliesslich ist die Datei nicht überschrieben, sondern weg. Okay, robocopy wird vermutlich nicht einen "normalen" Lösch-Befehl verwendet haben, sodass ein Undelete etwas schwieriger sein wird. Aber dennoch handelt es sich um eine normale NTFS-Disk und sollte von Tools durchsucht werden können.
Da nach dem Robocopy-Überschreibversuch keine oder nur noch ganz wenige Daten auf die Platte kamen, sollten die Fragmente der gelöschten PST-Datei eigentlich noch vorhanden sein.
Hat jemand ein Tip, mit welchem Tool man wohl solche von Robocopy "gelöschten" Dateien recovern könnte? GetDataBack for NTFS hat leider nichts gefunden. (War sonst meist ein zuverlässiges Tool dafür)
Ich habe ja die ganzen Daten auf (neue) externe 3TB Platten gesichert. Und gerade robocopy zählt als sehr sichere und schnelle Variante, um eine solch grosse Datenmenge zu kopieren.
Natürlich hätte ich das PST einzeln woanders hinkopieren können, dann noch das wichtige File XY usw. irgendwann ist es bei dieser Datenmenge einfach mühsam, und man erstellt sich eben einen Robocopy-Job.
Die erste Sicherung vom Montag hat ja auch wunderbar geklappt. Fühlte mich ab diesen Zeitpunkt wieder sicher und habe das RAID-Set schon abgeschrieben. (Sprich: ob Rebuild oder neu erstellen wäre egal gewesen)
Mein Fehler war heute, dass ich nochmals den Robocopy-Batch gestartet habe. Aber ehrlich...überall findet man tolle Beispiele, wie man genau so seine Daten regelmässig sichern kann. Auch als differential. Ich habe sogar einige Tests vorher mit Robocopy gemacht, um zu sehen, wie er auf geänderte/neue Files reagiert. Alles war für mich okay.
Und da ich nicht genau wusste, welche von den Daten in den letzten Tagen geändert wurden (meine Freundin griff auch noch auf den Server zu, obwohl ich es ihr in den letzten Tagen mehr oder weniger untersagt hatte), war ein kompletter Robocopy (über die alte Sicherung) für mich einfach logisch.
a) wusste ich nicht, dass das PST-File seit ungefähr gestern Abend korrupt ging (gestern konnte ich ja noch normal drauf zugreifen)
b) bin ich nicht davon ausgegangen, dass robocopy bei Lesefehler die Zieldatei entfernt. Für mich war ein Überspringen (nach x Retries) das erwartete Verhalten.
Ja, jetzt weiss ich es besser und werde wohl bei der nächsten Sicherung noch einen grösseren Aufwand betreiben (müssen), obwohl vermutlich nie mehr genau so ein dummer Zustand passieren wird.
Vielleicht hat mich auch noch die andere Komplettsicherung vom Oktober 12 in einer falschen Sicherheit gewogen, sodass ich heute nicht 100% dem Safety First Prinzip gefolgt bin.
Egal, ich habe Fehler begangen und musste was daraus lernen.
Anderer Ansatzpunkt: Auf der externen Platte, bei der robocopy heute mein PST-File gelöscht hat, könnte man doch mit einem Recovery-Tool dieses versuchen, zu retten? Schliesslich ist die Datei nicht überschrieben, sondern weg. Okay, robocopy wird vermutlich nicht einen "normalen" Lösch-Befehl verwendet haben, sodass ein Undelete etwas schwieriger sein wird. Aber dennoch handelt es sich um eine normale NTFS-Disk und sollte von Tools durchsucht werden können.
Da nach dem Robocopy-Überschreibversuch keine oder nur noch ganz wenige Daten auf die Platte kamen, sollten die Fragmente der gelöschten PST-Datei eigentlich noch vorhanden sein.
Hat jemand ein Tip, mit welchem Tool man wohl solche von Robocopy "gelöschten" Dateien recovern könnte? GetDataBack for NTFS hat leider nichts gefunden. (War sonst meist ein zuverlässiges Tool dafür)
WD20EARS Jumber bei Mischbetrieb mit WD20EADS
@Alex2108
Danke für den Tip. Hat leider auch nichts gebracht.
Zu meinem Vorfall schreibe ich noch morgen oder übermorgen eine abschliessende Zusammenfassung. (Als mögliche Erfahrung für andere)
Im Moment habe ich noch eine Frage zu den Jumbersettings bei einer WD20EARS Platte mit dem 9650SE Controller.
Ich hatte vorher 7 WD20EADS Platten drin. Bei allen hatte ich den Jumber 3+4 (PUIS bzw. PM2) gesetzt, damit die Platten beim Einschalten des Servers nicht gleichzeitig Strom ziehen.
Das hat bis jetzt wunderbar geklappt. Ob hier das Motherboard BIOS oder der RAID-Controller dies unterstützen muss weiss ich nicht. Vermutlich mal der RAID-Controller.
Jetzt habe ich zwei fehlerhafte EADS-Platten durch EARS-Platten ersetzt. Auf diesen ist nicht mehr explizit der Jumber 3+4 dokumentiert. Auch auf der WD Webseite wird dies bei den EARS-Modellen nicht explizit erwähnt. In einem allgemeinen SATA-Jumbersettings Dokument wird es jedoch von WD erwähnt.
Unterstützen nun die WD20EARS-Platten weiterhin diesen Jumber? (Ich habe ihn beim Einbau mal gesetzt)
Und noch eine zweite Frage bezüglich Jumber. Da die EARS-Platten im Gegensatz zur EADS mit Advanced Format kommen, gibts ja noch den Jumber 7+8. Wäre das in einem Gemischtbetrieb an diesem Controller wichtig? (RAID6)
Ich frage, weil ich im Moment am Initialisieren des RAIDS bin. Ich könnte nochmals anfangen, bevor ich meine Daten zurück kopiere.
Danke und Gruss
Visar
@Alex2108
Danke für den Tip. Hat leider auch nichts gebracht.
Zu meinem Vorfall schreibe ich noch morgen oder übermorgen eine abschliessende Zusammenfassung. (Als mögliche Erfahrung für andere)
Im Moment habe ich noch eine Frage zu den Jumbersettings bei einer WD20EARS Platte mit dem 9650SE Controller.
Ich hatte vorher 7 WD20EADS Platten drin. Bei allen hatte ich den Jumber 3+4 (PUIS bzw. PM2) gesetzt, damit die Platten beim Einschalten des Servers nicht gleichzeitig Strom ziehen.
Das hat bis jetzt wunderbar geklappt. Ob hier das Motherboard BIOS oder der RAID-Controller dies unterstützen muss weiss ich nicht. Vermutlich mal der RAID-Controller.
Jetzt habe ich zwei fehlerhafte EADS-Platten durch EARS-Platten ersetzt. Auf diesen ist nicht mehr explizit der Jumber 3+4 dokumentiert. Auch auf der WD Webseite wird dies bei den EARS-Modellen nicht explizit erwähnt. In einem allgemeinen SATA-Jumbersettings Dokument wird es jedoch von WD erwähnt.
Unterstützen nun die WD20EARS-Platten weiterhin diesen Jumber? (Ich habe ihn beim Einbau mal gesetzt)
Und noch eine zweite Frage bezüglich Jumber. Da die EARS-Platten im Gegensatz zur EADS mit Advanced Format kommen, gibts ja noch den Jumber 7+8. Wäre das in einem Gemischtbetrieb an diesem Controller wichtig? (RAID6)
Ich frage, weil ich im Moment am Initialisieren des RAIDS bin. Ich könnte nochmals anfangen, bevor ich meine Daten zurück kopiere.
Danke und Gruss
Visar
Versuch mal bitte Testdisk. Geht sehr gut damit. Kannst die PST damit auch rauskopieren. Vorraussetzung ist halt, dass die HDD nicht neu formatiert wurde. Dann könnte das Ganze etwas dauern...
Ohne hier jetzt Hoffnungen zerstören zu wollen, kann ich nur sagen, dass jeglicher Schreibzugriff Gift ist, wenn man etwas retten möchte.
Du hast nicht gerade wenig geschrieben danach, vergess das nicht.
Die pst wurde gelöscht und danach versucht die neue zu schreiben.
Da wirst Du von der alten sicher schon was überschrieben haben.
Du hast nicht gerade wenig geschrieben danach, vergess das nicht.
Die pst wurde gelöscht und danach versucht die neue zu schreiben.
Da wirst Du von der alten sicher schon was überschrieben haben.
@FNBalu
Eigentlich habe ich (fast) gar nichts überschrieben.
Ich habe eine neue 3 TB Platte formatiert und als externes USB-Laufwerk an den Server gehängt.
Danach habe ich mit Robocopy eine Komplettsicherung (ohne Moviedateien) des zu diesem Zeitpunkt bereits degraded RAID6 erstellt. Abgesehen von ein paar wenigen Dateien, welche auf der Source nicht mehr gelesen werden konnten, wurde alles gesichert. Dies ist somit der hauptsächliche Schreibvorgang auf dieser externen Platte.
Hier ein Auszug aus diesem Robocopy-Batch:
Zu diesem Zeitpunkt war mein aktuelles PST (Outlook_hw.pst) mit Stand vom 12.1. auf der externen Platte sauber gesichert.
Bevor ich dann das weiter absterbende RAID löschen bzw. Rebuilden wollte, startete ich nochmals ein "Update"-Robocopy Job. Hier ein Auszug:
Nach diesem fehlerhaften Retry-Versuch, bei dem mein Outlook_hw.pst gelöscht wurde, wurden ANSCHLIESSEND gemäss Log noch ganze 3 Dateien GESCHRIEBEN (ca. 1.7 MB Total). Alles andere wurde übersprungen, da sich ja nichts geändert hatte ("same").
Die externe Platte wurde dann nicht mehr aktiv genutzt, nur noch für Lesezugriffe. Es wurde nichts gelöscht und keine weiteren Daten mehr draufgeschrieben. Es hat auch noch ca. 900 GB frei auf der Platte. Geht ein Schreibvorgang nicht zuerst auf freie Sektoren als auf Sektoren, welche durch ein Löschvorgang frei geworden sind?
Egal, ich hatte wirklich das Gefühl, dass hier die Chancen für ein Recovery dieser einzelnen (okay, relativ grossen) Datei funktionieren müsste.
GetDataBack for NTFS hat gar nichts gefunden. EaseUS Data Recovery Wizard hat die PST 5x gefunden, aber als "unrecoverable" bezeichnet, weil alle Sektoren von einer anderen Datei überschrieben sein sollen. Komischerweise handelt es sich um eine ISO-Datei, welche bei der Update-Sicherung nicht neu geschrieben wurde. Sehr merkwürdig.
Ein Test mit TestDisk werde ich noch durchführen. Aber erst, wenn ich die Daten zurückkopiert habe. Im Moment liegen alle meine Daten auf dieser externen Platte. Da möchte ich keine unnötigen Experimente durchführen (auch wenn nicht-destruktiv).
Über dieses Robocopy-Verhalten mache ich mir übrigens immer noch so meine Gedanken...auch wenn es offenbar "normal" sein sollte.
Eigentlich habe ich (fast) gar nichts überschrieben.
Ich habe eine neue 3 TB Platte formatiert und als externes USB-Laufwerk an den Server gehängt.
Danach habe ich mit Robocopy eine Komplettsicherung (ohne Moviedateien) des zu diesem Zeitpunkt bereits degraded RAID6 erstellt. Abgesehen von ein paar wenigen Dateien, welche auf der Source nicht mehr gelesen werden konnten, wurde alles gesichert. Dies ist somit der hauptsächliche Schreibvorgang auf dieser externen Platte.
Hier ein Auszug aus diesem Robocopy-Batch:
Code:
-------------------------------------------------------------------------------
ROBOCOPY :: Robust File Copy for Windows
-------------------------------------------------------------------------------
Started : Sat Jan 12 15:58:42 2013
Source : d:\Daten\Office\
Dest : G:\Daten\Office\
Files : *.*
Options : *.* /V /TEE /S /E /COPY:DAT /NP /R:5 /W:15
------------------------------------------------------------------------------
New Dir 1 d:\Daten\Office\
New File 6148 .DS_Store
New Dir 0 d:\Daten\Office\hw\
New Dir 5 d:\Daten\Office\hw\Mails\
[COLOR="#FF0000"][B]New File 1.5 g Outlook_hw.pst[/B][/COLOR]
New File 1.3 g Outlook_hw_.pst
New File 191.8 m Outlook_hw_old.pstZu diesem Zeitpunkt war mein aktuelles PST (Outlook_hw.pst) mit Stand vom 12.1. auf der externen Platte sauber gesichert.
Bevor ich dann das weiter absterbende RAID löschen bzw. Rebuilden wollte, startete ich nochmals ein "Update"-Robocopy Job. Hier ein Auszug:
Code:
-------------------------------------------------------------------------------
ROBOCOPY :: Robust File Copy for Windows
-------------------------------------------------------------------------------
Started : Thu Jan 17 11:21:47 2013
Source : d:\Daten\
Dest : E:\Daten\
Files : *.*
Exc Dirs : d:\Daten\Video\Movies
Options : *.* /V /TEE /S /E /COPY:DAT /NP /R:5 /W:5
------------------------------------------------------------------------------
<schnippel>
1 d:\Daten\Office\
same 6148 .DS_Store
0 d:\Daten\Office\hw\
5 d:\Daten\Office\hw\Mails\
same 1.3 g Outlook_hw_.pst
same 191.8 m Outlook_hw_old.pst
[B][COLOR="#FF0000"] Newer 1.5 g Outlook_hw.pst
2013/01/17 12:55:12 ERROR 23 (0x00000017) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
Data error (cyclic redundancy check).
[/COLOR][/B]
Waiting 5 seconds... Retrying...
Newer 1.5 g Outlook_hw.pst
2013/01/17 12:56:15 ERROR 23 (0x00000017) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
Data error (cyclic redundancy check).
Waiting 5 seconds... Retrying...
Newer 1.5 g Outlook_hw.pst
2013/01/17 12:57:19 ERROR 23 (0x00000017) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
Data error (cyclic redundancy check).
Waiting 5 seconds... Retrying...
Newer 1.5 g Outlook_hw.pst
2013/01/17 12:58:24 ERROR 23 (0x00000017) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
Data error (cyclic redundancy check).
Waiting 5 seconds... Retrying...
Newer 1.5 g Outlook_hw.pst
2013/01/17 12:59:33 ERROR 23 (0x00000017) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
Data error (cyclic redundancy check).
Waiting 5 seconds... Retrying...
Newer 1.5 g Outlook_hw.pst
2013/01/17 13:00:37 ERROR 23 (0x00000017) Copying File d:\Daten\Office\hw\Mails\Outlook_hw.pst
Data error (cyclic redundancy check).
ERROR: RETRY LIMIT EXCEEDED.
<schnippel>Nach diesem fehlerhaften Retry-Versuch, bei dem mein Outlook_hw.pst gelöscht wurde, wurden ANSCHLIESSEND gemäss Log noch ganze 3 Dateien GESCHRIEBEN (ca. 1.7 MB Total). Alles andere wurde übersprungen, da sich ja nichts geändert hatte ("same").
Die externe Platte wurde dann nicht mehr aktiv genutzt, nur noch für Lesezugriffe. Es wurde nichts gelöscht und keine weiteren Daten mehr draufgeschrieben. Es hat auch noch ca. 900 GB frei auf der Platte. Geht ein Schreibvorgang nicht zuerst auf freie Sektoren als auf Sektoren, welche durch ein Löschvorgang frei geworden sind?
Egal, ich hatte wirklich das Gefühl, dass hier die Chancen für ein Recovery dieser einzelnen (okay, relativ grossen) Datei funktionieren müsste.
GetDataBack for NTFS hat gar nichts gefunden. EaseUS Data Recovery Wizard hat die PST 5x gefunden, aber als "unrecoverable" bezeichnet, weil alle Sektoren von einer anderen Datei überschrieben sein sollen. Komischerweise handelt es sich um eine ISO-Datei, welche bei der Update-Sicherung nicht neu geschrieben wurde. Sehr merkwürdig.
Ein Test mit TestDisk werde ich noch durchführen. Aber erst, wenn ich die Daten zurückkopiert habe. Im Moment liegen alle meine Daten auf dieser externen Platte. Da möchte ich keine unnötigen Experimente durchführen (auch wenn nicht-destruktiv).
Über dieses Robocopy-Verhalten mache ich mir übrigens immer noch so meine Gedanken...auch wenn es offenbar "normal" sein sollte.
So benötige nochmals eure Hilfe.
Mein 9650SE 4LPML wird ausgebaut. Wenn ich die Single Disks (JBOD?) auflöse im Webinterface, gehen mir meine Daten dann flöten?
Kann ich andernfalls einfach den Controller ausbauen und die HDD normal weiterverwenden?
€:
Habs mal getestet. Es funktioniert. Teilweise. 2 der 4 HDDs musste ich mit Testdisk anschubsen. Kurz mal die Partitionstabelle neugeschrieben und weiter gehts.
Mein 9650SE 4LPML wird ausgebaut. Wenn ich die Single Disks (JBOD?) auflöse im Webinterface, gehen mir meine Daten dann flöten?
Kann ich andernfalls einfach den Controller ausbauen und die HDD normal weiterverwenden?
€:
Habs mal getestet. Es funktioniert. Teilweise. 2 der 4 HDDs musste ich mit Testdisk anschubsen. Kurz mal die Partitionstabelle neugeschrieben und weiter gehts.
Zuletzt bearbeitet:
http://www.hardwareluxx.de/community/f168/lsi-3ware-9650se-4lpml-mit-bbu-939105.html#post20068037
Trenne mich nun von meinem 9650SE 4LPML mit BBU. Nutze wieder den onboard Raidcontroller, da ich eh nur JBOD fahre.
Trenne mich nun von meinem 9650SE 4LPML mit BBU. Nutze wieder den onboard Raidcontroller, da ich eh nur JBOD fahre.
Ähnliche Themen
[Kaufberatung]
"Vernünftige" USB-C Steckkarte gesucht
