Maxtor Shared Storage NAS 300 GB
Summary of long adventure: TL;DR.
ONE DISK IS NOT AN OPTION FOR A NAS
- Audience : advanced users
- linux skill required : yes
- strong opinion : yes
- frustration : yes
It looks so nice in the picture : storing data on a NAS, not on the local system.
You can access it from anywhere in the network, all is fine.
Until.. The NAS breaks down and you forgot the backups..
I had this NAS for a long time (several years), somewhere safe in the house, in a dry and protected and cool place, nobody would be able to find it, a digital safe, connected to my local network.
It seems a smart idea, but it really was not.
Here is my summary of trouble to get my data back.
1) The NAS did not appear in my network anymore
2) Checked power supply, switches, cables
3) conclusion, NAS is bad
4) reboot, does not come online again
5) open it up, take out harddisk, how hard can it be? Right?
I connected the disk to my machine with one of those PATA/SATA-to-USB things (20 euro things)
I was expecting to see the disk on my standard linux machine, but it did not appear.
The device was recognized and connected, but the partition table was not OK.
I googled around and found that Maxtor/Broadcom made up their own table format.
Here is the code to read it :
http://www.k0lee.com/hpmediavault/diskformat/disk_configuration.c
But it comes down to this : reading the first sector of the disk (with dd or some hex editor)
Long story, but somewhere on the disk is a REISER-FS (version 3.6) but the partition table was corrupted so the thing could not boot up anymore. (doc here : http://jcoppens.com/univ/data/pdf/fs/reiserfs.pdf )
I tried making a full backup of the disk with the normal dd command, but it failed every time.
(disk ticking, taking forever and failing completely as seen in kernel logs, using dmesg)
I found a way to make a complete image with ddrescue command (you need to install this)
(https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html)
This is a very smart program that records which sectors were copied without errors and can be restarted without reading known data again, very good!!
I copied the whole disk: (ignoring partitions)
The trick is to find the start of the ReiserFS partion in this large Blob.
We can search the Blob with some tools, I used midnight commander text search.
(to find the offset of the signature : ReIsEr2Fs\0\0\0: yes this is case sensitive)
https://www.forensicswiki.org/wiki/Reiserfs
When you find the block that looks like this you are lucky.
To find the start of the real offset of the partition you need to go back exactly 64Kbyte.
First part of reiser partition 64k is empty…
From that point you can mount the partition using a loopback mount.
eg: (you need to specify the reiserfs filesystem or it will not work!)
You also need to install : reiserfsprogs
$ sudo mount -t reiserfs -o loop,offset=528785408 maxtor_disk.img /mnt
Finally we can sleep again.
Hope this helps you out!
ONE DISK IS NOT AN OPTION FOR A NAS
- Audience : advanced users
- linux skill required : yes
- strong opinion : yes
- frustration : yes
It looks so nice in the picture : storing data on a NAS, not on the local system.
You can access it from anywhere in the network, all is fine.
Until.. The NAS breaks down and you forgot the backups..
I had this NAS for a long time (several years), somewhere safe in the house, in a dry and protected and cool place, nobody would be able to find it, a digital safe, connected to my local network.
It seems a smart idea, but it really was not.
Here is my summary of trouble to get my data back.
1) The NAS did not appear in my network anymore
2) Checked power supply, switches, cables
3) conclusion, NAS is bad
4) reboot, does not come online again
5) open it up, take out harddisk, how hard can it be? Right?
I connected the disk to my machine with one of those PATA/SATA-to-USB things (20 euro things)
I was expecting to see the disk on my standard linux machine, but it did not appear.
The device was recognized and connected, but the partition table was not OK.
[3031402.984558] usb 3-1.4.1: USB disconnect, device number 19
[3031412.046165] usb 3-1.4.1: new high-speed USB device number 20 using xhci_hcd
[3031412.203698] usb 3-1.4.1: New USB device found, idVendor=152d, idProduct=2338
[3031412.203703] usb 3-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[3031412.203706] usb 3-1.4.1: Product: USB to ATA/ATAPI Bridge
[3031412.203709] usb 3-1.4.1: Manufacturer: JMicron
[3031412.203711] usb 3-1.4.1: SerialNumber: 222222222222
[3031412.205482] usb-storage 3-1.4.1:1.0: USB Mass Storage device detected
[3031412.205695] scsi host11: usb-storage 3-1.4.1:1.0
[3031413.231124] scsi 11:0:0:0: Direct-Access Maxtor 6 SNCH 1E00 PQ: 0 ANSI: 2 CCS
[3031413.231676] sd 11:0:0:0: Attached scsi generic sg9 type 0
[3031413.231936] sd 11:0:0:0: [sdi] 586114704 512-byte logical blocks: (300 GB/279 GiB)
[3031413.232403] sd 11:0:0:0: [sdi] Write Protect is off
[3031413.232407] sd 11:0:0:0: [sdi] Mode Sense: 00 38 00 00
[3031413.232927] sd 11:0:0:0: [sdi] Asking for cache data failed
[3031413.232936] sd 11:0:0:0: [sdi] Assuming drive cache: write through
[3031413.259767] sd 11:0:0:0: [sdi] Attached SCSI disk
The old disk is on device /dev/sdi
I googled around and found that Maxtor/Broadcom made up their own table format.
Here is the code to read it :
http://www.k0lee.com/hpmediavault/diskformat/disk_configuration.c
But it comes down to this : reading the first sector of the disk (with dd or some hex editor)
/*
* Broadcom Disk Header Format
*
* Offset Meaning
* 0- 33 Magic: ``Broadcom NAS Version 1.0 MBR Tag/0/0''
* 34- 39 NAS ID: 6 bytes of binary data to uniquely identify the NAS
* that owns the disk. This can be the ethernet hardware
* address, but need not be.
* 40- 80 Disk Name: A zero-terminated ASCII string. After the
* string-terminating zero byte the rest of the bytes are padded
* out to zero. The zero terminator must be included -- i.e.
* byte 80 must be zero.
* 84- 99 Disk Unique ID: 16 bytes of binary data that uniquely identify
* the disk.
* 100- 100 A flag indicating which of the two partition table regions to
* use: 0 means the first one and any other value means the
* second one.
* 104- 104 The current disk spin-down value. For IDE and SATA disks,
* this represents the value programmed by the 0xe3 command of
* the ATA spec, on disks that support this feature. The spin-
* down value is an 8-bit write-only value that specifies how
* much idle time should pass before the disk automatically spins
* down. The ATA spec specifies how the 256 values map to times,
* and Western Digital implements an alternate mapping in many of
* its drives.
* 512-1535 The first partition table region.
* 1536-2559 The second partition table region.
*/
/*
* Broadcom Partition Spec Block Format
*
* Offset Meaning
* 0- 79 Name of disk. Each byte must be an ASCII upper- or lower-case
* letter, ASCII digit, ASCII dash, ASCII underscore, ASCII space,
* or zero. The first byte must not be zero. After a zero byte,
* all subsequent bytes must be zero.
* 80- 81 Zero.
* 82- 87 NAS ID of the NAS that claimed the disk.
* 88-103 Disk unique tag.
* 104-107 Partition number.
*/
/*
* Broadcom Pool Info Block Format
*
* Offset Meaning
* 0- 79 Name of pool. Each byte must be an ASCII upper- or lower-case
* letter, ASCII digit, ASCII dash, ASCII underscore, ASCII space,
* or zero. The first byte must not be zero. After a zero byte,
* all subsequent bytes must be zero.
* 80- 83 Zero.
* 84- 99 Unique tag of pool.
* 100-105 Unique tag of NAS that created pool.
* 106-107 Zero.
* 108-116 Creation time/date stamp of pool. This stamp is created based
* on the date and time (in universal time) that the pool was
* created. The first 4 bytes are the year, the next byte the
* month, the next byte the day, the next byte the hour, the next
* byte the minute, and the final byte is the second.
* 117-118 Zero.
* 119-119 RAID 5 Tag. 0 => non RAID 5 partition, 5 => RAID 5 Partition
* 120-123 Number of stripes in pool.
* 124-127 Number of mirrors in pool.
* 128-131 Number of spares in pool.
* 132-135 Number of this pane.
* 136-139 Number of chunks in this pane.
* 140-143 Number of this chunk in this pane.
* 144-147 Chunk size.
* 148-255 Partition spec of the start of the next pane.
* 256-363 Partition spec of the next chunk in this pane.
* 364-367 Resize operation in progress. A zero means there is no resize
* operation currently in progress and a one means there is
* currently a resize operation in progress. Any other value is
* illegal.
* 368-375 Resize move backward bytes complete. If there is no resize
* operation in progress, this should be zero. If there is a
* resize operation in progress, this should hold a count of the
* number of bytes completed in the backward movement pass of the
* data movement for the resizing.
* 376-383 Resize move forward bytes complete. If there is no resize
* operation in progress, this should be zero. If there is a
* resize operation in progress, this should hold a count of the
* number of bytes completed in the forward movement pass of the
* data movement for the resizing.
* 384-391 Resize old kilobytes in this partition.
* 392-399 Resize new kilobytes in this partition.
* 400-495 Zero.
* 496-511 Block validity marker: 0x5f9817820ea0bc335f9817820ea0bc33.
*/
Long story, but somewhere on the disk is a REISER-FS (version 3.6) but the partition table was corrupted so the thing could not boot up anymore. (doc here : http://jcoppens.com/univ/data/pdf/fs/reiserfs.pdf )
I tried making a full backup of the disk with the normal dd command, but it failed every time.
(disk ticking, taking forever and failing completely as seen in kernel logs, using dmesg)
I found a way to make a complete image with ddrescue command (you need to install this)
(https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html)
This is a very smart program that records which sectors were copied without errors and can be restarted without reading known data again, very good!!
I copied the whole disk: (ignoring partitions)
oetel@i7-pc:~$ sudo ddrescue /dev/sdi maxtor_disk.img mapfile
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 375521 kB, tried: 65536 B, bad-sector: 0 B, bad areas: 0
ipos: 375586 kB, non-trimmed: 0 B, current rate: 65536 B/s
opos: 375586 kB, non-scraped: 0 B, average rate: 25350 kB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 300090 MB, bad areas: 0, run time: 3h 17m 2s
pct rescued: 100.00%, read errors: 0, remaining time: n/a
time since last successful read: n/a
Finished
The trick is to find the start of the ReiserFS partion in this large Blob.
We can search the Blob with some tools, I used midnight commander text search.
(to find the offset of the signature : ReIsEr2Fs\0\0\0: yes this is case sensitive)
https://www.forensicswiki.org/wiki/Reiserfs
00000000 66 00 01 00 93 18 00 00 82 40 00 00 12 00 00 00 f........@......
00000010 00 00 00 00 00 20 00 00 00 04 00 00 ac 34 11 57 ..... ......¬4.W
00000020 84 03 00 00 1e 00 00 00 00 00 00 00 00 10 cc 03 ..............Ì.
00000030 08 00 02 00 52 65 49 73 45 72 32 46 73 00 00 00 ....ReIsEr2Fs...
00000040 03 00 00 00 04 00 03 00 02 00 00 00 dc 52 00 00 ............ÜR..
When you find the block that looks like this you are lucky.
To find the start of the real offset of the partition you need to go back exactly 64Kbyte.
First part of reiser partition 64k is empty…
From that point you can mount the partition using a loopback mount.
eg: (you need to specify the reiserfs filesystem or it will not work!)
You also need to install : reiserfsprogs
$ sudo mount -t reiserfs -o loop,offset=528785408 maxtor_disk.img /mnt
[3031412.205482] usb-storage 3-1.4.1:1.0: USB Mass Storage device detected
[3031412.205695] scsi host11: usb-storage 3-1.4.1:1.0
[3031413.231124] scsi 11:0:0:0: Direct-Access Maxtor 6 SNCH 1E00 PQ: 0 ANSI: 2 CCS
[3031413.231676] sd 11:0:0:0: Attached scsi generic sg9 type 0
[3031413.231936] sd 11:0:0:0: [sdi] 586114704 512-byte logical blocks: (300 GB/279 GiB)
[3031413.232403] sd 11:0:0:0: [sdi] Write Protect is off
[3031413.232407] sd 11:0:0:0: [sdi] Mode Sense: 00 38 00 00
[3031413.232927] sd 11:0:0:0: [sdi] Asking for cache data failed
[3031413.232936] sd 11:0:0:0: [sdi] Assuming drive cache: write through
[3031413.259767] sd 11:0:0:0: [sdi] Attached SCSI disk
[3037317.028554] REISERFS (device loop0): found reiserfs format "3.6" with standard journal
[3037317.028570] REISERFS (device loop0): using ordered data mode
[3037317.028570] reiserfs: using flush barriers
[3037317.039738] REISERFS (device loop0): journal params: device loop0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[3037317.039922] REISERFS (device loop0): checking transaction log (loop0)
[3037317.047940] REISERFS warning (device loop0): clm-2076 journal_read_transaction: device is readonly, unable to replay log
[3037317.047941] REISERFS warning (device loop0): reiserfs-2006 journal_init: Replay Failure, unable to mount
[3037317.048068] REISERFS warning (device loop0): sh-2022 reiserfs_fill_super: unable to initialize journal space
Success !! start celebration now !!
- chown all data so we can read it, (uid not matching, so we take ownership)
Copy the stuff from /mnt directory to some safe place
To unmount again:
$ sudo umount /mnt
- remove image file (300 GB)
- throw old disk in trash for recycling
Finally we can sleep again.
Hope this helps you out!
For more content hashtag : #oetelx
A French person also managed to recover data : https://micromy.eu
Reacties