Guten Tag, Liebes!
Ich werde Ihnen eine kurze Beschreibung geben, die zu einem vollständigen Datenverlust auf der virtuellen Maschine führen kann, aber der Ausweg wurde immer noch gefunden mit: getrennt
Ausgangsdaten:Betriebssystem: Debiab 9 64bit
FS: ext4 ohne LVM
Zweck: Erweitern des FS auf einer virtuellen Maschine von 14 GB auf 60 GB
Im Prinzip ist diese Aufgabe für den Administrator trivial, aber manchmal können die Sterne zusammenlaufen, so dass nicht alles so läuft, wie wir es möchten. Unter dem Schnitt werde ich versuchen, den Verlauf der Ereignisse wiederherzustellen, was dazu führte, dass der erste Administrator fast keine funktionierende VM erhielt.
Tag 1:Dem Administrator wurde eine ganz einfache Aufgabe übertragen - Sie müssen die Größe des FS auf der VM erweitern. Zuvor wurde bereits daran gearbeitet, das Festplatten-Image für diese VM zu erweitern, und daher blieb die Angelegenheit klein - die Größe des FS auf der VM zu erweitern.
FS-Struktur auf VM:/ boot - 56 MB
/ - der gesamte verbleibende Platz - ext4
Da die virtuelle Maschine aus einer Vorlage erstellt wird, gibt es kein LVM, was natürlich den gesamten Vorgang vereinfachen würde.
Und so beginnt der Administrator am Donnerstagabend, die Aufgabe auszuführen. Sein erster Schritt war das Booten der VM mit einem ISO-Image - SystemRescue. Nach dem erfolgreichen Laden der VM mit Hilfe des ISO-Images beginnt der Administrator mit der Arbeit und löscht mit Hilfe von fdisk den
Abschnitt / (/ dev / vda2) , der korrekt ist, da er erweitert werden muss. Nach dem Löschen der Partition (/ dev / vda2) erstellt der Administrator eine neue Partition - / dev / vda2 und der erste Fehler tritt auf - der Administrator erstellt zuerst eine erweiterte Partition und erst dann eine primäre Partition. Nach dem Vergleich des neuen Markups wird fdisk beendet und versucht, die Partition bereitzustellen:
Da sich das Festplattenlayout geändert hat und sich Anfang und Ende der Partition / dev / vda5 geändert haben, ist ein erwarteter Fehler aufgetreten, der darauf hinweist, dass kein Superblock gefunden wurde oder ein Fehler aufgetreten ist. Der Fehler ist ziemlich schwerwiegend, und wenn Sie sich der Lösung falsch nähern, können Sie Dateien verlieren oder sie schlagen lassen. Sie können natürlich ein Rollback durchführen, aber das Problem liegt auch darin, dass der Administrator vor seiner Arbeit keinen Screenshot des vorherigen Festplattenlayouts erstellt hat.
Da die Partition nicht gemountet werden kann ... versucht der Administrator, die Situation zu korrigieren, indem er die von ihm erstellten Partitionen löscht und eine neue Primärdatenbank erstellt. Da dies jedoch nicht das Ende des Stapels mit Daten bedeutet, führen alle seine Versuche zu demselben Ergebnis:
Superblock ungültig .
Nach mehreren Versuchen, die Partition selbst wiederherzustellen, bittet der erste Administrator den zweiten Administrator um Hilfe.
Zunächst verlässt der zweite Administrator die VM und kopiert das aktuelle Disk-Image mit dem Namen vm_bad_disk. Als nächstes steigt die VM von derselben Betriebssystemversion - Debian 9 64bit - und verbindet sich mit der zweiten Festplatte - vm_bad_disk.
Nachdem wir über ssh in eine neue VM gekommen sind, sehen wir uns die Liste der Festplatten in VM an:
root@recovery:~# fdisk -l
Disk /dev/vda: 4.9 GiB, 5242880000 bytes, 10240000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x09dea38e
Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 499711 497664 243M 83 Linux
/dev/vda2 501758 10237951 9736194 4.7G 5 Extended
/dev/vda5 501760 10237951 9736192 4.7G 83 Linux
Disk /dev/vdb: 58.6 GiB, 62914560000 bytes, 122880000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe8c76303
Device Boot Start End Sectors Size Id Type
/dev/vdb1 * 2048 194559 192512 94M 83 Linux
/dev/vdb2 196606 30717951 30521346 14.6G 5 Extended
/dev/vdb5 198656 30717951 30519296 14.6G 83 Linux
Hier ist / dev / vdb - das ist unsere vm_bad_disk. Als erstes entfernt der zweite Administrator / dev / vdb2 und / dev / vdb5 und versucht, / dev / vdb2 mit dem Anfang 194560 und einem ungefähren Ende zu erstellen, aber es wird auch:
Superblock ungültig .
Um mit der Partition / dev / vdb arbeiten zu können, ist ein Dienstprogramm für die Teilung installiert, um das Arbeiten mit der Partition zu vereinfachen.
Wir wiederholen die Aktion, indem wir / dev / vdb2 entfernen, das bereits getrennt ist, und helfen.
Der Administrator wird auf den Rettungsbefehl aufmerksam gemacht, mit dem Sie den Anfang und das Ende der Partition festlegen können, um den FS darauf zu finden. Die Befehlssyntax ist nicht kompliziert:
Geben Sie einfach getrennt ein:
> retten
Das System fragt:
Start - es zeigte 194560 an
Jetzt muss der Administrator das Ende (Ende der Partition) berechnen. Da der Administrator zunächst wusste, dass die Größe der gesamten Festplatte 14 GB beträgt und 1 Sektor 512 Byte groß ist, werden die folgenden Berechnungen durchgeführt:
14 GB sind ungefähr 15032385536 Bytes, wir berechnen die Anzahl der Sektoren:
15032385536/512 = 29360128
Dieser Wert muss in parted angegeben werden:
Ende 29360128
Drücken Sie fett die Eingabetaste und warten Sie auf das Ergebnis ... In diesem Fall musste ich nicht lange warten und zeigte, dass der FS gefunden wurde und ob es sich lohnt, die Änderungen vorzunehmen - wir antworten mit JA
Parted nimmt die erforderlichen Änderungen vor und der Administrator beendet parted.
Der Administrator kehrt zur Befehlszeile des Systems zurück und führt Folgendes aus:
mount / dev / vdb2 / mntDie Partition wird problemlos gemountet und zeigt, dass ihre Größe etwa 14 GB beträgt, was korrekt ist, da der FS noch nicht erweitert wurde. Der Administrator überprüft die Dateien schnell und alles sagt, dass es auf den ersten Blick keine Artefakte und beschädigten Dateien gibt.
Da die Partition live aussieht, führt der Administrator
Folgendes aus :
umount / dev / vdb2 und startet:
e2fsck / dev / vdb2 nach Abschluss der Prüfung - führt den Befehl zum Erweitern des Abschnitts aus:
resize2fs / dev / vdb2
Der Vorgang läuft ohne Probleme ab und der Administrator stellt die Partition erneut bereit, um sicherzustellen, dass alles in Ordnung ist:
mount / dev / vdb2 / mntDie Partition wird fehlerfrei gemountet und mit dem Befehl
df -p wird eine bereits erweiterte Partition angezeigt.
Der Administrator überprüft erneut die Dateien und Verzeichnisse in diesem Stapel und entscheidet, dass mit dem FS und den Dateien alles in Ordnung ist.
Der Administrator führt jetzt den Befehl shutdown -p aus und entfernt das zugeordnete Laufwerk von der VM, mit der die Aktionen ausgeführt wurden.
Es speichert das ursprüngliche VM-Disk-Image, mit dem alles in einem separaten Speicher gestartet wurde, ersetzt es durch das richtige Disk-Image und sendet die VM zum Booten.
Die VM startet problemlos und alle Daten sind vorhanden.
Moral:1) Machen Sie vor Ihren Aktionen einen Schnappschuss
2) Machen Sie einen Screenshot der gewünschten Einstellungen (in diesem Fall Partitionsmarkup).
3) Sichern Sie vor der Arbeit wichtige Dateien