In wie weit betrifft das Festplatten, die an Zusatzcontroller angeschlossen werden?
Da diese Funktion des BIOS während des POST abläuft, besteht für an PCI(e) Zusatzcontrollern oder über USB angeschlossenen Platten keinerlei Gefahr, derart missbraucht zu werden. Auch nicht, solange die internen Controller diese Platten als RAID-Member betrachten.
Wird allerdings die BIOS-Einstellung unwillkürlich zurückgesetzt (bei BIOS-Flash, primary BIOS Error etc) oder bewusst eine Platte zum Firmwareupdate (aktuell bei Seagate) alleine am internen Controller angeschlossen, ist ein überschreiben des oberen Plattenbereiches die zwangsläufige Folge. Auch interne Controlleranschlüsse, welche für eSATA verwendet werden, bergen diese Gefahr, wenn der Anschluss bei POR (ungewollt z.B. nach einem Netzausfall) bereits besteht.
Das schädigt dynamische MBR- oder GPT-partitionierte Platten genauso wie RAID-Memberplatten, wenn diese noch keine HPA enthielten.
Die allgemeine Problematik ist im Jahresrückblick des Gigabyte-Forums behandelt worden.
Da man der mangelnden Verfügbarkeit des Forums in den letzten Monaten nicht Herr wurde, setze ich keinen Link, sondern zitiere das Originalpost, um den Server vom Zusammenbruch zu verschonen:
BIOS-Backup auf HDD
Eine Idee, die besser nicht geboren worden wäre
Schon lange vor 2008 wurde bei Gigabyte praktiziert, ein BIOS-Image nicht nur auf einem zweiten Chip am Board, sondern auch auf einer an das Board angeschlossenen HDDs abzuspeichern. Das wäre an und für sich eine auf den ersten Blick unverfängliche und feine Sache, soferne die dazu gewählte Methode fehlerfrei wäre und auf bereits auf der HDD abgespeicherte Daten Rücksicht genommen würde. Beides ist jedoch nicht der Fall, womit diese „Feature“, welche dem Kunden unter dem Deckmäntelchen erhöhter Sicherheit angepriesen wird, fallweise ins Gegenteil umschlägt und den Anwender vor die Situation eines Datenverlustes einer oder mehrerer HDD’s stellen kann.
Die Tücke
Oft ist sich der Kunde gar nicht bewusst, dass er ein Board mit diesen Eigenschaften besitzt. Entweder hat er ein Komplettgerät gekauft oder aus zweiter Hand, meist wurde ein Board mit derartigen Eigenschaften primär wegen ganz anderer Vorzüge angeschafft und ganz sicher nicht ausschließlich wegen dieser einzigartigen Feature – So wird das Vorhandensein dieser Funktion entweder erst gar nicht wahrgenommen oder gerät nach dem ersten Blick ins Handbuch nach kurzer Zeit in Vergessenheit, denn es ist von außen nicht einmal in den Startup-Meldungen ersichtlich, dass eine der angeschlossenen(oder gar welche) HDD darin involviert ist.
Im Falle eines der nachfolgenden Szenarien wird daher nie oder nur in den allerseltensten Fällen diese Feature des Boards als Ursache für plötzlichen Datenverlust in Betracht gezogen.
Datenverlust in der Praxis (auch noch 2009 !)
Wen kann es treffen?
Jeden, der ein Board mit der Eigenschaft „BIOS-Backup to HDD“ besitzt (in der allgemeinen Boardausstattung auf der Herstellerseite weit unten unter „BIOS Safety“ angeführt) UND
- >= 1TB HDD’s daran betreibt, wenn eine alte, fehlerhafte BIOS-Version aktiv ist
- >= 1TB HDD’s daran betreibt, wenn eine alte, fehlerhafte BIOS-Version am Backup-Chip (keine Updatemöglichkeit) vorliegt
- HDD’s beliebiger Größe daran betreibt, die nicht als Basis-MBR Datenträger partitioniert sind (z.B. MBR-dynamische, EFI/GPT-dynamische Arrays oder Einzelvolumes)
- der RAID-Arrays am System betreibt
Szenario 1 - Der günstigste (Un)Fall:
Der Platz wird knapp, man schafft sich eine größere Platte an, welche (seit über einem Jahr erhältlich) 1000GB=1TB oder (seit einigen Monaten verfügbar) 1500GB=1,5TB Kapazität besitzt. Die Freude wird beim ersten Anstecken an das Board jäh getrübt, denn sie hat plötzlich nur mehr 32MB oder 500MB. Ohne Kenntnis der Ursache wandert die Platte zum Lieferanten zurück. Hat man das Glück, im Internet auf einen Forumsthread anderer Betroffener zu stoßen, wird man der zwingenden Notwendigkeit eines BIOS-Updates belehrt und erhält Information über eine Methode, die volle Kapazität wiederherzustellen.
Glück gehabt, da noch keine Daten zu verlieren waren!
Szenario 2:
Wie 1, nur mit dem Unterschied, dass der Fall erst eintritt, wenn schon Daten auf der Platte waren. Gerät man nicht an die richtige Recovery-Informationen, kann man die ursprüngliche Kapazität nicht wiederherstellen, um wieder an seine Daten zu kommen. - Totalverlust*)
Szenario 3:
Wie 1 oder 2, mit dem Unterschied, dass man feststellen muss, dass es für dieses Board kein neueres BIOS mehr gibt, welches den Fehler behebt, da der Service eingestellt wurde (EOL).
Dumm gelaufen... Totalverlust*) .
Szenario 4:
Wie 1 oder 2, man hat zwar glücklicherweise eine neue Version des BIOS aktiv, dieses wird aber in einem Fehlerfall(z.B. Checksum Error) durch eine am zweiten Chip liegende ältere Version ersetzt und ... PUFF! Totalverlust*)
Szenario 5:
Wie 1 bis 3, man tauscht bei Konfigurationen mit mehreren Platten irgendwann die Anschlussreihenfolge, oder entfernt eine bis dahin vom BIOS verwendete Platte, bzw. diese wird einmal nicht erkannt(entweder ist sie gestorben oder es ist bloß ein Stecker locker) ... Das BIOS sucht sich ein neues Opfer... PUFF! Totalverlust*)
Szenario 6:
Bei auch anderen als 1TB oder 1,5TB HDD’s jeder Kapazität möglich!!!
Aktuellstes BIOS, man hatte einen RAID-Array mit mehreren Platten am System.
Beim flashen einer neuen BIOS-Version oder bei einem Recovery des BIOS vom zweiten Chip geht die Controller-Einstellung ‚RAID’ verloren. BIOS wählt eine der Platten des Arrays für sein HDD-Backup und überschreibt dort die RAID-Information.
Nach Setzen der richtigen Controllerkonfiguration ist diese HDD aus der RAID-Konfiguration gefallen und lässt sich nicht mehr einbinden. Bei RAID0 Totalverlust, bei RAID1 oder 5 stundenlanges Rebuild. Bei falscher Vorgangsweise (durch probeweises Kabel herumstöpseln) ist auch bei RAID5 ein Totalverlust*) denkbar.
Szenario 7:
Bei allen SATA-HDDs und eventuell auch allen PATA-HDD’s ab UDMA/66
Die Platten hingen an einem anderen Rechner und wurden z.B. als dynamische Datenträger (oder mit einer anderen, nicht-Basic-MBR-Methode oder einem Partitionmanager) initialisiert/partitioniert. Beim Anschluss an ein Board mit BIOS, welches sein Backup rücksichtslos über auch nur eine der am Ende jeder Platte liegende Datenbanken schreibt, ist der gesamte Plattenverbund (aus einer oder mehrere HDD’s bestehend) weder an diesem noch an irgendeinem anderen Board mehr ansprechbar – Totalverlust*).
Szenario 8:
Wie Szenario 6 oder 7; Die Platten wurden erst nachträglich auf diesem Board angeschlossen, nachdem schon eine Platte mit einem BIOS-Backup darauf existierte, und als dynamische Datenträger formatiert – wird nun aus irgendeinem Grund die BIOS-Backup-HDD entfernt (z.B. beginnender Defekt) sucht sich das BIOS ein anderes Opfer - Totalverlust*) .
Gleiches ist möglich, wenn ein RAID mit mehreren Platten an den ersten Anschlüssen nachträglich eingerichtet wird - bei Rücksetzten des Controllers auf non-Raid (bei BIOS recovery) - von Rebuild bis Totalverlust*) .
*) Unter „Totalverlust“ versteht sich die nicht-mehr-Ansprechbarkeit der Daten einer oder mehrerer HDD’s. Ohne geeignete und richtige Recoverymaßnahmen kann dieser Zustand nicht aufgehoben werden. Falsch durchgeführte Rettungsversuche können sehr schnell zu einem endgültigen Verlust führen, obwohl nach Eintritt eines derartigen Ereignisses der Zugriff darauf zu 100% wiederherstellbar gewesen wäre.
Der Rückblick
Was geschah, und was (oder was auch nicht) dagegen unternommen wurde...
Herbst 2007
Als die HDD-Backup-BIOSse noch alle fehlerhaft waren und erstmals vor über einem Jahr bei 1TB Platten eines der Szenarien (1,2) hervorriefen, gingen diese Platten (die Modelle alle Hersteller waren betroffen) erstmal zu den Händlern zurück, auch noch Anfang des Jahres 2008.
Als schuldhaft wurde entweder eine fehlerhafte HDD-Firmware publiziert oder Märchen über angebliche Inkompatibilität mit den Boards, welche diese Plattentypen noch nicht unterstützen, in die Welt gesetzt und verbreitet. Vom technischen Standpunkt unter Berücksichtigung der ATA-Spezifikationen unterscheiden sich jedoch 1GB Platten in keiner Weise von den Vorgängermodellen mit geringerer Kapazität – außer einer größeren Anzahl vorhandener Sektoren. Betriebssysteme und Treiber konnten damit hervorragend umgehen, und auf anderen Boards funktionierte das klaglos. Natürlich hatten die ersten 1TB-Modelle auch ihre Probleme, die aber in anderen Bereichen angesiedelt waren, hinter denen sich diese „Inkompatibilität“ in den Anfangswirren recht gut verstecken konnte. In Wahrheit jedoch wäre das BIOS inkompatibel zu den ATA-Spezifikationen, wenn es Platten bis 2TB nicht ohne Einschränkungen bedienen könnte. Solange es nicht versucht, ein Backup draufzuschreiben, funktioniert ja auch alles bestens. Tut es das aber, wird die Platte wegen eines Programmierfehlers im BIOS geschrottet.
Februar 2008
Taiwan hatte still und heimlich (da in den changelogs nicht ersichtlich) den BIOS-Bug in einigen der bordspezifischen Versionen behoben. Jene Boards, für die ein neues BIOS verfügbar gemacht wurde, zeigten daraufhin keinen wundersamen Schrumpfungsprozess mehr bei den 1TB HDD’s. Trotzdem dauerte es noch lange, bis zumindest Beta-Versionen die angebliche „Inkompatibilität“ bei den meisten Boardtypen behoben hatten. Die Verwirrung der Benutzer wurde durch geflissentliche Nichtmitteilung in den Changelogs auch im Unklaren gelassen, welches die meisten Kunden vom Einsatz einer Beta-Version überzeugen hätte können. Ganz abgesehen von jenen Boards, die ihr End-of-Lifetime erreichten – deren Besitzer werden von Taiwan nie mehr eine „Kompatibilität“ zu stinknormalen SATA-Platten über 750GB erhalten...
Mai 2008
Erstmals hier im Forum ein Beitrag von mehreren an anderem Rechner erstellten 1TB-Platten, wovon plötzlich eine geschrumpft war, als sie auf das neues Board gesteckt wurde. Das rege Interesse auch von anderen ebenfalls gerade Betroffenen, führte nach der Fehlerbehebung zu einer Diskussion, welche sich nach 3 Monaten und 250 Postings später totgelaufen hatte – Es gab zwar massenweise BIOS-Betas, aber keine Information, ob genau dieser Fehler darin gefixt ist – womit dem Kunden vorbehalten blieb, es selbst auszuprobieren. Auch Ende August gab es noch Boards, für die immer noch keine 1TB-„Kompatibilität“ verfügbar war.
Juli 2008
Ein Post mit gemeldeter Datenträgerkorruption von 500+750GB HDD’s zeigt, was auch mit Platten anderer Größen passiert, wenn die nicht Basic-MBR partitioniert sind. Die Datenrekonstruktion war mühsam, wie alles, dass man das erste Mal abcheckt, aber erfolgreich.
In der daraufhin entfachten Diskussion Bios schreibt auf Festplatte? wurde die Wende (weg von der 1TB-Schrumpfung, da allgemein alle andenen Größen auch irgendwie betroffen sein können) vollzogen, welches Gefahrenpotential nach wie vor schlummert - und jederzeit akut werden kann.
Aber auch dieses Thema mündete nach 4 Monaten phasenweisen Schweigens und Wartens auf ein Wunder letztendlich nur in der kindischen und technisch völlig unbeleckten Vorstellung eines GB-nahen Moderators, dass es sich hier überhaupt um kein Problem handelt.
Gigabyte.de Mitarbeiter hielten es in diesem Thread nie für notwendig, eine Stellungnahme abzugeben – offenbar in Erinnerung, dass ihre leichtfertige und tatsachenverfälschende Antwort schon im 1TB-Thread nicht besonders gut ankam. Von einem anderen (ehrenamtlichen) Moderator verlautete, dass dieses Problem durchaus gewissenhaft und eingehend diskutiert wurde, und man daraufhin nach Zuziehung von „Experten“ zu dem Schluss gekommen sei, dass es sich hier um ein nebensächliches und daher gänzlich unwichtiges Problem handle. Abschließend wurde der Thread mit technisch absurdem Unsinn moderatorseitig zugemüllt.
Dezember 2008
Ein neuer Anlauf im Thread Mal wieder Dual BIOS Backup wurde genommen, der nach einer Woche in der Menge neuerer Vorweihnachts-Posts unterging, der Ersteller wird seit 3 Wochen vermisst.(ich hoffe, er und sein PC sind wohlauf)...
Schon in den Vormonaten gab es vereinzelte Forumsposts, wo sich RAID-Arrays nach derartiger BIOS-Aktivität zerlegt hatten, zwei im Dezember gemeldeten Fälle mit kleineren Platten sind zweifelsfrei darauf zurückzuführen.
Neues von der BIOS-bug-Front ist nun ebenfalls zu vermelden: Bei den 1,5TB Platten wird nicht ganz so rigoros geschrumpft: Es bleiben immerhin noch 500GB (also ein Drittel) zur freien Verschwendung. Der Kundensupport (von Seagate, denn die bieten es bisweilen als einzige an) und einige Betroffene staunen und rätseln darüber gerade wieder im Seagate-Benutzerforum, um welchen Firmware-Bug der HDD es sich da jetzt wieder handeln könnte. Die Platten werden wieder auf Garantie ausgetauscht ... Hatten wir das nicht schon mal?
--------------------------------------------------------------------------
Zum Abschluss noch ein kleines Ratespiel: Wenn 1TB Platten auf 32MB, 1,5TB Platten auf 500GB geschrumpft wurden, was ist dann bei künftigen 2TB Platten fallweise zu erwarten?
a) 32MB
b) 64MB
c) 500GB
d) 1000GB
e) keine Schrumpfung
ernst@das-bios-ist-schuld
Beitrag vom 31.12.2008 Nachtrag vom 06.01.2009 in Violett*)
Nach den Ereignissen des
Seagate-Debakels
rate ich jedenfalls allen HDD-Firmware-flashwütigen
DRINGENDST davon ab, dies unüberlegt
an einem dieser betroffenen Boards durchzuführen.
Durch die spezielle Anordnung der Platte als einzige beim Firmwareupdate können damit nicht-Basis-MBR partitionierte Platten unter der Überschreibung durch das BIOS leiden, bei der Entfernung der Platten aus dem RAID-Verbund kann es passieren, dass diese danach nicht mehr vom Controller als Array-Platten erkannt werden.
Noch ein Auszug aus dem gesperrten Diskussionsthread - die Zukunftsperpektiven:
Seagate hat, wie die Fachpresse verlautet, mit der Anlieferung von 500GB Laufwerken mit nur einem Platter unter 50€ begonnen, womit die Uhr für 2TB Platten tickt und vielleicht noch 2009 die erste HDD erhältlich sein wird, welche die 2,2TB Barriere durchschlägt.
Werden dann automatisch alle bisherigen, selbst die noch in Verkauf stehenden Boards zu dieser HDD inkompatibel? Oder wird für die betreffenden Boards mit BIOS-Backup-to-HDD damit das EOL eingeläutet?
Warum? Jede Platte über 2,2TB kann leider nur mehr im Vista mittels EFI/GPT(=dynamische) Partitionierung in voller Kapazität betrieben werden, und damit ist dann unter Windows wirklich jede dieser von einem anderen Board eingeschleppten HDD's (und auch alle neu ans Board gehängte Kapazitätsmonster) vom Szenario 4 bis 8 betroffen, und nicht nur ein paar bedauernswerte exotischen Einzelfälle.
Schöne Aussichten also...
(Auszug meines Beitrags vom 07.01.2009)
Abschließend noch ein Kommentar zum zugehörigen HardTecs4U Artikel:
Ist die Festplatte in den hinteren Bereichen leer, oder die Partitionierung wurde mit dem Windows-Setup oder dem Linux-Tool "fdisk" durchgeführt, so besteht keine Gefahr. Die beiden genannten Partitionierungs-Tools lassen am Ende jeder Festplatte einige Megabyte Platz, so dass es zu keinem Verlust durch die Kopie kommt.
Das ist nur bedingt richtig. Bei HDD’s über 80GB ist mir noch keine untergekommen, welche nicht genügend Platz selbst bei Anlegen einer maximal möglichen Basic-MBR-Partition lassen würden.
Es gibt aber einen feinen Unterschied in der Methode, welche die beiden genannten Komponenten unterscheidet: während im Windows darauf geachtet wird, dass mindestens 2048 Sektoren hinter dem letzten Partitionsende für eine spätere Umwandlung in eine „dynamic disk“ freigehalten werden, bietet das Linux-Tool diesen Platzhalter nicht. Bei kleineren Platten, z.B. 20GB, kann daher dieser freie Bereich gar nicht oder nur in ungenügender Größe vorhanden sein.