だから私は参加者が破損したディスクのイメージを撮り、インストールプロセスを循環し、データを回復するためのトレーニングシナリオを作成しています。これはかなり基本的なものですが、奇妙な問題に固執しました。
/dev/vdbドライブがあります。
[root@training ~]# fdisk -l /dev/vdb
Disk /dev/vdb: 21.5 GB, 21474836480 bytes, 41943040 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
まず、画像を撮影し、画像とドライブのmd5sumが一致することを確認します。
[root@disk-training ~]# dd if=/dev/vdb of=/recovery/recovery.img conv=sync,notrunc,noerror
10485760+0 records in
10485760+0 records out
5368709120 bytes (5.4 GB) copied, 64.6406 s, 83.1 MB/s
[root@disk-training ~]# md5sum /dev/vdb
08452c6ca60007e69694e7e96258554d /dev/vdb
[root@disk-training ~]# md5sum /recovery/recovery.img
08452c6ca60007e69694e7e96258554d /recovery/recovery.img
次に、キャッシュの混乱がないことを確認するためにキャッシュを削除します。
[root@disk-training ~]# sync; echo 1 > /proc/sys/vm/drop_caches
[root@disk-training ~]# sync; echo 2 > /proc/sys/vm/drop_caches
[root@disk-training ~]# sync; echo 3 > /proc/sys/vm/drop_caches
testdiskを混合してパーティションを復元し、fsckを使用してファイルシステムを復元すると、ファイルを検索できます。
[root@disk-training ~]# testdisk /dev/vdb
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org
You have to reboot for the change to take effect.
[root@disk-training ~]# partprobe /dev/vdb
[root@disk-training ~]# fsck -y /dev/vdb1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
/dev/vdb1 was not cleanly unmounted, check forced.
Resize inode not valid. Recreate? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23896, counted=23897).
Fix? yes
Free blocks count wrong for group #1 (32127, counted=32126).
Fix? yes
Free inodes count wrong for group #0 (8181, counted=8180).
Fix? yes
Free inodes count wrong (327669, counted=327668).
Fix? yes
/dev/vdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vdb1: 12/327680 files (0.0% non-contiguous), 58463/1309696 blocks
[root@disk-training ~]# mount /dev/vdb1 /mnt/
[root@disk-training ~]# ls -l /mnt/file
-rw-r--r-- 1 root root 10 Dec 12 15:41 /mnt/file
だから、すべて良いです。そのため、画像をループデバイスとして設定し、別のmd5sumを実行して次のことを確認します。
[root@disk-training ~]# losetup /dev/loop0 /recovery/recovery.img
[root@disk-training ~]# md5sum /dev/loop0
08452c6ca60007e69694e7e96258554d /dev/loop0
今、同じプロセスを実行しても成功しません。
[root@disk-training ~]# testdisk /dev/loop0
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org
You have to reboot for the change to take effect.
[root@disk-training ~]# partprobe /dev/loop0
[root@disk-training ~]# fsck -y /dev/loop0p1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/loop0p1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
私が行ったいくつかの基本的なトラブルシューティング方法は次のとおりです。
[root@disk-training ~]# dumpe2fs /dev/loop0p1
dumpe2fs 1.42.9 (28-Dec-2013)
dumpe2fs: Bad magic number in super-block while trying to open /dev/loop0p1
Couldn't find valid filesystem superblock.
[root@disk-training ~]# mke2fs -n /dev/loop0p1
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
327680 inodes, 1309696 blocks
65484 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1342177280
40 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
[root@disk-training ~]# for i in {32768,98304,163840,229376,294912,819200,884736}; do e2fsck -b $i /dev/loop0p1; done
e2fsck 1.42.9 (28-Dec-2013)
e2fsck: Bad magic number in super-block while trying to open /dev/loop0p1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
e2fsck 1.42.9 (28-Dec-2013)
e2fsck: Invalid argument while trying to open /dev/loop0p1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
......
私はこの結果に非常に混乱しているので、誰かが私に何が起こっているのか説明することができるかどうか疑問に思います。
ベストアンサー1
イメージのドライブ構造が失われ、testdiskが間違ったパーティションを復元したことがわかりました。 testdiskを使用してヘッド数を1より高く設定すると、問題が解決するようです。