Help needed with replacing a faulty drive/undoing new config

[lukemattle]

One of my drives (disk1) showed some SMART warnings so I returned it and got sent a new one. When I plugged the new one in, despite it being exactly same model of drive, it said the replacement disk was too small. After some poking around on the forums I saw someone suggesting to use "New Config" to fix this (I created a New Config preserving all current assignments). However, after doing this, it says that all existing data on my parity drive will be overwritten when I start the array and I don't want that to be overwritten as I'll lose all my data.

I haven't done anything after creating a New Config as I don't want to lose anything. Can anyone help me please?

tower-diagnostics-20240619-1620.zip

[JorgeB]

New config cannot be used to replace a disk, it warns exactly about that.

 

Is old disk1 still connected? If yes, which one is it?

 

 

[lukemattle]

Unfortunately, I do not have the old disk1 as it had to be returned before I recieved the new drive

 

EDIT: I know I've been stupid by making a new config but is there any way at all to get the data back?

Edited June 19 by lukemattle
add line

[lukemattle]

I found a file called disk.old in my boot device under /boot/config, would this be of any use?

[JorgeB]

You can try this, but it will only work if parity is still valid:

 

-Assuming the array is still as the screenshot above, after the new config
-Check all assignments and assign any missing disk(s) if needed, including the new disk1, replacement disk should be same size or larger than the old one
-IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked)
-Stop array
-Unassign disk1
-Start array (in normal mode now) and post new diags.

[lukemattle]

I believe my parity is still valid but the thing that worries me is that when I tried to replace disk1 without the new config, it said that the replacement disk was too small despite it being the same model of WD Green 6TB. Should I still proceed with your instructions?

[JorgeB]

If it's the same size yes, there could have been a partition staring sector difference.

[lukemattle]

Here are the diagnostics after completing the steps above:tower-diagnostics-20240620-0917.zip

[lukemattle]

After looking through my share it looks like most of my files are gone. Do they still exist on the parity drive?

[JorgeB]

Jun 20 01:16:59 Tower kernel: mount: attempt to access beyond end of device
Jun 20 01:16:59 Tower kernel: md1p1: rw=4096, sector=11721045063, nr_sectors = 1 limit=11720979536
Jun 20 01:16:59 Tower kernel: XFS (md1p1): last sector read failed

 

Looks like that disk really is smaller, post the output of:

 

fdisk -l /dev/sdc

and

fdisk -l /dev/sdd

 

[lukemattle]

[JorgeB]

So as you can see by the number of sectors, the disk is actually smaller, so it won't do, was this disk shucked? In any case you will need a different 6TB disk.

[lukemattle]

So if I buy a different 6TB disk (or larger) will I get my data back?

[JorgeB]

If parity is valid it should work, but cannot be larger than 6TB, that would require a parity swap, and for that you would need a place older disk, like the old one.

[lukemattle]

Would you explain to be what exactly I need to do to get my data back please? Also, why does all my data not appear when I unassign disk 1, as the parity should be valid with the parity drive (sdc) and disk 2 (sde), nothing should have been wiped. Thanks for all your help so far

[JorgeB]

26 minutes ago, lukemattle said:

Would you explain to be what exactly I need to do to get my data back please?

A new 6TB disk, assuming parity is valid

 

26 minutes ago, lukemattle said:

Also, why does all my data not appear when I unassign disk 1, as the parity should be valid with the parity drive (sdc) and disk 2 (sde),

Because current disk1 is smaller than the previous disk, I though you've been over all this.

[lukemattle]

Quote

A new 6TB disk, assuming parity is valid

Don't suppose you know if an HGST HUS726060ALE614 6TB would be the same size/bigger than my old WD? I can't find the exact size in bytes anywhere and that is the only 6TB drive I can pick up for a reasonable price.

[lukemattle]

I just had a power cut and when the power came back on, it started the array with disk1 assigned to the new WD drive (which unraid said was too small before the new config) and is now doing a data rebuild. Should I let it continue?

[JorgeB]

17 minutes ago, lukemattle said:

Don't suppose you know if an HGST HUS726060ALE614 6TB would be the same size/bigger than my old WD?

All 6TB disks should be the same size, disk that come from enclosures can sometimes be smaller.

 

3 minutes ago, lukemattle said:

Should I let it continue?

Assuming the disk is still unmountable you can cancel.

[lukemattle]

I believe it has mounted. Here are the diagnosticstower-diagnostics-20240620-1243.zip

[itimpi]

According to the diagnostics it looks like you ran a format (thus wiping the data from the emulated drive)?

[lukemattle]

What does it say I ran a format on? All that happened to my knowledge is that my power went out and when it came back on, it was doing a data rebuild. Earlier I mounted the drive to unassigned devices to see if it had anything on it, would that have formatted it?

[JorgeB]

Jun 20 04:32:47 Tower emhttpd: creating volume: disk1 (xfs)
Jun 20 04:32:47 Tower emhttpd: shcmd (64108): /sbin/wipefs -af /dev/md1p1

 

Disk was formatted, so only option now would be to use something like UFS explorer, it may or not recover some data.

[lukemattle]

Crap. Can't believe I had a power cut at the worst time. Luckily I have backups of anything that I cared about. Thanks for your help.

[JorgeB]

Format is not related to the power cut, someone must have clicked the format button, also the syslog covers almost 24H uptime, including the new config, not sure how there could have been a power cut, since the syslog starts over after every boot.