8.9 KiB
title, date, tags, rating, excerpt, created, updated
| title | date | tags | rating | excerpt | created | updated | |
|---|---|---|---|---|---|---|---|
| 🐈日志<% tp.file.title %> | <% tp.date.now("YYYY-MM-DD HH:mm:ss") %> |
|
⭐️ | 2025-08-30T11:45 | 2025-10-24T19:29 |
1 TODO
- 多喝水，避免久坐不动
- 恢复东玺门fn
2 Tracking
- 不小心的发现
Joyofn：磁盘不能挂载，刚才试了一下，居然可以只读挂载，需要命令行，记录如下： 首先要找出未挂载的设备： lsblk -fp
mount -t btrfs -o ro,usebackuproot,rescue=all /dev/mapper/trim_8fb31b0c_0d86_4f2a_b166_c37adf4f139a-0 /vol2 成功地只读挂载了！ 昨天交了学费300元！不是钱多少的问题，是自己学艺不精！ 罗工的方法不能讲不正确，只是说能恢复数据，但是要原样恢复linux数据还是不太完美，权限什么都没有，复制到Windows的NTFS下，各种复制文件中的坑很多。
采用了飞牛自带的备份套件，将存储空间2的docker复制到/vol4/1000/USBD1/Temp1下 （很快不到2小时） https://club.fnnas.com/forum.php?mod=viewthread&tid=47765
SSH登录，使用命令：rsync -av /vol2 /vol4/1000/Temp 将存储空间2 全部复制到 /vol4/1000/Temp 期间报错：
rsync: [sender] readlink_stat("/vol2/1000/docker/emby/xiaoya/每日更新/电视剧/美剧/星际之门：SG-1 (1997)/Season 10") failed: Input/output error (5)
rsync: [sender] readlink_stat("/vol2/1000/docker/emby/xiaoya/每日更新/电视剧/美剧/星际之门：SG-1 (1997)/Season 2") failed: Input/output error (5)
rsync: [sender] readlink_stat("/vol2/1000/docker/emby/xiaoya/每日更新/电视剧/美剧/星际之门：SG-1 (1997)/Season 3") failed: Input/output error (5)
rsync: [sender] opendir "/vol2/1000/docker/emby/xiaoya/每日更新/电视剧/美剧/星际之门：SG-1 (1997)/Season 1" failed: Input/output error (5)
ERROR: vol2/docker/overlay2/625f4640bcbdc24a2ab110c4caa35aac43ba6d3310884161d7b08884f8ded3d5/diff/var/www/onlyoffice/documentserver/web-apps/apps/spreadsheeteditor/main/resources/help/en/Functions/improduct.htm.gz failed verification -- update discarded.
ERROR: vol2/docker/overlay2/625f4640bcbdc24a2ab110c4caa35aac43ba6d3310884161d7b08884f8ded3d5/diff/var/www/onlyoffice/documentserver/web-apps/apps/spreadsheeteditor/main/resources/help/en/Functions/lognormdist.htm.gz failed verification -- update discarded.
rsync: [sender]
readlink_stat("/vol2/docker/overlay2/fb572fbda42a59632346b93a9bb2c6f42a92acfe67d1812a8e609c0235bc990f/diff/tmp/.org.chromium.Chromium.tAYquR") failed: Input/output error (5)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.2.7]
包含了所有的属性信息，最佳命令： nohup rsync -avz /source/path user@remote:/destination/path > rsync.log 2>&1 & tail -f rsync.log https://www.ruanyifeng.com/blog/2020/08/rsync.html
[!hint] Tips： 只要磁盘报错，只读状态的时候，马上开始进行备份，不要尝试重启恢复，永远是备份优先！然后才是根据情况制定恢复策略！
恢复难度在于： 我的应用安装在存储空间2，数据也在存储空间2，正确的方法：应用安装到存储空间，数据在存储空间2，但是谁又能保证存储空间1不出问题，每次都是存储空间2出问题，就是在写盘的时候掉电了。。。
关于rsync参数z，刚才试了一下，文件名尾巴都带了什么几个字母，估计是压缩后的文件，不能使用cp命令。
将一张磁盘使用磁盘盒接入到fn上，然后创建存储空间2，将该盘格式化成btrfs磁盘，作为存储空间2使用
使用rsync命令将之前保存在/vol4/1000/Temp/vol2中的文件，复制到/vol2上 逐步使用： rsync -av /vol4/1000/Temp/vol2/1000/docker /vol2/1000/ & rsync -av /vol4/1000/Temp/vol2/1000/downloads /vol2/1000 rsync -av /vol4/1000/Temp/vol2/1000/Photos /vol2/1000
rsync -av /vol4/1000/Temp/vol2/@appcenter /vol2 rsync -av /vol4/1000/Temp/vol2/@appconf /vol2 rsync -av /vol4/1000/Temp/vol2/@apphome /vol2 rsync -av /vol4/1000/Temp/vol2/@appdata /vol2 rsync -av /vol4/1000/Temp/vol2/@appmeta /vol2 rsync -av /vol4/1000/Temp/vol2/@appshare /vol2 rsync -av /vol4/1000/Temp/vol2/@apptemp /vol2 rsync -av /vol4/1000/Temp/vol2/docker /vol2 rsync -av /vol4/1000/Temp/vol2/@sysappmeta /vol2
rsync -av /vol4/1000/Temp/vol2/appcenter-downloads /vol2 rsync -av /vol4/1000/Temp/vol2/.cache.trim-sysrestore /vol2 rsync -av /vol4/1000/Temp/vol2/mediasrv.transcode /vol2
注意不能使用-avz z表示压缩复制。
不小心的发现，改进了恢复方式： 挂载到存储空间，使用rsync复制/vol2到本机的其他存储空间目录，rysnc -av 。。。 root@JoyoFn:/vol4/1000/Temp/vol2# rsync -av ./1000/docker /vol2/1000 & 将另一张盘接入fn中，创建存储空间、格式化，然后再使用rsync命令复制到这张新盘中，使用a参数就是带了原来的所有属性。 由于btrfs文件系统问题，使用rsync备份时会报很多错误，只能最最大的可能备份和恢复！ 在完成备份后，使用btrfs check --repair命令，基本上没有什么效果，网上也介绍了方法，都不成功，btrfs坏了，反正没有修复成功！ 后续要高度注意数据安全：
- 新增UPS，保证突然掉电硬盘不出问题
- 每周进行快照，7个快照循环，存储空间2每天一个快照dmesg | tail -20
- 重要数据使用飞牛和群晖的备份套件备份
这个方法居然成功了！估计恢复率有90%+！✅👍🏻真心要给自己一个点赞！功夫不负有心人！ 估计由于一些btrfs中文件问题，造成部分容器运行报错，待观察！ 重点是：onlyoffice、emby、chromium等之前rsync时有错误提示！ 注意：/vol2/1001这个目录不能mkdir，估计是系统内核管理的
至少后续不会为btrfs文件系统的问题而过于无助！
罗工的ufs方法只能说是一种数据恢复的最后的手段，我的方法就是如何减少损失的方式实现应用级的恢复！
【后续】 刚才关了一次fn，然后开机，发现存储空间2，又是挂不上，很可能是关机前docker运行尚未结束，造成btrfs文件的混乱，看来又要再恢复一次了。。。 用我这个方式，不用开机拿出硬盘，先只读挂载，然后rsync，创建存储空间2，格式化硬盘，再rsync恢复备份的数据。 只能说btrfs真的脆弱！
做了一个脚本recovery-space2.sh，放在/root目录 ./recovery-space2.sh &
rsync -av /vol4/1000/Temp/vol2/1000/docker /vol2/1000
rsync -av /vol4/1000/Temp/vol2/1000/downloads /vol2/1000
rsync -av /vol4/1000/Temp/vol2/1000/Photos /vol2/1000
rsync -av /vol4/1000/Temp/vol2/@appcenter /vol2
rsync -av /vol4/1000/Temp/vol2/@appconf /vol2
rsync -av /vol4/1000/Temp/vol2/@apphome /vol2
rsync -av /vol4/1000/Temp/vol2/@appdata /vol2
rsync -av /vol4/1000/Temp/vol2/@appmeta /vol2
rsync -av /vol4/1000/Temp/vol2/@appshare /vol2
rsync -av /vol4/1000/Temp/vol2/@apptemp /vol2
rsync -av /vol4/1000/Temp/vol2/docker /vol2
rsync -av /vol4/1000/Temp/vol2/@sysappmeta /vol2
rsync -av /vol4/1000/Temp/vol2/appcenter-downloads /vol2
rsync -av /vol4/1000/Temp/vol2/.cache.trim-sysrestore /vol2
rsync -av /vol4/1000/Temp/vol2/mediasrv.transcode /vol2
做了一个快照，不知道是否能还原，下次试试！ 【2026.5.30】 晚上回家看到数据已拷贝完成，不敢去运行docker，从内存较低来看，应该docker还没有正常运行起来，等了一段时间，重启系统后回到界面，发现又提示存储空间2只读了！再也忍不住心中的愤怒，决定该用ext4文件系统，有一点小疏忽，应该去看一看快照是否可以还原！问题是这个存储空间只读或者对应的磁盘不能挂载，还能使用快照吗?
于是使用上面的方法和脚本再一次恢复了存储空间2，虽然不能做快照了，但是可以设计一个存储空间2的备份方式，确保docker数据备份和完整。 使用ext4文件系统发现同样的文件，现在占用是393G，原来是260G，大概有这样的差异，但是现在不用担心每次重启系统会担心存储空间又会“只读"了。😀
- btrfs
btrfs check /dev/mapper/trim_8fb31b0c_0d86_4f2a_b166_c37adf4f139a-0
而不是：btrfs check /dev/sdaX...
btrfs check --repair /dev/mapper/trim_8fb31b0c_0d86_4f2a_b166_c37adf4f139a-0 btrfsck --repair /dev/mapper/trim_8fb31b0c_0d86_4f2a_b166_c37adf4f139a-0
不成功！
parent transid verify failed on 136952725504 wanted 1134278 found 1133850 parent transid verify failed on 136952725504 wanted 1134278 found 1133850
parent transid verify failed on 136952725504 wanted 1134278 found 1133850
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=177732780032 item=183 parent level=1 child bytenr=136952725504 child level=1
ERROR: failed to repair root items: Input/output error