To understand why this happened and how to safely assemble the array later, we must break down Synology's underlying storage architecture.
Synology DSM does not run raw Btrfs directly over physical drives. It uses a layered abstraction:
- Physical Disks $\rightarrow$ partitioned into LVM/MD RAID arrays (/dev/md2 typically holds user data).
- MD RAID 5 $\rightarrow$ provides block-level parity redundancy.
- LVM (Logical Volume Manager) $\rightarrow$ mapped over the MD RAID block device.
- Btrfs Filesystem $\rightarrow$ formatted on top of the LVM logical volume.
When Drive 3 was pulled, the array lost parity redundancy. When Drive 2 hit bad sectors at 40% rebuild, the md driver encountered unrecoverable read errors (URE) on the surviving drives, causing the array to drop offline to prevent silent data corruption.
Because Synology injects custom metadata into Btrfs and mdadm configuration, blindly running standard mdadm --assemble --force on Ubuntu might corrupt the superblock alignment or write back dirty RAID metadata.
Follow @kenj_3436 's advice on cloning Drive 2 first. Once cloned, you will assemble mdadm in read-only / overlay mode using loop devices so no write intent bitmaps or superblock flags are written back to the physical drives.