Lazy loaded image
DevOps
"Never-Lost Secrets: A Google Drive + AES-256 Backup Setup for Vaultwarden”
Words 1504Read Time≈ 4 min
Nov 27, 2025
Dec 11, 2025
type
status
date
slug
summary
tags
category
icon
password
If you self-host Vaultwarden, you’ve probably already had this thought:
“What happens if this box dies and never comes back?”
Vaultwarden is a lightweight, community-maintained implementation of the Bitwarden server API, written in Rust and compatible with the official clients.GitHub It’s perfect for home labs and small teams—but like any self-hosted service, it’s only as safe as your backup story.
This post is my current answer to that question: a disaster-recovery setup for Vaultwarden that:
  • Backs up automatically on a schedule
  • Encrypts backups with a strong password (AES-256 via zip)
  • Pushes them off-site to Google Drive using rcloneGitHub
  • Sends me a simple Chinese status email every morning
  • Includes a small “README for future me” inside every backup
Everything is driven by a single docker-compose.yml plus one extra script tweak.

1. Design goals

I tried to keep the design simple and realistic:
  1. Infrastructure as Code
      2. If I have docker-compose.yml and the latest backup, I should be able to rebuild the whole thing on any Linux box with Docker.
  1. Sidecar backup
      2. Vaultwarden focuses on serving traffic; a dedicated sidecar container handles backups, encryption, and upload.
  1. Off-site, but still private
      2. Google Drive is treated like a dumb storage bucket. Backups are encrypted before they leave the server, so even if the cloud account gets compromised, the data is still unreadable without the password.
  1. Future-proof for my own brain
      2. Each backup bundle includes a small README in plain text, so even if I forget everything in two years, I can still follow the steps.
The tech stack:
  • Vaultwarden Docker image
  • ttionya/vaultwarden-backup as the sidecar, which supports backing up the database, attachments, keys, and more, plus remote upload via rclone and SMTP notificationsGitHub
  • rclone configured for Google Drive
  • A bit of shell glue code for nicer email content

2. Architecture in one glance

Two containers, one data volume:
  1. vaultwarden – the main server
      • Exposes HTTP/HTTPS via reverse proxy (not shown here)
      • Stores everything in /data
  1. vaultwarden_backup – backup sidecar
      • Mounts the same data directory read-only
      • Packs db.sqlite3, attachments, config, keys, etc. into an encrypted zipGitHub
      • Uploads to Google Drive via rclone
      • Sends an email after each run
The data itself lives at /vw-data on the host.

3. The core docker-compose.yml

Here’s a trimmed (but usable) version of the compose file I run in production (on JDCloud at the moment). Adjust paths, domains and secrets to your own environment.
The official README for ttionya/vaultwarden-backup documents all supported env vars and shows examples for rclone remotes and restore options.GitHub

4. Making the notifications human-friendly (Chinese mail example)

The backup image already supports SMTP notifications, but the default emails are more like logs. I wanted something friendlier and localized, so I added a small snippet into the backup script that sends a custom mail in Chinese after a successful run.
The idea:
  • Run the normal backup as usual.
  • If it exits with code 0, send a short, clear, human-readable email via curl + SMTP.
One-time patch (run this on the host, and replace all emails and passwords):
A few notes:
  • Use an app password (or SMTP token), not your normal login password.
  • You’re modifying the container’s script; after updating the image, check whether this patch needs to be re-applied.
  • You can of course write this in English or any other language; I just happen to prefer Chinese for personal ops mails.

5. README as a “time capsule” for future you

Backups are useless if you can’t remember how to restore them.
To help my future self (or family), I put a README.txt into Vaultwarden’s attachments directory:
  • Path on host: /vw-data/attachments/README.txt
  • Contents:
    • What this backup is for (Vaultwarden data)
    • Where the zip password is stored offline
    • Rough restore steps
    • Any version notes that might matter
Because the backup tool includes attachments in its default backup set, this README is bundled into every encrypted archive.GitHub
A simple structure could be:
It doesn’t have to be perfect. It just needs to be something a tired future you can follow step by step.

6. Restore flow (from zero to working again)

This is the “panic day” checklist I keep in mind.
  1. Prepare a fresh server
      • Install Docker + docker-compose (or Docker Compose plugin).
      • Make sure you have DNS / reverse proxy ready if you’re using a domain.
  1. Download the backup
      • Use rclone or the browser to grab the latest encrypted zip from your Google Drive remote.
      • Verify the download (size, checksum if you have one).
  1. Decrypt & extract locally
      • On a trusted machine, unzip using the backup password.
      • You should see a directory structure similar to /data in Vaultwarden:
          • db.sqlite3, config.json, rsa_key*, attachments/, maybe sends/, icon_cache/, etc.rs.ppgg.in
  1. Place it into the new data directory
      • On the new server, create /vw-data.
      • Copy all extracted files into /vw-data.
  1. Deploy using compose
      • Put your docker-compose.yml on the new server.
      • Make sure the volume path matches (/vw-data:/data).
      • Run docker compose up -d.
  1. Verify
      • Log into Vaultwarden via browser.
      • Check logins, attachments, icons.
      • Confirm new scheduled backups are running and uploading correctly.
The official Vaultwarden documentation and community wiki also emphasize the importance of backing up db.sqlite3, attachments, sends, config.json, keys and icon cache for a full restore.rs.ppgg.in+1

7. Small lessons learned along the way

A few things that turned out to be useful in practice:
  • Don’t schedule backups exactly on the hour.
      • I run mine at 04:45 to avoid intersecting with typical system cron jobs or external backups.
  • Retention is not only about space.
      • 30 days feels like a good compromise: long enough to notice silent corruption or mistakes, short enough to not explode storage.
  • Treat Google Drive as hostile.
      • Encryption happens before upload; Drive is just a place to store blobs. rclone makes it relatively easy to hook this into many different cloud providers if you ever migrate.Awesome Docker Compose
  • Actually test restore once in a while.
      • Spin up a temporary VM, run through the restore flow end-to-end. It’s the only way to really know your plan works.

8. Closing

These days, every morning when I see that small “✅ Vaultwarden backup succeeded” email on my phone, I’m not thinking “nothing can go wrong now”. I’m just a bit calmer knowing that if something goes wrong, I’m not starting from zero.
If you already have a different backup approach—Borg, restic, filesystem snapshots—feel free to mix and match. Vaultwarden itself doesn’t care how you protect /data, as long as you do it consistently and can restore it cleanly.
And if you improve this setup or find a simpler version, I’d be happy to see your variant and steal a few ideas in return.
—
上一篇
解决Next.js国际化应用在Vercel部署后的路由导航问题
下一篇
The Ultimate macOS Terminal Guide (2025 Edition): From Basic to Pro with Rust & Zsh
Catalog