# Bestehende Gentoo-Box auf Raid1 & LVM umziehen

## uhai

Hallo Experten,

nach ein paar frustrierenden Erfahrungen bzgl. nicht aktueller Backups   :Sad:  habe ich mich entschlossen, meine Gentoo-Home-Box mit einem Raid1 nachzurüsten. Leider bin ich mir mit den Details bei diesem Umzug nicht sicher und möchte gerne Euren Rat einholen, bevor ich hier größeren Flurschaden anrichte...

BESTAND:

Bisher habe ich hier ein 1TB-Laufwerk mit LVM laufen. Eine VolumeGroup ist eingerichtet:

```
# vgdisplay

  --- Volume group ---

  VG Name               tux

  System ID             

  Format                lvm2

  Metadata Areas        2

  Metadata Sequence No  23

  VG Access             read/write

  VG Status             resizable

  MAX LV                0

  Cur LV                6

  Open LV               5

  Max PV                0

  Cur PV                1

  Act PV                1

  VG Size               798,62 GiB

  PE Size               4,00 MiB

  Total PE              204446

  Alloc PE / Size       141056 / 551,00 GiB

  Free  PE / Size       63390 / 247,62 GiB

  VG UUID               J6rWVn-nNOm-3LOV-bEHl-uNxz-X5KD-OAj5US

```

Folgende LogicalVolumes sind eingerichtet:

```
# lvdisplay

  --- Logical volume ---

  LV Name                /dev/tux/usr

  VG Name                tux

  LV UUID                WYF0Y4-s5KW-bqQf-Flqw-Kfb1-VqpC-yI7eb1

  LV Write Access        read/write

  LV Status              available

  # open                 1

  LV Size                41,00 GiB

  Current LE             10496

  Segments               3

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     256

  Block device           253:0

   

  --- Logical volume ---

  LV Name                /dev/tux/home

  VG Name                tux

  LV UUID                rD8KMd-Zfpv-71UP-3TcM-hZp2-XIvG-MMdEjf

  LV Write Access        read/write

  LV Status              available

  # open                 1

  LV Size                178,00 GiB

  Current LE             45568

  Segments               4

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     256

  Block device           253:1

   

  --- Logical volume ---

  LV Name                /dev/tux/var

  VG Name                tux

  LV UUID                kc51OX-INZG-cftK-22hU-un66-nZIu-MHgiiP

  LV Write Access        read/write

  LV Status              available

  # open                 1

  LV Size                20,00 GiB

  Current LE             5120

  Segments               3

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     256

  Block device           253:2

   

  --- Logical volume ---

  LV Name                /dev/tux/opt

  VG Name                tux

  LV UUID                W2ZMZU-P5wB-jnGf-mCX3-DgnZ-LY3N-cI9wMK

  LV Write Access        read/write

  LV Status              available

  # open                 1

  LV Size                10,00 GiB

  Current LE             2560

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     256

  Block device           253:3

   

  --- Logical volume ---

  LV Name                /dev/tux/tmp

  VG Name                tux

  LV UUID                0dRZsm-LVXI-Wdu8-jX7X-T1kR-LgnC-BDqSKL

  LV Write Access        read/write

  LV Status              available

  # open                 1

  LV Size                2,00 GiB

  Current LE             512

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     256

  Block device           253:4

   

  --- Logical volume ---

  LV Name                /dev/tux/Fotos

  VG Name                tux

  LV UUID                8Y0jIK-R78Z-rolw-3VFv-WOg5-mOHd-JVPujI

  LV Write Access        read/write

  LV Status              available

  # open                 0

  LV Size                300,00 GiB

  Current LE             76800

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     256

  Block device           253:5

```

Diese Struktur funktioniert soweit für mich und ich möchte sie gerne übernehmen. Das Vorgehen stelle ich mir so vor:

geplanter Ablauf des Umbaus:

1. Backup auf externes 1TB-Laufwerk. Mit tar "/" und alle Unterverzeichnisse ausser "/tmp", "/proc", "/dev" auf das externe Laufwerk schaffen und dann Verbindung trennen.

2. System mit Raid1 & LVM neu einrichten und dann die Daten zurück kopieren.

offen Fragen:

LVM oder EVMS? Bei Koffler "Linux", 7. Auflage, fand ich den Hinweis, das EVMS besser sei als LVM. Mit EVMS könne man die Volumes im laufenden Betrieb verändern. Hat jemand Erfahrungen mit EVMS? Kann ich damit jedes Dateisystem einsetzen? Gibt es dazu ein Gentoo-Howto - ich konnte hier nichts zu EVMS finden.

tar oder dar? Anscheinend kann ich mit dar auch geöffnete files sichern, während tar diese Dateien übergehen würde (habe ich irgendwo gelesen). dar lässt sich hier allerdings nicht emergen... Lohnt sich die Fehlersuche für "emerge dar"oder reicht tar aus?

Kann ich meinen Kernel vorher um Raid erweitern und dann "/" einfach komplett zurück kopieren? Oder sollte ich nur /home und das world-file zurück kopieren und portage dann den Rest machen lassen?

xfs, ext4 oder ext3? bisher läuft hier alles auf ext3. ext4 scheint inzwischen ja auch stabil zu laufen, xfs scheint gut zu lvm zu passen, da die sich das Dateisystem im laufenden Betrieb vergrößern lässt. Hat jemand dazu Erfahrungen? Was würdet Ihr einsetzen? Wenn ich so eine Aktion starte, will ich doch gleich den System-Aufbau grundsätzlich überprüfen und optimieren, was geht.

Wie oft Dateisystem-Überprüfungen ausführen? Bisher sieht meine fstab so aus:

```
/dev/sda1               /boot           ext3            noauto,noatime  1 2

/dev/sda3               /               ext3            noatime         0 1

/dev/sda2               none            swap            sw              0 0

/dev/cdrom              /mnt/cdrom      auto            noauto,ro,user  0 0

# Synce für MDA - siehe http://wiki.archlinux.org/index.php/Sync_and_connect_with_windows_mobile

#

none           /mnt/synce      cefs    rw,user,noauto,codadev=/dev/cfs0       0         0

shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0

#Logical Volumes

/dev/tux/usr            /usr            ext3            noatime         0 2

/dev/tux/home           /home           ext3            noatime         0 2

/dev/tux/opt            /opt            ext3            noatime         0 2

/dev/tux/var            /var            ext3            noatime         0 2

/dev/tux/tmp            /tmp            ext3            noatime         0 2

```

"/" wird also nicht regelmäßig überprüft. Die anderen Laufwerke werden alle 6 Monate bzw. nach 50 mounts getestet. Welche Intervalle nutzt Ihr? Eventuell sollte ich die Intervalle für /home verkürzen?

verfügbare Doku:

Habe ich da etwas brauchbares übersehen? Bitte um Ergänzungen...

Gentoo Linux x86 mit Software-Raid und LVM2: Kurzleitfaden zur Installation

Software RAID in the new Linux 2.4 kernel, Part 2 (ich habe allerdings 2.6.38 )

Gentoo/x86 Installation Tips & Tricks (nicht aktuell)

Linux Software-RAID HOWTO

Linux Software-RAID HOWTO

EVMS User Guide (doch was gefunden   :Very Happy:  )

Für Tips und Ratschläge wäre ich Euch sehr dankbar. Ich werde jetzt nach einem Reboot erst mal das Sicherungslaufwerk vorbereiten...

uhai

----------

## root_tux_linux

Also ich würds auch so machen

1) Mit TAR  das komplette System sichern (von LiveCD aus)

2) RAID1 und dann LVM einrichten (ob EVMS oder LVM kann ich dir ned helfen)

3) Dann würde ich lieber ext4 nehmen weil es laut Benchmarks z.B. phoronix schneller ist als XFS und XFS ist bekannt für Datenverlusst wenn der z.B Strom ausfällt.

4) fsck lass ich nach jedem 100stem boot ausführen und fahr gut damit

----------

## uhai

Danke root_tux_linux,

momentan klemmt's am Platz für die Sicherung  :Smile: 

ext4 ist dann meine Wahl. EVMS scheint eine Kombination aus raid und lvm zu sein?! Evtl. kann ich dann mit EVMS beides erschlagen.... wäre auch nicht dumm.

uhai

----------

## bbgermany

Hi,

also von EVMS direkt solltest du vielleicht Abstand halten. Das ist Hard Masked im Portage, da die letzte Version von 2006 ist. Die Alternative ist dann LVM2, was du ja bereits erfolgreich im Einsatz hast.

Mein Server zuhause hat übrigens folgendes Setup: 

3x 1TB im Software-RAID5 (mdadm), dann ein LVM2 über das gesamte md0 Device.

Damit fahre ich recht gut und flott.

MfG. Stefan

----------

## schmutzfinger

Wenn es am Platz für die Sicherung klemmt dann gibt es eine einfache und nicht besonders riskante Lösung für das Problem. Da du ein raid1 aufsetzen willst hast du mindestens doppelt so viel Platz wie Daten. Wenn du dein altes Setup solange behalten willst bis das raid1 fertig ist brauchst du den Platz 3 mal. (2x für das Raid + das alte System) Du kannst das Raid1 aber auch mit der zweiten Platte als "missing" aufsetzen. Wenn du dann erfolgreich das neue Raid mit fehlendem Spiegel benutzen kannst, kannst du deine alte Platte in den Raidverbund einfügen. In dem Fall brauchst du den Platz nur zwei mal. Aber es gibt auch die Chance, dass deine Daten dabei verloren gehen. In dem ganzen Prozess gibt es nämlich ein Zeitfenster in dem du nur eine funktionierende Kopie deiner Daten hast. Und zwar in dem Moment wenn dein Raid1 mit einer von zwei Platten läuft, und das alte System schon von der zweiten Platte gelöscht wurde. Dieses Zeitfenster geht vom umpartitionieren der "alten" Platte zu ner Raid-Platte bis zum fertigen Sync der beiden Platten. In der Zeit gibst du noch ein paar kritische Befehle ein, bei denen du die beiden Platten nicht verwechseln solltest. (fdisk, mdadm ...) Und dann natürlich noch das Warten auf die Synchronisation, in der Zeit sollte die "volle" Platte nicht den Geist aufgeben.

Das Risikio ist aber durchaus überschaubar. Da du bisher anscheinend sowieso darauf vertraut hast, dass eine Platte nicht ausfällt, musst du daran nur noch ein wenig länger glauben. Bei einem modernen Rechner würde ich im schlimmsten Fall mit 50MB/s für den Sync rechnen, wahrscheinlich geht es doppelt so schnell. Das Risiko durch einen der Befehle aus Versehen die falsche Platte zu erwischen gibt es zwar, aber in so einem Fall ist man normalerweise ziemlich vorsichtig und sollte genau wissen was ein Befehl macht.

Ich habe mit dieser Methode schon mehreren Systemen zu einem Raid1 verholfen, also das funktioniert nicht nur in der Theorie  :Wink: .

----------

## uhai

Ich habe den Platz insgesamt 3-fach:

Das eingebaute Laufwerk liegt identisch hier nochmal im Regal, dazu habe ich ein externes USB-Laufwerk gleicher Größe.

Ich ziehe mit unison derzeit den aktuellen Stand vom internen Laufwerk auf das externe USB-Laufwerk. Das wird dann abgestöpselt. Anschließend baue ich die Kiste in aller Ruhe um.

Das EVMS so alt ist, ist mir bisher entgangen. Danke für die Warnung. Ich hatte irgendwo im Internet einen Hinweis gefunden, dass EVMS flexibler sein soll als LVM2.  Das aktuellere System ist mir aber lieber....

uhai

----------

## schmutzfinger

Für ein "richtiges" backup würde ich auf keinen Fall unison nehmen. Ich kann mir gut vorstellen, dass du damit hard- und soft-links und Dateiatribute kaputt machen kannst. Dateisysteme wie /dev /proc und /sys sind für simple Kopierprogramme auch ein Problem. Wenn es nur Daten sind dann ist unison vielleicht ok, aber eine root-Partition würde ich damit nicht kopieren. Wenn die Zielpartition das selbe Dateisystem und die selbe Grösse hat dann solltest du einfach dd nehmen. Ansonsten tar oder cpio.

----------

## uhai

/proc und /sys kann ich mit ignore = path ausnehmen. Aber sockets sind ein Problem, da bricht unison ab. - Schade ich dachte, ich kann mit einem gewohnten Tool arbeiten.

tar bricht mit einem Fehler ab, den ich nicht finde...

Jetzt sehe ich mir cpio mal an.

Kann ich bei dd-Backups nacher einzelne Dateien wiederherstellen? dd macht doch ein image, oder? Kann man das mounten und dann wie auf ein Laufwerk zugreifen?

uhai

----------

## wols

Gute Tipps:

http://en.gentoo-wiki.com/wiki/HOWTO_Migrate_To_RAID

http://en.gentoo-wiki.com/wiki/RAID/Software

Für später:

http://news.jensbenecke.de/artikel/1007_linux-raid-defekte-platte-tauschen.html

http://www.unixwerk.de/linux/raidtausch.html

----------

## Max Steel

 *uhai wrote:*   

> /proc und /sys kann ich mit ignore = path ausnehmen. Aber sockets sind ein Problem, da bricht unison ab. - Schade ich dachte, ich kann mit einem gewohnten Tool arbeiten.
> 
> tar bricht mit einem Fehler ab, den ich nicht finde...
> 
> Jetzt sehe ich mir cpio mal an.
> ...

 

Loop kann dir helfen ; )

----------

## wols

Hallo,

bei mir schon "fast hundertfach" in beide Richtungen bewährt:

```
rsync -avn --numeric-ids --exclude=mnt/* --exclude=proc/* --exclude=sys/* / /mnt/backup/
```

Wegen Copy/Paste die Option 'n' (DRY-run) - bitte im Ernstfall entfernen

----------

## schmutzfinger

Mit Knoppix oder anderer LiveCD booten. Das alte root-Verzeichnis nach /mnt/oldroot mounten, das neue nach /mnt/newroot.

```

cd /mnt/oldroot

find . -depth -print0 | cpio -p0Vmud --sparse /mnt/newroot

```

oder

```

cd /mnt/oldroot

tar cpf - . | tar xpf - -C /mnt/newroot

```

Wenn man zusehen will dann kann noch ein 'v' an eines der beiden tar's dran.

Jetzt noch in /mnt/newroot die /etc/fstab anpassen und fertig. Wenn man noch grub installieren will oder sonstige Scherze kann man auch mit chroot reingehen. Dazu /proc, /dev und /sys bind-mounten und die resolv.conf reinkopieren. Siehe dazu gentoo Manual.

----------

