File system broken after power cut down

[timnas]

Recently, there were electrical works in my building and appartment that caused a power cut down.

The beep of my UPS was probably to annoying for workers so they decided to unplug the NAS that was then running on the battery (facepalm).

When power was restored, I plugged it back on my UPS, and press the start button. Then I received an email:

New disk detected. [Disk 1] (Nas)

A new disk was added to the ReadyNAS.  If multiple disks have been added, they will be processed one at a time.  Please do not remove any added disk(s) during this time.

Wow! No! It's not a new disk! Wait...

And guess what? ... Power cut again, and unplugged from battery again.

Since then, it won't start. So I extracted the disk, tried to clean, to put it back several times, then I decided to proceed to a check/repair/forensic journey...

When I analyze the partition structure of the 2 TB disk, it seems to be partially broken. I use a Freecom Hard Drive Dock Duplicator to both connect the disk to USB to a working machine (and old 32-bits IBM X60) and duplicate the disk autonomously as is to be sure I have a backup if I did something wrong. What I want to achieve is either:

• fix the booting issue and make the NAS start as usual
• or retreive all the data from the disk and start a fresh install of the NAS, loosing all the configuration I did (scripts and crons and manually installed services and security tools etc.).

When docked through USB, the device is mounted as /dev/sdb, /dev/sdb1, /dev/sdb2 and /dev/sdb3.

Please note that I'm not familiar with RAID, filesystems, disk partitionning and data forensics.

The following is all I have, without being sure of what it means. Please tell me if you see/understand something in this mess, and if I'm wrong.

sudo mdadm -E /dev/sdb3

/dev/sdb3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 1858b355:7c24531e:2fddde7f:10cf1e0b
           Name : x60:99  (local to host x60)
  Creation Time : Sun Jan  1 19:35:50 2017
     Raid Level : raid1
   Raid Devices : 1

 Avail Dev Size : 3897323368 (1858.39 GiB 1995.43 GB)
     Array Size : 1948661632 (1858.39 GiB 1995.43 GB)
  Used Dev Size : 3897323264 (1858.39 GiB 1995.43 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262056 sectors, after=104 sectors
          State : active
    Device UUID : a8fe3d88:cb0c2668:fe0eac8d:b3b5d84c

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Jan  1 19:35:50 2017
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 2ebf2efb - correct
         Events : 0


   Device Role : Active device 0
   Array State : A ('A' == active, '.' == missing, 'R' == replacing)

testdisk

Disk /dev/sdb - 2000 GB / 1863 GiB - CHS 243201 255 63
     Partition               Start        End    Size in sectors
 P Linux Raid                    64    8386607    8386544 [E0469AA064B8:0]
 P Linux Raid               8388672    9437231    1048560 [E0469AA064B8:1]
>P Linux Raid               9437248 3906760519 3897323272 [E0469AA064B8:2]

Since then I did something wrong, before cloning the disk so the mistake is forever:

tried testdisk partition discovery and write partition structure to disk

Disk /dev/sdb - 2000 GB / 1863 GiB - CHS 243201 255 63
     Partition               Start        End    Size in sectors
 P Linux Raid                    64    8386607    8386544 [E0469AA064B8:0]
 P Linux Raid               8388672    9437231    1048560 [E0469AA064B8:1]
>P Linux Raid               9437248 3906760519 3897323272 [x60:2]

(How can I rename the third partition so it is back to original name?)

Assembling the RAID partition

sudo mdadm --assemble -v /dev/md99 /dev/sdb3

 sudo mdadm --query --detail /dev/md99

/dev/md99:
        Version : 1.2
  Creation Time : Sun Jan  1 19:35:50 2017
     Raid Level : raid1
     Array Size : 1948661632 (1858.39 GiB 1995.43 GB)
  Used Dev Size : 1948661632 (1858.39 GiB 1995.43 GB)
   Raid Devices : 1
  Total Devices : 1
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Sun Jan  1 19:35:50 2017
          State : clean 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           Name : x60:99  (local to host x60)
           UUID : 1858b355:7c24531e:2fddde7f:10cf1e0b
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       19        0      active sync   /dev/sdb3

sudo mount -t btrfs -o ro /dev/md99 /mnt/nashd/

mount: wrong fs type, bad option, bad superblock on /dev/md99,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Any ideas?

Thank you.

 Tim

[FramerV]

Hi timnas,

I apologize but I think this is for phone support already. Seems to be complicated already given the things that occurred. Check if you still have support warranty via my.netgear.com; if none, you can get a per-incident support.

Regards,

[JennC]

Hello timnas,

We’d greatly appreciate hearing your feedback letting us know if the information we provided has helped resolve your issue or if you need further assistance. 

If your issue is now resolved, we encourage you to mark the appropriate reply as the “Accept as Solution” or post what resolved it and mark it as solution so others can be confident in benefiting from the solution. 
 
The Netgear community looks forward to hearing from you and being a helpful resource in the future!
 
Regards,

[timnas]

To be honest, I was expecting more something like

StephenB says: No worries buddy, your data are still there.
Just apt-get foo-barfs and mount a ext4 volume with offest 42.

Me : Dude, you're the guru among the gurus.It works like a charm.
Please accept my eternal gratitude. May I pay you with Beercoins?

Anyway, and at last, I was able to retrieve all my data from my 2 TB HDD just today.

I am now able to mount every partition:

• System (ext3 - 4GB)
• Restore? (can't remember - 512 MB)
• Data (ext4 - 1.8 TB)

But if I am now technically able to fix the booting issue of the NAS, I don't know what to start with.

I guess a serial console would help debugging the booting process, or a directly-connected display...

In last resort, I will buy a new HDD and proceed to a factory reset 😞

[StephenB]

---

@timnas wrote:

StephenB says: No worries buddy, your data are still there.
Just apt-get foo-barfs and mount a ext4 volume with offest 42.

Me : Dude, you're the guru among the gurus.It works like a charm.
Please accept my eternal gratitude. May I pay you with Beercoins?

---

Beercoins?  You didn't say that before 

Your situation looked delicate, I didn't want to offer advice that might backfire and make it worse.  FramerV's suggestion on paid support seemed appropriate to me.

[timnas]

---

@FramerV wrote:

I apologize but I think this is for phone support already. Seems to be complicated already given the things that occurred. Check if you still have support warranty via my.netgear.com; if none, you can get a per-incident support.

---

Thank you for you suggestion.

Since it is available only 90 days, support period had ended years ago for me (2012).

I'm not ready to pay for a phone support session, so I'd better go with the factory reset option.

I will know if it is a hardware or a software failure then.

[StephenB]

---

@timnas wrote:

---

I will know if it is a hardware or a software failure then.

---

True enough. 

What model is this?

[timnas]

Wow, I'm sorry this info is not shown, I'm pretty sure I had to select my Readynas model in the form to start this thread.

It is a Readynas Duo v2.

PS : yes I did:

Spoiler

Model (Recommended - Helps the community give the best answers)

[StephenB]

---

@timnas wrote:

Wow, I'm sorry this info is not shown, I'm pretty sure I had to select my Readynas model in the form to start this thread.

Which is difficult, because there are so many models. Anyway I was wondering if it was still covered by the hardware warranty, but unfortunately it isn't.

But I think you'll find that the hardware (including disks) are fine - usually what happens is that the power cut results in some file system corruption (often of the OS partition), which results in an unbootable system.  Based on posts here, I think the OS 6 NAS are less vulnerable to that particular problem.