trurl

Disk2 and what other disk?

Do you have a backup plan? A single copy of your important and irreplaceable data isn't good enough no matter how that data is stored.

Post new Diagnostics

Maybe something else was done earlier and you just hadn't noticed until you had this other problem. Since repair is done in maintenance mode it is not possible for anything to access the filesystems of other drives. Only the filesystem being repaired is accessed.

Start in normal not maintenance mode

Me neither. Repair would not be the cause of your loss. It especially can't lose data on other drives. Did you format anything?

My guess is disk3 was disabled before disk1 failed. Question is, for how long? Can disk3 (or a clone) be expected to emulate disk1 well enough to allow any disk1 data to be recovered. I know you said Synology data is gone, but do you have other backups? Are you already reusing the Synology disks?

lost+found would be a new user share. Why do you think any data was lost?

I don't see any lost+found in your diagnostics. Are you using USB2 port (recommended) for your boot flash?

Click the FIX button

Did you also disable Docker and VM Manager in Settings?

Waiting for the result of this test.

Check filesystem again from the webUI and post the output

Setup Notifications to alert you immediately by email or other agent as soon as a problem is detected. See if scrub will fix cache.

Does your Synology still have all its disks and files?

Are you sure disk1 is truly dead? I don't see it in diagnostics. Since you have single parity and disk3 is disabled, you can't start the array without disk1. SMART for disk3 doesn't look so good. I wonder if you have been ignoring warnings for disk3 and maybe disk1. What is the Unassigned Device 20TB sdd? I guess it can't have been in the array since parity is only 18TB. Too large to use to replace either of the failing disks. Parity swap can't be considered with multiple disks failed. Do you have any spare disks you might use to try to recover anything? It will be complicated but there are some possible approaches. You would need disks at least as large as the failed disks but no larger than parity. See if you can get disk1 to show up again and post new diagnostics.

You should remove this deprecated plugin compose.manager.plg - 2025.11.01 (Deprecated) (Up to date) Also, what about your user scripts?

Unrelated, but you have a share configured to be on cache pool only, another configured to be on plex pool only. But they have files on the array or other pool. And another share not configured to use cache, but has files on cache. Mover won't move these because there is no Mover action, because there is no Secondary. d-------s shareUseCache="only" # Share exists on cache, disk1 m---a shareUseCache="no" # Share exists on disk1, disk2, disk3, cache p-------e shareUseCache="only" # Share exists on plex, disk1, cache

You seem to have a plugin related to USB that is unknown or too old to be updated. Remove that plugin. libvirt.hotplug.usb.plg - 2025.12.03 (Unknown to Community Applications)

Your system share is on the array. Ideally, Docker/VM shares - appdata, domains, system - should have all files on cache or other pool with nothing on the array, so Docker/VM will perform better, and so array disks can spin down since these files are always open. Arguably, system is the most important share to have off the array, since its files are always open if Docker or VM Manager is enabled, even if no containers or VMs are running. In fact, you have system and domains both configured to be moved to the array. Nothing can move open files so you will have to disable Docker and VM Manager in Settings before these shares can be moved. None of this should be the cause of your other problems.

For future reference, you should always repair the filesystem BEFORE rebuilding.

Reboot and post new diagnostics with the array started in normal (not maintenance) mode.

Not clear enough for anybody to follow those instructions. Primary:cache; Secondary:array; Mover action:array->cache Might be a good idea to post diagnostics so we can make sure that will go well.

Is that the final count, or is it still running and increasing? Seems more like parity was invalid to begin with.

Why do you want to do this? What is your plan for your new configuration?