I am trying to recover about 5tb of data off of a 20tb volume on my xpenology system. The volume crashed while the system was under normal operating conditions. I have the system on battery backup, so power failure is not a likely cause. I have done a fair bit of research on how to accomplish the recovery, but I am running into a roadblock on what I expect is my potential solution. If I can get so pointers in the right direction I would really appreciate it. So I'll just drop some details here:
fdisk -l
cat /proc/mdstat
mdadm --assemble --scan -v
*These results contain numbers that get caught up in the forum filter so I removed them. If there is a way to post the results without it being flagged I will*
I have one volume with the default name of "volume1" located at /dev/mapper/vg1000-lv or /dev/vg1000/lv I am not super familiar with how all of this works, but my research tells me that I can be using some repair options on the volume to correct the errors that caused the system to crash in the first place. These repair options are where I run into my trouble. Here is what I am talking about:
fsck.ext4 -v /dev/vg1000/lv
$ sudo fsck.ext4 -v /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/vg1000/lv
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>
I think this is telling me that I have a bad super-block. When it goes to repair with a backup super-block it has some trouble. This could mean that I am dead in the water, but I think the method of finding some alternative blocks for repair is as follows:
mke2fs -n /dev/vg1000/lv
sudo mke2fs -n /dev/vg1000/lv
mke2fs 1.42.6 (21-Sep-2012)
mke2fs: Size of device (0x13ff8e000 blocks) /dev/vg1000/lv too big to be expressed
in 32 bits using a blocksize of 4096.
On a typical system this lists out some blocks that are suitable replacements, but I have a 20tb volume! When I created the volume, I did not know that there was a pseudo 16tb limit on the ext4 system. Now I do. This is where my predicament is. I think there is a way to run this if I do some stuff I don't quite understand. For instance, this post (redacted because spam filter)
Can anyone comment on whether this is a possibility? Am I going in the right direction?
Question
Donkey545
Hello,
I am trying to recover about 5tb of data off of a 20tb volume on my xpenology system. The volume crashed while the system was under normal operating conditions. I have the system on battery backup, so power failure is not a likely cause. I have done a fair bit of research on how to accomplish the recovery, but I am running into a roadblock on what I expect is my potential solution. If I can get so pointers in the right direction I would really appreciate it. So I'll just drop some details here:
fdisk -l
cat /proc/mdstat
mdadm --assemble --scan -v
*These results contain numbers that get caught up in the forum filter so I removed them. If there is a way to post the results without it being flagged I will*
I have one volume with the default name of "volume1" located at /dev/mapper/vg1000-lv or /dev/vg1000/lv I am not super familiar with how all of this works, but my research tells me that I can be using some repair options on the volume to correct the errors that caused the system to crash in the first place. These repair options are where I run into my trouble. Here is what I am talking about:
fsck.ext4 -v /dev/vg1000/lv
I think this is telling me that I have a bad super-block. When it goes to repair with a backup super-block it has some trouble. This could mean that I am dead in the water, but I think the method of finding some alternative blocks for repair is as follows:
mke2fs -n /dev/vg1000/lv
On a typical system this lists out some blocks that are suitable replacements, but I have a 20tb volume! When I created the volume, I did not know that there was a pseudo 16tb limit on the ext4 system. Now I do. This is where my predicament is. I think there is a way to run this if I do some stuff I don't quite understand. For instance, this post (redacted because spam filter)
Can anyone comment on whether this is a possibility? Am I going in the right direction?
Any help would be greatly appreciated!
Dom
Edited by Donkey545More info added
Link to comment
Share on other sites
19 answers to this question
Recommended Posts