17

Unfortunately, I was unable to recover the file system and had to resort to lower-level data recovery techniques (nicely summarised in Ubuntu's Data Recovery wiki entry), of which Sleuth Kit proved most useful. Marking as answered for cleanliness' sake.


10

This may be outdated already, but a few suggestions: If you are absolutely sure that the original blocksize is 4096, as claimed by testdisk, you can rewrite the superblocks on the disk using mke2fs -S. From man: -S Write superblock and group descriptors only. This is useful if all of the superblock and backup superblocks are corrupted, ...


6

I'm not sure how you can examine any particular superblock, but you can use this command to examine the general contents that all the superblocks share like so, using dumpe2fs. $ sudo dumpe2fs /dev/mapper/fedora_greeneggs-home | less Example $ sudo dumpe2fs /dev/mapper/fedora_greeneggs-home | less Filesystem volume name: <none> Last mounted on: ...


6

Simply run mdadm --build -l1 -n2 /dev/md0 /dev/dm-10 /dev/dm11 to get your data back. Verify that the devices are correct (or use the aliases from /dev/mapper) before doing this! Also, if your kernel has already used (or is using) one of these devices, data will be inconsistent. You should set up the second device as a degenerate 1.2 array, copy the data ...


5

Have a look at this question. I assume that is familiar to your problem. Recreating and even syncing a RAID-1 should not destroy data. Obviously the MD device starts at another offset now. Thus where mount looks for a superblock there is data. This can have happened in at least two ways: You (or rather: the default setting) have created the new array with ...


5

All backup superblocks are the same. They are all a copy of the superblock, and are scattered throughout the disk to provide redundancy in case a large contiguous part of the disk is corrupted. Formatting a partition, even with the same filesystem type, clears the superblock. (It makes sense: the purpose of formatting is to create a clean slate on the ...


4

Warning: Don't use GParted to resize a multi-device BTRFS filesystem! Data loss likely to happen! Looks like GParted is the culprit. Apparently, it doesn't know how to resize multi-device btrfs filesystems and just runs btrfs filesystem resize but does not take care of each device using resize 1:49g and resize 2:49g. This is what btrfs filesystem show ...


4

You don't seem to have a separate home partition. /dev/sda3 is an extended partition (hence the "Étendue" in fdisk -l), you will not be able to mount it and it will not contain your /home. Unless you have a 2nd hard disk, it appears you deleted your /home partition while installing Windows. The only partitions in sda are the Windows one (sda1), what I ...


4

If it's RAID 1 with 0.90 superblock, you should be able to mount directly without using the RAID layer at all. Data starts without offset at the beginning of the disk, so there should be no problem. Use the read-only mount option or a read-only loop device for the experiment just in case. If that works, the simplest method would be to use the other disk to ...


4

Take a look at the e2fsprogs package. It seems that you can get all your backup superblocks from dumpe2fs /dev/sd<partition-id> | grep -i superblock and then have e2fsck check the FS for you, or just try to do mount -o sb=<output-of-dumpe2fs> /dev/sd<partition-id> /your/mountpoint with a backup superblock. See this for reference: http://www....


3

You will need to use TestDisk's sister program PhotoRec to recover your files. It's been a couple of years since I last used these programs, but IIRC you won't be able to recover them in-place, so I hope you have enough spare HD space to recover your files to. It's a good idea to read through the relevant TestDisk & PhotoRec docs before you attempt to ...


3

1.- Originally, fdisk created partitions trying to make them aligned to cylinder boundaries, leaving the first cylinder on disk free, as it would be used for the MBR, patition table and other stuff. This way, the first partition usually started on block 63 (each block being 512 bytes). The fdisk from distributions like RedHat 6.x, still works this way, but ...


3

It's all about layers. You have a disk (the lowest layer). On that disk you put a partition table. On that, you put a RAID. On the RAID you put LUKS. On the LUKS you add LVM. On the LVM, finally the filesystem (the highest layer). Disk -> Partition -> RAID -> LUKS -> LVM -> Filesystem You may skip or reorder some of those layers. It usually ...


3

If it's 0.90 superblock format, you should be able to just use a member directly (in read only mode if you please). That gives you access to your data and then you can create a new fresh RAID-1 with just the other disk, copy your data over, then add the original disk to the RAID. If it's something else though (like 1.2 metadata) you'd first have to find the ...


3

The errors that you're seeing look like a disk failure, not a problem with the filesystem. If the disk itself is failing, fsck won't help.


3

Here's what the official documentation has to say about that: If the sparse_super feature flag is set, redundant copies of the superblock and group descriptors are kept only in the groups whose group number is either 0 or a power of 3, 5, or 7. If the flag is not set, redundant copies are kept in all groups. The sparse_super feature (this is one of ...


3

The Linux e2fsck is only for checking and fixing errors in filesystem types ext2, ext3 and ext4. It can do nothing at all for NTFS. The Bad magic number in super-block error message basically means "I cannot find anything at all that would indicate this is an ext2/3/4 type filesystem. If you are sure this is in fact one of those filesystem types, then you ...


2

Reverting the devices to their original size should just restore the RAID device. You can confirm that by doing: losetup --sizelimit=$((1230*(2**30))) -r /dev/loop1 /dev/dm-10 mdadm -E /dev/loop1 mdadm should now find the superblock if the size is correct. Then you can resize your disks back to that size (-r above is for read-only, so it won't do any harm)...


2

The resize_inode feature creates a hidden inode ( number 7, you can view it in debugfs with stat <7> ) to reserve those blocks so that the GDT can be grown. By default it reserves enough space to grow the filesystem to 1024 times its original size. You can disable the feature or adjust the size using options to mke2fs at format time. What does ...


2

I have had the most success by executing the following strategy: # mdadm --stop /dev/md0 # mdadm --create /dev/md0 --metadata=1.2 --level=5 --raid-devices=4 --chunk=128 --layout=left-symmetric /dev/sda1 /dev/sdb1 /dev/sdc1 missing That creates the device with the same parameters as originally used. The missing causes the device to be created in degraded ...


2

By some mystery I had wiped the volume group and the physical volume in it. It was just a matter of recovering them using the metadata I could back-up using testdisk. I copied the original /etc/lvm folder on the Desktop of the live user, then $ pvcreate --uuid "cZ83jX-WXkk-tNG4-ulGT-sAqq-HlKq-Omtqc8" \ --restorefile /home/liveuser/Desktop/etc/lvm/archive/VG....


2

I accidentally formatted an ext4 partition to NTFS in my Ubuntu 16.04 recently and was able to recover the full partition successfully by running a file system check. sudo fsck.ext4 -v /dev/sda10 I recorded the steps in this blog post.


2

Structures fetched from Ultrix 3.0 v7 of restor so variations can occur: ftp://ftp.uvsq.fr/pub/tuhs/PDP-11/Distributions/dec/Ultrix-3.0/v7restor/include/sys/ The s5fs is rather archaic but ...: Disk layout could be something like: [B][S][Inode List][ Data Blocks ] | | | +-- Super Block +----- Boot Area The Super Block holds data for the file system....


2

If the first sector of the filesystem is undamaged, start with the file command. Pass the -s option so that it looks at the device content instead of just saying “it's a device”. file -s /dev/sdb3 The database used by file isn't the same as the database used by the kernel when mounting, so it can happen that file doesn't recognize a filesystem that the ...


2

Found the answer in the official documentation. Looks like the filesystem cannot be mounted. $ sudo xfs_db /dev/sda1 xfs_db> sb xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 62769952 rblocks = 0


2

...in the event of all backups being corrupt the filesystem is so far gone there is no point in trying to repair... Exactly that, just use normal automatic offsite backups and ignore "superblocks".


2

Don't panic. Note the message /dev/sda5 contains a crypto_LUKS file system. If that's true, then you cannot directly run e2fsck on /dev/sda5, because it's encrypted. Everything on a LUKS-encrypted disk is encrypted, including superblocks and other filesystem metadata, so e2fsck cannot understand it at all. You must first run cryptsetup luksOpen /dev/sda5 ...


1

The superblock and backup superblocks should all be the same. Sometimes the backups can be corrupted just like the superblock, though, so if you find that the one at 32768 is corrupt, try the next one, and continue until you find one that works. if they all seem corrupt, verify you are working with the correct block size.


1

I've found solution here 64bit and metadata_csum features should be disabled sudo tune2fs -O ^metadata_csum,^64bit /dev/sdXX


Only top voted, non community-wiki answers of a minimum length are eligible