This shows you the differences between two versions of the page.
unix:lvm_recovery [2012/02/11 23:33] robm [Finding the ext4 file-system] |
unix:lvm_recovery [2013/08/20 22:54] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Recovering my lost data: LVM and RAID ====== | ||
- | So I upgraded Ubuntu 9.10 to Ubuntu 11.10. When the system boots it says it cannot mount ''/ | ||
- | |||
- | ===== About the file-system: | ||
- | |||
- | There are many layers of indirection between the file-system and the physical storage when using LVM or RAID. When using both, the number of layers can seem excessive. Here's a diagram of the layers involved in my (lost) setup: | ||
- | |||
- | < | ||
- | digraph G { | ||
- | node [shape=box] | ||
- | |||
- | md0 [label=" | ||
- | sdb1 [label=" | ||
- | sdc1 [label=" | ||
- | sdd1 [label=" | ||
- | sde1 [label=" | ||
- | sdf1 [label=" | ||
- | sdb [label=" | ||
- | sdc [label=" | ||
- | sdd [label=" | ||
- | sde [label=" | ||
- | sdf [label=" | ||
- | |||
- | fs_store [label=" | ||
- | lv_store [label=" | ||
- | vg_store [label=" | ||
- | pv_store [label=" | ||
- | |||
- | sdb1 -> sdb | ||
- | sdc1 -> sdc | ||
- | sdd1 -> sdd | ||
- | sde1 -> sde | ||
- | sdf1 -> sdf | ||
- | md0 -> {sdb1 sdc1 sdd1 sde1 sdf1} | ||
- | pv_store -> md0 | ||
- | vg_store -> pv_store | ||
- | lv_store -> vg_store | ||
- | fs_store -> lv_store | ||
- | } | ||
- | </ | ||
- | |||
- | Note that the RAID block device, '' | ||
- | |||
- | ===== Problem statement ===== | ||
- | |||
- | Since upgrading system boot is interrupted with an error screen to the affect of " | ||
- | |||
- | < | ||
- | digraph G { | ||
- | node [shape=box] | ||
- | |||
- | md0 [label=" | ||
- | sdb1 [label=" | ||
- | sdc1 [label=" | ||
- | sdd1 [label=" | ||
- | sde1 [label=" | ||
- | sdf1 [label=" | ||
- | sdb [label=" | ||
- | sdc [label=" | ||
- | sdd [label=" | ||
- | sde [label=" | ||
- | sdf [label=" | ||
- | |||
- | sdb1 -> sdb | ||
- | sdc1 -> sdc | ||
- | sdd1 -> sdd | ||
- | sde1 -> sde | ||
- | sdf1 -> sdf | ||
- | md0 -> {sdb1 sdc1 sdd1 sde1 sdf1} | ||
- | } | ||
- | </ | ||
- | |||
- | The RAID (multi-disk) status looks fine to me: | ||
- | |||
- | < | ||
- | root@ikari: | ||
- | Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] | ||
- | md127 : active raid5 sdb[1] sde[3] sdc[0] sdd[2] sdf[4](S) | ||
- | 937713408 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU] | ||
- | | ||
- | unused devices: < | ||
- | </ | ||
- | |||
- | but the resulting 960.2 GB block device is partitioned as a "Linux RAID autodetect" | ||
- | |||
- | < | ||
- | root@ikari: | ||
- | |||
- | Disk /dev/md127: 960.2 GB, 960218529792 bytes | ||
- | 255 heads, 63 sectors/ | ||
- | Units = sectors of 1 * 512 = 512 bytes | ||
- | Sector size (logical/ | ||
- | I/O size (minimum/ | ||
- | Disk identifier: 0xd71c877b | ||
- | |||
- | Device Boot Start | ||
- | / | ||
- | Partition 1 does not start on physical sector boundary. | ||
- | </ | ||
- | |||
- | ====== Recovery strategy ====== | ||
- | |||
- | - Create a disk-image of '' | ||
- | - Use LVM snapshots with this disk-image to make (and quickly roll-back) experimental changes | ||
- | |||
- | ===== Formatting the external USB drive ===== | ||
- | |||
- | So I created a single "Linux LVM" partition on the 2TB disk, created a single 1.8TB physical volume and a single 1.8TB volume group containing it. On this I created a 1TB logical volume called '' | ||
- | |||
- | LVM snapshots are interesting creatures. As the name suggests, the snapshot (named '' | ||
- | |||
- | Now here is where things get interesting. The snapshot, '' | ||
- | |||
- | < | ||
- | digraph G { | ||
- | sdj [label=" | ||
- | sdj1 [label=" | ||
- | pv_scratch [label=" | ||
- | vg_scratch [label=" | ||
- | lv_scratch [label=" | ||
- | snap [label=" | ||
- | |||
- | lv_scratch -> vg_scratch -> pv_scratch -> sdj1 -> sdj | ||
- | snap -> vg_scratch | ||
- | |||
- | snap -> lv_scratch [style=" | ||
- | } | ||
- | </ | ||
- | |||
- | < | ||
- | root@ikari: | ||
- | |||
- | Disk /dev/sdj: 2000.4 GB, 2000398934016 bytes | ||
- | 255 heads, 63 sectors/ | ||
- | Units = sectors of 1 * 512 = 512 bytes | ||
- | Sector size (logical/ | ||
- | I/O size (minimum/ | ||
- | Disk identifier: 0x000f0222 | ||
- | |||
- | | ||
- | / | ||
- | </ | ||
- | |||
- | < | ||
- | root@ikari: | ||
- | /dev/dm-0: read failed after 0 of 4096 at 0: Input/ | ||
- | /dev/dm-1: read failed after 0 of 4096 at 0: Input/ | ||
- | /dev/dm-2: read failed after 0 of 4096 at 0: Input/ | ||
- | /dev/dm-3: read failed after 0 of 4096 at 0: Input/ | ||
- | --- Physical volume --- | ||
- | PV Name / | ||
- | VG Name | ||
- | PV Size 1.82 TiB / not usable 4.00 MiB | ||
- | Allocatable | ||
- | PE Size 4.00 MiB | ||
- | Total PE 476931 | ||
- | Free PE 86787 | ||
- | Allocated PE 390144 | ||
- | PV UUID | ||
- | |||
- | root@ikari: | ||
- | /dev/dm-0: read failed after 0 of 4096 at 0: Input/ | ||
- | /dev/dm-1: read failed after 0 of 4096 at 0: Input/ | ||
- | /dev/dm-2: read failed after 0 of 4096 at 0: Input/ | ||
- | /dev/dm-3: read failed after 0 of 4096 at 0: Input/ | ||
- | --- Volume group --- | ||
- | VG Name | ||
- | System ID | ||
- | Format | ||
- | Metadata Areas 1 | ||
- | Metadata Sequence No 13 | ||
- | VG Access | ||
- | VG Status | ||
- | MAX LV 0 | ||
- | Cur LV 2 | ||
- | Open LV 0 | ||
- | Max PV 0 | ||
- | Cur PV 1 | ||
- | Act PV 1 | ||
- | VG Size 1.82 TiB | ||
- | PE Size 4.00 MiB | ||
- | Total PE 476931 | ||
- | Alloc PE / Size | ||
- | Free PE / Size 86787 / 339.01 GiB | ||
- | VG UUID | ||
- | |||
- | root@ikari: | ||
- | /dev/dm-0: read failed after 0 of 4096 at 0: Input/ | ||
- | /dev/dm-1: read failed after 0 of 4096 at 0: Input/ | ||
- | /dev/dm-2: read failed after 0 of 4096 at 0: Input/ | ||
- | /dev/dm-3: read failed after 0 of 4096 at 0: Input/ | ||
- | --- Logical volume --- | ||
- | LV Name / | ||
- | VG Name vg_scratch | ||
- | LV UUID aFBpgv-gqcd-jjLU-c7xO-Jyeb-2R0t-HpEF84 | ||
- | LV Write Access | ||
- | LV snapshot status | ||
- | / | ||
- | LV Status | ||
- | # open 0 | ||
- | LV Size 1.00 TiB | ||
- | Current LE | ||
- | Segments | ||
- | Allocation | ||
- | Read ahead sectors | ||
- | - currently set to 256 | ||
- | Block device | ||
- | |||
- | --- Logical volume --- | ||
- | LV Name / | ||
- | VG Name vg_scratch | ||
- | LV UUID OvOsQ7-uACi-xJVZ-vseu-fKEc-F73h-CmSalH | ||
- | LV Write Access | ||
- | LV snapshot status | ||
- | LV Status | ||
- | # open 0 | ||
- | LV Size 1.00 TiB | ||
- | Current LE | ||
- | COW-table size | ||
- | COW-table LE | ||
- | Allocated to snapshot | ||
- | Snapshot chunk size 4.00 KiB | ||
- | Segments | ||
- | Allocation | ||
- | Read ahead sectors | ||
- | - currently set to 256 | ||
- | Block device | ||
- | </ | ||
- | |||
- | So here's the goal I'm aiming for on my external storage: | ||
- | |||
- | < | ||
- | digraph G { | ||
- | sdj [label=" | ||
- | sdj1 [label=" | ||
- | pv_scratch [label=" | ||
- | vg_scratch [label=" | ||
- | lv_scratch [label=" | ||
- | snap [label=" | ||
- | |||
- | lv_scratch -> vg_scratch -> pv_scratch -> sdj1 -> sdj | ||
- | snap -> vg_scratch | ||
- | snap -> lv_scratch [style=" | ||
- | |||
- | node [shape=box] | ||
- | fs_store [label=" | ||
- | lv_store [label=" | ||
- | vg_store [label=" | ||
- | pv_store [label=" | ||
- | |||
- | |||
- | pv_store -> snap | ||
- | vg_store -> pv_store | ||
- | lv_store -> vg_store | ||
- | fs_store -> lv_store | ||
- | |||
- | |||
- | } | ||
- | </ | ||
- | |||
- | ====== Recognising the nested LVM volumes ====== | ||
- | |||
- | Since it's been a few days and reboots since I last worked on this, I'll start by plugging the USB drive it. | ||
- | |||
- | < | ||
- | root@ikari: | ||
- | [ 479.180019] usb 2-5: new high speed USB device number 7 using ehci_hcd | ||
- | [ 479.313228] scsi13 : usb-storage 2-5:1.0 | ||
- | [ 480.312605] scsi 13:0:0:0: Direct-Access | ||
- | [ 480.336633] sd 13:0:0:0: Attached scsi generic sg10 type 0 | ||
- | [ 480.337029] sd 13:0:0:0: [sdi] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) | ||
- | [ 480.337671] sd 13:0:0:0: [sdi] Write Protect is off | ||
- | [ 480.337671] sd 13:0:0:0: [sdi] Mode Sense: 2f 08 00 00 | ||
- | [ 480.340027] sd 13:0:0:0: [sdi] No Caching mode page present | ||
- | [ 480.340027] sd 13:0:0:0: [sdi] Assuming drive cache: write through | ||
- | [ 480.341806] sd 13:0:0:0: [sdi] No Caching mode page present | ||
- | [ 480.341811] sd 13:0:0:0: [sdi] Assuming drive cache: write through | ||
- | [ 480.357290] | ||
- | [ 480.359346] sd 13:0:0:0: [sdi] No Caching mode page present | ||
- | [ 480.359350] sd 13:0:0:0: [sdi] Assuming drive cache: write through | ||
- | [ 480.359354] sd 13:0:0:0: [sdi] Attached SCSI disk | ||
- | </ | ||
- | |||
- | The (outer) LVM PVs are automatically detects, and their VGs + LVs are subsequently detected: | ||
- | |||
- | < | ||
- | root@ikari: | ||
- | PV | ||
- | / | ||
- | |||
- | root@ikari: | ||
- | VG #PV #LV #SN Attr VSize VFree | ||
- | vg_scratch | ||
- | |||
- | root@ikari: | ||
- | LV | ||
- | lv_scratch vg_scratch owi-a- | ||
- | snap | ||
- | </ | ||
- | |||
- | Somewhere on the '' | ||
- | |||
- | < | ||
- | 8018600: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018610: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018620: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018630: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018640: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018650: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018660: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018670: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018680: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018690: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80186a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80186b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80186c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80186d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80186e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80186f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018700: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018710: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018720: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018730: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018740: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018750: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018760: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018770: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018780: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018790: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80187a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80187b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80187c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80187d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80187e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80187f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018800: 4c41 4245 4c4f 4e45 0100 0000 0000 0000 LABELONE........ | ||
- | 8018810: 9148 4053 2000 0000 4c56 4d32 2030 3031 .H@S ...LVM2 001 | ||
- | 8018820: 5341 7536 6e32 7578 474c 5148 6743 5351 SAu6n2uxGLQHgCSQ | ||
- | 8018830: 6b56 6b5a 655a 4c78 7874 314b 7652 6a31 kVkZeZLxxt1KvRj1 | ||
- | 8018840: 00f8 0391 df00 0000 0000 0300 0000 0000 ................ | ||
- | 8018850: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018860: 0000 0000 0000 0000 0010 0000 0000 0000 ................ | ||
- | 8018870: 00f0 0200 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018880: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 8018890: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 80188a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | </ | ||
- | |||
- | I know from using '' | ||
- | |||
- | < | ||
- | root@ikari: | ||
- | |||
- | root@ikari: | ||
- | / | ||
- | /dev/loop0 [ | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | / | ||
- | /dev/ram10 [ 64.00 MiB] | ||
- | /dev/ram11 [ 64.00 MiB] | ||
- | /dev/ram12 [ 64.00 MiB] | ||
- | /dev/ram13 [ 64.00 MiB] | ||
- | /dev/ram14 [ 64.00 MiB] | ||
- | /dev/ram15 [ 64.00 MiB] | ||
- | / | ||
- | 0 disks | ||
- | 24 partitions | ||
- | 0 LVM physical volume whole disks | ||
- | 2 LVM physical volumes | ||
- | |||
- | root@ikari: | ||
- | PV | ||
- | /dev/loop0 store_vg | ||
- | / | ||
- | </ | ||
- | |||
- | If '' | ||
- | |||
- | < | ||
- | root@ikari: | ||
- | LV | ||
- | store_lv | ||
- | home_zfs | ||
- | lv_scratch vg_scratch owi-a- 894.27g | ||
- | snap | ||
- | </ | ||
- | |||
- | ====== Finding the ext4 file-system ====== | ||
- | |||
- | OK, so now I can read/write my '' | ||
- | |||
- | < | ||
- | root@ikari: | ||
- | / | ||
- | </ | ||
- | |||
- | Time to play with a hex editor again to look at a valid '' | ||
- | |||
- | After a bit of searching I find the characteristic '' | ||
- | |||
- | < | ||
- | # xxd / | ||
- | 05c9db0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9dc0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9dd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9de0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9df0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9e00: 00c0 fc06 c017 f90d c9da b200 0c2a d00a .............*.. | ||
- | 05c9e10: c604 f906 0000 0000 0200 0000 0200 0000 ................ | ||
- | 05c9e20: 0080 0000 0080 0000 0040 0000 9d17 aa4d .........@.....M | ||
- | 05c9e30: 9d17 aa4d 0200 1b00 53ef 0100 0100 0000 ...M....S....... | ||
- | 05c9e40: 4c2c a24d 004e ed00 0000 0000 0100 0000 L, | ||
- | 05c9e50: 0000 0000 0b00 0000 8000 0000 3400 0000 ............4... | ||
- | 05c9e60: 0600 0000 0300 0000 9495 5e9b 7d7e 41da ..........^.}~A. | ||
- | 05c9e70: a595 6af4 4848 b5c6 7374 6f72 6500 0000 ..j.HH..store... | ||
- | 05c9e80: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9e90: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9ea0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9eb0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9ec0: 0000 0000 0000 0000 0000 0000 0000 c803 ................ | ||
- | 05c9ed0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 05c9ee0: 0800 0000 0000 0000 0000 0000 9a4a cd41 .............J.A | ||
- | 05c9ef0: 88ff 4759 ac42 d083 8b3f 3b0d 0201 0000 ..GY.B...?; | ||
- | 05c9f00: 0000 0000 0000 0000 cf4a 9f46 0906 0000 .........J.F.... | ||
- | 05c9f10: 0a06 0000 0b06 0000 0c06 0000 0d06 0000 ................ | ||
- | </ | ||
- | |||
- | By comparing this to my valid file-system, | ||
- | |||
- | < | ||
- | # xxd /dev/sda1 | less | ||
- | 0000380: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 0000390: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 00003a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 00003b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 00003c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 00003d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 00003e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 00003f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 0000400: 0020 2601 005d 9804 73d1 3a00 8366 bb02 . & | ||
- | 0000410: d8da 2001 0000 0000 0200 0000 0200 0000 .. ............. | ||
- | 0000420: 0080 0000 0080 0000 0020 0000 b153 264f ......... ...S&O | ||
- | 0000430: d9bf f44e 0d00 2200 53ef 0100 0100 0000 ...N.." | ||
- | 0000440: 98b4 f44e 004e ed00 0000 0000 0100 0000 ...N.N.......... | ||
- | 0000450: 0000 0000 0b00 0000 0001 0000 3c00 0000 ............< | ||
- | 0000460: 4602 0000 7b00 0000 89bb eae1 b864 492d F...{........dI- | ||
- | 0000470: a3d6 2bc9 5336 151e 0000 0000 0000 0000 ..+.S6.......... | ||
- | 0000480: 0000 0000 0000 0000 2f00 1eae 7c13 0000 ......../ | ||
- | 0000490: 0000 c099 98a1 0188 ffff 985d 698f 0188 ...........]i... | ||
- | 00004a0: ffff 307a 87a2 0188 ffff 307a 87a2 0188 ..0z......0z.... | ||
- | 00004b0: ffff 585c 698f 0188 ffff 645d 1681 ffff ..X\i.....d].... | ||
- | 00004c0: ffff c000 588f 0188 0000 0000 0000 ed03 ....X........... | ||
- | 00004d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 00004e0: 0800 0000 0000 0000 b60a 4000 5547 eae9 ..........@.UG.. | ||
- | 00004f0: 2f3c 45ee 9913 70fb 20b7 7395 0101 0000 /<E...p. .s..... | ||
- | 0000500: 0000 0000 0000 0000 98b4 f44e 0af3 0200 ...........N.... | ||
- | 0000510: 0400 0000 0000 0000 0000 0000 ff7f 0000 ................ | ||
- | 0000520: 0080 4802 ff7f 0000 0100 0000 ffff 4802 ..H...........H. | ||
- | 0000530: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 0000540: 0000 0000 0000 0000 0000 0000 0000 0008 ................ | ||
- | 0000550: 0000 0000 0000 0000 0000 0000 1c00 1c00 ................ | ||
- | 0000560: 0100 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 0000570: 0000 0000 0400 0000 b6b0 300b 0000 0000 ..........0..... | ||
- | 0000580: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | 0000590: 0000 0000 0000 0000 0000 0000 0000 0000 ................ | ||
- | </ | ||
- | |||
- | So let's create another loopback device with an offset: | ||
- | |||
- | < | ||
- | # losetup /dev/loop1 / | ||
- | </ | ||
- | |||
- | For the record, that makes the current overall loopback settings: | ||
- | |||
- | < | ||
- | # losetup -a | ||
- | /dev/loop0: [0005]: | ||
- | /dev/loop1: [0005]: | ||
- | </ | ||
- | |||
- | So is the '' | ||
- | |||
- | < | ||
- | # file -Ls /dev/loop1 | ||
- | /dev/loop1: Linux rev 1.0 ext3 filesystem data, UUID=94955e9b-7d7e-41da-a595-6af44848b5c6, | ||
- | </ | ||
- | |||
- | Success! | ||
- | |||
- | **Update**: I ended up writing a Python script, [[https:// | ||
- | |||
- | ====== Getting my data back ====== | ||
- | |||
- | Obviously I tried mounting it first, to no avail: | ||
- | |||
- | < | ||
- | root@ikari:/ | ||
- | mount: wrong fs type, bad option, bad superblock on /dev/loop1, | ||
- | | ||
- | In some cases useful info is found in syslog - try | ||
- | dmesg | tail or so | ||
- | |||
- | </ | ||
- | |||
- | Since this is all sitting on top of the LVM snapshot I made earlier (''/ | ||
- | |||
- | First attempt, no joy: | ||
- | |||
- | < | ||
- | # fsck.ext4 -y /dev/loop1 | ||
- | e2fsck 1.41.14 (22-Dec-2010) | ||
- | fsck.ext4: Group descriptors look bad... trying backup blocks... | ||
- | fsck.ext4: Bad magic number in super-block when using the backup blocks | ||
- | fsck.ext4: going back to original superblock | ||
- | Error reading block 3226742528 (Invalid argument). | ||
- | |||
- | Force rewrite? yes | ||
- | |||
- | Superblock has an invalid journal (inode 8). | ||
- | Clear? yes | ||
- | |||
- | *** ext3 journal has been deleted - filesystem is now ext2 only *** | ||
- | |||
- | The filesystem size (according to the superblock) is 234428352 blocks | ||
- | The physical size of the device is 187529782 blocks | ||
- | Either the superblock or the partition table is likely to be corrupt! | ||
- | Abort? yes | ||
- | |||
- | Error writing block 3226742528 (Invalid argument). | ||
- | </ |