282 lines
11 KiB
Markdown
282 lines
11 KiB
Markdown
# Postgresql
|
||
|
||
- 进入postgresql
|
||
docker ps | grep postgresql
|
||
|
||
docker exec -it container_id bash
|
||
|
||
psql -U moviepilot
|
||
|
||
|
||
# Syncthing
|
||
|
||
Syncthing遇到权限问题，解决办法：
|
||
https://zhuanlan.zhihu.com/p/29836885447
|
||
https://www.orcy.net.cn/1636.html
|
||
|
||
# airconnect
|
||
|
||
```
|
||
services:
|
||
airconnect:
|
||
network_mode: host
|
||
image: 1activegeek/airconnect
|
||
```
|
||
|
||
群晖上也有airconnect套件
|
||
原理：提供airserver，类似airserver
|
||
安装airconnect，就是一台airplay server，使用iPhone或者支持airplay的客户端在内网就能找到这些设备播放！
|
||
https://github.com/philippe44/AirConnect
|
||
https://gitcode.com/gh_mirrors/ai/AirConnect
|
||
https://post.smzdm.com/p/awovpkgm/
|
||
https://github.com/eizedev/AirConnect-Synology
|
||
https://hin.cool/posts/airconnect.html
|
||
https://sspai.com/post/65136
|
||
|
||
|
||
|
||
# Openlist
|
||
|
||
- 飞牛权限
|
||
https://club.fnnas.com/forum.php?mod=viewthread&tid=34775
|
||
|
||
|
||
# Openwrt
|
||
|
||
设置桥接方式：
|
||
|
||
删除或者停止WAN接口
|
||
进入LAN设置，选静态地址->br-lan
|
||
填写IPV4地址
|
||
进入DHCP，勾选忽略此接口
|
||
|
||
将上游网线插入三个LAN之一，不能插入WAN（靠近电源）口
|
||
无线接口只要选中网络为LAN即可，保存应用，重启路由器OK！
|
||
|
||
|
||
# 网络相关
|
||
## 本地IP
|
||
|
||
curl https://myip.ipip.net
|
||
https://ddns.oray.com/checkip, https://ip.3322.net, https://4.ipw.cn, https://v4.yinghualuo.cn/bejson
|
||
|
||
## iftop
|
||
|
||
https://blog.meow.page/archives/find-which-process-eat-my-bandwidth-on-synology/
|
||
|
||
[[`iftop` 是一个实时网络流量监控工具，类似 `top`]]
|
||
|
||
|
||
|
||
# 数据同步迁移
|
||
|
||
## rsync
|
||
群晖（Synology）与飞牛（FeiNiu，国产私有云NAS）之间**原生不支持双向实时同步**，因二者分属不同生态，无官方互通协议（如Synology的Synology Drive Server与飞牛的“飞牛云”未开放标准WebDAV/Resilio Sync/Nextcloud兼容接口）。用户常误以为启用双方的“文件同步”功能即可自动双向实时同步，实则面临：① 协议不兼容导致连接失败；② 即便通过WebDAV挂载实现单向同步，也无法触发删除、重命名等元数据的双向传播；③ 实时性依赖轮询（如每5–30分钟），非真正inotify级实时；④ 权限、硬链接、扩展属性（xattr）及AFP/SMB特殊语义丢失。此外，跨平台ACL映射缺失易引发权限混乱，而飞牛对SMB3多通道或群晖Btrfs快照的兼容性亦未验证。若强行用rsync+inotify或第三方工具（如FreeFileSync+WatchService），将牺牲原子性、断点续传与冲突自动处理能力——这正是双向实时同步落地的最大障碍。
|
||
|
||
- 飞牛数据备份和恢复
|
||
停止docker服务
|
||
卸载存储2
|
||
lsblk -fp 查看未挂载设备ID
|
||
只读挂载到存储空间2
|
||
mount -t btrfs -o ro,usebackuproot,rescue=all /dev/mapper/trim_7db5153a_b22d_43bc_a516_5041e3e504f7-0 /vol2
|
||
|
||
如果是ext4 文件系统：
|
||
mount -t ext4 -o ro /dev/mapper/trim_7db5153a_b22d_43bc_a516_5041e3e504f7-0 /vol2
|
||
|
||
|
||
将磁盘盒接入飞牛，第一次清除磁盘，格式化成btrfs，
|
||
nohup rsync -avz /source/path user@remote:/destination/path > rsync.log 2>&1 &
|
||
tail -f rsync.log
|
||
|
||
简化：
|
||
rsync -av --numeric-ids --delete /vol2 /vol5 &
|
||
同一个服务器可以简化成：
|
||
rsync -av --delete /vol2 /vol5 &
|
||
|
||
报错：
|
||
rsync: [receiver] mkstemp failed: Operation not permitted (1)
|
||
|
||
chmod -R 700 /vol5
|
||
mkdir -p /vol5/vol2
|
||
chmod -R 755 /vol5/vol2
|
||
rsync -av /vol2 /vol5
|
||
|
||
由于上述问题，手工在飞牛界面卸载了存储空间5，怀疑是存储空间5挂载方式问题，手工输入同样的命令，rsync没有报上述错误，然后手动将外接磁盘挂载到：
|
||
当然先要准备：
|
||
mkdir -p /vol4/DataBackup
|
||
chmod -R 755 /vol4/DataBackup
|
||
|
||
mount -t btrfs -o rw /dev/mapper/trim_9bdcaad4_ea98_4d60_8602_7999eb18868c-0 /vol4/DataBackup
|
||
|
||
开始打算挂载到/vol5结果不成功，提示没有vol5这个存储空间，在飞牛界面去创建存储空间5，报没有可用的磁盘，只好采用上述办法，命令行少了：usebackuproot,rescue=all
|
||
|
||
|
||
mount -t btrfs -o rw /dev/mapper/trim_9bdcaad4_ea98_4d60_8602_7999eb18868c-0 /vol4/DataBackup ✅
|
||
|
||
rsync -av /vol2/1000/Photos /vol4/DataBackup
|
||
|
||
测试OK！
|
||
清理/vol4/DataBackup
|
||
|
||
|
||
rsync -av /vol2 /vol4/DataBackup &
|
||
|
||
按单个目录来复制：
|
||
rsync -av /vol2/@appconf /vol4/DataBackup/vol2
|
||
|
||
还是老问题！
|
||
|
||
？？？
|
||
|
||
为什么下面的命令可以执行？
|
||
rsync -av /vol2 /vol3/1000/20260601 --exclude={‘all.mp4’,’config.mp4’,’115.mp4’,’pikpak.mp4’}
|
||
|
||
|
||
而
|
||
rsync -av /vol2 /vol5/
|
||
rsync -av /vol2 /vol4/DataBackup
|
||
|
||
/DataBackup是mount挂载的另一个盘，= /vol5
|
||
/vol5和/vol3、/vol4 本质上都是外接USB盘，前者不行，后2者可以？
|
||
|
||
网上很多这种提问，是目标目录或者目标服务器的文件系统权限不一致，可是：
|
||
我现在的这种同步或者备份方式，都是为了保存原来的数据和权限，-a ，而且为避免跨服务器权限问题，在同一台服务器上使用不同的磁盘备份数据。
|
||
|
||
rsync -av /vol2/@appconf /vol4/DataBackup/vol2 ❌
|
||
rsync -av /vol2/@appconf /vol4/1000/DataBackup ✅
|
||
|
||
说明和分析：
|
||
上面 /vol2/@appconf是root:root 复制到/vol4/DataBackup root:root权限
|
||
下面 /vol2/@appconf是root:root 复制到/vol4/1000DataBackup fnAdmin:root权限
|
||
|
||
使用的root用户操作，将root文件复制到root权限不行，
|
||
将root权限复制到fnAdmin权限就可以？
|
||
就是说root目标目录下不能保存非root权限的文件？ACL限制？！
|
||
|
||
|
||
解决方案：
|
||
|
||
- 重启系统后先挂载新磁盘，目标盘为存储空间2，btrfs
|
||
- 再挂载原先的磁盘（原来的存储空间2），挂载后变成存储空间5
|
||
- 以root身份SSH到fn，创建一个脚本/root/rsync-5-2.sh
|
||
|
||
```
|
||
#rsync -av /vol4/1000/Temp/vol2/1000/Photos /vol2/1000 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/@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
|
||
```
|
||
|
||
|
||
先手工使用
|
||
rsync -av /vol4/1000/Temp/vol2/1000/Photos /vol2/1000
|
||
rsync -av /vol4/1000/Temp/vol2/@apptemp /vol2
|
||
测试通过！
|
||
没有报上述错误的原因是什么呢：
|
||
没有想明白。。。
|
||
至少这种方式rync在创建mkstemp没有权限问题了！
|
||
|
||
然后开始运行脚本！
|
||
这种方式也是直接替换某个飞牛数据盘的方法：
|
||
先卸载需要替换的磁盘，使用磁盘盒接入新盘
|
||
重启系统
|
||
挂载新盘为存储空间2，在挂载原来的磁盘为存储空间5
|
||
cd /root
|
||
./rsync-5-2.sh &
|
||
注意有2个目录先期做了测试，注释了！
|
||
|
||
当然还是先做好备份再用这个方法保险！
|
||
|
||
|
||
【20260603】
|
||
昨天用256G SSD替代了原来的128G SSD
|
||
方法：
|
||
先将原来的SSD做了一个全盘克隆 Windows下DG
|
||
然后还是用DG将SSD克隆到256G的SSD上，按扇区原样，主要是因为有引导分区，保持原来的分区1大小，系统分区，大约54G
|
||
先保存存储空间，尽管没有什么数据，
|
||
删除分区2，trim分区，就是存储空间1
|
||
lsblk
|
||
parted /dev/sdX
|
||
rm 2
|
||
q
|
||
重启系统，进入存储空间管理，添加存储空间。。。选上面的分区->basic->格式化
|
||
|
||
cd /vol1
|
||
rsync -av /vol3/1000/20260601/vol2/docker /vol1
|
||
将docker迁移到存储空间1，以便获得更快的运行速度
|
||
|
||
重启系统，正常
|
||
过了一会，好像没多久，突然发现存储空间2变成只读了！
|
||
|
||
然后又开始折腾，寻找各种办法，
|
||
重启后依然不能挂载存储空间2，用之前的命令
|
||
mount -t btrfs -o rw 不行，改为
|
||
mount -t btrfs -o ro,usebackuproot,rescue=all /dev/mapper/trim_7db5153a_b22d_43bc_a516_5041e3e504f7-0 /vol2
|
||
|
||
由于已有备份，这次就没有rsync备份
|
||
|
||
btrfs scrub
|
||
btrfs check --repair
|
||
|
||
各种失败，只好放弃，打算umount，结果不让unmount
|
||
|
||
fuser -mv /vol2
|
||
kill -9 xx
|
||
失败！
|
||
只好重启，存储空间2依然没有挂载
|
||
只好格式化：
|
||
mkfs.btrfs /dev/mapper/xxx 注意不能mkfs.btrfs /dev/sda
|
||
进入存储空间管理挂载，成功！
|
||
|
||
rsync -av /vol3/1000/20260601/vol2/1000/docker /vol2/1000
|
||
|
||
将docker数据恢复到存储空间2，开启docker，正常！
|
||
但是有几个容器或者compose不能启动camkeep/t3fap/owncloud，发现是路径是<font color="#c0504d">/vol1/</font>overlay...
|
||
需要删除镜像，再重新拉取镜像构建。
|
||
owncloud是使用volumes,通过
|
||
docker volumes inspect 卷名
|
||
在备份的文件中找到/vol2/docker/volumes/owncloud_mysql/_ Data目录，cp -r 就恢复了！
|
||
|
||
xiaoya不能正常运行，原因未知，天园没有这个问题，可能是/vol2/docker文件还在，没有删除，一旦移走，估计会像东玺门一样不能运行，需要重新卸载->安装，上午一直安装xiaoya不成功，只要是aliyunTVToken获取程序有问题，程序员可能在调试。。。
|
||
中午安装成功了！
|
||
|
||
|
||
|
||
将/vol2应用进行恢复
|
||
|
||
rsync -av /vol3/1000/20260601/vol2/@appcenter /vol2
|
||
。。。
|
||
|
||
现在情况是2个节点都已经更换了系统盘
|
||
备份机制：
|
||
每天零点自动做快照
|
||
定期（初步计划是每周）做一个rsync同步，在本机的其他磁盘上
|
||
每周9161负责将docker数据文件备份到9161上
|
||
两边节点的原来系统盘（120G）全部保存，以防万一。
|
||
|
||
|
||
|
||
几个需要关注的问题：
|
||
1、东玺门存储空间2磁盘，每天系统重启后报错，需要经常关注下是否到了很严重的地步（昨天就不能挂载了，今天更换了！不能偷懒！）
|
||
2、感觉天园飞牛重启系统恢复正常很慢，至少10分钟以上？
|
||
|
||
|
||
|
||
|
||
# 远程文件夹装载
|
||
|
||
|
||
|
||
|