Score:0

Recover data from FAT 32

gr flag

I made some videos with a camera. The SD memory is a FAT 32. Arriving at home when I inserted the SD I received the erorr Error mounting /dev/sdb1 at /media/user/disk: can't read superblock on /dev/sdb1

I tried to recovery something with testdisk but it didn't work.

Kinldy ask you for any suggestion.

Thanks, Andrea

I followed the suggestions given in this forum, but the problem seems to be difficult to solve: here is my output using mke2fs and fsck.

user@user-All-Series:~$ sudo mke2fs -n /dev/sdb1
mke2fs 1.46.5 (30-Dec-2021)
/dev/sdb1 contiene un file system vfat
Proceed anyway? (y,N) y
Creazione del file system con 3788800 4k blocchi e 948416 inode
Etichetta del file system=95371903-f8cf-494c-af08-b14b32582d07
Backup del superblocco salvati nei blocchi: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

user@user-All-Series:~$ sudo fsck -b 32768 /dev/sdb1
fsck da util-linux 2.37.2
Usage: fsck.vfat [OPTIONS] DEVICE
Check FAT filesystem on DEVICE for errors.

Options:
  -a              automatically repair the filesystem
  -A              toggle Atari variant of the FAT filesystem
  -b              make read-only boot sector check
  -c N            use DOS codepage N to decode short file names (default: 850)
  -d PATH         drop file with name PATH (can be given multiple times)
  -f              salvage unused chains to files
  -F NUM          specify FAT table NUM used for filesystem access
  -l              list path names
  -n              no-op, check non-interactively without changing
  -p              same as -a, for compat with other *fsck
  -r              interactively repair the filesystem (default)
  -S              disallow spaces in the middle of short file names
  -t              test for bad clusters
  -u PATH         try to undelete (non-directory) file that was named PATH (can be
                    given multiple times)
  -U              allow only uppercase characters in volume and boot label
  -v              verbose mode
  -V              perform a verification pass
  --variant=TYPE  handle variant TYPE of the filesystem
  -w              write changes to disk immediately
  -y              same as -a, for compat with other *fsck
  --help          print this message
user@user-All-Series:~$ sudo fsck -b /dev/sdb1
fsck da util-linux 2.37.2
fsck.fat 4.2 (2021-01-31)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  1:58/00, 3:43/00, 4:61/00, 5:6e/00, 6:6f/00, 7:6e/00, 8:45/00, 9:4f/00
  , 10:53/00, 14:a0/18, 15:18/03, 26:80/ff, 33:00/80, 34:76/ce, 35:00/01
  , 36:b0/74, 37:03/0e, 65:01/00, 71:45/4e, 73:53/20, 74:5f/4e, 75:44/41
  , 76:49/4d, 77:47/45, 78:49/20, 79:54/20, 80:41/20, 81:4c/20
  Not automatically fixing this.

Please help. Thanks

oldfred avatar
cn flag
Are you sure it is FAT32 and not exFAT? FAT32 has a 4GB file limit and with videos you may have larger files or even some new cameras.
Score:0
es flag

testdisk was actually the best approach. But like many similar data recovery strategies, that may or may not work. If it doesn't, you may really be out of luck.

You could try photorec, but AFAIK this is mostly for files that were accidentially deleted. If your FAT32 filesystem is corrupted, that might also not work.

Sadly, SD cards only have a limited life time, even more so with a FAT filesystem that writes the same few disk blocks for the FAT over and over again; that tends to wear down flash media. At some point they stop working, and it's time to replace the SD card.

Having duplicate card slots in the camera and writing to them in parallel (similar to mirroring / RAID 1) helps to avoid data loss, but that's too late for you, I guess.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.