前段时间遇到类似问题。排查下来返现是我的 sing-tun 配置只 bypass 了默认的 172.17.0.1/16 ，而 docker compose 里 bridge network 会新建一个 interface ，就可能是 172.21.0.1/16 。所以我把从 172.16.0.0/12 都进加进去就正常了
- https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4
- https://sing-box.sagernet.org/configuration/inbound/tun/#inet4_route_exclude_address

所以你可以排查看看是不是宿主机上运行了什么特别的东西

@zhhmax #25

> 在某些极端情况下可能会增加恢复时的工作量

赞同，不过对于自建密码管理器我很重视：

- 很关注 bitwarden 客户端的 issues ，在更新 vaultwarden 之前都会像这样 https://github.com/dani-garcia/vaultwarden/compare/1.30.4...1.30.5 查看改了什么，所以基本上可以确保不会因为一些 breaking change 丢失数据

- 定期会做还原演练

@kuanat #26

> git 可以天然记录变更历史

我以前就有这么做的，因为 vaultwarden 默认使用 sqlite ，密码相关的数据全部在 sqlite 文件中，我就是通过 .dump 转为 sql 文件加到 .git 里来追踪变更，类似于 https://news.ycombinator.com/item?id=38110286

@zhhmax #21

> 凭借一些手段把一段时间内没有变更的压缩包废弃掉

既然这些手段都是为了达成相同目标，那 cron 相对于这个方案还有哪些优势呢。。。

目前认可的是这个方案增加了复杂性所以引入了 #13 #15 提到的问题，还有别的什么？这个问题对我来说也算有解

并且例如 #11 提到的，其实靠各种意义上的 diff （ binary 或是 SQL plain text ）都挺难处理到 access_log 方案这样"精确"的

@zhhmax #18

> 当你使用客户端的时候，创建或修改的密码必然是先在客户端上保存，然后再推送到服务端

https://bitwarden.com/help/using-bitwarden-offline/

Any unlocked Bitwarden app can be used offline in read-only mode ... you won't be able to make edits to or add vault items

> 每五分钟产生一个压缩包

不赞同，我认为和编程一样，自然是越精确越好，对于一些用户来说，为了可能几天才出现一次的变更，何必用这么频繁的备份呢？

@drymonfidelia #13 很好的提醒，谢谢。那后面有可能自己实现一个反代，实际上这个简单反代需求也不太需要 Nginx 。

@pems002 #12 我有在维护基于此思路的 syslog server 简单实现和 docker compose file ，包括一些容器、Nginx 加固等，不过还很早期，等我继续查阅资料学习和优化一番再来分享

@greenskinmonster #10 感谢，学到个命令 incron

我之前用的 inotifywatch ，有些问题，例如我提到的 "登录、注册、设备、二次验证之类的变更"，每次登录都会导致数据库文件变化，而我并不需要处理这种变化，access_log 方案就是对此的升级

@RiddMa #6

> 不是有“忘记密码”功能吗？

确实，但有的东西也许不存在一个"忘记密码"功能

> 又不是天天在加新的密码

我倒觉得这恰恰是我追求每次变更都备份的重要支撑。。。变更不频繁所以完全可以每次都备份

> 真正重要的数据不应该依赖单一的备份手段

赞同，所以这个方案并不提及具体如何备份

并且我是在每次变更后备份并发送通知汇报备份结果，变更一定是我和 bitwarden 主动交互，所以如果出现了错误或者没收到通知，我也可以在很短的时间内得知并处理

@guisheng #5 允许本地保存的话不可避免要处理多客户端的冲突吧，不太懂，但应该挺难妥善处理的？ https://www.inkandswitch.com/local-first/

这个预算个人认为无，在这里讨论过，以及我的建议 https://ex.noerr.eu.org/t/1005595#r_14160180

@hiplon @Xusually

我是从 cron 到 inotifywatch 再到如今的 access_log ，这些方案的变更就一个追求，就是我在文中提到的：

"确保对自己有价值的变更都被备份"

而没有 cron 那样的时间差，可以避免丢失时间间隔中的变更，因为我认为密码数据很重要，丢失一条可能都很严重，不像笔记备份数据那样我可以接受丢失一部分

改了改配置文件，已经用上了，一段时间后再来总结一下实际体验中的优缺点

@maymay5 #6

- 我不想让私钥或者可以读私有仓库的 PAT 离开我的笔记本电脑，所以没办法在别的设备上去主动同步仓库；
- 如果是利用同步备份的工具来做，可以看我列出的优点中的第一条：需要维护麻烦的排除规则，因为本地仓库文件夹里有各种 .*ignore ，有时甚至还会有不在 ignore 文件中但也不打算提交的文件，又或者是 submodule 等等；
- 工具你可以试试 restic ，压缩、加密、增量，有快照有策略

@hellodigua #3

这就是我之前的思路，见优势里列的第 3 条，我本来为了可以加密备份甚至打算直接本地跑一个的，转念一想既然都本地了，那直接用路径就行了，不需要跑个服务了，用法都一样

@hellodigua

> github 本身就算备份了

我觉得不算，例如存在封号 /t/924024 ，我觉得没有用户尤其是大陆用户可以保证自己理解并永远遵守了所有 ToS ，因为有些事情不受你控制 （如 https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls ），也没有人可以保证风控不会出 BUG

> 写一个 github action ，每天定时打包一个 zip 发送到 OSS 里面

理解，优点是可以备份不是自己在本地发起的提交，但个人觉得没这个思路优雅和安全：

1. github repo 有 public 也有 private ，还可能是某个 organization 的 member ，每个仓库一个 github actions 有维护负担，只用一个 actions 则面临权限问题，尝试突破就无法遵循安全实践

2. 用到的 git hosting service 可能不止 github ，还有 gitlab 或者一些自建的服务

@Tink #70 并没有反串。我不开发也不测试，我只是它的用户。我经常用闲鱼，但和 **国内这些大厂的其它 APP** 比起来，它确实没给我留下差到让我记忆深刻的体验

你还可以看看 #19 #37 #46 #54

OP 你博客挂了

桌面那你就用 Pop!_OS 吧，Ubuntu server 就自己移除 snapd