vaultwarden 备份思路

2024-01-12 19:52:08 +08:00
 0o0O0o0O0o

今天统计各服务商的 S3 意外发现 vaultwarden 的备份数据已经很大了,所以思考了一下。

我的旧方案是每日备份若干次,并且 inotifywait 了 data 目录一旦有写操作就备份,备份方式是无脑打 .tar.gz ,尽管大小不超过 5MB ,但由于备份频繁,所以占用和增长速度都变得有点过分。

新思路:

  1. 先 git init 个 repository
  2. 利用 vaultwarden 建议的 SQLite Online Backup API 先备份 db.sqlite3
    sqlite3 db.sqlite3 ".backup /tmp/vaultwarden.sqlite3"
  3. 再利用 sqlite3 dump 成 sql 文件
    sqlite3 /tmp/vaultwarden.sqlite3 .dump > vaultwarden.sql
  4. 再按需添加数据库之外的文件,我是很纯粹地当密码管理器使用,所以不需要 attachments 、sends ,否则又引入了二进制文件,而且 git 无法记录文件权限
  5. 判断一下有没有变化,有变化就 commit

最后用支持增量备份的工具来备份这个 git repository 就好了,不但可以备份到 S3 ,还可以 push 到任意 git 服务。

5423 次点击
所在节点    程序员
26 条回复
nagisaushio
2024-01-12 19:59:59 +08:00
每次备份,新的 targz 直接覆盖旧的不就行了吗,为什么所有历史版本都要存
Akkuman
2024-01-12 20:00:33 +08:00
litestream 可以将 sqlite3 增量同步到 s3
0o0O0o0O0o
2024-01-12 20:01:32 +08:00
@nagisaushio #1 不存历史版本的话这备份意义何在啊
cccer
2024-01-12 20:09:24 +08:00
直接 sqlite3 原文件提交就行,git 自己会压缩相同部分。我每次备份提交 500k ,500 多提交整个仓库才 4M 大小。
0o0O0o0O0o
2024-01-12 20:14:43 +08:00
@Akkuman #2 这个从备份数据库这个角度确实专业太多了
0o0O0o0O0o
2024-01-12 20:15:35 +08:00
@cccer #4 转成文本也算有点附加收益,参见:

https://news.ycombinator.com/item?id=38110286
spritevan
2024-01-12 20:23:07 +08:00
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
bkmi
2024-01-12 20:25:32 +08:00
@0o0O0o0O0o 备份只是以防万一罢了,留一段时间的足以,留着所有历史记录意义何在
0o0O0o0O0o
2024-01-12 20:30:38 +08:00
@bkmi #8 确实,这次也顺便加上了生命周期规则,过久的历史版本转类型或删除
sypopo
2024-01-12 20:32:44 +08:00
我就每天备份一次,保留 30 天
0o0O0o0O0o
2024-01-12 20:38:34 +08:00
@spritevan #7

1. 主密码永远不应该离开客户端,所以我不可能在服务器上定期备份时解密,我不清楚 bw cli 能不能在没有主密码的前提下备份已加密的数据库;
2. vaultwarden 毕竟是第三方实现,bw cli 应该是很难完整导出 vaultwarden 的数据的
zggsong
2024-01-12 20:40:14 +08:00
chinni
2024-01-12 20:43:42 +08:00
restic
borgbackup
可以了解下
比你这方便很多
0o0O0o0O0o
2024-01-12 20:54:08 +08:00
@chinni #13 其实你说的这俩是我的常规备份手段,但

1. 我压根不需要加密,而且在这个场景里我最需要的后端是 S3 ,所以不选用 borg
2. 虽然我长期使用 restic 很满意它的增量备份,但我觉得它并不够稳定,在面对多后端的情况下不如 rclone (尽管 restic 支持 rclone 当后端),偶尔会在一些非 AWS 的 S3 上面报错,历史 issues 有时也不了了之或者以提 issue 的人删掉之后重新 init 当作解决方案

综上,我还是直接选择 rclone 了
yumusb
2024-01-12 22:18:16 +08:00
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"
goodryb
2024-01-12 22:56:01 +08:00
并且 inotifywait 了 data 目录一旦有写操作就备份 , 这个也太频繁了吧,我现在一天备份一次,保留 30 天的足够了
6IbA2bj5ip3tK49j
2024-01-12 23:54:33 +08:00
你这种备份策略有点太傻了。
6IbA2bj5ip3tK49j
2024-01-12 23:59:58 +08:00
合理的是像 promox 提供的策略。
不管你备份有多频繁。
在保留最近的 X 份的基础上。
每日备份保留 D 份,每周备份保留 W 份,每月备份保留 M 份,每年备份保留 Y 份。
最终也只要保留 X+D+W+M+Y 。
越早的备份可以越稀疏。
0o0O0o0O0o
2024-01-13 00:08:38 +08:00
@goodryb #16 是想着让丢失数据的时间窗口短一些,赶不上楼上提到的 litestream ,但也够用了。如果只靠一天一次的 cron job ,最坏的情况要丢失一天的数据
0o0O0o0O0o
2024-01-13 00:25:06 +08:00
@xgfan 我平时用 borg 等备份也是类似的 prune 策略,vaultwarden 这个有点特殊,你听我狡辩:

我默认服务器是不安全的,为了避免服务器被黑后备份的数据被删,我是只给了它对 S3 的写入权限用于不停写入 .tar.gz ,然后也存了一种看看到底会如何增长的心态留了一年没配置生命周期规则;

至于新方案,我则多给了些权限用于同步 git repo ,但依然不能给可以删除历史版本的权限,所以我目前的策略可能也就是通过 S3 服务商提供的生命周期规则把时间够久的历史版本换个存储类型节省成本。但考虑到这个方案的文件大小增长速度肯定很慢,所以我可能还是会全部保留观察一年。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/1008203

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX