Datenträger - Festplatten, SSDs, Speichersticks und -Karten, CD/ 19.562 Themen, 109.845 Beiträge

HDDs über 2 TB, Backup, Verschlüsselung - 2,2 TB-Bug

nemesis² / 11 Antworten / Baumansicht Nickles

Zu dem Thema gab es bisher nur wenige Fragen und die Platten mit 3 oder 4 TB gehen weg wie warme Semmeln. Da dort erheblich mehr Risiken lauern, als ich gedacht hatte, gibt es hier eine kleine Sammlung. Man möchte ja, dass es funktioniert und nicht nur scheinbar und später doch im Daten-GAU endet.


Festplatten mit 3 bis 4 GB sind recht preiswert und irgendwann hält man diese Größe für praktisch und notwendig. Backup ist wichtig und wird früher oder später auch auf solch große - oder noch viel größere HDDs gemacht.


Von Problemen wie dem 2,2 TB-Bug wußte ich vorher und habe ausgiebig getestet. Meine Erwartungen an die Fallstricke wurden aber weit übertroffen! Es kommt auf das Zusammenspiel von Betriebssystem, (BIOS ), Controller und Treibern an, ob man Daten auf über 2 TB verwaltet oder am Ende schrottet! Derartige Probleme sind nicht neu, schon vor Jahren gab es den ähnlichen 128 GB-Bug.


Machbar ist viel, so auch eine 4 TB HDD (512e Sektoren) mit GPT-Partitionierung, komplett verschlüsselt und die läuft (per Adapter) zur Not auch an einem alten Board mit VIA KT266A (nur IDE-Anschlüsse), voll verschlüsselt unter Windows XP (32 Bit). Das ist Gefrickel, als Notsystem, um an die Daten heranzukommen reicht es. Meist genügt völlig, ein aktuelles Betriebsystem zu verwenden (Windows ab Vista 32 Bit), neuere Linux-Versionen.
Primäres Ziel soll hier das Backup auf eine Platte mit 3 (2,5) oder mehr (20+) GB sein, die (fast) vollständig verschlüsselt ist und im Notfall muss man natürlich an seine Daten wieder herankommen! Und das mit dem Rechner, der gerade verfügbar ist.
Das klingt einfach, und ist es im Prinzip auch. Übersieht man aber ein entscheidendes Detail, gibt es schnell den Daten-GAU!


Als Beispiel für die Verschlüsselung dient TrueCrypt, mit dem eine bzw. mehrere Partitionen der HDD verschlüsselt werden. Die Verschlüsselung ist sinnvoll, denn dann kann die Backup-Platte mit relativ ruhigem Gewissen an einem entfernteren Ort gelagert werden, wo sie vor Feuer, Wasser etc. besser geschützt ist, aber ggf. Diebstahl ausgesetzt ist und dieser nicht  gleich bemerkt wird. Oder man macht einen wechselseitigen Austausch mit Bekannten, hält seine Daten so aber privat.


Beim Backup gilt generell: 3, 2, 1. Das heißt mindestens drei Kopien, zwei auf externen Datenträgern und einer davon außer Haus. Es dürfen sich nie alle Datenräger zur gleichen Zeit im selben Raum befinden oder an einen Rechner/Netzwerk angeschlossen sein!


Bei Vollverschlüsselung sollten es besser drei externe Medien sein!

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „HDDs über 2 TB, Backup, Verschlüsselung - 2,2 TB-Bug“
Optionen

Die Hardwarelösung


Bis vor einiger Zeit gab es nur HDDs bis 2 TB und dafür reichte die MBR-Partitionierung aus (bedingt bis 4 TB, aber nur unter Linux). Darüber geht es mit einem Trick, den viele USB-HDDs anwenden: deren Contoller im Gehäuse übersetzt je 8 Sektoren zu 512 Byte zu einen 4 kByte großen Sektor und nur  diesen sieht dann das Betriebssytem/die Anwendung. Damit laufen auch Platten bis 16 TB unter Windows XP (32 Bit).


Alle Software, die auf so eine die HDD zugreift, muss mit 4 k Sektoren umgehen können. Falls das Gehäuse dekfekt geht und man die Daten der HDD darin retten muss, kann diese NICHT einfach an einen SATA-Port des Boards gehängt werden, sondern muss in einem anderen Gehäuse mit der gleichen Übersetzung (512e => 4 kB) eingebaut werden!


Sonst passt ja die Partitionierung/Formatierung nicht und man kann nicht auf die Daten zugreifen. Beim Schreibversuch gäbe es höchstens Datenverlust.

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Die Hardwarelösung Bis vor einiger Zeit gab es nur HDDs bis ...“
Optionen

"Neues" Partitionierungschema - und XP


16 TB sind irgendann zu wenig, von so einem Gehäuse will man sich nicht abhängig machen und meist kommt eine neueres OS zum Einsatz:


Hier verwendet man das GPT-Partitionierungsschema, kann die 512(e) Sektoren behalten und die HDD direkt an das Board anschließen. Aber auch hier lauern Fallen:


Windows XP (32 Bit) kann von Haus aus nicht damit umgehen - die GPT-Unterstützung kann
mit Einschränkungen nachgerüstet werden.  Dazu bieten die Festplatten-Hersteller diverse Tools, die bei mir nicht oder nicht zufriedenstellend funktioniert haben und z. T. muss da auf Partitionen zu je 2 TB aufgespaltet werden. Das die Tools bei mir nicht funktionierten, lag einerseits daran, dass nur an RAID-SATA-Ports getestest wurde und um zu arbeiten, wird  meist eine herstellereigenene HDD verlangt. Wenn die zwar dran hängt, von dem Programm aber nicht erkannt wird (von Windows schon), ist auch Essig. Das ist eher etwas für eine Zweitplatte im System und taugt eher wenig für Wechselplatten.

Eine Alternative ist der Paragon GPT-Loader, der rüstet die fehlende GPT-Unterstützung  für Windows XP (32 Bit) nach. Der kostet Geld, dafür kann man aber mit (GPT-)Partitionen beliebiger Größe arbeiten, diese sogar in der Datenträgerverwaltung und CMD (diskpart) bearbeiten. Zwar soll der nur mit "internen" SATA-HDDs laufen, das ist aber schwammig formuliert und es klappt auch mit (e)SATA - sogar Hotplug.


XP werden sicher die wenigsten noch einsetzen, aber für einen älteren Rechner  mit einer (Offline-)Installation z. B. für Multimedia-Geräte, für die es keine Windows 7-Treiber/Software gibt, bietet sich hier eine Möglichkeit.


Ein Haken kommt gleich: Der GPT-Loader funktioniert nur mit den Standard-Treibern  für den SATA-Controller und wie auch bei den zuvor genannten Lösungen der HDD-Hersteller funktioniert das NICHT an RAID-Controllern! (eine Ausnahme kommt später)


Andererseits muss die 4 TB-SATA-HDD nicht zwingend am SATA-Port laufen, ggf. dem einzigen, der an einem RAID-Controller hängt, sondern per IDE-SATA-Adapter funktioniert sie auch am IDE-Port des Boards mit dem GPT-Loader. Das ist offiziell nicht vorgesehen, klappt aber. Es muss der Treiber für den "Zweikanal-Standard-PCI-IDE-Controller" installiert sein und schon laufen 4 TB oder mehr noch immer unter XP! Da die HDD mit GPT partitioniert ist, läuft sie ohne Verrenkungen an anderen, aktuellen Sytemen - auch direkt am Board zur Datenrettung. Das ist für den Daten(-träger)austausch wichtig.


Der andere Nachteil dieser Notlösung: die SATA-HDD läuft per Adapter am IDE-Port  im UDMA33-Modus (max. 30 MByte/s), selbst wenn der Adapter auf "80-pol. Kabel" per Brücke "nachgelötet" ist (Pin 34 auf Masse legen). Für dieses Problem hatte ich keine Lösung gefunden, Adapter, Board und HDD könnten mehr, tun es aber nicht in dem Zusammenspiel. Ursache scheint der SATA 150 (SATA1) Modus zu sein, denn IDE-HDDs, die max. UDMA100 können, bringen angemessene Leistung. Den Versuch, eine SATA-HDD auf UDMA100 zu begrenzen, habe ich vorsichtshalber gelassen.

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Neues Partitionierungschema - und XP 16 TB sind irgendann ...“
Optionen

Treiberprobleme


Meist sind veraltete Treiber für den 2,2 TB-Bug verantwortlich. Sehr oft RAID-Treiber. Die müssen aktuell sein und > 2 TB unterstützen, sonst gibt es weniger Kapazität oder Datenverlust. Die aktuellen Betriebssysteme bringen passende Treiber mit - oft aber nur für die Standard-Controller und nur eingeschränkt für RAID-Controller.


Es geht hier nur um den Betrieb einer oder HDDs als einzelnes Laufwerk - KEIN RAID-Verbund! Trotzdem müssen die Treiber aktuell und >2TB-fähig sein!

Auf meinem Board war ein JMicron-Controller für eSATA und IDE-Port. Der lief mit dem RAID-Treiber JMB36x. Unter XP arbeitete dieser alte Treiber mit dem GPT-Loader zusammen, zeigte aber fatalerweise den 2,2 TB-Bug. Eine Partition, so hinten erstellt und befüllt, ist dann an einem anderen OS/Board nicht sichtbar. (... und eigentlich wurde nicht hinten geschrieben, sondern vorne ÜBERschrieben => massiver Datenverlust)
Eine aktuelle Treiberversion für JMB36x arbeitet nicht mehr mit dem GPT-Loader zusammen => kein Bug.


Dieser RAID-Controller ist einer, dem man den "Zweikanal-Standard-PCI-IDE-Controller"-Treiber unterjubeln kann und dann läuft auch damit der GPT-Loader und man hat volle Größe (ohne Bugs).


Der einzige Controller mit anscheinend hardwaremäßigem 2,2 TB-Bug, den ich bisher gesehen habe ist ein LogiLink USB-IDE-Adapter. Mit IDE-SATA Adapter dran kam bei der letzten Partition der 4 TB HDD: "Datenträger ist nicht formatiert ..." Von wegen! In der Datenträgerverwaltung (von XP mit GPT-Loader) wurden die Partitionen korrekt angezeigt (3,8 TB; 15 GB). Unter Windows 8.1 zeigte sich der Bug aber auch: letzte Partition sei "RAW", beim Zugriff "Falscher Parameter". Hier ist der Controller das Problem.

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Treiberprobleme Meist sind veraltete Treiber für den 2,2 ...“
Optionen

Pseudo-Partitionen, Wunschgröße


Ein Nebeneffekt der Lösung mit GPT-Loader und XP ist, das bei TrueCrypt "Pseudo-Partitionen" zur Auswahl stehen. Bei einer 4 TB-HDD kann da 3,6 TB und 1,6 TB (und/oder noch 2 TB; 746 GB bei 3 TB HDD, ...) sichtbar sein, auch wenn keine derartigen Partitionen vorhanden sind.

Wählt man versehentlich diese, kann das Passwort ja nicht passen.
Das irritiert nur und in diesem Fall sollten eindeutige, abweichende Partitionsgrößen gewählt werden, um später die "echten" wiederzuerkennen - falls man mehr als eine möchte (eine für dieses und eine für das andere Zeug ...)


Man erkennt die verschlüsselten Partitionen nur an deren Größe, da kein Laufwerksbuchstabe zugeordnet ist.

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Pseudo-Partitionen, Wunschgröße Ein Nebeneffekt der ...“
Optionen

Linux


Unter Linux ist hier vieles einfacher, da liefen problemlos 3 und 4 TB in voller Größe und das selbst per Adapter an so einer alter alten PCI-RAID-Controllerkarte (DC100, RAID-BIOS deaktiviert). Es muss aber eine aktuelle Distribution sein.


Nicht jedes BIOS kommt mit HDDs über 2 TB richtig klar - muss es hier auch nicht, weil nicht gebootet werden muss (ist ja nur die Datenplatte dran) und unter Windows/Linux per Treiber auf die HDD zugegriffen wird. Trotzdem wird die Größe der HDD oft modulo 2 TB angezeigt. Selbst wenn im BIOS korrekt "3000 MB" stehen, werden woanders ggf. trotzdem erst mal nur "modulo 2 TB" angezeigt.

Hängt das BIOS beim POST wegen "Übergröße": für den entschprechenden Anschluss "None" einstellen.

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Linux Unter Linux ist hier vieles einfacher, da liefen ...“
Optionen

Problemfall Gigabyte


Im Ernstfall hat man eventuell nicht das voll kompatible System für >2 TB zur Verfügung und eine Backupplatte ist ggf. für mehrere Rechner zuständig. Hier lauert eine weitere Falle:


http://www.planet3dnow.de/vbulletin/showthread.php/359222-Komisches-RAM-Slot-Problem-Gigabyte-X38-DQ6-Defekt-!?goto=nextnewest


Einige ältere Gigabyte-Boards haben die Unsitte, ungefragt und noch nicht mal im Handbuch beschrieben, ihr BIOS auf die letzten Sektoren der HDD zu kopieren und die HDD um diese Größe "zu schrumpfen". Da wird ein HPA eingerichtet und egal was vorher dort stand, wird eiskalt überschrieben! Und das bei jeder HDD, die angesteckt wird (als Bootplatte und im IDE-Modus steht).


Bei der GPT-Partitionierung sitzt dort am Ende aber die Backup-GPT und wird zerballert! In der Folge meckerte z. B. "Gparted", dass die Backup-GPT korrupt ist. Linux scheint so eine künstliche Begrenzung der HDD-Kapazität nicht sonderlich zu mögen und ließ bei mir problemloses (Um-)Partitionieren nur zu, wenn die HDD ohne Begrenzung lief. Linux soll auch in das HPA schreiben können. Das BIOS würde sich aber immer wieder ans Plattenende schreiben.


Bei diesem BIOS-Problem zeigt die GPT dann eine größere Kapazität an, als die HDD nun anbietet! (Partition größer als Platte ...). Zwar kann man unter Windows mit der eingeschränkten Kapazität Paritionieren, irgendwo klemmte es wieder. Der GPT-Loader verursachte dann auch BSODs (auch wenn nur HDDs <2 TB dran waren).


Das heißt: BIOS-Update machen, die sinnlose Funktion wie "Backup BIOS Image to HDD" auf "disabled" zu setzen und dann mit einem Festplattentool (des Herstellers) die HDD wieder auf volle Größe aufblasen ("Recover native size").


Ohne dies, kann es zu den dollsten Problemen kommen, das z. B. die große GPT-Partitionierte HDD dann auch nicht mehr unter Windows 7 läuft und im Gerätemanager  mit 2,8 TB MBR-basierter Datenträger (3 TB-HDD) steht usw. ...
Dieses Problem sollte man immer im Hinterkopf haben, wenn man eine Backup-/Wechsel-HDD an einem fremden oder unbekannten Rechner hängen muss (z. B. im Ernstfall).

Aus Sicherheitsgründen sollten die letzten 2-10 MB am Ende der HDD frei bleiben, dann gibt es wenigstens keinen relevanten Datenverlust, falls dort etwas überschrieben wird.
Die Daten vom RAID-Array stehen aber zwingend hinten (zumindest teilweise) und so killt ein altes Board schnell ein RAID-Array ...

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Problemfall Gigabyte Im Ernstfall hat man eventuell nicht ...“
Optionen

Abwärtskompatibilität


Oft heißt es: es funktionieren nur die ersten 2 TB und die kann man wenigstens nutzen. Das halte ich selbst als Übergangslösung für eher bedenklich, eine 3 TB HDD verhält sich ganz anders als eine mit max. 2 TB! Kommt irgendein BIOS/Board/Programm nicht mit HDDs über 2 TB klar, dann nur eine 2 TB HDD verwenden! Selbst eine Begrenzung der "LBA reported Size" funktioniert nicht immer, denn z. B. das Seagate-DOS-Tool dafür hat selbst einen 2,2 TB-Bug und das schrumpft eine 3 TB HDD nicht auf 2 TB wie gewählt, sondern auf ungefähr 1,1 TB ...

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Abwärtskompatibilität Oft heißt es: es funktionieren nur ...“
Optionen

Der fiese Bug zeigt sich erst später - Kontrollpartition


Der 2,2 TB-Bug kann öfter lauern - gerade am unbekannten Notrechner, wenn man an sein Backup muss oder einen anderen Rechner backupt.


Das fatale dabei: hat man nur eine einzige Partition über die ganze Platte, läuft es scheinbar problemlos und man bekommt erst viel später (ggf. nach Monaten/Jahren) den Daten-GAU mit! Das wäre gerade beim Backup tragisch, aber man kann vorsorgen und so läuft bei mir  jede Wechsel-HDD (512 e, direkt dran) über 2 TB:


An deren Ende kommt eine kleine Kontroll-Partition. Hier reichen 10-100 MB (FAT16/32/NTFS), man kann aber auch ein paar GB nehmen und dort Backup-Tools oder ISOs fürs Notsystem etc. lagern. Diese Partition muss immer sichtbar sein, sinnvoll gekennzeichnet wie z. B. "3TBok" und enthält ein paar Testdateien (Text oder Bilder reichen). Erscheint dieses Laufwerk im Explorer und man kann problemlos Text oder Bilder darauf öffen, ist alles ok.


Sollte aber auch NUR EINMAL dieses Laufwerk nicht erscheinen oder gar mehrfach in der Datenträgerverwaltung als Pseudo-Partition auftauchen, dann hat man den 2,2 TB-Bug erwischt! In diesem Fall keinerlei Schreibzugriffe auf die HDD, auswerfen, abstöpseln, die Ursache suchen und beheben! Andernfalls droht böse Datenverlust!!!

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Der fiese Bug zeigt sich erst später - Kontrollpartition ...“
Optionen

Verschlüsselung (am Beispiel TrueCrypt)


Abgesehen von der Kontrollpartition am Ende werden alle anderen komlett verschlüsselt. Da kommt der Dieb nicht (so schnell) an die Daten - man selbst im Ernstfall vielleicht auch nicht. Ein kleiner Fehler und schon ist alles weg? Ganz so fragil ist es doch nicht, wenn man vorgesorgt hat:


Gleich, nachdem eine Partition verschlüsselt wurde, macht man ein Backup des Volume Headers (und merkt sich das zugehörige Passwort!). Das ist ganz wichtig, zerballert es den Volume Header und man hat davon kein passendes Backup, sind sämtliche Daten auf der Partition verloren!!! Bei jedem Passwortwechsel muss man gleich wieder den neuen Volume Header backupen! Volume Header und zugehöriges Passwort bilden immer eine Einheit! Deshalb gibt es mit einem Passwortwechsel auch einen anderen Volume Header.


Die verschlüsselten Partitionen sollte man als "versteckt" markieren (auch bei GPT), dann ignoriert Windows die und ordnet keinen Buchstaben zu. So gibt es die wenigsten Schreibversuche (falls der 2,2 TB-Bug am unbekannten Rechner lauert, mindert das  etwas das Risiko für Datenverlust)


Bei TrueCrypt wird Blockweise verschlüsselt, gibt es ein oder mehere Defekte Sektoren auf der Platte, sind meist nur ein paar Dateien futsch (außer es trifft die MFT usw.).

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Verschlüsselung am Beispiel TrueCrypt Abgesehen von der ...“
Optionen

Partition-Recover bei TrueCrypt:


Eine Partition "verschwindet" im Fehlerfall schnell einmal. Meist kann man die z. B. mit "testdisk" wiedergestellt werden, ABER:


Die Programme suchen dazu auf der Platte nach dem Bootsektor einer Partition (z. B. FAT12/32/NTFS, ...) und tragen die Partition wieder ein. Da es (low-level) aber keinen sichtbaren Bootsektor bei der verschlüsselten Partition gibt, kann ihn kein Programm identifizieren und damit nichts wiederherstellen! Die Partition bleibt verloren!


Aber nicht ganz, denn neben dem Volume Header Backup schreibt man sich gleich die Sektoradressen auf, an denen die Partitionen beginnen und enden. Das kann man z. B. mit "GParted" anzeigen lassen. Hilfreich ist auch die grobe Größe, Art (primär/logisch) und das Programm, mit dem man partitioniert hat bzw. die Sektoradressen anzeigen lässt, sich zu merken/notieren, man kann es später brauchen:


Tritt nun der Super-GAU ein, dass eine oder alle Partitionen verschwunden sind (Partitionstabelle gekillt, EPBR-Kette gerissen usw.), wird eine eine Partition erstellt - UNFORMATIERT, die genau an der zuvor notierten Sektoradresse beginnt (und an der anderen endet, Ende könnte auch weiter hinten liegen, wenn dort nichts Wichtiges mehr ist - beim "Hidden Volume" muss sicher auch das Ende passen!).


Man muss exakt den richtigen Anfangs-Sektor treffen (=> Vorschau) und dabei wissen, womit erstellt und welche Ausrichtung (an Zylindern oder MB, primär/logisch -  bekommt man auch heraus, wenn man nur die Sektoradresse aufgeschrieben hatte). Hier muss man etwas probieren, um die richtige Stelle zu treffen.


Da die Windows-Programme eher selten Sektoradressen anzeigen, partitioniere ich praktisch alles unter Linux (meist kommt bei mir  die Boot-CD von Paragon Backup&Recovery [ab 2012?] zum Einsatz - kostenlose Version reicht hier Dicke!).

Erst wenn man sich sicher ist (oder auf einer 1:1 Kopie arbeitet), die Partition eintragen!


Damit überschreibt man einen Teil des Volume Headers. Das macht aber nichts, denn dessen Backup wird jetzt zurückgespielt und schon kann wieder auf die verschlüsselte Partition zugegriffen werden! (hoffentlich ...)


Man hat kein Backup vom Volume Header, weiß aber genau, an welchem Sektor die Partition begann? Dann sollte helfen, die ersten paar Sektoren der Partition (Größe Volume Header + Reserve) mit einem Disk-Editor zu sichern, danach die Partition erstellen wie vorher genannt und dann mit dem Disk-Editor die gesicherten Sektoren wieder draufspielen. Das sollte funktionieren. (hab ich noch nicht probiert)

Nun möge das Backup regelmäßig aktualisiert werden und im Ernstfall funktionieren! Ich brauche meines gelegentlich.

bei Antwort benachrichtigen
nemesis² Nachtrag zu: „Partition-Recover bei TrueCrypt: Eine Partition verschwindet ...“
Optionen

Der 2,2 TB-Bug ist leider nicht das einzige Problem, dass bei Platten über 2 TB lauert. Die damals zur Überwindung der 128 GB-Grenze genannten 48 Bit sind wohl ein Witz bzw. nur auf bestimmte Controller(-Treiber) anwendbar.


Wenn schon eine 5 TB-HDD in einer - relativ neuen - USB 3.3 Docking-Station:

http://www.sharkoon.com/?q=de/node/1735


nur 4 TB erkennt und schon bei 5 TB scheitert (c't 18/2014, S. 63), riecht das für mich nach nur 33 Bit Adressierung (knapp 4,4 TB möglich) im USB-SATA-Bridge-Chip. Hier hat der Hersteller aber korrekt max. 4 TB mit angegeben. Da die übergroße HDD nicht erkannt wird, erkennt man das Problem aber relativ schnell.

Bei USB-Gehäusen muss man also noch viel mehr aufpassen, jede neue Größe (5, 6, 8 TB, ...) immer wieder testen - und das natürlich am USB- und ggf. (e)SATA-Anschluss. Gerade diese Tests müssen wieder "crossover" geschehen, was per (e)SATA hinten geschrieben wurde, muss per USB problemlos ausgelesen werden können. Es reicht im Zweifelsfall NICHT aus, separat für USB und SATA zu testen.

bei Antwort benachrichtigen