[background]
A few days ago, due to loose power plug and other reasons, frequent power failure;
At the same time, aoteng is used for caching.
After one day's restart, the virtual machine will not be able to start.
There should be something wrong with the hard disk. But because of the power problem, it can't be adjusted.
The newly purchased power comes back in these two days. Plug in the hard disk and try to repair it
[environment]
win10 ltsc
vmware
dsm6.2
1T+1T storage pool raid0 NTFS = = "virtual 1T vmdk
4T basic NTFS = = 'virtual 4T vmdk
[process]
Because it's only 1t that's hung up, so we only need to repair 1t
1. Because it's raid0, you can take out a hard disk just in case
2. Create a new ubuntu virtual machine and install related software
sudo -i # So the steps need administrator rights apt update && apt install -y mdadm lvm2 btrfs-prog
3. Back up a copy
dd if=/dev/sdd of=1t.img bs=8M # Use dd to back up the image and try not to move the original data losetup --partscan --find --show 1t.img # Scan loop devices lsblk # Scan it. If there is no loop, try the following again. I don't seem to use the following #mkdir $DISK_PATH0 # Mount loop, may not be necessary #mount /dev/loop0pX $DISK_PATH0
3. By default, Kingway enables soft raid, so it needs to mount the soft raid
mdadm -Av /dev/md3 /dev/loop18p3 #Mount loop lsblk # Check it out. This is normal ------- loop18 7:18 0 1000G 0 loop ├─loop18p1 259:3 0 2.4G 0 loop ├─loop18p2 259:4 0 2G 0 loop └─loop18p3 259:5 0 995.4G 0 loop └─md3 9:3 0 995.4G 0 raid1
4. Disk repair
According to the official documents, the next step is to mount md3 directly and read the data.
However, it may be that my damage is quite serious. I have to find another way to report the error.
Be sure to determine the file system. I thought it was ext4, and it turned out to be btrfs. Fortunately, it was operated on the image.
If you're not sure, try fsck.ext4. You will be prompted
btrfs-find-root /dev/md3 &> /tmp/root.txt head /tmp/root.txt ______ Couldn't setup extent tree Superblock thinks the generation is 12684 Superblock thinks the level is 1 Found tree root at 394632675328 gen 12684 level 1 Well block 394631839744(gen: 12683 level: 1) seems good, but generation/level doesn't match, want gen: 12684 level: 1 Well block 394631561216(gen: 12682 level: 1) seems good, but generation/level doesn't match, want gen: 12684 level: 1 Well block 394631364608(gen: 12681 level: 1) seems good, but generation/level doesn't match, want gen: 12684 level: 1 Well block 394630971392(gen: 12680 level: 1) seems good, but generation/level doesn't match, want gen: 12684 level: 1 Well block 394630627328(gen: 12679 level: 1) seems good, but generation/level doesn't match, want gen: 12684 level: 1 Well block 394630348800(gen: 12678 level: 1) seems good, but generation/level doesn't match, want gen: 12684 level: 1 ______ btrfs check --tree-root <block> --super <sup> # < block > try from top to bottom, such as 394631839744, < sup > = 0 / 1 / 2 # It's different from the one in reference 3. I've reported an Error here. There's more Error ---- Invalid key type(BLOCK_GROUP_ITEM) found in root(202) ignoring invalid key Invalid key type(BLOCK_GROUP_ITEM) found in root(202) ignoring invalid key Invalid key type(BLOCK_GROUP_ITEM) found in root(202) ignoring invalid key Invalid key type(BLOCK_GROUP_ITEM) found in root(202) ignoring invalid key checking free space cache cache and super generation don't match, space cache will be invalidated checking fs roots checking csums checking root refs ERROR: transid errors in file system found 296381579264 bytes used, error(s) found total csum bytes: 290972 total tree bytes: 298598400 total fs tree bytes: 280166400 total extent tree bytes: 17727488 btree space waste bytes: 54920864 file data blocks allocated: 359966142464 referenced 359930527744 ---- btrfs check --repair --tree-root <block> --super <sup> #I used the same parameters as above, so it's OK this time #But if you use the above command again, the same error will be reported ---- Invalid key type(BLOCK_GROUP_ITEM) found in root(202) ignoring invalid key Invalid key type(BLOCK_GROUP_ITEM) found in root(202) ignoring invalid key Invalid key type(BLOCK_GROUP_ITEM) found in root(202) ignoring invalid key No device size related problem found checking free space cache cache and super generation don't match, space cache will be invalidated checking fs roots checking csums checking root refs found 296381579264 bytes used, no error found total csum bytes: 290972 total tree bytes: 298598400 total fs tree bytes: 280166400 total extent tree bytes: 17727488 btree space waste bytes: 54920864 file data blocks allocated: 359966142464 referenced 359930527744 ---- btrfs rescue super-recover /dev/md3 # All supers are valid, no need to recover # Since there is nothing to do at this step, try to mount it mkdir btrfs root@m-server:/media/ubuntu# mount /dev/md3 ./btrfs/ root@m-server:/media/ubuntu# ls btrfs/ bo_nas @download oct_nas svn @synophoto-bin-r.core @synophoto-geoco.core @synorcd.core @database @eaDir @pulseaudio.core @synoaudiod.core @synophoto-bin-t.core @synophoto-perso.core TimeMachine DDSM1 homes R1 @synoelasticd.core @synophoto-conce.core @synophoto-task-.core @tmp ddsm2 @ipcalc.core @sharesnap @synologydrive @synophoto-face-.core @synophoto-thumb.core # The mount is successful. Just copy it happily
