47
HPE Server + Datenverlust
Guten Morgen Admins,
für folgenden Fall hoffe ich auf eine letzte Hilfe.
Problem
Auf einem DataCenter laufen viele VMs, ein Teil davon kann nicht mehr gesichert werden, egal wie, die VHDX lässt sich nicht wegkopieren. Datenfehler (CRC-Prüfung),... nichts zu machen.
Ursache
Smart Storage Administrator
Nicht wiederherstellbare Medienfehler auf Laufwerken während des letzten Umbaus oder einer Background Surface Analyse (ARM).
Fehler werden automatisch behoben, wenn der Sektor/die Sektoren überschrieben wird/werdem Sicherung und Wiederherstellung sind empfehlenswert.
Auslöser
Eine Routine, eine Festplatte meldete Verschleiß an (danke an Observium/Zabbix das ich keine ILO Lizenz zahlen muss) und wurde getauscht. Das hatte sonst immer gut funktioniert, also früher, damals.
HPE Support
zusammengefasster Aktionsplan:
Löschen Sie das logische Laufwerk auf dem all ihre VMs liegen und erstellen es neu.
Fazit
Das System/Server/DataCenter fällt erstmal mit einer ordentlich Downtime aus.
Frage
Hatte jemand den Fehler schon und konnte das Problem anders lösen, d.h. ohne das logisch Laufwerk löschen zu müssen?
Info
Mir ist der Ablauf klar, ich weiß was ich zu tun haben und kenne den Aufwand dahinter.
Über Hilfe und Anregungen freue ich mich, auf konstruktive Vorschläge gehe ich sehr gern ein,
Danke im Voraus!
für folgenden Fall hoffe ich auf eine letzte Hilfe.
Problem
Auf einem DataCenter laufen viele VMs, ein Teil davon kann nicht mehr gesichert werden, egal wie, die VHDX lässt sich nicht wegkopieren. Datenfehler (CRC-Prüfung),... nichts zu machen.
Ursache
Smart Storage Administrator
Nicht wiederherstellbare Medienfehler auf Laufwerken während des letzten Umbaus oder einer Background Surface Analyse (ARM).
Fehler werden automatisch behoben, wenn der Sektor/die Sektoren überschrieben wird/werdem Sicherung und Wiederherstellung sind empfehlenswert.
Auslöser
Eine Routine, eine Festplatte meldete Verschleiß an (danke an Observium/Zabbix das ich keine ILO Lizenz zahlen muss) und wurde getauscht. Das hatte sonst immer gut funktioniert, also früher, damals.
HPE Support
zusammengefasster Aktionsplan:
Löschen Sie das logische Laufwerk auf dem all ihre VMs liegen und erstellen es neu.
Fazit
Das System/Server/DataCenter fällt erstmal mit einer ordentlich Downtime aus.
Frage
Hatte jemand den Fehler schon und konnte das Problem anders lösen, d.h. ohne das logisch Laufwerk löschen zu müssen?
Info
Mir ist der Ablauf klar, ich weiß was ich zu tun haben und kenne den Aufwand dahinter.
Über Hilfe und Anregungen freue ich mich, auf konstruktive Vorschläge gehe ich sehr gern ein,
Danke im Voraus!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 83993748354
Url: https://administrator.de/contentid/83993748354
Ausgedruckt am: 03.12.2024 um 17:12 Uhr
47 Kommentare
Neuester Kommentar
Falls noch nen weiterer Host mit passenden Ressourcen vorhanden ist könnte man versuchen die VMs mit shared-nothing live-migration rüberzuschieben.
Zitat von @pebcak7123:
Falls noch nen weiterer Host mit passenden Ressourcen vorhanden ist könnte man versuchen die VMs mit shared-nothing live-migration rüberzuschieben.
Danke.Falls noch nen weiterer Host mit passenden Ressourcen vorhanden ist könnte man versuchen die VMs mit shared-nothing live-migration rüberzuschieben.
Bricht leider ab, nicht mal ein lokaler Export funktioniert (VM natürlich runtergefahren).
Ich könnte zwar Daten/VMs auf den Host schieben und in Betrieb nehmen, aber die VMs die vom Medienfehler betroffen sind, lassen sich nicht bewegen.
Gehen wir einfach davon aus, es gibt keine andere Hardware auf welche ich ausweichen kann. Sowas soll's ja in der Praxis geben, KMUs mit nur einem Hardwareserver.
was sagt HP Support dazu?
(wenn die keine Lösung wissen, dann gibts eh keine)
und wenn ihr keinen Wartungsvertrag habt, tja dann per Stunde bezahlen...
Ist mal meine Empfehlung dazu.
Weil nur dann weisst du ob es eben ne Lösung dazu gibt, oder halt "vergiss es".
Meine Erfahrung da sitzen wirklich sehr fähige System Engineers im 2nd Level Support.
(wenn die keine Lösung wissen, dann gibts eh keine)
und wenn ihr keinen Wartungsvertrag habt, tja dann per Stunde bezahlen...
Ist mal meine Empfehlung dazu.
Weil nur dann weisst du ob es eben ne Lösung dazu gibt, oder halt "vergiss es".
Meine Erfahrung da sitzen wirklich sehr fähige System Engineers im 2nd Level Support.
Wäre auch interessant zu wissen was das denn für ein Storage ist. Interne Laufwerke in irgendeinem Raid ?
Aus dem Bericht lese ich jetzt raus, lokaler Storage, eine HDD rausgezogen, Neue rein. Korrekt?
Du schreibst, einige lassen sich nicht nicht mehr sichern/verschieben. Es betrifft also nicht das ganze Volume?
Was für ein Dateisystem verwendest Du?
Vielleicht sind ein paar Infos noch Hilfreich um ggf. noch eine Idee zu haben.
Eine Routine, eine Festplatte meldete Verschleiß an (danke an Observium/Zabbix das ich keine ILO Lizenz zahlen muss) und wurde getauscht. Das hatte sonst immer gut funktioniert, also früher, damals.
Wurde dazu der lokalen Stoarge manager benutzt und das Laufwerk zuvor dekativiert? Gibt es eine HotSpare, die eingesprungen ist? Offenbar ist ja beim rebuild was kaputt gegangen am logischen Teil.Du schreibst, einige lassen sich nicht nicht mehr sichern/verschieben. Es betrifft also nicht das ganze Volume?
Was für ein Dateisystem verwendest Du?
Vielleicht sind ein paar Infos noch Hilfreich um ggf. noch eine Idee zu haben.
Also ein RAID geht normalerweise nicht kaputt bei einem Plattentausch, auch wenn man nicht manuell vorher die defekte Platte deaktiviert. Welches Dateisystem ist das denn, hier gabs ja grade erst eine große Diskussion in einem Fall mit ReFS und iSCSI mount. Es wäre definitiv wichtig zumindest eine Theorie zu haben, warum und wann das passiert ist.
Geht es jetzt nur um eine Minimierung der Downtime oder sind ansonsten wirklich Daten unwiederbringlich verloren? Solche Threads gibt es ja immer wieder und viele probieren sofort drauf los aber irgendjemand trägt eventuell eine Verantwortung und in solchen Fällen wird es schnell auch mal schlimmer. Daher sollte man sich selbst erstmal darüber klar werden wo das Ziel liegt und wenn man hier im Forum fragt, auch mitteilen, ob eventuell Risiken bestehen. Es gibt ja z.B. auch auf Datenrettung spezialisierte Unternehmen, da geht es dann nicht um Zeit und Downtime sondern um Informationserhalt.
In einem ähnlichen Fall gab es eine kaputte Datenbank aufgrund einer defekten Platte. Leider fehlt auch in dem Thread viel an Struktur und ich weiß nicht, was das Ergebnis ist:
Defekte SQL-Datenbank reparieren
Geht es jetzt nur um eine Minimierung der Downtime oder sind ansonsten wirklich Daten unwiederbringlich verloren? Solche Threads gibt es ja immer wieder und viele probieren sofort drauf los aber irgendjemand trägt eventuell eine Verantwortung und in solchen Fällen wird es schnell auch mal schlimmer. Daher sollte man sich selbst erstmal darüber klar werden wo das Ziel liegt und wenn man hier im Forum fragt, auch mitteilen, ob eventuell Risiken bestehen. Es gibt ja z.B. auch auf Datenrettung spezialisierte Unternehmen, da geht es dann nicht um Zeit und Downtime sondern um Informationserhalt.
In einem ähnlichen Fall gab es eine kaputte Datenbank aufgrund einer defekten Platte. Leider fehlt auch in dem Thread viel an Struktur und ich weiß nicht, was das Ergebnis ist:
Defekte SQL-Datenbank reparieren
Moin...
Backup der VMs funktionert?
Frank
Backup der VMs funktionert?
Frank
Vielen Dank, ich reiche nach:
@ThePinky777
Was HPE sagt hatte ich geschrieben.
@pebcak7123
lokal, RAID5
@pcpanik
Korrekt, aber leider kein Hotspare dabei.
Die Platten werden vom HPE Techniker getauscht, der Kunde hat das bezahlt und darf die Finger davon lassen.
Ja, es betrifft nicht alle VMs auf dem Host.
NTFS wird verwendet.
@ukulele-7
Danke für den vielen Text, hilft leider 0%, da du das Kernproblem nicht erfasst hast (siehe Titel).
Du darfst dich natürlich, z.B. bei einem Autounfall, erstmal mit dem Hersteller und Fahrer unterhalten, warum denn das Auto so schnell gefahren ist, noch bevor du den Notruf wählst.
Falls ich aber deine konstruktive Hilfe überlesen habe, entschuldige ich mich schomal
.
@Vision2015
nur zum Teil
@ThePinky777
Was HPE sagt hatte ich geschrieben.
@pebcak7123
lokal, RAID5
@pcpanik
Korrekt, aber leider kein Hotspare dabei.
Die Platten werden vom HPE Techniker getauscht, der Kunde hat das bezahlt und darf die Finger davon lassen.
Ja, es betrifft nicht alle VMs auf dem Host.
NTFS wird verwendet.
@ukulele-7
Danke für den vielen Text, hilft leider 0%, da du das Kernproblem nicht erfasst hast (siehe Titel).
Du darfst dich natürlich, z.B. bei einem Autounfall, erstmal mit dem Hersteller und Fahrer unterhalten, warum denn das Auto so schnell gefahren ist, noch bevor du den Notruf wählst.
Falls ich aber deine konstruktive Hilfe überlesen habe, entschuldige ich mich schomal
.@Vision2015
nur zum Teil
Moin...
backups der betroffenden VMs sind nicht möglich?
Frank
backups der betroffenden VMs sind nicht möglich?
Frank
Nein, in keinster Weise. Ich kann nicht mal die VHDX per Hand kopieren, weder auf das gleiche System/RAID, noch auf ein anderes. Es bricht dann ab, weil die Quelldatei nicht gelesen werden konnte.
Was ich interessant finde, dass Deine VMs noch laufen. Die müssen doch Änderungen schreiben.
NTFS ... Du kannst mit chkdsk /scan mal gucken, ob es eine Reperaturmöglichkeit findet.
NTFS ... Du kannst mit chkdsk /scan mal gucken, ob es eine Reperaturmöglichkeit findet.
Hi,
wenn chkdsk nichts bringt, evtl. mit ddrescue (gnu ddrescue) versuchen offline die daten zu kopieren.
wenn chkdsk nichts bringt, evtl. mit ddrescue (gnu ddrescue) versuchen offline die daten zu kopieren.
@pcpanik
Auf Basis vom Datacenter ein chkdsk durchrasseln zu lassen... wer hält da meine Hand?
Ich hab da etwas Bedenken, den Ansatz hatte ich auch schon, aber dann vom HPE Support erwartet, es hat sicherlich (Optimist) seinen Grund.
@Flash600
Da muss ich in dem Praxisfall wirklich abwägen, dass Unbekannte zu wagen oder den bekannten Prozess, d.h. die Schadensminimierung, zu starten.
Auf Basis vom Datacenter ein chkdsk durchrasseln zu lassen... wer hält da meine Hand?
Ich hab da etwas Bedenken, den Ansatz hatte ich auch schon, aber dann vom HPE Support erwartet, es hat sicherlich (Optimist) seinen Grund.
@Flash600
Da muss ich in dem Praxisfall wirklich abwägen, dass Unbekannte zu wagen oder den bekannten Prozess, d.h. die Schadensminimierung, zu starten.
/scan guckt ja erstmal nur. Aber ich kann Deine Bedenken verstehen.
Ich würde alle VMs, die sich verschieben lassen da runter holen. Wirst Du wahrscheinlich schon gemacht haben.
Dann prüfen, ob die letzten Backups funktional sind. Gff. vorher ein Offline-Image abziehen, sofern Du die Option hast.
Eine viel andere Wahl bleibt Dir ja kaum, sofern hier nicht noch jemandem was Schlaues einfällt. Und dann erstmal mit /scan gucken. Mit einem erfolgreichen Image im Rücken ist es wohl noch immer Risikoreich aber besser als ohne.
Im aktuellen Zustand sind Deine VMs ja offenbar auch verloren.
Ich würde alle VMs, die sich verschieben lassen da runter holen. Wirst Du wahrscheinlich schon gemacht haben.
Dann prüfen, ob die letzten Backups funktional sind. Gff. vorher ein Offline-Image abziehen, sofern Du die Option hast.
Eine viel andere Wahl bleibt Dir ja kaum, sofern hier nicht noch jemandem was Schlaues einfällt. Und dann erstmal mit /scan gucken. Mit einem erfolgreichen Image im Rücken ist es wohl noch immer Risikoreich aber besser als ohne.
Im aktuellen Zustand sind Deine VMs ja offenbar auch verloren.
Moin...
Hyper-Replikation ?
Frank
Zitat von @nachgefragt:
Nein, in keinster Weise. Ich kann nicht mal die VHDX per Hand kopieren, weder auf das gleiche System/RAID, noch auf ein anderes. Es bricht dann ab, weil die Quelldatei nicht gelesen werden konnte.
hm... da die VMs laufen, hast du mal ein Backup innerhalb der VM versucht- meinetwegen mit dem Windows Backup Programm?Nein, in keinster Weise. Ich kann nicht mal die VHDX per Hand kopieren, weder auf das gleiche System/RAID, noch auf ein anderes. Es bricht dann ab, weil die Quelldatei nicht gelesen werden konnte.
Hyper-Replikation ?
Frank
Hallo,
ich würde wahrscheinlich zunächst das Volume im Hyper-V offline nehmen und einen ARM-Scan ausführen. Beim Rebuild, insbesondere unter Last, können Medienfehler auch temporär (Timeout) bzw. falsch detektiert werden und sind mangels Parität zwangsläufig nicht korrigierbar, sodass der Controller die Sektoren ausblendet.
Das ist aber davon abhängig, wie viel Vertrauen man in die ursprünglich nicht ausgefallenen Disks hat, und wie groß die Zahl der vom Host nicht lesbaren Sektoren ist.
Ansätze auf Ebene des Host-Dateisystems oder darüber geben jedenfalls die vom Controller als nicht lesbar markierten Sektoren verloren, was vom Umfang her das ganze Vorhaben konterkarieren kann. Man kann dabei eigentlich nur unter Ignorieren der Fehler kopieren: https://github.com/DavorJ/PS-ForceCopy/blob/master/Force-Copy.ps1
Oder die nicht lesbaren Sektoren in-place nullen mit einem Disk-Editor und dann regulär kopieren (vorausgesetzt, die Fehlermeldung ist korrekt und nicht nur subsidiär für einen größeren Schaden).
Grüße
Richard
ich würde wahrscheinlich zunächst das Volume im Hyper-V offline nehmen und einen ARM-Scan ausführen. Beim Rebuild, insbesondere unter Last, können Medienfehler auch temporär (Timeout) bzw. falsch detektiert werden und sind mangels Parität zwangsläufig nicht korrigierbar, sodass der Controller die Sektoren ausblendet.
Das ist aber davon abhängig, wie viel Vertrauen man in die ursprünglich nicht ausgefallenen Disks hat, und wie groß die Zahl der vom Host nicht lesbaren Sektoren ist.
Ansätze auf Ebene des Host-Dateisystems oder darüber geben jedenfalls die vom Controller als nicht lesbar markierten Sektoren verloren, was vom Umfang her das ganze Vorhaben konterkarieren kann. Man kann dabei eigentlich nur unter Ignorieren der Fehler kopieren: https://github.com/DavorJ/PS-ForceCopy/blob/master/Force-Copy.ps1
Oder die nicht lesbaren Sektoren in-place nullen mit einem Disk-Editor und dann regulär kopieren (vorausgesetzt, die Fehlermeldung ist korrekt und nicht nur subsidiär für einen größeren Schaden).
Grüße
Richard
1
Moin...
kein schlechter ansatz von C.R.S.
ich würder aber vorher versuchen ein Backup aus den VMs selber zu starten.
was sind das für VMs? was laufen da für dienste?
sind alte Backups vorhanden, können wichtige Daten aus der VM rauskopiert werden und mit alten Backups hergstellt werden?
bei einem Exchange würde ich die DB aus der VM kopieren und ein Recover Setup machen..
Frank
kein schlechter ansatz von C.R.S.
ich würder aber vorher versuchen ein Backup aus den VMs selber zu starten.
was sind das für VMs? was laufen da für dienste?
sind alte Backups vorhanden, können wichtige Daten aus der VM rauskopiert werden und mit alten Backups hergstellt werden?
bei einem Exchange würde ich die DB aus der VM kopieren und ein Recover Setup machen..
Frank
Moin @nachgefrag,
wenn das bei einem RAID5 nach einem Rebuild passiert, dann spricht das dafür, dass bereits vorher schon mehr als eine HDD einen Schaden hatte.
Wahrscheinlich ist auf dem Volume auch keine zyklische Integritätsprüfung gelaufen und daher ist das ganze auch nicht aufgefallen.
Ich kann dir vor jeglichem Reparaturversuch nur raten, die Daten der betroffenen VM's so gut es geht zu sichern.
Ansonsten kommst du um ein Neuaufbau des entsprechenden Volumes, glaube ich nicht wirklich herum.
Gruss Alex
lokal, RAID5
wenn das bei einem RAID5 nach einem Rebuild passiert, dann spricht das dafür, dass bereits vorher schon mehr als eine HDD einen Schaden hatte.
Wahrscheinlich ist auf dem Volume auch keine zyklische Integritätsprüfung gelaufen und daher ist das ganze auch nicht aufgefallen.
Ich kann dir vor jeglichem Reparaturversuch nur raten, die Daten der betroffenen VM's so gut es geht zu sichern.
Ansonsten kommst du um ein Neuaufbau des entsprechenden Volumes, glaube ich nicht wirklich herum.
Gruss Alex
@Vision2015
Ja, wenn es ein Datenserver mache ich eine Robocopy, bei einem SQL Server verschiebe ich das Backup,... usw. Einige Systeme unterer anderer Hoheit, d.h. ich kann die Wiederherstellung bzw. den Neuaufbau derer gar nicht abschätzen. Mit Überraschungen ist fest zu rechnen.
@c.r.s.
Auf Anweisung HPE wurde die Priorität der Oberflächenanalyse auf "Hoch" gesetzt.
Ja, wenn es ein Datenserver mache ich eine Robocopy, bei einem SQL Server verschiebe ich das Backup,... usw. Einige Systeme unterer anderer Hoheit, d.h. ich kann die Wiederherstellung bzw. den Neuaufbau derer gar nicht abschätzen. Mit Überraschungen ist fest zu rechnen.
@c.r.s.
Das ist aber davon abhängig, wie viel Vertrauen man in die ursprünglich nicht ausgefallenen Disks hat
Die sind im Backup, da muss ich mich drauf verlassen (prüfen wir regelmäßig).groß die Zahl der vom Host nicht lesbaren Sektoren ist
Was ist ein gesunder Wert und wo finde ich die Anzahl?Auf Anweisung HPE wurde die Priorität der Oberflächenanalyse auf "Hoch" gesetzt.
Moin @nachgefragt,
und wie war die Oberflächenanalyse vorher eingestellt?
War der Schreib-Cache zuvor ebenfalls schon deaktiviert?
Gruss Alex
Auf Anweisung HPE wurde die Priorität der Oberflächenanalyse auf "Hoch" gesetzt.
und wie war die Oberflächenanalyse vorher eingestellt?
War der Schreib-Cache zuvor ebenfalls schon deaktiviert?
Gruss Alex
inaktiv
War der Schreib-Cache zuvor ebenfalls schon deaktiviert?
ja
Moin @nachgefragt,
genau das haben ich vermutet, das ist bei einem HDD RAID nicht wirklich gut. 😬
Denn dadurch hat der RAID-Controller keine zyklische Konsistenz-/Integritätsprüfung gemacht und dadurch sind die HDD Defekte auch nicht rechtzeitig erkannt worden. 😔
Das jetzt im Nachgang einzuschalten, bringt bei deinem jetzigen Problem, meiner Erfahrung nach überhaupt nichts mehr. Im Gegenteil, damit kannst du den Schaden eventuell sogar noch vergrössern, da du wahrscheinlich noch weitere defekte HDD's in diesem Verbund hast.
Gruss Alex
Nachtrag:
😮💨 ... gut ... den das ist bei den meisten HDD's, also ein aktivierter Device-Schreib-Cache, in einem RAID eher tödlich.
Bei manchen SSD's kann man diesen zwar aktivieren, aber nur bei Enterprise SSD's deren Cache durch z.B. ein P-CAP geschützt ist.
und wie war die Oberflächenanalyse vorher eingestellt?
inaktivgenau das haben ich vermutet, das ist bei einem HDD RAID nicht wirklich gut. 😬
Denn dadurch hat der RAID-Controller keine zyklische Konsistenz-/Integritätsprüfung gemacht und dadurch sind die HDD Defekte auch nicht rechtzeitig erkannt worden. 😔
Das jetzt im Nachgang einzuschalten, bringt bei deinem jetzigen Problem, meiner Erfahrung nach überhaupt nichts mehr. Im Gegenteil, damit kannst du den Schaden eventuell sogar noch vergrössern, da du wahrscheinlich noch weitere defekte HDD's in diesem Verbund hast.
Gruss Alex
Nachtrag:
War der Schreib-Cache zuvor ebenfalls schon deaktiviert?
ja😮💨 ... gut ... den das ist bei den meisten HDD's, also ein aktivierter Device-Schreib-Cache, in einem RAID eher tödlich.
Bei manchen SSD's kann man diesen zwar aktivieren, aber nur bei Enterprise SSD's deren Cache durch z.B. ein P-CAP geschützt ist.
Zitat von @MysticFoxDE:
Im Gegenteil, damit kannst du den Schaden eventuell sogar noch vergrössern, da du wahrscheinlich noch weitere defekte HDD's in diesem Verbund hast.
Interessant.Im Gegenteil, damit kannst du den Schaden eventuell sogar noch vergrössern, da du wahrscheinlich noch weitere defekte HDD's in diesem Verbund hast.
= Vorgabe action plan vom HPE Support Engineer
OFF-TOPIC
Da wünscht man sich wieder, wenn sowas eintritt, den IT-Juristen der Schadensersatz einfordert, wenn überhaupt möglich.
Solange Backups da sind sollte das doch alles kein Beinbruch sein und ne gute Gelegenheit von RAID 5 wegzukommen.
Gerade mit HDDs würde ich das heutzutage keinesfalls mehr einsetzen. Zusätzlich vielleicht Gedanken über ne Redundanz wie Failover Cluster (mit externem Storage oder als HCI ) oder HyperV-Replication machen wenn der Ausfall so problematisch ist.
Gerade mit HDDs würde ich das heutzutage keinesfalls mehr einsetzen. Zusätzlich vielleicht Gedanken über ne Redundanz wie Failover Cluster (mit externem Storage oder als HCI ) oder HyperV-Replication machen wenn der Ausfall so problematisch ist.
Moin @nachgefragt,
du glaubst doch nicht ernsthaft, dass du wirklich mit einem HPE Mitarbeiter gesprochen hast. 😔
Vergiss es, die haben sich in den AGB's gegen sowas abgesichert.
Sprich, wenn ein Schaden entsteht und der Kunde keine Backups hat, dann Kunde selber schuld und nicht HPE. 🙃
Gruss Alex
= Vorgabe action plan vom HPE Support Engineer
du glaubst doch nicht ernsthaft, dass du wirklich mit einem HPE Mitarbeiter gesprochen hast. 😔
OFF-TOPIC
Da wünscht man sich wieder, wenn sowas eintritt, den IT-Juristen der Schadensersatz einfordert, wenn überhaupt möglich.
Da wünscht man sich wieder, wenn sowas eintritt, den IT-Juristen der Schadensersatz einfordert, wenn überhaupt möglich.
Vergiss es, die haben sich in den AGB's gegen sowas abgesichert.
Sprich, wenn ein Schaden entsteht und der Kunde keine Backups hat, dann Kunde selber schuld und nicht HPE. 🙃
Gruss Alex
Moin @pebcak7123:
Und warum sollte man das machen?
Denn dieses Problem hätte der TO auch bei anderen RAID-Leveln gehabt.
Das Problem hier ist nicht das RAID Level, sondern weil die "Oberflächenanalyse" nicht aktiviert war und dadurch die HDD Defekte nicht rechtzeitig aufgefallen sind. Entweder ist diese per Default nicht aktiv und dann gehört HPE eine auf den Deckel oder der entsprechende Besitzer hat diese selbst deaktiviert, weil die Prüfung durchaus Ressourcen kostet, dann ist er jedoch selber schuld, aber ganz sicher nicht das RAID-Level!
Unter 10 HDD's geht das schon, über 10 HDD's würde ich jedoch eher RAID-6 nehmen.
Na ja, wenn das entsprechende SAN auch mit HDD's bestückt ist und dort die Konsistenz-/Integritätsprüfung ebenfalls deaktiviert wird, dann ist es nur eine Frage der Zeit, bis auch dort ein ähnliches Problem auftritt. 😔
Gruss Alex
Solange Backups da sind sollte das doch alles kein Beinbruch sein und ne gute Gelegenheit von RAID 5 wegzukommen.
Und warum sollte man das machen?
Denn dieses Problem hätte der TO auch bei anderen RAID-Leveln gehabt.
Das Problem hier ist nicht das RAID Level, sondern weil die "Oberflächenanalyse" nicht aktiviert war und dadurch die HDD Defekte nicht rechtzeitig aufgefallen sind. Entweder ist diese per Default nicht aktiv und dann gehört HPE eine auf den Deckel oder der entsprechende Besitzer hat diese selbst deaktiviert, weil die Prüfung durchaus Ressourcen kostet, dann ist er jedoch selber schuld, aber ganz sicher nicht das RAID-Level!
Gerade mit HDDs würde ich das heutzutage keinesfalls mehr einsetzen.
Unter 10 HDD's geht das schon, über 10 HDD's würde ich jedoch eher RAID-6 nehmen.
Zusätzlich vielleicht Gedanken über ne Redundanz wie Failover Cluster (mit externem Storage oder als HCI )
Na ja, wenn das entsprechende SAN auch mit HDD's bestückt ist und dort die Konsistenz-/Integritätsprüfung ebenfalls deaktiviert wird, dann ist es nur eine Frage der Zeit, bis auch dort ein ähnliches Problem auftritt. 😔
Gruss Alex
1
Was mich an der ganzen Sache wirklich wundert, dass die VMs noch arbeiten. Wenn die VHDX Dateien korrupt sind und nicht mehr gelesen werden können zum klonen oder sichern, wie schreiben die VMs da noch hinein?
Zitat von @pcpanik:
Was mich an der ganzen Sache wirklich wundert, dass die VMs noch arbeiten. Wenn die VHDX Dateien korrupt sind und nicht mehr gelesen werden können zum klonen oder sichern, wie schreiben die VMs da noch hinein?
Was mich an der ganzen Sache wirklich wundert, dass die VMs noch arbeiten. Wenn die VHDX Dateien korrupt sind und nicht mehr gelesen werden können zum klonen oder sichern, wie schreiben die VMs da noch hinein?
Achtung bisschen Ironie zum Aufheitern hier:
Vielleicht haben die VMs ihre virtualität verinnerlicht und schreiben ihre Daten daher nicht mehr physikalisch sonder rein Virtuell
Oder sie haben sich virtualisiert aufs Netzwerkkabel geretet nachdem sie festgestellt haben physikalisch geht nix mehr
und hängen nun im iSCSI/SAS/Fibreschannel Cache und simmulieren anwesenheit
alles kein nach dem Motto - was KI's heutzutage nicht alles reparieren können...
einen hab ich noch: Vielleicht haben sie sich selbst in die Cloud migriert, neues sicherungskonzept der NSA
Aber vorsicht Cloud ist auch nur die Festplatte eines anderen Rechners....
Zitat von @nachgefragt:
@c.r.s.
@c.r.s.
Das ist aber davon abhängig, wie viel Vertrauen man in die ursprünglich nicht ausgefallenen Disks hat
Die sind im Backup, da muss ich mich drauf verlassen (prüfen wir regelmäßig).Da hast du mich misssverstanden, glaube ich. Ich meinte die nicht ausgefallenen physischen Disks. Die sollten im Inventar getrackt werden, und das sehe ich mir in so einem Fall als erstes an. Im Idealfall wären das Disks mit etwas gestreutem "mittleren" Alter (laufen schon >3-4 Monate ohne Fehler), die ausgefallene ein Ausreißer mit plausiblem altersbedingtem Verschleiß. Im schlechtesten Fall wurde eine Charge vor 4-5 Jahren reingeschoben, und nun ist halt die erste ausgefallen.
Das vorher inaktive Scan-Setting setzt das Vertrauen schon mal herab. Wenn man viel Zeit hat: Die Disks im ausgeschaltete Zustand herausnehmen und einzeln auf nicht lesbare Sektoren untersuchen (z.B. mit dd einlesen bzw. dann kann man sie auch gleich zur Sicherheit kopieren, dabei Fehler überspringen und zählen).
groß die Zahl der vom Host nicht lesbaren Sektoren ist
Was ist ein gesunder Wert und wo finde ich die Anzahl?Da gibt es keine pauschale Antwort. Du müsstest einen Diskeditor nehmen (wie WinHex, aber ich weiß nicht genau, was die kostenlose Version kann) und ansehen, welchen Anteil die nicht lesbaren Sektoren an der Gesamtzahl haben und wie sie verteilt sind. Aus der Sektorzuordnung zur jeweiligen VHD und den Workloads ergibt sich dann auch ein konkretes Schadensbild für die jeweilige VM.
Es gilt, zwei mögliche Fehler (oder ihre Abstufungen) zu unterscheiden: Wenn eine oder mehrere der alten nicht ausgefallenen Disks tatsächlich Medienfehler aufweisen, entspräche die Zahl der unlesbaren Sektoren auf dem logischen Laufwerk der Summe der Fehler auf den physischen Disks (das degraded RAID5, bei dem die detektiert wurden, kann ja als RAID0 betrachtet werden). Im anderen Extremfall sind alle physischen Disks lesbar, und der Controller hat beim Rebuild Sektoren aufgrund fälschlich erkannter Medienfehler deaktiviert.
Ohne Kenntnis des Zustands der physischen Disks würde ich sehr großflächige sequenzielle Lesefehler eher der falschen Erkennung zuordnen.
Dann besser den 2. Satz des Beitrags lesen.
Auch beim Backup besteht immer ein Restrisiko (trotz healthy check,...), ob ein System denn wirklich wirklich wiederherzustellen gehen.
Auch beim Backup besteht immer ein Restrisiko (trotz healthy check,...), ob ein System denn wirklich wirklich wiederherzustellen gehen.
Moin...
na ja... nutzt jetzt auch nix mehr- hast du den jetzt alle VMs sichern können?
Frank
Zitat von @nachgefragt:
Dann besser den 2. Satz des Beitrags lesen.
Auch beim Backup besteht immer ein Restrisiko (trotz healthy check,...), ob ein System denn wirklich wirklich wiederherzustellen gehen.
äh... dafür macht man regelmäßig ein Restore, um genau das zu Testen!Dann besser den 2. Satz des Beitrags lesen.
Auch beim Backup besteht immer ein Restrisiko (trotz healthy check,...), ob ein System denn wirklich wirklich wiederherzustellen gehen.
na ja... nutzt jetzt auch nix mehr- hast du den jetzt alle VMs sichern können?
Frank
äh.... genau das machen wir regelmäßig!
äh... funktioniert mit den meisten VMs wie beschrieben
äh... nur in dem Fall leider nicht
äh... der HPE Support meinte ebenso, dass Problem löst sich von selbst.
äh... und somit liegt das letztere funktionierende Backup immer weiter zurück
äh... und wie genau hilft das nun konstruktiv der Problemstellung?
äh... meine Zeitmaschine ist leider kaputt, soviel im Voraus.
äh... funktioniert mit den meisten VMs wie beschrieben
äh... nur in dem Fall leider nicht
äh... der HPE Support meinte ebenso, dass Problem löst sich von selbst.
äh... und somit liegt das letztere funktionierende Backup immer weiter zurück
äh... und wie genau hilft das nun konstruktiv der Problemstellung?
äh... meine Zeitmaschine ist leider kaputt, soviel im Voraus.
naja mal butter bei die fische, wie alt ist denn das letzte funktionierende Backup ?
Ich würde nichts mehr auf die Konsistenz der Daten von so einem halb ausgefallenen Array geben und vor allem nicht damit weiterarbeiten.
Ich würde nichts mehr auf die Konsistenz der Daten von so einem halb ausgefallenen Array geben und vor allem nicht damit weiterarbeiten.
Zitat von @pebcak7123:
naja mal butter bei die fische, wie alt ist denn das letzte funktionierende Backup ?
Jetzt, knapp 30 Tage.naja mal butter bei die fische, wie alt ist denn das letzte funktionierende Backup ?
Da der HPE Support meinte das sich das Problem durch die Oberflächenanalyse selbst beheben wird, verstrich einfach Zeit.
Ich würde nichts mehr auf die Konsistenz der Daten von so einem halb ausgefallenen Array geben
Da bin ich bei dir, auch wenn es nichts mit meiner Frage zu tun hat.
Moin @nachgefragt,
😯 … 😖 … Moment, ich muss ganz schnell …
… so, jetzt, ähm ja, falls jetzt jemand einen kleinen Atompilz in einem Wald im Schwabenland beobachtet hat, keine Sorge, das war ich, musste mich nur mal kurz notentladen. 🤪
Nun zurück zum Thema … das was dir der HPE Support da erzählt, ist schlichtweg ein kompletter Schwachsinn!
Die Oberflächenanalyse hätte den Schaden vielleicht im Vorfeld verhindern können, in dem sie die Beschädigung der HDD’s schon früher erkannt hätte, wenn sie auch im Vorfeld schon eingeschaltet gewesen wäre. Bis zu einem gewissen Mass, hätte sie die Fehler dann auch korrigieren können und wenn nicht, dann hätte sie die entsprechende(n) HDD(’s), vereinfacht ausgedrückt, zum Austausch markiert. Hätte man dann die defekten HDD’s auch rechtzeitig getauscht, dann wäre der ganze Murks wahrscheinlich auch nicht passiert.
Nachdem nun aber bereits eine HDD hart rausgeflogen ist und daraufhin ein Rebuild gelaufen, der zu dem jetzigen Ergebnis geführt hat, sprich, inkonsistente Daten, wird eine Oberflächenanalyse genau gar nicht bringen, weil ein Rebuild im Grunde sehr ähnlich funktioniert ist wie eine Oberflächenanalyse.
Wenn du jedoch bei dem jetzigen Beschädigungsgrad, zusätzlich zu den Zugriffsversuchen die der Datenrettung dienen, nun auch noch die zum Teil sehr massiven Zugriffe durch die Oberflächenanalyse den bereits beschädigten HDD’s antust, riskierst du nur, dass diese noch schneller den Geis aufgeben!
Sprich, in so einem Fall, sollte man die Zugriffe auf das beschädigte RAID auf ein Minimum reduzieren, sprich, schauen, dass man so schnell wie möglich die Daten von diesem runterkratzt.
Danach würde ich als erstes die SMART Werte jeder HDD überprüfen und alle aussortieren, die aus der Reihe tanzen. Respektive, ich würde dem Kunden in dem Fall wahrscheinlich gleich empfehlen, die Wiederherstellung auf einem neuen RAID mit neuen HDD’s zu machen und die alten HDD’s zu entsorgen. Ähm, kleine Korrektur, ich würde ihm eher empfehlen die alten HDD’s zu entsorgen und gleich Enterprise-SSD’s zu nehmen, da schlichtweg schneller und haltbarer.
Gruss Alex
Interessant.
= Vorgabe action plan vom HPE Support Engineer
= Vorgabe action plan vom HPE Support Engineer
äh... der HPE Support meinte ebenso, dass Problem löst sich von selbst.
Da der HPE Support meinte das sich das Problem durch die Oberflächenanalyse selbst beheben wird, verstrich einfach Zeit.
😯 … 😖 … Moment, ich muss ganz schnell …
… so, jetzt, ähm ja, falls jetzt jemand einen kleinen Atompilz in einem Wald im Schwabenland beobachtet hat, keine Sorge, das war ich, musste mich nur mal kurz notentladen. 🤪
Nun zurück zum Thema … das was dir der HPE Support da erzählt, ist schlichtweg ein kompletter Schwachsinn!
Die Oberflächenanalyse hätte den Schaden vielleicht im Vorfeld verhindern können, in dem sie die Beschädigung der HDD’s schon früher erkannt hätte, wenn sie auch im Vorfeld schon eingeschaltet gewesen wäre. Bis zu einem gewissen Mass, hätte sie die Fehler dann auch korrigieren können und wenn nicht, dann hätte sie die entsprechende(n) HDD(’s), vereinfacht ausgedrückt, zum Austausch markiert. Hätte man dann die defekten HDD’s auch rechtzeitig getauscht, dann wäre der ganze Murks wahrscheinlich auch nicht passiert.
Nachdem nun aber bereits eine HDD hart rausgeflogen ist und daraufhin ein Rebuild gelaufen, der zu dem jetzigen Ergebnis geführt hat, sprich, inkonsistente Daten, wird eine Oberflächenanalyse genau gar nicht bringen, weil ein Rebuild im Grunde sehr ähnlich funktioniert ist wie eine Oberflächenanalyse.
Wenn du jedoch bei dem jetzigen Beschädigungsgrad, zusätzlich zu den Zugriffsversuchen die der Datenrettung dienen, nun auch noch die zum Teil sehr massiven Zugriffe durch die Oberflächenanalyse den bereits beschädigten HDD’s antust, riskierst du nur, dass diese noch schneller den Geis aufgeben!
Sprich, in so einem Fall, sollte man die Zugriffe auf das beschädigte RAID auf ein Minimum reduzieren, sprich, schauen, dass man so schnell wie möglich die Daten von diesem runterkratzt.
Danach würde ich als erstes die SMART Werte jeder HDD überprüfen und alle aussortieren, die aus der Reihe tanzen. Respektive, ich würde dem Kunden in dem Fall wahrscheinlich gleich empfehlen, die Wiederherstellung auf einem neuen RAID mit neuen HDD’s zu machen und die alten HDD’s zu entsorgen. Ähm, kleine Korrektur, ich würde ihm eher empfehlen die alten HDD’s zu entsorgen und gleich Enterprise-SSD’s zu nehmen, da schlichtweg schneller und haltbarer.
Gruss Alex
Guten Morgen,
die Schritte muss ich dennoch durchgehen die HPE "vorschlägt", sonst geht's nicht weiter. Ich versuche zu retten was zu retten ist.
Danke für Eure Ideen und einen guten Start in die Woche.
die Schritte muss ich dennoch durchgehen die HPE "vorschlägt", sonst geht's nicht weiter. Ich versuche zu retten was zu retten ist.
Danke für Eure Ideen und einen guten Start in die Woche.
Moin @nachgefragt,
das verstehe ich jetzt nicht wirklich, da das was dir der HPE Support bisher vorgeschlagen hat, überhaupt keinen Sinn macht.
Das verstehe ich wiederum sehr gut und drücke dir dafür auch kräftig die Daumen.
Ebenso.
Gruss Alex
die Schritte muss ich dennoch durchgehen die HPE "vorschlägt", sonst geht's nicht weiter.
das verstehe ich jetzt nicht wirklich, da das was dir der HPE Support bisher vorgeschlagen hat, überhaupt keinen Sinn macht.
Ich versuche zu retten was zu retten ist.
Das verstehe ich wiederum sehr gut und drücke dir dafür auch kräftig die Daumen.
Danke für Eure Ideen und einen guten Start in die Woche.
Ebenso.
Gruss Alex
Danke für Eure Ideen und einen guten Start in die Woche.
Viel Glück und bitte informiere uns, was Du gemacht hast und ob es von Erfolg gekrönt war.
Ich schließe mich @MysticFoxDE da an, was HP da rät ergibt keinen Sinn (mehr). Aber das ist ja leider immer wieder das Problem. Die haben vorgaben, an die sie sich zu halten haben und weichen davon nicht ab.
Ich muss sagen, der Dell Support war bisher da deutlich felxibler, wenn ich mit denen zu tun hatte.
Und denk' mal über ein RAID6 nach, wenn Du alles neu machst. Auch wenns Geschwindiglkeit kostet, der Sicherheitsvorteil wiegt das auf.
Moin @pcpanik,
Ähm, wenn den "HPE" Sportlern tatsächlich jemand vorgegeben hat, bei einem Volume, welches nach einem Rebuild fehlerhafte Daten aufweist, als nächstes eine Oberflächenanalyse durchzuführen, dann gehören demjenigen die Ohren langgezogen und zwar sehr kräftig. 😡
Na ja, genaugenommen ist das mittlerweile derselbe Laden der sowohl für HPE als auch DELL und viele anderen, deren Support händelt. 😔
Gruss Alex
Ich schließe mich @MysticFoxDE da an, was HP da rät ergibt keinen Sinn (mehr). Aber das ist ja leider immer wieder das Problem. Die haben vorgaben, an die sie sich zu halten haben und weichen davon nicht ab.
Ähm, wenn den "HPE" Sportlern tatsächlich jemand vorgegeben hat, bei einem Volume, welches nach einem Rebuild fehlerhafte Daten aufweist, als nächstes eine Oberflächenanalyse durchzuführen, dann gehören demjenigen die Ohren langgezogen und zwar sehr kräftig. 😡
Ich muss sagen, der Dell Support war bisher da deutlich felxibler, wenn ich mit denen zu tun hatte.
Na ja, genaugenommen ist das mittlerweile derselbe Laden der sowohl für HPE als auch DELL und viele anderen, deren Support händelt. 😔
Gruss Alex
Na ja, genaugenommen ist das mittlerweile derselbe Laden der sowohl für HPE als auch DELL und viele anderen, deren Support händelt.
Keine Ahnung, wer das macht .... hat sich da in den letzten 4 Jahren was geändert?
OFF TOPIC
Mehr und mehr stelle ich fest,
egal ob Dell, Fujitsu, HPE, Sophos,... man bezahlt brav den Support zyklisch im Voraus, die aktive Gegenleistung dahinter wird immer fragwürdiger und zweifelhafter. Sollte man aktiven Support benötigen, zeigt sich der wahre Glanz dahinter, ausgenommen sind 0 8 15 Fälle.
Ich meine nicht wenn jemand
Dieses ganze Support Outsouring in eine "andere Welt und Struktur" ist teurer als ich ursprünglich angenommen hatte.
Da gilt es Dienstleister im eigenen 100km Radius finden und fördern, welche sich tatsächlich und selbst für das Thema verantwortlich fühlen, anstatt alles zum Hersteller durchzureichen und auf die Lösung von Außen zu warten.
Mehr und mehr stelle ich fest,
egal ob Dell, Fujitsu, HPE, Sophos,... man bezahlt brav den Support zyklisch im Voraus, die aktive Gegenleistung dahinter wird immer fragwürdiger und zweifelhafter. Sollte man aktiven Support benötigen, zeigt sich der wahre Glanz dahinter, ausgenommen sind 0 8 15 Fälle.
Ich meine nicht wenn jemand
- Ersatzteile bevorratet die am next-next-business-day getauscht werden,
- Produktpflege und Instandhaltung betreibt, anstatt ungefragt unnötige Features zu implementieren,
Dieses ganze Support Outsouring in eine "andere Welt und Struktur" ist teurer als ich ursprünglich angenommen hatte.
Da gilt es Dienstleister im eigenen 100km Radius finden und fördern, welche sich tatsächlich und selbst für das Thema verantwortlich fühlen, anstatt alles zum Hersteller durchzureichen und auf die Lösung von Außen zu warten.
2
Moin @pcpanik,
das ist z.B. einer der grösseren, der für viele Hersteller in der EU den Support übernimmt.
https://www.stortrec.de/
Ja ... leider ... zum Teil sehr extrem und dass nicht erst in den letzten 4 Jahren.
Als Kunde bekommst du das aber nicht wirklich mit, weil die entsprechenden Unternehmen/Hersteller solche "Umstrukturierungen" nicht wirklich gerne veröffentlichen, weil sie genau wissen, dass das den meisten Kunden nicht wirklich schmeckt. 😔
Ich habe z.B. nach 2014 mehrfach mit dem Support von Microsoft zu tun gehabt und bind dabei fast jedes mal in einem russischen Call-Center gelandet. Irgendwann habe ich einen der Supportler mal direkt gefragt, was die den genau mit Microsoft "verkuttelt" sind und darauf antwortete mir der entsprechende Mitarbeiter mit "überhaupt gar nicht ... wir sind ein externes Call-Center" und dann hat er mir noch ein paar weitere Infos gesteckt und seit dem spare ich mir auch jeglichen Anruf bei der Microsoft Hotline.
Na ja, das letztere stimmt nicht so ganz ... die Krönung des Microsoft Supports war eher ein etwas komplizierterer Vorfall, bei dem mir ein sehr hochrangiger Entwickler (Support - Level 4) nach einigem hin und her auf einmal geschrieben hat, dass ihm das ganze nun zu kompliziert wird und ich soll mich doch bitte wieder an den Level 1 Support wenden. 😡
Gruss Alex
Keine Ahnung, wer das macht ....
das ist z.B. einer der grösseren, der für viele Hersteller in der EU den Support übernimmt.
https://www.stortrec.de/
hat sich da in den letzten 4 Jahren was geändert?
Ja ... leider ... zum Teil sehr extrem und dass nicht erst in den letzten 4 Jahren.
Als Kunde bekommst du das aber nicht wirklich mit, weil die entsprechenden Unternehmen/Hersteller solche "Umstrukturierungen" nicht wirklich gerne veröffentlichen, weil sie genau wissen, dass das den meisten Kunden nicht wirklich schmeckt. 😔
Ich habe z.B. nach 2014 mehrfach mit dem Support von Microsoft zu tun gehabt und bind dabei fast jedes mal in einem russischen Call-Center gelandet. Irgendwann habe ich einen der Supportler mal direkt gefragt, was die den genau mit Microsoft "verkuttelt" sind und darauf antwortete mir der entsprechende Mitarbeiter mit "überhaupt gar nicht ... wir sind ein externes Call-Center" und dann hat er mir noch ein paar weitere Infos gesteckt und seit dem spare ich mir auch jeglichen Anruf bei der Microsoft Hotline.
Na ja, das letztere stimmt nicht so ganz ... die Krönung des Microsoft Supports war eher ein etwas komplizierterer Vorfall, bei dem mir ein sehr hochrangiger Entwickler (Support - Level 4) nach einigem hin und her auf einmal geschrieben hat, dass ihm das ganze nun zu kompliziert wird und ich soll mich doch bitte wieder an den Level 1 Support wenden. 😡
Gruss Alex
Moin @nachgefragt,
für dich als Kunden ist ein externer Herstellersupport fast immer nachteilig, da dieser selten wirklich gut ist.
Für den Hersteller, vor allem die, die nur noch von irgendwelchen Finanzheinis geführt werden, welche von der Materie des entsprechenden Unternehmens immer seltener eine Ahnung haben, ist das Outsourcing des Supports, mittlerweile jedoch lediglich eine von vielen Möglichkeiten der Gewinnmaximierung. 😔
Ich sage nur Pat Gelsinger ... EMC ... VMware und nun Intel. 😭 🤢🤮
👍👍👍
Gruss Alex
Dieses ganze Support Outsouring in eine "andere Welt und Struktur" ist teurer als ich ursprünglich angenommen hatte.
für dich als Kunden ist ein externer Herstellersupport fast immer nachteilig, da dieser selten wirklich gut ist.
Für den Hersteller, vor allem die, die nur noch von irgendwelchen Finanzheinis geführt werden, welche von der Materie des entsprechenden Unternehmens immer seltener eine Ahnung haben, ist das Outsourcing des Supports, mittlerweile jedoch lediglich eine von vielen Möglichkeiten der Gewinnmaximierung. 😔
Ich sage nur Pat Gelsinger ... EMC ... VMware und nun Intel. 😭 🤢🤮
Da gilt es Dienstleister im eigenen 100km Radius finden und fördern, welche sich tatsächlich und selbst für das Thema verantwortlich fühlen, anstatt alles zum Hersteller durchzureichen und auf die Lösung von Außen zu warten.
👍👍👍
Gruss Alex
Lustig, dass ausgerechnet beim Synology Deutschland Support die MA auch dort angestellt sind und in der Zentrale in Düsseldorf sitzen. War mal dort. Sehr Nett. Wenn die nicht mehr weiter wissen, geht das Ticket dann nach Taiwan zum HQ weiter. Die sind zum Outsourcen wahrscheinlich noch zu klein. Lach. Naja, will jetzt nicht zu viel OffTopic werden.
@nachgefragt hat ja genug mit dem Problem zu kämpfen. Drücke die Daumen, dass was zu retten ist.
@nachgefragt hat ja genug mit dem Problem zu kämpfen. Drücke die Daumen, dass was zu retten ist.
Zitat von @pcpanik:
Lustig, dass ausgerechnet beim Synology Deutschland Support die MA auch dort angestellt sind und in der Zentrale in Düsseldorf sitzen.
Mach mal an deiner Synology ein Support Ticket auf.Lustig, dass ausgerechnet beim Synology Deutschland Support die MA auch dort angestellt sind und in der Zentrale in Düsseldorf sitzen.
Meine wurden noch nie von einem deutschen Support beantwortet, und schon gar nicht in der Qualität, zumindest das, was man mal darunter verstanden hat.
FAQ Links verteilen, aus den hauseigenen Foren, sind die Tagesordnung, egal ob HPE, Synology, Sophos, Dell,... echter Support ist das nicht. Die Türen zum Level 2 oder gar Level 3 Support muss man erstmal erklimmen.
Im OpenSource Bereich bin ich, als nicht zahlender Anwender, ein vielfach besseres, mittlerweile, gewohnt, was die Qualität der Antworten angeht. Das macht ein gute Community aus, solange, bis das System zur Systematik wird.
Meine wurden noch nie von einem deutschen Support beantwortet,
Meine schon Soll ja auch gar nicht Thema sein.Wie schauts denn eigentlich aus, konntest Du das Dateisystem retten?
Wir mussten hier beharrlich nachhaken, dann wurden über 50% aller Festplatten getauscht (den Zustand sieht der Kunden nicht und bekommt den auch nicht genannt, ist aber so ein Ampel System), nicht nacheinander möglich, sondern alle auf einmal. Es müssen also alle Daten verschoben werden, RAID löschen und neu erstellen, dann wieder in Betrieb nehmen.
