ricreis394

It's supposed to appear something there, but it isn't. Also, the disk is repaired, but unraid can't detect it as a disk used before, it recognizes as a new disk into the array

I don't think we are in sync. Are these the steps you want me to do? - Disk isn't assigned - start array - click format ? That won't delete all my data?

If I don't assign, how do I format it? I'm confused...

At first there was 2 disks with problems, I fixed the one with the repair and rebuild. Right now I have data in this disk (recovered too) and I need to add the data to the array but I don't have sufficient free space to allocate that whole data unless I add the disk to the array. Basically, what's the best way to copy the data onto the array, assuming that I don't have enough free space right now. After the copy I'll add this disk to the array

You sure that it's okay to start the array with the disk in this state? I'm affraid Unraid will erase it's content

Sorry but I can't find the solution in the docs. Should I start the array with maintenance mode? I'm affraid of losing data... Need some guidance

I'm copying 2.8TB but I only have 700GB left on my array, can I still copy data. After the copy I'll add this disk into the array so the storage will increase. Right now the array tells `Device is missing (disabled), contents emulated`

Okay, I did the command with the -L and the result was good. I can now mount the disk via unassigned devices and I can find a lot of missing files in the array, that's good! I suspect the next step is to copy the contents into the array, right? Only then I can format the disk and add it back to the array to resolve a missing disk. Am I right?

Nice! Gives better result. Phase 1 - find and verify superblock... - block cache size set to 1506168 entries Phase 2 - using internal log - zero log... zero_log: head block 1778397 tail block 1778324 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Can I procced with the -L ?

This disk seems recovered. I'm attempting to recover the other disk (disk1) and I'm affraid that I have lose data. Right now I have missing data, I tried plugging in again the disk1, and tried to add to the array (without starting it), but the array recognizes it as a new disk (sad...), so I tried to mount it via unassigned devices, but gives me error `Device '/dev/sdd' failed to mount. Check the syslog for details.` Then I tried to do a `xfs_repair -v /dev/sdd` but it can't find the Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... ........................................................................................................................................................................... Does it mean I have lose all of that data? Diagnostics attached towernas-diagnostics-20231013-0850.zip

Now I'm trying to rebuild back the drive, following this guide: https://docs.unraid.net/unraid-os/manual/storage-management/#rebuilding-a-drive-onto-itself It'll take around 4 hours, let's see what is the result

Ok, did the command with the -L and this is the output Phase 1 - find and verify superblock... sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_icount 0, counted 10624 sb_ifree 0, counted 772 sb_fdblocks 732208911, counted 62708200 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 2 - agno = 1 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:538229) is ahead of log (1:2). Format log to cycle 4. done The disk continues disabled and unmountable but appears that I'm able to access it's files (?) Diagnostics attached towernas-diagnostics-20231012-2159.zip

attempted to do xfs_repair without -n and it returned this: Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... writing modified primary superblock sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. is it safe or is it the better option to run xfs_repair with -L parameter?

Do you mean disk2 (HUS724030ALS640_P8K4XPAW) ? That's the one which is plugged in and disabled. The disk1 isn't on the system atm disk2 is the one I want to recover data

Diagnostics in attachment Parity-check is still running (1h30 left to finish) towernas-diagnostics-20231012-1647.zip