USE YOUR QNAP ONLY TO STORE BACKUPS!

CREATE A 1:1 BACKUP WITH DD OVER SSH BEFORE PROCEEDING WITH THIS PROCEDURE!

ALSO: (IF RAID1) TAKE OUT ONE HARDDISK (BOTH HARDDISK WILL HAVE THE FULL DATASET)

NEVER UNIQUE DATA OF WHICH NO BACKUP EXISTS! (like your holiday-pictures that you removed from your laptop harddisk to free some space… ARGH… and that you PLANNED to burn on DVD but never did.)

One lucky day thought “why not check my QNAP filesytem?… just to be shure.”

BAD IDEA!

YOU CAN TRY THIS PROCEDURE! BUT I WAS NOT ABLE TO RECOVER MY DATA!

https://dwaves.de/2015/06/22/linux-ext4-ohoh/

LUCKILY I ONLY LOST (MOSTLY) BACKUP-DATA AND ONLY SOME ORIGINAL DATA! (PROJECT-MANAGEMENT)

USE YOUR QNAP ONLY FOR BACKUPS! DO NOT! DO NOT! DO NOT! STORE UNIQUE DATA OF WHICH ON BACKUP EXISTS ON A QNAP!

i ended up with a segfaulting fsck:

dmesg | tail; # display the last 10 lines of systemlog

# what the actual f...?
[ 2275.718458] e2fsck[12411]: segfault at 8577000 ip 00000000f726cdad sp 00000000ff87d408 error 4 in libext2fs.so.2.4[f725a000+30000]
e2fsck[10634]: segfault at 857e000 ip 00000000f72cddad sp 00000000ff8bafb8 error 4 in libext2fs.so.2.4[f72bb000+30000]
e2fsck[12411]: segfault at 8577000 ip 00000000f726cdad sp 00000000ff87d408 error 4 in libext2fs.so.2.4[f725a000+30000]

mount -t ext4 /dev/md0 /mnt/md0; # trying to mount the partition would fail with:

wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

dmesg | tail; # display the last 10 lines of systemlog

[ 3802.545751] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (240)
[ 3808.840758] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 7936 failed (19897!=0)
[ 3808.844567] EXT4-fs (md0): group descriptors corrupted!

try to restore superblock: (QNAP!)

If there is no file system superblock or the check fail, you can try backup superblock.

1. Use the following command to find backup superblock location

/usr/local/sbin/dumpe2fs /dev/md0 | grep superblock

Sample output:

Primary superblock at 0, Group descriptors at 1-6
Backup superblock at 32768, Group descriptors at 32769-32774
Backup superblock at 98304, Group descriptors at 98305-98310
..163840…229376…294912…819200…884736…1605632…2654208…4096000… 7962624… 11239424… 20480000…
23887872…71663616…78675968..102400000..214990848..512000000…550731776…644972544

2. Now check and repair a Linux file system using alternate superblock # 32768:

e2fsck -b 32768 /dev/md0

Sample output:

fsck 1.40.2 (12-Jul-2007)
e2fsck 1.40.2 (12-Jul-2007)
/dev/sda2 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizescf
…….
Free blocks count wrong for group #241 (32254, counted=32253).
Fix? yes
………
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 59586/30539776 files (0.6% non-contiguous), 3604682/61059048 blocks

3. Now try to mount file system using mount command:

mount /dev/md0 /share/MD0_DATA -t ext4

RAID fail – able to mount but data disappear

•If the mount is OK, but data is disappear, unmount the RAID and run e2fsck again (can try backup superblock)

•If still fail, try data recovery program (photorec, R-Studio) or contact data recovery company

cat /sys/block/md0/queue/physical_block_size; # what blocksize does my harddisk have?
512

/sbin/fsck.ext4 -b 229377 -B 512 /dev/md0

dumpe2fs /dev/md0 | grep -i superblock; # search for superblock backups and group descriptors
dumpe2fs 1.41.4 (27-Jan-2009)

Primary superblock at 0, Group descriptors at 1-466
Backup superblock at 32768, Group descriptors at 32769-33234
Backup superblock at 98304, Group descriptors at 98305-98770
Backup superblock at 163840, Group descriptors at 163841-164306
Backup superblock at 229376, Group descriptors at 229377-229842
...

mke2fs -n /dev/md0; # another way search for superblock backups, but not group descriptors

# on systems like Debian 10 the command will be called
mkfs.ext4 -n /dev/md0

mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
487989248 inodes, 1951945600 blocks
97597280 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
59569 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, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544, 1934917632

The superblock is essentially file system metadata and defines the file system type, size, status, and information about other metadata structures (metadata of metadata). The superblock is very critical to the file system and therefore is stored in multiple redundant copies for each file system. The superblock is a very “high level” metadata structure for the file system. For example, if the superblock of a partition, /var, becomes corrupt then the file system in question (/var) cannot be mounted by the operating system. Commonly in this event fsck is run and will automatically select an alternate, backup copy of the superblock and attempt to recover the file system. The backup copies themselves are stored in block groups spread through the file system with the first stored at a 1 block offset from the start of the partition. This is important in the event that a manual recovery is necessary. You may view information about superblock backups with the command dumpe2fs /dev/foo | grep -i superblock which is useful in the event of a manual recovery attempt. Let us suppose that the dumpe2fs command outputs the line Backup superblock at 163840, Group descriptors at 163841-163841. We can use this information, and additional knowledge about the file system structure, to attempt to use this superblock backup: /sbin/fsck.ext3 -b 163840 -B 1024 /dev/foo. Please note that I have assumed a block size of 1024 bytes for this example.

An inode exists in, or on, a file system and represents metadata about a file. For clarity, all objects in a Linux or UNIX system are files; actual files, directories, devices, and so on. Please note that, among the metadata contained in an inode, there is no file name as humans think of it, this will be important later. An inode contains essentially information about ownership (user, group), access mode (read, write, execute permissions) and file type.

A dentry is the glue that holds inodes and files together by relating inode numbers to file names. Dentries also play a role in directory caching which, ideally, keeps the most frequently used files on-hand for faster access. File system traversal is another aspect of the dentry as it maintains a relationship between directories and their files.

A file, in addition to being what humans typically think of when presented with the word, is really just a block of logically related arbitrary data. Comparatively very dull considering all of the work done (above) to keep track of them.

maybe it would be also good to try this:

http://unix.stackexchange.com/questions/4402/what-is-a-superblock-inode-dentry-and-a-file

http://linux.die.net/man/8/e2fsck

http://wiki.qnap.com/wiki/Memory_Test

still no luck restoring the filesystem?

last resort: let photorec recover files.jpg but without filenames:

GNU Linux – recover deleted files NTFS – undelete ext3 vs ext4 – rescue accidentally deleted data files – overwritten partition table – foremost – gpart

links:

http://unix.stackexchange.com/questions/4402/what-is-a-superblock-inode-dentry-and-a-file

http://qnapsupport.net/?page_id=1336

liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!
admin