@Sypherone Wait, wait, wait, we're mixing up MBR and Superblock. MBR = Master Boot Record, this is basically the partition table and filesystem independent. You're right that normally there is no MBR backup! The Superblock on the other side is from the filesystem. Linux for example doesn't read what filesystem is used from the MBR but parses the Superblock instead. This Superblock indeed does have backups.
Restoring an MBR is damn simple through: Just create a new one (from Linux, WITHOUT formatting the drive, so use low-level software like fdisk), assuming there's only one partition with the size of the whole drive. Even if this assumption is wrong (which I doupt) you should have access to the first partition of the drive now.
Anyway, we can't tell if this is a corrupted MBR or a corrupted Superblock without diagnosting the drive. My guess would be more like a corrupted Superblock as this gets written to while the drive is in use while the MBR should be read only (except you format the drive or something like that). To restore the superblock have a look at
https://superuser.com/questions/593792/fat-filesystem-bad-superblock , for example, but keep in mind to take a raw disc image before attempting anything. On Linux you take such an image with
sudo dd if=/dev/sdX of=/path/to/the/file.img bs=4k (exchange X with the letter of the drive. hdX isn't used anymore, today all is sdX. The
bs=4k is optional but speeds up the dumping by aligning the read chunks to the drives blocksize (which is either 512b or 4kb. Choosing 4kb with a 512b blocksize doesn't hurt)). Mac might be similiar. On Windows you need special software for this.
//EDIT: Keep in mind that dumping will take some time and that dd won't give any output except at the end: There will be an error message, this is ignoreable as it just means the end of the drive has been reached, so dd can't read any more data.
//EDIT²: LOL, I'm having the exact same issue as described at the superuser link right now: Android fails to mount the SD card. From a first look the MBR is just fine but the Superblock damaged. Taking a dd backup while we speak. Will keep you informed how this works out. Will take a lot of time through as this is a big sized card and I'm dumping via USB2.0. Current state: Around 4 of 128 GB backuped.
//EDIT³: Damn, dd failed to create the backup. I hate this card reader, would need a new one... Still let's try to recover that superblock. First step: fscking the drive. The good thing is that it correctly identifies a FAT filesystem but the bad thing is that it shows a one bit difference between the superblock (also called boot sector on FAT) and its backup, so let's try to overwrite the superblock with the backup. The whole fsck process needs a lot of time, too, and also failed with an I/O error. So we go a bit more low level by executing
sudo fsck.vfat -w /dev/sdk1 and interrupting execution after the superblock had been copied:
Code:
$ sudo fsck.vfat -w /dev/sdk1
fsck.fat 4.2 (2021-01-31)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
[123?q]? 2
^C
Okay, now let's try to mount the partition but keep it read-only to not corrupt any more data (remember that I broke my own advise by not taking a raw backup) :
Code:
$ sudo mkdir /tmp/tmpmount
$sudo mount -o ro /dev/sdk1 /tmp/tmpmount
The
-o ro keeps it read only and this worked like a charm: All files and folders seem to be present. So unmount (
sudo umount /dev/sdk1 or
sudo eject /dev/sdk) and put the SD card back into the mobile phone: It doesn't work. Now this is weird and my next try will be to mount the card read-only again, backup all files and folders, formatting the card and put the backups back... Still I start to guess this is a hardware issue, so probably won't work, too...
