Hi Leute,
es erinnern sich sicherlich einige an mein Thema Grundsatzüberlegungen vor Neuinstallation, in welchem ich sehr ausführlich meinen damals noch geplanten Server vorbereitet habe. Mittlerweile sind mit der tatkräftigen Hilfe aus diesem Forum wohl alle Probleme gelöst, das Ding läuft jedenfalls wunderbar. Allerdings habe ich jetzt für den laufenden Betrieb doch noch zwei Fragen:
1. Ich habe mir dieselbe Platte, welche ich für das RAID-1 verwende, noch ein drittes Mal angeschafft, damit ich im Problemfall schnell Ersatz zur Hand habe. Ich möchte die Platte dahingehend komplett vorbereiten, dass ich sie nur noch anstelle der potentiell defekten Platte einbauen muss und dann sofort das RAID rebuilden kann. Sprich, sie muss vorformatiert werden, die md-devices müssen angelegt werden und das crypt schon aktiviert werden. Wie gehe ich da am besten vor? Ich habe denselben Rechner nochmal, also die Platte dort einfach alleine einbauen, den Debian-Bootstick nehmen und die Platte als Einzelplatte für RAID-1 vorbereiten? Geht das überhaupt? Oder doch anders?
2. Die meisten Partitionen sehen ja so aus: Partition->md-device->crypt->Filesystem. Wenn ich (aus Wartungsgründen) nicht von den Platten booten will, sondern z.B. von einer grml, wie gehe ich da vor? Erkennt grml das alles, oder muss ich jede "Ebene" von Hand starten? Muss ich zwingend ein 64Bit-System nehmen, oder kann ich auf die Daten auch mit einem 32Bit-Livesystem zugreifen, ohne das etwas zerstört wird?
Wie Ersatzfestplatte vorbereiten? Wie auf System zugreifen?
Re: Wie Ersatzfestplatte vorbereiten? Wie auf System zugreif
Gute Idee.dirk11 hat geschrieben:Sprich, sie muss vorformatiert werden
Naja ... sagen wir "sie muss vorpartitioniert werden".
Schlechte Idee.dirk11 hat geschrieben:, die md-devices müssen angelegt werden und das crypt schon aktiviert werden.
mdadm macht das alles von selber, wenn du die Platte eingebaut hast und mdadm sagst, dass es die Partitionen den vorhandenen Raids hinzufügen soll. (vorher die defekten Partitionen aus den Raids entfernen!). Wenn du da vorher irgendwas vorzubereiten versuchst, bringt das mdadm höchstens durcheinander, bietet dir aber keine Vorteile.
Du kannst die Platte allerdings jetzt schon einbauen, und die Partitionen als "Spare" für die jeweiligen Raids eintragen. Dann werden sie automatisch sofort genutzt, wenn eine der Platten versagt. Das halte ich aber in deinem Fall für etwas übertrieben (genau wie den prophylaktischen Kauf der Reserve-Platte).
Ich weiß nicht, was passiert, wenn du die Partitionen jetzt schon als "Spare" markierst, und die Platte dann wieder ausbaust. In einer virtuellen Maschine ausprobieren?
Gute Frage ...dirk11 hat geschrieben:2. Die meisten Partitionen sehen ja so aus: Partition->md-device->crypt->Filesystem. Wenn ich (aus Wartungsgründen) nicht von den Platten booten will, sondern z.B. von einer grml, wie gehe ich da vor?
Die md-devices sollte es eigentlich von selber erkennen. Die Crypt-Devices nicht.
Also musst du dann mit einem "cryptsetup luksOpen /dev/mdX cryptTarget" das verschlüsselte md-Device erst mal entschlüsselt. Danach kannst du mit einem "mount /dev/mapper/cryptTarget /mnt" das Dateisystem zugänglich machen.
Eventuell müssen vorher noch ein paar Kernel-Module von Hand geladen werden, damit das mit dem Crypt klappt.
Ausprobieren?
Das ist allerdings kein "booten". Du bist in einem fremden System (grml) und machst deine Daten zugänglich. Mit der üblichen "chroot"-Arie könntest du danach einem "booten" näher kommen.
Gute Frage. Ich wüsste gerade keinen Grund, warum es mit einem 32-Bit-System nicht funktionieren sollte. "kaputt" machst du damit garantiert nichts. (Außer das Live-System hat fiese Fehler. Ich würd nicht mit einer Live-CD von 2005 auf eine aktuelle Installation losgehen)dirk11 hat geschrieben:Muss ich zwingend ein 64Bit-System nehmen, oder kann ich auf die Daten auch mit einem 32Bit-Livesystem zugreifen, ohne das etwas zerstört wird?
Ausprobieren?
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001