I am writing this from inside a ubuntu live system and I am currently watching a very slow rsync process that recovers the „lost“ data from the Seagate Central NAS harddisk of a friend.

The NAS suddenly stopped showing the files and said friend freaked out because he thought he had lost all his data. But experience shows, often times it is not a broken harddisk but something else.
After trying a few tools which all pretended everything is fine i decided to take a closer look. I pryed the hdd out from the plastic encasing and plugged it into a sata to usb converter.

Windows did not bother to show me the disk. It just said „Meh, its not initialised, i do not like it…“. Well, it was worth a try, but usually Linux is a far better option to do basic data recovery.

I booted up ubuntu on my notebook and tried to get a look at the disk. Unfortunately, the usb adapter was not compatible with whatever was happening on the disk.  So i had to use my desktop pc and plug in the disk directly to the mainboard. And this is what parted -l was telling me:

Model: ATA ST4000DM000-1F21 (scsi)
Disk /dev/sdg: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                Flags
 1      1049kB  22,0MB  21,0MB  ext2         Kernel_1            msftdata
 2      22,0MB  43,0MB  21,0MB  ext2         Kernel_2            msftdata
 3      43,0MB  1117MB  1074MB  ext4         Root_File_System_1  msftdata
 4      1117MB  2190MB  1074MB  ext4         Root_File_System_2  msftdata
 5      2190MB  3264MB  1074MB  ext4         Config              msftdata
 6      3264MB  4338MB  1074MB               Swap
 7      4338MB  5412MB  1074MB  ext4         Update              msftdata
 8      5412MB  4001GB  3995GB               Data                lvm

This looks like there is some sort of linux on the NAS and unfortunately the largest partition did not list a filesystem. But the lvm was very obvious. A quick lvdisplay -a should list all logical volumes…

--- Logical volume ---
  LV Path                /dev/vg1/lv1
  LV Name                lv1
  VG Name                vg1
  LV UUID                VuYO3Z-kWCY-ti7A-wAVr-EaqH-p2Uu-KEglHU
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                3,63 TiB
  Current LE             952571
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

There it is! Luckily it was available. But just trying to mount it would only give somthing like this in dmesg:

[ 1661.456483] EXT4-fs (dm-0): bad block size 65536

The problem: the blocksize over 4k was something the usual mount does not like. And like always, the internet had the answer, just use another set of tools:

sudo apt-get install fuseext2
sudo mkdir /mountTarget
sudo fuseext2 -o ro -o sync_read /dev/vg1/lv1 /mountTarget

This mounts the volume at /mountTarget where you can then access the files (fuseext2 does not have a problem with large blocksizes)! Hooray.

Please always mount filesystem as read-only when trying to do data recovery!

As initially mentioned i used rsync to copy the files to a network share on my network. As far as i can tell, nothing was lost in the process. Why did the NAS stop showing the files? I do not know…