Schlagwort: LVM

Änderungen bei LVM

Raptor 2101Leave a comment

Wer wie ich regelmäßig einen Raid 1 (Mirror) mit LVM aufbaut/betreibt, wird seit neusten (zu mindestens wenn er auf den aktuellen Ubuntu LTS setzt) in folgendes Problem laufen. Der bisher gültige Befehl führt nicht mehr zum gewünschten Ergebnis:

lvconvert -m 1 volumeGroup/logicalVolume  --corelog
  Insufficient free space: 1 extents needed, but only 0 available

Das ganze liegt daran, dass sich die art wie LVM jetzt einen Raid aufbaut wohl geändert haben soll. Ich bin da nicht tiefer hinabgestiegen. Schlussendlich muss man einfach noch den Typ mit angeben, dann klappt es wieder.

lvconvert -m 1 volumeGroup/logicalVolume  --corelog --type mirror
  volumeGroup/logicalVolume: Converted: 0,0%
  ...
  volumeGroup/logicalVolume: Converted: 100,0%

LVM – Rolling Mirror

Raptor 2101Leave a comment

Rolling Backups sind eine beliebte Variante um zum einen alle BackupMedien gleich-verteilt zu ab zu nutzen und zum anderen mehrere Backupversionen zur Verfügung zu haben. Diese Arbeitsweise wird jedoch mit zunehmender Speichergröße unpraktisch. Ein Fullbackup ist bei 2TB nicht mehr Täglich möglich (6-8 Stunden IO nur durch Backup). Bei inkrementellen Backups ist das Wiederherstellen einzelner Dateien zeitaufwändiger.

Ein guter Kompromiss sind Tools wie „rdiff-backup“. Diese bietet quasi ein Full und Inkrementell Backup  in einem rutsch an. Da nur Änderungen geschrieben werden, bleibt die Dauer des einzelne Backuplaufes kurz und da immer ein FullBackup gehalten wird, kann man ohne Umwege auf die „aktuellste“ Version zurückgreifen. Nur wenn man auf ältere Versionen zurückgreifen will, muss man „ein bisschen“ Rechenzeit einplanen.

Jedoch muss bei rdiff-backup immer der letzte aktuelle Stand als Backup vorliegen. Tauscht man einfach platten durch, kann man beim „einlegen“ einer neuen Platte nicht mehr auf die alten Daten zugreifen. Mann muss die neue Platte also vorher mit den alten Daten bespielen.

Die Idee: Man richtet kurzzeitig einen Mirror zwischen HDD n und HDD n+1 ein. Die Syncronistation beeinflusst das Gesamtsystem kaum, da es sich Backupplatten handelt. Das Backup bleibt über die gesamte Zeit verfügbar, es können also weitere Inkrements gespeichert werden. Die Syncronisationsdauer spielt also keine Rolle. Ist der Mirror hergestellt entfernt man HDD n aus dem System und legt sie in einer anderen „Brandzone“ ab. HDD n+1 übernimmt jetzt die aktive Backupphase. Das kann man so lange treiben bis einem Entweder die Platten ausgehen oder man die gewünschte Datensicherheit/Speicherdauer erreicht hat.

Zum umsetzen kann man LVM nutzen. Das Backupdevice muss jedoch von Anfang schon ein LVM-Device sein.

Als erstes initialisiert man einen Mirror. In Fall wird dem Logischen Device vgBackup/lvBackup die Platte /dev/sda hinzugefügt.

pvcreate  #ggf  zu für die LVM Nutzung vorbereiten.
vgextend diskGroup  #Diskgruppe erweitern
lvconvert -m 1 diskGroup/logcalDevice  --corelog --type mirror -b
lvs #hiermit kann der Sync-Status abgefragt werden.

Nun muss der Spiegel aufgebrochen werden. Normalerweise kann man die Platte einfach so entfernen (HotSwap) wenn kein IO stattfindet. Wenn man sichergehen will, mountet man das Device mal kurz read only.

Anschließend werden ein Haufen fehlermeldungen auftrehten die auf die Fehlende Platte hinweisen. Die wird man mit folgendem Befehl los:

vgreduce --removemissing diskGroup --force