这是一个创建于 301 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天统计各服务商的 S3 意外发现 vaultwarden 的备份数据已经很大了，所以思考了一下。
我的旧方案是每日备份若干次，并且 inotifywait 了 data 目录一旦有写操作就备份，备份方式是无脑打 .tar.gz ，尽管大小不超过 5MB ，但由于备份频繁，所以占用和增长速度都变得有点过分。
新思路：
- 先 git init 个 repository
- 利用 vaultwarden 建议的 SQLite Online Backup API 先备份 db.sqlite3
sqlite3 db.sqlite3 ".backup /tmp/vaultwarden.sqlite3" - 再利用 sqlite3 dump 成 sql 文件
sqlite3 /tmp/vaultwarden.sqlite3 .dump > vaultwarden.sql - 再按需添加数据库之外的文件，我是很纯粹地当密码管理器使用，所以不需要 attachments 、sends ，否则又引入了二进制文件，而且 git 无法记录文件权限
- 判断一下有没有变化，有变化就 commit
最后用支持增量备份的工具来备份这个 git repository 就好了，不但可以备份到 S3 ，还可以 push 到任意 git 服务。
26 条回复 • 2024-01-13 21:11:36 +08:00
 |
1
nagisaushio 301 天前 via Android
每次备份，新的 targz 直接覆盖旧的不就行了吗，为什么所有历史版本都要存
|
 |
2
Akkuman 301 天前 via Android
litestream 可以将 sqlite3 增量同步到 s3
|
 |
3
0o0O0o0O0o OP @nagisaushio #1 不存历史版本的话这备份意义何在啊
|
 |
4
cccer 301 天前
直接 sqlite3 原文件提交就行，git 自己会压缩相同部分。我每次备份提交 500k ，500 多提交整个仓库才 4M 大小。
|
|
5
0o0O0o0O0o OP @Akkuman #2 这个从备份数据库这个角度确实专业太多了
|
|
6
0o0O0o0O0o OP |
 |
7
spritevan 300 天前
Usage: bw export [options]
Export vault data to a CSV or JSON file. Options: --output <output> Output directory or filename. --format <format> Export file format. --password [password] Use password to encrypt instead of your Bitwarden account encryption key. Only applies to the encrypted_json format. --organizationid <organizationid> Organization id for an organization. -h, --help display help for command Notes: Valid formats are `csv`, `json`, and `encrypted_json`. Default format is `csv`. If --raw option is specified and no output filename or directory is given, the result is written to stdout. Examples: bw export bw --raw export bw export --output ./exp/bw.csv bw export myPassword321 --output bw.json --format json |
 |
8
bkmi 300 天前 via Android  1
@0o0O0o0O0o 备份只是以防万一罢了，留一段时间的足以，留着所有历史记录意义何在
|
|
9
0o0O0o0O0o OP @bkmi #8 确实，这次也顺便加上了生命周期规则，过久的历史版本转类型或删除
|
 |
10
sypopo 300 天前 via Android
我就每天备份一次，保留 30 天
|
|
11
0o0O0o0O0o OP @spritevan #7
1. 主密码永远不应该离开客户端，所以我不可能在服务器上定期备份时解密，我不清楚 bw cli 能不能在没有主密码的前提下备份已加密的数据库； 2. vaultwarden 毕竟是第三方实现，bw cli 应该是很难完整导出 vaultwarden 的数据的 |
 |
12
zggsong 300 天前
|
 |
13
chinni 300 天前
restic
borgbackup 可以了解下 比你这方便很多 |
|
14
0o0O0o0O0o OP @chinni #13 其实你说的这俩是我的常规备份手段，但
1. 我压根不需要加密，而且在这个场景里我最需要的后端是 S3 ，所以不选用 borg 2. 虽然我长期使用 restic 很满意它的增量备份，但我觉得它并不够稳定，在面对多后端的情况下不如 rclone （尽管 restic 支持 rclone 当后端），偶尔会在一些非 AWS 的 S3 上面报错，历史 issues 有时也不了了之或者以提 issue 的人删掉之后重新 init 当作解决方案 综上，我还是直接选择 rclone 了 |
 |
15
yumusb 300 天前
version: '3'
services: vaultwarden: image: vaultwarden/server:latest volumes: - ${PWD}/data:/data restart: always tunnel: image: cloudflare/cloudflared restart: always command: tunnel run depends_on: - vaultwarden environment: - TUNNEL_TOKEN=xxxxxxx backup: image: alpine:latest volumes: - ./:/app - ./.gitconfig:/root/.gitconfig - ./.git-credentials:/root/.git-credentials command: /bin/sh -c "apk add --no-cache git && echo '*/5 * * * * cd /app && git add . && git commit -m AutoBackup && git push && echo OK ' | crontab - && crond -f" |
 |
16
goodryb 300 天前
并且 inotifywait 了 data 目录一旦有写操作就备份 ， 这个也太频繁了吧，我现在一天备份一次，保留 30 天的足够了
|
 |
17
6IbA2bj5ip3tK49j 300 天前
你这种备份策略有点太傻了。
|
|
18
6IbA2bj5ip3tK49j 300 天前
合理的是像 promox 提供的策略。
不管你备份有多频繁。 在保留最近的 X 份的基础上。 每日备份保留 D 份，每周备份保留 W 份，每月备份保留 M 份，每年备份保留 Y 份。 最终也只要保留 X+D+W+M+Y 。 越早的备份可以越稀疏。 |
|
19
0o0O0o0O0o OP @goodryb #16 是想着让丢失数据的时间窗口短一些，赶不上楼上提到的 litestream ，但也够用了。如果只靠一天一次的 cron job ，最坏的情况要丢失一天的数据
|
|
20
0o0O0o0O0o OP @xgfan 我平时用 borg 等备份也是类似的 prune 策略，vaultwarden 这个有点特殊，你听我狡辩：
我默认服务器是不安全的，为了避免服务器被黑后备份的数据被删，我是只给了它对 S3 的写入权限用于不停写入 .tar.gz ，然后也存了一种看看到底会如何增长的心态留了一年没配置生命周期规则； 至于新方案，我则多给了些权限用于同步 git repo ，但依然不能给可以删除历史版本的权限，所以我目前的策略可能也就是通过 S3 服务商提供的生命周期规则把时间够久的历史版本换个存储类型节省成本。但考虑到这个方案的文件大小增长速度肯定很慢，所以我可能还是会全部保留观察一年。 |
 |
21
bao3 300 天前
真的要安全，每个密钥，你都应该在 bitwarden 和另一个 app 同时存储，且在不同位置。只有这样你服务器上的备份才有了意义。你既然都默认是服务器不安全了，当然要异地灾备
|
|
22
0o0O0o0O0o OP @bao3 #21 vaultwarden 的设计允许服务器是不安全的，数据不会被攻击者解密。所以你说的这个保护的是“服务器被黑后写入的数据”吗？
|
|
23
bao3 300 天前
@0o0O0o0O0o 这取决于你对安全的理解，比如损失文件是否是安全的一部分，如果不是，那就无需考虑。
|
|
24
0o0O0o0O0o OP @bao3 #23
谢谢，认同你说的，我确实完全没考虑到如何防止这部分数据的丢失。尽管我在 PC 上是把 Bitwarden 目录加进了日常备份的列表，但只是习惯性地写了进去，没有这方面的考虑。 目前想到的是在客户端以密文状态定期对比已备份到 S3 的数据和本地的数据 |
|
25
0o0O0o0O0o OP 24 小时过去，发现一个问题是每次打开 bitwarden 都会在数据库里修改 devices 表的 updated_at ，这种改变没有备份的意义，脚本里应该处理一下类似的问题
|
 |
26
zhuweitung 299 天前
ttionya/vaultwarden-backup
|
Select Language