first commit
This commit is contained in:
CrazyJasonwell
@@ -0,0 +1,169 @@
|
||||
---
|
||||
title: 🐈日志<% tp.file.title %>
|
||||
date: <% tp.date.now("YYYY-MM-DD HH:mm:ss") %>
|
||||
tags:
|
||||
- dailynote
|
||||
rating: ⭐️
|
||||
excerpt:
|
||||
created: 2025-08-30T11:45
|
||||
updated: 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坏了，反正没有修复成功！
|
||||
后续要高度注意数据安全：
|
||||
1. 新增UPS，保证突然掉电硬盘不出问题
|
||||
2. 每周进行快照，7个快照循环，存储空间2每天一个快照dmesg | tail -20
|
||||
3. 重要数据使用飞牛和群晖的备份套件备份
|
||||
|
||||
这个方法居然成功了！估计恢复率有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
|
||||
```
|
||||
|
||||
|
||||
## 3 Tips
|
||||
|
||||
## 4 Questions
|
||||
|
||||
## 5 Thoughts
|
||||
|
||||
## 6 NextDo
|
||||
|
||||
|
||||
Reference in New Issue
Block a user