« Back to all recent discussions

NAS310 - RAID1 failed, volume down, how do I recover data?

steststest Posts: 9  Junior Member
edited July 2019 in Questions
I've been running an NSA310 for a long time with just a 1TB hard drive inside, and now I am trying to add a second 1TB ESATA drive for a RAID1 setup. Not long after I clicked the migrate button to start, a the youngest in the house managed to grab the ESATA cable and it pulled out of the NAS. Now my volume is down, even though all it should have been doing was copying data to the other drive.

When I run the scan volume utility in the web client, I get the following results:
e2fsck 1.41.14 (22-Dec-2010)
The filesystem size (according to the superblock) is 244061472 blocks
The physical size of the device is 244061454 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? no
/dev/md0 contains a file system with errors check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md0: 399705/61022208 files (2.5% non-contiguous) 206351709/244061472 blocks

How do I recover my many years' worth of data?



  • MijzelfMijzelf Posts: 1,282  Paragon Member
    Can you open the Telnet backdoor, login over telnet, and post the output of

    cat /proc/mdstat

  • steststest Posts: 9  Junior Member
    Let's see if this can get around the HTML filter...

    ~ $ cat /proc/mdstat
  • steststest Posts: 9  Junior Member
    edited duplicate comment to not take up space, since I can't delete.
  • MijzelfMijzelf Posts: 1,282  Paragon Member
    For some reason the filesystem on the raid array is bigger than the array itself. I think that is caused because it was a linear array, and now raid1, and the raid1 header needs some extra space.
    Fortunately the header is a version 1.0 header, which means it's at the end of the partition. So by acessing the filesystem on the partition itself, we get some extra space to play with.
    The partition is in use by the raid array, so to access it, we first have to stop the array.
    The procedure:
    stop raid array
    repair filesystem
    shrink filesystem
    start raid array
    grow filesystem on raid array

    In commands:
    If any of this commands fail, stop and post the results.

    It is possible that e2fsck is actually called e2fsck.new.  You can check that beforehand by simply executing it without arguments.
  • steststest Posts: 9  Junior Member
    I ran this and thought e2fsck's result wasn't a failure but now that I'm thinking about it, I'm a bit worried.
     ~ # mdadm --stop /dev/md0mdadm: stopped /dev/md0
    The browser GUI is now showing the volume as Degraded instead of Down, and it still shows as "84.30% (772.56 GB) Used", but I'm still unable to access anything stored on the drive.

    I did have another separate issue come up that having the ESATA drive would be useful for. At this point, I'd be happy with either the RAID 1 functioning as intended, or just having access to my files on the internal disk with no RAID like I did before (and I could then use the ESATA elsewhere). Thanks for your continuing help in either direction.
  • MijzelfMijzelf Posts: 1,282  Paragon Member
    Hm. Your files should be visible by now. Have you tried to reboot the box?
  • steststest Posts: 9  Junior Member
    I thought I had, and I tried it again and am able to see a handful of files. I can see all the shares that were on it before; most are empty, and three of them have some small files visible.

    In the web GUI, I see the volume still degraded, with options to scan (with optional "Auto File Repair") or Repair the volume (as well as edit or delete, which I'm sure I don't want). Should these repair operations be safe to perform?
  • steststest Posts: 9  Junior Member
    I just now stopped and thought about the note on the volume page of the web gui:
    When internal disk becomes defective while in RAID1 mode, the NSA will be in "uninitilized" state.
    You can bring the NSA to its normal state by using the external disk as the new internal disk.
    After login WEB GUI, you can repair the degraded RAID1 by another external disk.
    Does this mean to say that the only way to recover usage is by the repair button, letting it copy everything over to the ESATA drive to reconstruct the RAID1? I'm very apprehensive about just trying things on my own now, with all my data at stake.
  • MijzelfMijzelf Posts: 1,282  Paragon Member
    First, don't panic. According to e2fsck you have 399705 files, occupying 206351709*4k, which is a bit more than 800GB. e2fsck isn't complaining about anything, so the files are just there. The only problem is to find them back.
    Do you know an (exact) filename of one of the missing files? Then login on the telnet backdoor, and execute
    cd /i-data/md0
    where <filename> is your file (When containing spaces, put it in quotes). It should show up, showing where it is.
    You can also get a complete listing by only running 'find .'

    Does this mean to say that the only way to recover usage is by the repair button, letting it copy everything over to the ESATA drive to reconstruct the RAID1?
    No. A degraded array can simply be used. It's only not redundant. This story is about a crashed internal disk, apparently the external is not visible then. You have to put the external disk inside to get a normal, degraded volume.

  • steststest Posts: 9  Junior Member
    I don't remember any specific filenames, but I tried a bunch of file extensions with nothing promising.
    ~ $ cd /i-data/md0/

  • MijzelfMijzelf Posts: 1,282  Paragon Member
    $ cd /i-data/md0/
    That looks strange. Normally /i-data/md0 is a symlink to /etc/zyxel/storage/sysvol, which is a symlink to the data volume in /i-data/, and so I expect it to end in /i-data/<something>, and not in /etc/zyxel/storage/sysvol.

    Possibly that symlink is damaged. Can you post the output of
    ls -l /etc/zyxel/storage/

  • steststest Posts: 9  Junior Member
    ~ $ ls -l /etc/zyxel/storage/

  • MijzelfMijzelf Posts: 1,282  Paragon Member
    That is strange. sysvol is a directory, and it is created in 2013! How can it ever have worked?

    Anyway, let's rename it, and create a symlink

    ln -s /i-data/
    898a84cb /etc/zyxel/storage/sysvol

  • steststest Posts: 9  Junior Member
    2013 is a reasonable estimate for when I started using this drive in the NAS, it might have been even earlier. The 310 is pretty old hardware lol. If that was a deciding factor, should I still follow those steps?
  • MijzelfMijzelf Posts: 1,282  Paragon Member
    Yes. If it doesn't lead to anything, the directory can be changed back. But As far as I remember even my NSA220 from 2008 had a symlink for sysvol.
Sign In or Register to comment.