https://nishikino-maki.com/archives/Extract-data-from-DSM.html
前言：
0.方法不一定适合硬件故障、数据误删等且不仅以上情况，量力而行，节哀顺变（喂）。
1.操作前请保证自己知道在做什么操作，以及知道DSM分区、文件系统、RAID相关知识。
2.以下仅保证个人这次数据拯救的可行性且作为事后记录。
3.本文主要基于当 Synology NAS 出现故障时，如何使用计算机恢复数据？。
“抱歉，您所指定的页面不存在”
先是这几天DSM的Web端频频挂掉，直接显示“抱歉，您所指定的页面不存在”。
不稳定的原因暂且不清楚。
反正我看硬盘的SMART、存储空间的健壮性以及CPU和内存的稳定度（在Windows下比如MEMTEST64）都没有出现异常，设备温度也相当稳定甚至最近的天气下连50℃都没有，那么只能归咎与黑盒一般的DSM了。
注意，这个时候切勿随便重启DSM，而是里面趁着SMB等服务还能使用尽快提取走所有数据。因为你的DSM设备已经不稳定了。
当然你也可以学我一样头铁觉得只是libsynopkg.so.1、libsynoshare.so.6和libsynostoragemgmt.so文件损坏。
那么可以考虑以下办法：
从官方的DSM_DS3617xs_15284.pat之类同型号同DSM版本的pat包（我这里是6.1.7的3617xs）的hda1.tgz/hda1/usr/lib下提取出来，7-zip就可以完成。
然后通过winscp连接到DSM，cp文件到相同目录（指/usr/lib)之下，记得chmod权限成0644。
chmod 644 /lib/libsynopkg.so.1
chmod 644 /lib/libsynoshare.so.6
chmod 644 /lib/libsynostoragemgmt.so
替换完以后sudo reboot。
理论上应该可以解决问题。（指我第二次遇上这个情况的时候）
但是！你很可能和我第一次遇上这个情况一样，并没有打开DSM的SSH，于是，你只能考虑保住数据的前提下触发迁移操作重装DSM系统。
注意，以下操作很可能丢失数据，成功率并不是100%。
注意，以下操作建议先关机，将第一块硬盘以外的硬盘全部拔出断电，保证不会被误操作影响到。
确认过情况以后进入PE，打开Diskgenius或者傲梅又或者能操作磁盘分区的软件，格式化第一个硬盘的第一个分区为同样的EXT4格式。（第一个2.4G EXT4分区是DSM系统分区，第二个2G LVM分区基本是套件和配置信息，第三个LVM分区是存储空间）。
然后重启系统，重新通过群晖助手或者find.synology.com又或者路由器设备列表找到DSM，重新执行迁移设备的DSM系统安装。
注意，是迁移，不是重新安装，不然会丢掉套件等配置信息。
确定系统可以恢复使用以后再把其余硬盘重新插入。
理论上应该可以解决问题。（指我第一次遇上这个情况的时候）
然而，还是无法修复以上的情况，只能重装了DSM，且发现存储空间全部不识别了！
注意，这个时候和数据误操作一样，冷静，切勿进行更多的操作。
在确定自己没有误删存储空间（指第三个分区）的情况下，这个情况仍然处于可控的范围。
在翻阅群晖的文档可以看到官方早已预见有这个问题——“硬盘在迁移到新的 NAS 后可能无法重新装载存储空间。”（见前言中“当 Synology NAS 出现故障时，如何使用计算机恢复数据？”）。那么，基本可以按照文档的方法处理，这里会插入一下个人的情况：
sudo -i
切换到root，当然不切也可以下面的命令前面都加sudo
apt-get update
apt-get install -y mdadm lvm2
mdadm -AsfR && vgchange -ay
重新组合存储空间，毕竟存储空间之类的LVM需要挂载
cat /proc/mdstat
获取当前存储空间的路径
1.并不一定要使用Ubuntu且不局限于提供的18.04版本，用自己习惯的Linux系统也并无不可，官方提供的下载链接的系统版本没有什么特别的。
当然这里还是基于当前的Ubuntu 20 LTS系统，毕竟我懒得打命令，Ubuntu一般用apt安装器，我就可以直接复制了。
2.如果和我一样使用默认单盘Basic模式且EXT4格式的存储空间，那么将会简单很多；但是如果是BTRFS格式的存储空间那么将复杂不少；如果是多盘RAID的话记得同一个存储空间RAID涉及到的硬盘都要一次全部挂载到Ubuntu/Linux里面。
如果是EXT4的话，基本上作为从盘链接硬盘重新启动Ubuntu以后基本已经是自动挂载上了EXT4的分区了，剩下的就是拷走文件即可，甚至可以开启SSH然后通过WinSCP直接把文件联机拷走。
如果是BTRFS的话很可能会提示Error等报错无法挂载系统，那么需要在官方文档的基础上继续安装btrfs-tools。但是这个软件包很可能会提示没有可用又或者已被废弃，反正我们Ubuntu不过是为了拯救数据安装的而已，直接执行——
sudo apt-get install btrfs*
安装所有和btrfs相关的工具。
然后再次尝试读取BTRFS分区，注意这里已经通过官方文档的cat /proc/mdstat命令可知当前设备是/dev/md4，且已经挂上另一块用于放置被拷出文件的盘（比如这里的TOSHIBA）——
btrfs restore /dev/md4 /media/user2/TOSHIBA/ -D
加-D是为了测试是否可以读取到文件，如果顺利的话可以看到比如Restoring /media/user2/TOSHIBA/@syno/storage/file1.7z之类的log。
再确认过文件以后就可以重新执行一次不带-D的命令正式从BTRFS分区导出数据了。
（当然我在写这里的时候甚至还在导出文件，只有30M/s的速度我甚至以为是跑在了USB 2.0的上，鬼知道什么情况了，能拷出文件总比不能好╮(╯▽╰)╭
注意，在导出数据过程中是没有进度条的，所以如果看着卡死的话确认一下硬盘读取灯之类的在闪烁就好了，在导出完毕以后才会提示Reached the end of the tree searching the directory。
最后，我大概是要迁移回到 Windows Server承载数据+Linux承载业务 的的复合环境了。
EOF