I need assistance safely recovering my Unraid server (Atlantis) using my existing drives before replacing another failing drive.

Current configuration:

• Unraid 7.2.x, dual parity with two 18 TB Seagate parity drives.

• Disk 1: 14 TB Seagate Exos (ZTM02968), previously missing but now detected after checking connections. Passed an extended SMART test with zero pending, reallocated, or uncorrectable sectors.

• Disk 4: 8 TB Seagate Archive SMR (Z840R2L9), disabled but physically detected. Has historical ATA errors and 5,005 CRC errors.

• Disk 10: 8 TB Seagate BarraCuda SMR (ZCT0R53D), active but has 16 pending sectors, 16 offline uncorrectable sectors, and severe I/O latency, often reaching 100% utilization.

Both Disk 1 and Disk 4 were already disabled by August 2024, and Unraid has been emulating their contents through dual parity. Disk 1's physical XFS filesystem UUID differs from the current emulated filesystem UUID.

Steps completed:

• Confirmed both parity drives are detected and Unraid reports zero array disk errors.

• Verified the emulated XFS filesystems mount cleanly.

• Backed up Unraid's configuration, Disk 1's appdata and 3D printing files, and part of Disk 4's appdata.

• Disabled Docker and both Mover schedules.

• Stopped the array cleanly and selected the original Disk 1 for rebuilding onto itself.

Current situation:

The array is STOPPED. Unraid displays "Replacement disk installed" and warns that starting will initiate a parity-sync and/or data rebuild, overwriting the physical Disk 1.

I want to restore normal operation using the existing disks, then replace Disk 10 with a larger CMR drive.

Questions:

1. Is it advisable to rebuild Disk 1 onto itself while Disk 4 remains disabled and Disk 10 has known media errors?

2. What is the safest sequence for recovering Disk 1 and Disk 4 without invalidating dual parity?

3. Should I preserve the original disks rather than rebuilding immediately?

4. What precautions should I take before eventually replacing Disk 10?

I have attached my latest diagnostics ZIP and would appreciate guidance before starting the rebuild.

atlantis-diagnostics-20261112-0615.zip

Your diagnostics show Unraid 7.3.4, not 7.2.x. That is fine, just so it's clear.

With two disks disabled on dual parity, you have no redundancy left. The emulated disk1 and disk4 depend on every other disk, including disk10, reading correctly.

Some good news about disk10. All of its logged read errors are at the same location. The 16 pending sectors are only two 4K physical sectors. The last error was about 1,000 power-on hours ago, and the current syslog has no read errors for it. So the damage looks small. With some luck, at worst, the rebuilt disks will have a few KB of wrong data at that one offset, if that area is in use.

Disk1 and disk4 both have a lot of UDMA CRC errors. Both are on the second LSI HBA, on the same cable as disk2 and disk3, which have none. CRC errors are a connection problem, not a disk problem, and the most likely reason both were disabled. The syslog also shows an onboard SATA link failing at boot, which is probably why disk1 was missing earlier.

To answer your questions:

1. Yes, rebuilding onto the same disks is fine. Their contents are from 2024, so they are not useful as a backup, and the different UUID on disk1 confirms this. I would rebuild disk1 and disk4 at the same time. Dual parity can do that, disk10 only has to be read once, and both parity levels are back when it finishes.

2. Suggested sequence:

- Keep Docker, VMs and the mover disabled. Make sure anything irreplaceable on disk1 and disk4 is backed up, because right now the emulated disks are the only copy.

- Power down and replace the cable that goes to disks 1 to 4 on the second HBA. Also check the power connections to disk1 and disk4.

- Run an extended SMART test on disk4. Its last test was a short one at about 38,000 hours, it now has over 73,000, and it has 10 reported uncorrectable errors. If the test fails, rebuild disk4 onto a new disk instead (up to 18TB).

- Rebuild both disks: stop the array, unassign disk1 and disk4, start the array, stop it, assign both disks again, then start the array. Optional: start in maintenance mode. This way nothing writes to the array during the rebuild.

- When it finishes post new diagnostics. I want to check whether disk10 had read errors during the rebuild.

3. There is no real value in keeping the old disks untouched. Their data is outdated. If you have spare disks and prefer to rebuild onto those, that works too.

4. For disk10, wait for the new diagnostics. Then replace it with a CMR disk no larger than your 18TB parity disks: stop the array, assign the new disk to disk10, and start the array to rebuild. You will have full redundancy again during that rebuild.

Once everything is fixed, set up notifications, so a disabled disk does not go unnoticed for that long again.

3 hours ago, Patrick S. said:

Both Disk 1 and Disk 4 were already disabled by August 2024

I hope you will be more diligent in the future.

3 hours ago, Patrick S. said:

Unraid displays "Replacement disk installed"

@JorgeB

Can he rebuild disk1 onto the original disk1 now that Unraid has already noticed disk1 has been replaced? If he replaces it with original disk1 will it still consider that a replacement, or will he have to start the array with disk1 not assigned so Unraid can "recognize" the replacement. Seems like either are possible scenarios based on how parity works and I have never tried it this way.

Unrelated, but all of your shares are configured to only write to the array, and not use any pool, though your appdata share does have some files on plex_cache.

Ideally, Docker/VM related shares - appdata, domains, system - should have all files on a pool with none on the array, so Docker/VM will perform better, and so array disks can spin down since these files are always open.

We can work on that after you get your array back to normal.

15 minutes ago, trurl said:

@JorgeB

Can he rebuild disk1 onto the original disk1 now that Unraid has already noticed disk1 has been replaced? If he replaces it with original disk1 will it still consider that a replacement, or will he have to start the array with disk1 not assigned so Unraid can "recognize" the replacement. Seems like either are possible scenarios based on how parity works and I have never tried it this way.

The description in the first post might imply that it already thinks original disk1 is the replacement. If nothing else was ever assigned there, and it was really just "missing", then it would be a replacement.

Unassigning disk1, starting array, stopping array, and reassinging it will always reset the assignment and rebuild. That's why I recommended doing that for both.

1 hour ago, trurl said:

The description in the first post might imply that it already thinks original disk1 is the replacement. If nothing else was ever assigned there, and it was really just "missing", then it would be a replacement.

To expand a little more, basically, if the disk is disabled (red x), user always needs the unassign/reassign flow. If it's invalid (orange triangle), which IIRC was not the case, it would rebuild at array start directly; but the unassign/reassign always works for rebuilding.