I forgot I was running an unbalanced gather move from other drives to /dev/sdl, after booting it said wrong disk, I did new config and started the array a couple times but it won't mount.

I've tried all the btfrs recovery commands I found but they all give;

does the array need to be off when attempting these? would it make any difference - in short, have I lost 6tb of data or is there a way I can get the drive mounted in the array again?

(Would Unbalanced have deleted the moved data since the operation hadn't finished yet, it uses rsync right?)

will it have removed each file after it was successfully transferred, or does Unbalanced wait until the whole operation finishes?

Edit: answered my own question - the source data is all gone :( at least it was just my /anime/ and I've still got all my TV/movies.

Thanks

Edited December 16, 2025Dec 16 by paradox.actual

1 hour ago, paradox.actual said:

I've tried all the btfrs recovery commands I found but they all give;

You need to run the command on the partition (/dev/sdl1), not the whole device, or for parity to remain valid, use the md device, in this case /dev/md8p1, but before trying any command, I recommend posting the diags after array start.

41 minutes ago, JorgeB said:

before trying any command, I recommend posting the diags after array start.

Start the array in Normal (not Maintenance) mode, then

Attach Diagnostics ZIP to your NEXT post in this thread.

The disk shows no partitions to target with the recovery command. Here's the diag;

orbitalhub-diagnostics-20251222-1550.zip

26 minutes ago, paradox.actual said:

The disk shows no partitions

Confirmed:

Dec 31 17:41:18 OrbitalHub emhttpd: online: ST16000DM001-3Y4103_ZXA0B6LY (sdl) 512 31251759104 => no partitions

Something else happened. If parity is valid, Unraid should be able to correctly recreate it. Unassign that disk, start the array, post new diags, leave the actual disk untouched for now.

Unfortunately I was in the middle of swapping the parity disk so no parity :(

Is it possible to recover the btrfs superblock or should I just wipe it and slap it back in the array?

You can try recreating the partition if it was using the Unraid standard starting sector, or the other common one. If it was a more custom layout, it would be harder.

With the array stopped, type sfdisk /dev/sdl then type 64 and hit enter; then hit CTRL + C to abort, and post that output.

Alright trying it now.

Get this when starting the array;

Edited December 22, 2025Dec 22 by paradox.actual

Try again but now with 2048 and post that output, no use in starting the array for now, we are still not creating the partition. Always abort with CTRL +C

Oh I've already had it started multiple times since this happened. It fails to mount and nothing interacts with the drive so I just left it until I could be bothered sorting it out.

It's OK to start it, I just meant it still won't work until something is actually done. There was no BTRS signature on sector 64, which is the Unraid default. Try 2048, which is a common starting sector form for many other OSes, I assume the disk was not new.

34 minutes ago, paradox.actual said:

Oh I've already had it started multiple times since this happened. It fails to mount and nothing interacts with the drive so I just left it until I could be bothered sorting it out.

There's also no btrfs signature on that sector; if it's not on sector 64 or 2048 it will be much harder to find, if not impossible. Do you know where that disk came from, i.e., where it was last partitioned?

Do you mean before I added it to the array? It was cleared and then added to the array as BTRFS along with the rest of it.

12 hours ago, paradox.actual said:

Do you mean before I added it to the array?

Yes.

Try this as well; it may help find the correct starting sector:

grep -a -b -o '_BHRfS_M' /dev/sdX | head -n 1

This should be done with the array stopped, replace X with the correct drive letter for disk8, and post any output from that command, if there's a btrfs signature there, it should show something after a few minutes.

Instead of grep, which may run OOM if the sector is not quickly found, use this instead:

dd if=/dev/sdX bs=16M status=progress 2>/dev/null | hexdump -C | grep '_BHRfS_M'

Thanks trying that now.

Is anything more going to happen or should I close it?

Nothing was happening so closed and started array again.

Edited December 26, 2025Dec 26 by paradox.actual

That shows the location of the btrfs superblock and its backup, and we can calculate the partition starting sector from that, which, according to those, is 411,648, so it's a starting sector that is very non-standard and not guessable.

To confirm that is the actual file system before recreating the partition, do this:

losetup -f --show -o 210763776 /dev/sdl

Then post output from btrfs fi show

btrfs fi show is not detecting the filesystem; make sure /dev/sdl is still the correct disk, it can change with a reboot, if yes, confirm with a mount attempt:

mkdir /x

mount -v /dev/loop3 /x

If that fails, post the output from:

btrfs-select-super -s 1 /dev/loop3

same.

Filesystem mounted, now post the output from:

btrfs fi usage -T /x

Also browse /x and see if the contents are what you expect.

looks like everything is there, so how do we go about fix it so the array mounts it properly?

Do I move the data from the mounted /x to a drive on the array and wipe it and re-add it?