USE YOUR QNAP ONLY TO STORE BACKUPS!

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 i 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!

http://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

[ 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!

i 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

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

links:

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

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

admin