NSA325-v2 - how to restore data without NSA?

Lefty Posts: 4  Freshman Member
edited February 2020 in Personal Cloud Storage
Assuming my NSA325 will crash, but HDD will not. How do I access my data?
Same with data in DAR files on external HDD I've got plugged in via USB to NSA. How to manage that without NSA?


Accepted Solution

All Replies

  • Lefty
    Lefty Posts: 4  Freshman Member
    Thanks, that's clear.
  • Damian
    Damian Posts: 5  Freshman Member
    Hi, I tried exactly that, but no luck. I am operating a NSA325V2 for many years as backup device with two JBOD volumes. The volumes thus are quite old, I guess from around 2012. I removed one of the drives from the NSA, and plugged it into a raspberry pi 4 using a usb adapter running latest raspbian buster. No luck mounting though - sdc2 is missing.: (drive is /dev/sdc)

    [email protected]:~ $ sudo fdisk -l
    [removed irrelevant drives]

    Disk /dev/sdc: 2.7 TiB, 3000557895680 bytes, 5860464640 sectors
    Disk model: Elements 25A3
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disklabel type: dos
    Disk identifier: 0x00000000

    Device     Boot Start        End    Sectors Size Id Type
    /dev/sdc1           1 4294967295 4294967295   2T ee GPT

    Partition 1 does not start on physical sector boundary.

    [email protected]:/home/pi# cat /proc/partitions
    major minor  #blocks  name

       1        0       4096 ram0
       1        1       4096 ram1
       1        2       4096 ram2
       1        3       4096 ram3
       1        4       4096 ram4
       1        5       4096 ram5
       1        6       4096 ram6
       1        7       4096 ram7
       1        8       4096 ram8
       1        9       4096 ram9
       1       10       4096 ram10
       1       11       4096 ram11
       1       12       4096 ram12
       1       13       4096 ram13
       1       14       4096 ram14
       1       15       4096 ram15
     179        0   31166976 mmcblk0
     179        1     262144 mmcblk0p1
     179        2   30900736 mmcblk0p2
       8        0   30031250 sda
       8        1   30031234 sda1
       8       16  976762584 sdb
       8       17  976700872 sdb1
       8       32 2930232320 sdc

    [email protected]:/home/pi# parted /dev/sdc1 print
    Error: Could not stat device /dev/sdc1 - No such file or directory.
    Retry/Cancel? c
    [email protected]:/home/pi# parted /dev/sdc2 print
    Error: Could not stat device /dev/sdc2 - No such file or directory.
    Retry/Cancel? c
    [email protected]:/home/pi# parted /dev/sdc print
    Error: Invalid argument during seek for read on /dev/sdc
    Retry/Ignore/Cancel? i
    Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
    OK/Cancel? o
    Model: WD Elements 25A3 (scsi)
    Disk /dev/sdc: 3001GB
    Sector size (logical/physical): 512B/4096B
    Partition Table: unknown
    Disk Flags:

    If I try the same on the NSA; which mounts the device automatically (works perfect), it looks like this:

    [email protected]:~$ sudo parted /dev/sdb print
    Model:  WD30EZRX-00MMMB0 (scsi)
    Disk /dev/sdb: 3001GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt

    Number  Start   End     Size    File system     Name       Flags
     1      1049kB  512MB   511MB   linux-swap(v1)  mitraswap
     2      512MB   3001GB  3000GB                  eexxtt44

    Does anyone have a hint for me?

  • Mijzelf
    Mijzelf Posts: 1,977  Guru Member
    Sector size (logical/physical): 512 bytes / 4096 bytes
    Sector size (logical/physical): 512B/512B
    I think your USB to SATA convertor is doing bad things™, and converts the sectorsize of disks >2TiB. (For compatibilitiy with Windows XP, you know.), which means the partition table is incompatible (as it addresses in sectors).

    You can test that by converting the sectorsize back, using a loopdevice.

    losetup --sector-size 512 -P -f /dev/sdb

    Now you should see the partitions in /proc/partitions as partitions of the loopdevice. (Probably /dev/loop0)

  • Damian
    Damian Posts: 5  Freshman Member
    Thanks for the help! There are loop-partitions, but I was not able to mount them using mount or mdadm. How should I be able to do that?
  • Damian
    Damian Posts: 5  Freshman Member
    I verified the process with my Desktop-PC and a Ubuntu Live USB Stick. Reading works fine.

    I am interested in this only for failure scenarios (e.g. the Zyxel goes bust and I need to access the backups stored on the JBOD drives). So basically it is good to know how to get it working. But I would just LOVE to find a way to just attach such drives to one of my Raspberry Pi 4s and access the data. 

    Does anyone know a way, are there SATA/USB bridges allowing this?
  • Mijzelf
    Mijzelf Posts: 1,977  Guru Member
    Which kernel runs on your RPi? According to the man page --sector-size is supported since 4.14. According to Wikipedia a RPi 4 should run at least 4.19 -if it runs Raspbian.

    How does your /proc/partitions look? Any strange messages in dmesg? Does mdadm show useful information when adding --verbose (twice)?
    Does mdadm fail, or does the assembled md device not mount? If the latter, again, what does dmesg say? And mount -vv?

    It would be nice if you can compare this between Raspbian and Ubuntu live. The outputs should be mainly the same.

    Does anyone know a way, are there SATA/USB bridges allowing this?
    They exist. Unfortunately there isn't a list. I have read about some brand and type where different chips were used, so one sample works, and another doesn't.
    BTW, if you use the disk exclusively with that SATA/USB bridge, there is no problem. 4k sectors are fine, as long as the partition table is created for that. You only get in trouble if you exchange pure Sata with this bridge.

  • Damian
    Damian Posts: 5  Freshman Member
    Thanks for the reply! I will check it again on one of the next weekends, I can't pull one of the drives out of the Zyxel right now because of backups running. I will reply with more detail then.