vaultwarden 备份思路

每次备份，新的 targz 直接覆盖旧的不就行了吗，为什么所有历史版本都要存

litestream 可以将 sqlite3 增量同步到 s3

@nagisaushio #1 不存历史版本的话这备份意义何在啊

直接 sqlite3 原文件提交就行，git 自己会压缩相同部分。我每次备份提交 500k ，500 多提交整个仓库才 4M 大小。

@Akkuman #2 这个从备份数据库这个角度确实专业太多了

@cccer #4 转成文本也算有点附加收益，参见：

https://news.ycombinator.com/item?id=38110286

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

@0o0O0o0O0o 备份只是以防万一罢了，留一段时间的足以，留着所有历史记录意义何在

@bkmi #8 确实，这次也顺便加上了生命周期规则，过久的历史版本转类型或删除

我就每天备份一次，保留 30 天

@spritevan #7

1. 主密码永远不应该离开客户端，所以我不可能在服务器上定期备份时解密，我不清楚 bw cli 能不能在没有主密码的前提下备份已加密的数据库；
2. vaultwarden 毕竟是第三方实现，bw cli 应该是很难完整导出 vaultwarden 的数据的

我的方案： https://www.zggsong.com/posts/tutorial/vaultwarden-back/

restic
borgbackup
可以了解下
比你这方便很多

@chinni #13 其实你说的这俩是我的常规备份手段，但

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

综上，我还是直接选择 rclone 了

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"

并且 inotifywait 了 data 目录一旦有写操作就备份 ， 这个也太频繁了吧，我现在一天备份一次，保留 30 天的足够了

你这种备份策略有点太傻了。

合理的是像 promox 提供的策略。
不管你备份有多频繁。
在保留最近的 X 份的基础上。
每日备份保留 D 份，每周备份保留 W 份，每月备份保留 M 份，每年备份保留 Y 份。
最终也只要保留 X+D+W+M+Y 。
越早的备份可以越稀疏。

@goodryb #16 是想着让丢失数据的时间窗口短一些，赶不上楼上提到的 litestream ，但也够用了。如果只靠一天一次的 cron job ，最坏的情况要丢失一天的数据

@xgfan 我平时用 borg 等备份也是类似的 prune 策略，vaultwarden 这个有点特殊，你听我狡辩：

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

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

真的要安全，每个密钥，你都应该在 bitwarden 和另一个 app 同时存储，且在不同位置。只有这样你服务器上的备份才有了意义。你既然都默认是服务器不安全了，当然要异地灾备

@bao3 #21 vaultwarden 的设计允许服务器是不安全的，数据不会被攻击者解密。所以你说的这个保护的是“服务器被黑后写入的数据”吗？

@0o0O0o0O0o 这取决于你对安全的理解，比如损失文件是否是安全的一部分，如果不是，那就无需考虑。

@bao3 #23

谢谢，认同你说的，我确实完全没考虑到如何防止这部分数据的丢失。尽管我在 PC 上是把 Bitwarden 目录加进了日常备份的列表，但只是习惯性地写了进去，没有这方面的考虑。

目前想到的是在客户端以密文状态定期对比已备份到 S3 的数据和本地的数据

24 小时过去，发现一个问题是每次打开 bitwarden 都会在数据库里修改 devices 表的 updated_at ，这种改变没有备份的意义，脚本里应该处理一下类似的问题

ttionya/vaultwarden-backup