Nas542

VL4DST3R · March 5

Thanks, I will try what you suggested and report back.

VL4DST3R · March 6

https://community.zyxel.com/en/discussion/comment/62863#Comment_62863

Hey, sorry for taking a while to reply, I did as you suggested and got the following:
Note: the setup I had was drives 1-3 in a JBOD and drive 4 by itself, so I assume that's why the first command failed.

~ # mdadm -A /dev/md0 /dev/sd[abcd]3
mdadm: superblock on /dev/sdd3 doesn't match others - assembly aborted
~ # mdadm -A /dev/md0 /dev/sd[abc]3
mdadm: /dev/md0 has been started with 3 drives.
~ # mkdir -p /mnt/mountpoint
~ # mount /dev/md0 /mnt/mountpoint
mount: unknown filesystem type 'LVM2_member'

I've also ran dmesg and got the following log (Attached since it is very long)

dmesg log.txt

Mijzelf · March 6

So far the disks seem healthy. And your raid array contains a logical volume group, instead of a filesystem. To mount the internal filesystem execute

vgscan
vgchange -ay
mount /dev/dm-0 /mnt/mountpoint

Maybe /dev/dm-0 has to be /dev/dm-1 or /dev/dm-2. Don't know what is inside the volume group. lvdisplay might tell.

About sdd, you can assemble that the same way:

mdadm -A /dev/md1 /dev/sdd3

After which you can create a mountpoint and mount /dev/md1, unless it also contains a volume group, in which case you have to repeat the commands above. (And choose an even higher /dev/dm-#)

VL4DST3R · March 7

Update: Turns out the latest firmware update was INDEED the issue, and going back solved the issue. From what I understand update 13 will be pulled from the update servers so other people won't end up in the same situation as me and OP, but supposedly no other updates are planned to come.

Sadly, in my scrambling last night to get to a configuration that works, I used one of the 3 drives of my JBOD for the initialization procedure of the NAS, and thus it got formatted, leaving me with 2/3ds of a working JBOD. Can I do anything to access the data in this incomplete state?

Mijzelf · March 7

A tool like PhotoRec can recover files from bare metal without help of the filesystem, as long as they have a recognizable header, which also somehow tells which size the file has, and the file is not fragmented.

Drawback are that any metadata from the filesystem is not recovered. No path (including the filename itself) or timestamp.

Which disk is wiped? If it's not the first one, maybe a rebuilded with a block of zero's can be repaired using e2fsck. But I have no experience with such extreme damage.

VL4DST3R · March 7

The first one is indeed the one I lost, but I'm not sure it makes much difference, they all seem to be the same.

I have used Photorec but it gives all files generic names and ruins any folder structure. I'm interested in only a few particular files i have not yet backed up, not necessarily the entire thing, so keeping the folder structure was kinda important for me. Also tried testdisk but without much success - cant seem to get it to display anything. At the moment I'm trying my luck with DMDE on my windows machine but it is very slow to rebuild the FS for a 4tb drive.

Do you know any other tool that maintains folder structure?

Mijzelf · March 7

I'm not sure it makes much difference, they all seem to be the same.

It does. The JBOD array (in more common words linear array) is a virtual 12TB disk, from which the first 4TB is on the first disk, the second on the second disk, and the last on the 3rth disk.

So it is like you had a physical 12TB disk, containing a single partition with filesystem, from which you overwrote the first 33% with zero's.

Do you know any other tool that maintains folder structure?

No.

Nas542

All Replies

Categories

Consumer Product Help Center