Saving a partition in Debian when it’s gone, something is wrong
Good afternoon, dear!
I'll tell you a story that could lead to a complete loss of data on the virtual machine, but the way out was still found with: parted
Initial data:
OS: Debiab 9 64bit
FS: ext4 without LVM
Goal: Expand FS on a virtual machine from 14GB to 60GB
')
In principle, for the admin, this task is trivial, but sometimes the stars can converge so that everything goes wrong. Under the cut, I will try to restore the course of events, which led to the fact that the first admin received almost no working VM.
Day 1:
Before the admin was set quite a simple task - you need to expand the size of the file system on the VM. Previously, work has already been done on expanding the disk image for this VM and, therefore, it remained to be small - to expand the size of the file system on the VM.
FS structure on VM:
/ boot - 56Mb
/ - all remaining space - ext4
Since the virtual machine is created from a template, there is no LVM, which of course would simplify the whole procedure.
And so the admin on Thursday evening starts the task. The first step was to boot the VM using an iso image - SystemRescue. After a successful VM boot with the help of an iso-image, the admin starts working and deletes the / (/ dev / vda2) partition with fdisk, which is correct since it needs to be expanded. After deleting the partition (/ dev / vda2), the admin creates a new partition - / dev / vda2 and the first error happens - the admin first creates an extened partition and then creates the primary and saves the new markup from fdisk and tries to mount the partition:
Since the disk layout has changed and the beginning and end of the / dev / vda5 section have changed, an expected error has appeared that was not found or an erroneous superblock. The error is quite serious and if the solution is not right, you can lose the files or get them beaten. You can of course roll back, but the problem lies in the fact that the admin in front of his work did not take a screenshot of the previous disk layout.
Since the partition cannot be mounted ... the administrator attempts to correct the situation by deleting the partitions created by him and creating a new primary, but as he does not mean the end of the partitions with the data, all his attempts lead to one result:
Superblock invalid .
After several attempts to restore the partition on their own, the first administrator to ask for help from the second administrator.
First of all, the second admin leaves the VM and copies the current disk image with the name vm_bad_disk. Next comes VM with the same OS version - Debian 9 64bit and the second disk, vm_bad_disk.
Logging in to a new VM via ssh - we look at the disk listing in the VM:
Here / dev / vdb - this is our vm_bad_disk. First, the second admin removes / dev / vdb2 and / dev / vdb5 and tries to create / dev / vdb2 since 194560 began and the approximate end, but also receives:
Superblock invalid .
To work with partition / dev / vdb - put parted utility for more convenient work with partition.
Repeat the action with deleting / dev / vdb2 already in parted and doing help.
The admin’s attention is attracted by the rescue command, which allows you to specify the beginning and end of the partition to find the file center on it. There is nothing complicated in the command syntax:
Just type in parted:
> rescue
The system will ask:
Start - here it was stated 194560
Now the admin needs to calculate End (the end of the partition). Since initially the admin knows that the size of the entire disk was 14GB and that 1 sector is 512 bytes ... then the following calculations are made:
14 GB is approximately 15032385536 bytes, we calculate the number of sectors:
15032385536/512 = 29360128
This value must be specified in parted:
End 29360128
Press boldly Enter and wait for the result ... In this case, it was not long to wait and parted issued - that the file system was found and whether it is worth making changes - we answer YES
Parted will make the necessary changes and the admin will exit parted.
Admin returns to the system command line and does:
mount / dev / vdb2 / mnt
The partition is mounted without any problems and shows that its size is about 14 GB, which is correct, the FS expansion has not been done yet. The admin fluently checks the files and everything says that at first glance there are no artifacts and broken files.
Since the partition looks live, the admin does: umount / dev / vdb2 and runs:
e2fsck / dev / vdb2 after the end of the test - runs the command to expand the partition:
resize2fs / dev / vdb2
The operation goes without any problems and the admin mounts the partition again to make sure everything is OK:
mount / dev / vdb2 / mnt
The partition is mounted without errors and with the help of the df -p command it sees an already extended partition.
The admin once again checks the files and directories on this party and decides that everything is OK with filesystems and files.
The admin executes the command: shutdown -p now and removes the attached disk from the VM with which the actions were performed.
It saves the original VM disk image with which it all started in a separate storage and replaces it with the disk's correct image and sends the VM to boot.
VM is loaded without any problems and all data is in place.
Morality:
1) Take a SnapShot before your actions
2) Take a screenshot of the desired settings (in this case, partition markup)
3) Before work, backup important files
I'll tell you a story that could lead to a complete loss of data on the virtual machine, but the way out was still found with: parted
Initial data:
OS: Debiab 9 64bit
FS: ext4 without LVM
Goal: Expand FS on a virtual machine from 14GB to 60GB
')
In principle, for the admin, this task is trivial, but sometimes the stars can converge so that everything goes wrong. Under the cut, I will try to restore the course of events, which led to the fact that the first admin received almost no working VM.
Day 1:
Before the admin was set quite a simple task - you need to expand the size of the file system on the VM. Previously, work has already been done on expanding the disk image for this VM and, therefore, it remained to be small - to expand the size of the file system on the VM.
FS structure on VM:
/ boot - 56Mb
/ - all remaining space - ext4
Since the virtual machine is created from a template, there is no LVM, which of course would simplify the whole procedure.
And so the admin on Thursday evening starts the task. The first step was to boot the VM using an iso image - SystemRescue. After a successful VM boot with the help of an iso-image, the admin starts working and deletes the / (/ dev / vda2) partition with fdisk, which is correct since it needs to be expanded. After deleting the partition (/ dev / vda2), the admin creates a new partition - / dev / vda2 and the first error happens - the admin first creates an extened partition and then creates the primary and saves the new markup from fdisk and tries to mount the partition:
Since the disk layout has changed and the beginning and end of the / dev / vda5 section have changed, an expected error has appeared that was not found or an erroneous superblock. The error is quite serious and if the solution is not right, you can lose the files or get them beaten. You can of course roll back, but the problem lies in the fact that the admin in front of his work did not take a screenshot of the previous disk layout.
Since the partition cannot be mounted ... the administrator attempts to correct the situation by deleting the partitions created by him and creating a new primary, but as he does not mean the end of the partitions with the data, all his attempts lead to one result:
Superblock invalid .
After several attempts to restore the partition on their own, the first administrator to ask for help from the second administrator.
First of all, the second admin leaves the VM and copies the current disk image with the name vm_bad_disk. Next comes VM with the same OS version - Debian 9 64bit and the second disk, vm_bad_disk.
Logging in to a new VM via ssh - we look at the disk listing in the VM:
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
Here / dev / vdb - this is our vm_bad_disk. First, the second admin removes / dev / vdb2 and / dev / vdb5 and tries to create / dev / vdb2 since 194560 began and the approximate end, but also receives:
Superblock invalid .
To work with partition / dev / vdb - put parted utility for more convenient work with partition.
Repeat the action with deleting / dev / vdb2 already in parted and doing help.
The admin’s attention is attracted by the rescue command, which allows you to specify the beginning and end of the partition to find the file center on it. There is nothing complicated in the command syntax:
Just type in parted:
> rescue
The system will ask:
Start - here it was stated 194560
Now the admin needs to calculate End (the end of the partition). Since initially the admin knows that the size of the entire disk was 14GB and that 1 sector is 512 bytes ... then the following calculations are made:
14 GB is approximately 15032385536 bytes, we calculate the number of sectors:
15032385536/512 = 29360128
This value must be specified in parted:
End 29360128
Press boldly Enter and wait for the result ... In this case, it was not long to wait and parted issued - that the file system was found and whether it is worth making changes - we answer YES
Parted will make the necessary changes and the admin will exit parted.
Admin returns to the system command line and does:
mount / dev / vdb2 / mnt
The partition is mounted without any problems and shows that its size is about 14 GB, which is correct, the FS expansion has not been done yet. The admin fluently checks the files and everything says that at first glance there are no artifacts and broken files.
Since the partition looks live, the admin does: umount / dev / vdb2 and runs:
e2fsck / dev / vdb2 after the end of the test - runs the command to expand the partition:
resize2fs / dev / vdb2
The operation goes without any problems and the admin mounts the partition again to make sure everything is OK:
mount / dev / vdb2 / mnt
The partition is mounted without errors and with the help of the df -p command it sees an already extended partition.
The admin once again checks the files and directories on this party and decides that everything is OK with filesystems and files.
The admin executes the command: shutdown -p now and removes the attached disk from the VM with which the actions were performed.
It saves the original VM disk image with which it all started in a separate storage and replaces it with the disk's correct image and sends the VM to boot.
VM is loaded without any problems and all data is in place.
Morality:
1) Take a SnapShot before your actions
2) Take a screenshot of the desired settings (in this case, partition markup)
3) Before work, backup important files
Source: https://habr.com/ru/post/446252/
All Articles