Filesystem wiederherstellen nach dem versehentlichen mkfs…

1. Das entsprechenede Device in der
/etc/fstab auskommentieren!

2. Die BackUp Configs sind in den Verzeichnissen
/etc/lvm/archive/... und /etc/lvm/backup/ in der entsprechenden Datei mit dem Namen des zerstörten “Volume Group” stehen die notwendigen IDs für
- Physical Volume
- Volume Group
- Logical Volume es sind die kryptische Zeichenketten die hier von Bedeutung sind.

3. Mit
[root@node1 ~]# pvcreate -t -v -u hgUOYh-UTdT-AYGI-Klvx-hX5B-Klei-cgHMSj /dev/sdb1 das Physical Volume testweise anlegen udn auf meldungen achten!

4. Wenn alles sauber durchgelaufen ist dann mit
[root@node1 ~]# pvcreate -v -u hgUOYh-UTdT-AYGI-Klvx-hX5B-Klei-cgHMSj /dev/sdb1 das Physical Volume tatsächlich anlegen!

5. Mit
[root@node1 ~]# pvs und [root@node1 ~]# pvscan prüfen ob das Physical Volume sauber angelegt wurde.

6. jetzt muss das Volume Group wiederhergestellt werden anhand der BackUp oder Archiv Datei
[root@node1 ~]# vgcfgrestore -t -v -f /etc/lvm/backup/VolGr01 VolGr01 hierbei wird das Volume Group nur testweise angelegt, auch hier darauf achten ob hier alles ohne fehler durchläuft.

7. Wenn bei dem Schritt zuvor keine Fehler aufgetreten sind dann jetzt das Volumen tatsächlich anlegen mit
[root@node1 ~]# vgcfgrestore -v -f /etc/lvm/backup/VolGr01 VolGr01auf Meldungen achten!

8. Jetzt prüfen in welchen Zustand das Volume Group und Logical Volumes sind
[root@node1 ~]# pvs
[root@node1 ~]# vgs
[root@node1 ~]# lvsdie Logical Volumes und die Volume Group sollten jetzt aufgelistet werden und im Inaktiven zustand sein ebenso auch das in dem entsprechendem Volume Group enthaltene Logical Volume.

9. eventuell vgchange und lvchange ausführen, anschließend schritt 8. wiederholen.

10. um ein bestimmtes Logical Volume zu aktivieren folgendes ausführen:
[root@node1 ~]# lvchange -ay /dev/VolGr01/SysVol04wieder schritt 8. wiederholen um den Status abzufragen.

11. versuchen das Volume zu mounten in der Regel wird das nicht funktionieren!

12. Um das Filesystem jetzt zu reparieren folgendes ausführen:
[root@node1 ~]# fsck.ext3 -n /dev/VolGr01/SysVol04hierbei werden die Fehler nur angezeigt und nicht behoben.

13. Bevor man das Dateisystem jetzt tatsächlich repariert sollte man ein Backup des Devices erstellen:
[root@node1 ~]# dd if=/dev/VolGr01/SysVol04 | gzip | dd of=/mnt/platte-img.gzhierbei wird das Blockdevice mit dd eingelesen an gzip übergeben gepackt und wieder an das dd weitergereicht und in die Datei gepackt.

14. jetzt kann
[root@node1 ~]# fsck.ext3 -p /dev/VolGr01/SysVol04versucht werden das Dateisystem automatisch repariert werden.

15. Sollte der schritt zuvor scheitern so sollte man das ganze manuell mit:
[root@node1 ~]# fsck.ext3 /dev/VolGr01/SysVol04hierbei wird man bei jeder Aktion nach Entscheidung gefragt…
in meinem Fall hatte ich das ganze immer mit ja bestätigt gehabt bzw. gleich mit:
[root@node1 ~]# fsck.ext3 -y /dev/VolGr01/SysVol04gestartet.

16. die reparierten Dateien wenn es solche dann gibt befinden sich dann in dem Device unter lost+found in kryptischen Verzeichnissen welche an die Inode-Nummern erinnern und nicht die ursprünglichen Namen besitzen da diese durch das formatieren eindeutig überschrieben wurden.

Zusätzlich nützliches:
[root@node1 ~]# fsck.ext3 -n /dev/VolGr01/SysVol04 mit -p automatisch reparieren
[root@node1 ~]# while true; do ls -l /mnt/platte-img.gz; sleep 10; done wiederholtes ausgeben der Befehle