sadan9

@leang521 群晖的 SHR 本质上是 mdadm （就是你前面看到的/dev/mdX ） + lvm （用来组装+划分空间）
现在主要是想办法把/dev/md3 恢复出来。

你手上还有别的 linux 机器不？试试把 sata4 ，sata5 （即现在 raid6 中未使用的 2 块盘）拿到别的机器上：
mdadm --assemble --scan
看看能不能扫到阵列。

@cr3bit
看有没有写入数据了。除了他自己主动写入，剩下的就看群晖自己了。我看他有 2 个 volume ，如果套件都在另外一个上面应该还好......

@leang521
理论上只有 1 ，2 在线的情况下，读取出的数据应该也是正确的。但你这样读取出来的错误的数据，我只能猜测是之前数据就已经不正确了。或者在重建过程中群晖做了别的什么操作导致 RAID6 上 4 块盘的状态并不一致。

从给的数据来看，volume_2 （ 7T 的卷）由 stat1 ，2 ，4 ，5 盘的第 3 个分区组成。
整个操作过程中尝试直接重新使用 4 块盘重新组建 raid ，但系统只使用了 2 块（ 1 ，2 ）。另外两块盘处于 remove 状态。

看了一下阵列并未启用 Bitmap （群晖默认应该是不启用的），也就是现在即便现在你把盘插回去重建，也只会使用 1 ，2 的数据来全量重建 4 ，5 。这种情况下 4 ，5 得到的数据和你现在直接从 1 ，2 上读取的应该是一样由问题的。

还有一种思路就是把 4 ，5 盘单独尝试挂载一下阵列，看看能不能得到正确的数据。


另外不考虑数据问题的话，可以尝试使用以下指令吧 4 ，5 重新加回阵列。
但再次强调，这么做是以 1 ，2 盘的数据重新计算并覆盖 4 ，5 。

mdadm --re-add /dev/md3 /dev/sata4p3
#检查 raid 状态，等待重建完成
mdadm -D /dev/md3

mdadm --re-add /dev/md3 /dev/sata5p3
#检查 raid 状态，等待重建完成
mdadm -D /dev/md3

@bclerdx
电信 2G+联通 1G > 局域网口 2.5G 。

提供一下个人的情况，刚刚把 J4125 换成 N100 。
换之前是电信 1000M+联通 1000M 接入。4 口 2.5G 能满足需求。
但电信近期升级到 2000M ，2.5G 的局域网口就成瓶颈了。
被迫换成 N100 ，3 个 2.5G+ 2 个 10G SFP+。

上海电信表示观测到同样的现象。
开着 BT 玩亚服的 Diablo 2 经常被中断 5 分钟左右。

@cpstar 桥接是 2 层，NAT 是 3 层。完全是 2 个问题。除非你的业务场景涉及同一个段内的广播，不然直接走 3 层路由。
4 楼是正确解法，如果不想在 zt 的 web 上设置静态路由，甚至可以考虑使用 RIP 或者 OSPF 。

提醒一句，自用和给别人用在性质上不一样。