آموزش پشتیبان‌گیری و بازیابی دیتای Vaultwarden در VPS

محتویات ضروری برای پشتیبان‌گیری از Vaultwarden

پشتیبان‌گیری از Vaultwarden شامل کپی کامل پوشه داده است و پایگاه‌داده موجود در آن باید به روش صحیح کپی شود. به جای cp از sqlite3 db.sqlite3 ".backup out.sqlite3" استفاده کنید، زیرا کپی ساده از پایگاه‌داده‌ای که در حال نوشتن است، ممکن است فایلی ایجاد کند که باز نشود. سپس فایل‌های کنار آن را نیز حفظ کنید؛ این همان بخشی است که اغلب فراموش می‌شود.

در نصب Docker، پوشه داده همان مسیری است که در /data mount کرده‌اید. این مسیر یا یک آدرس روی میزبان (host) است یا یک volume نام‌گذاری‌شده، و تفاوت بین bind mounts و named volumes تعیین می‌کند که داده‌های vault شما واقعاً در کجای دیسک قرار دارند. محتویات این پوشه به شرح زیر است:

• db.sqlite3: شامل تمام حساب‌های کاربری، آیتم‌های vault، پوشه‌ها و سازمان‌ها. از دست دادن این فایل به معنای از دست رفتن کل vault است.
• db.sqlite3-wal و db.sqlite3-shm: شامل write-ahead log (WAL) و ایندکس حافظه اشتراکی آن. نوشته‌های اخیر تا زمانی که SQLite آن‌ها را در فایل اصلی ادغام نکند، در اینجا باقی می‌مانند.
• attachments/: فایل‌هایی که کاربران به آیتم‌های vault پیوست کرده‌اند؛ این فایل‌ها به صورت رمزنگاری‌شده و در یک دایرکتوری به ازای هر آیتم ذخیره می‌شوند.
• sends/: فایل‌های مربوط به لینک‌های Bitwarden Send.
• config.json: تمام تنظیماتی که از صفحه مدیریت (admin page) ذخیره کرده‌اید.
• rsa_key.pem، به همراه rsa_key.der و rsa_key.pub.der در نسخه‌های قدیمی‌تر: کلیدی که توکن‌های ورود را امضا می‌کند.
• icon_cache/: آیکون‌های وب‌سایت‌های دانلودشده. این تنها دایرکتوری است که می‌توانید از آن صرف‌نظر کنید، زیرا Vaultwarden در صورت نیاز دوباره آن‌ها را دریافت می‌کند.

آیا دیتابیس Vaultwarden من امن است؟ محتوای واقعی فایل چیست

دو دستور به این پرسش پاسخ می‌دهند و می‌توانید همین حالا هر دو را اجرا کنید.

sudo apt update && sudo apt install -y sqlite3
sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select email from users;"
sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select name from ciphers limit 1;"

دستور اول آدرس ایمیل کاربران شما را به صورت متن ساده (cleartext) چاپ می‌کند. دستور دوم نام یک آیتم را چاپ می‌کند که به این شکل است:

2.k9Qw1nQ0y7Yy2Xw==|E1r0J3l5s7d9f1g3h5j7k9==|Lm4nOp6qRs8tUv0wXy2zAb4cDe6fGh8i=

نام آیتم‌ها، نام‌های کاربری، رمزهای عبور و یادداشت‌ها پیش از ارسال توسط کلاینت رمزنگاری می‌شوند، بنابراین سرور فقط متن رمزنگاری‌شده‌ای (ciphertext) را ذخیره می‌کند که قادر به خواندن آن نیست. پیشوند 2. نشان‌دهنده نوع رمزنگاری Bitwarden است و پس از آن یک بردار اولیه (IV)، متن رمزنگاری‌شده و یک MAC (کد احراز اصالت پیام) قرار می‌گیرد که همگی به صورت base64 و با جداکننده | هستند. کلیدی که این داده‌ها را رمزگشایی می‌کند از رمز عبور اصلی (master password) حساب کاربری مشتق می‌شود که هرگز به شکل قابل استفاده به سرور نمی‌رسد. همان‌طور که در مقایسه Vaultwarden و نسخه خودمیزبان Bitwarden توضیح داده شده، این بخش در Vaultwarden و سرور رسمی کاملاً یکسان است.

باقی دیتابیس رمزنگاری نمی‌شود. آدرس‌های ایمیل، نام حساب‌ها، راهنمای رمز عبور و کدهای بازیابی احراز هویت دومرحله‌ای به صورت متن ساده ذخیره می‌شوند؛ در کنار آن‌ها متادیتایی مانند زمان ایجاد و اینکه کدام سازمان مالک یک آیتم است نیز قرار دارد. بنابراین، خودِ فایل پشتیبان یک سند محرمانه است. هر کسی که به آن دسترسی داشته باشد، متوجه می‌شود کاربران شما چه کسانی هستند و می‌تواند به داده‌های رمزنگاری‌شده به صورت آفلاین و با هر سرعتی که سخت‌افزارش اجازه می‌دهد، حمله کند. همین واقعیت باعث می‌شود قوانین ذخیره‌سازی در ادامه اهمیت یابند: نسخه پشتیبان پیش از خروج از سرور باید رمزنگاری شود. توکن مدیریت (admin token) نیمه دیگر همین مشکل است و مراحل ایمن‌سازی Vaultwarden خودمیزبان هر دو مورد را پوشش می‌دهد.

چرا کپی کردن فایل db.sqlite3 در حین اجرای Vaultwarden پشتیبان‌گیری محسوب نمی‌شود

نرم‌افزار Vaultwarden به‌صورت پیش‌فرض از SQLite در حالت WAL استفاده می‌کند (ENABLE_DB_WAL=true). هر عملیات نوشتن ابتدا در db.sqlite3-wal ثبت می‌شود و تنها پس از یک checkpoint است که داده‌ها در db.sqlite3 ادغام می‌شوند. اگر فقط db.sqlite3 را کپی کنید، در بهترین حالت، پایگاه داده را مطابق با آخرین checkpoint در اختیار خواهید داشت؛ بنابراین ممکن است رمز عبوری که ده دقیقه پیش ذخیره کرده‌اید در آرشیو شما نباشد و هیچ هشداری هم دریافت نکنید. در بدترین حالت، کپی‌برداری در حین انجام یک checkpoint صورت می‌گیرد و مستندات رسمی SQLite هشدار می‌دهند که جدا کردن پایگاه داده از فایل WAL می‌تواند منجر به از دست رفتن تراکنش‌های تاییدشده یا خرابی کامل پایگاه داده شود.

کپی کردن هر سه فایل با cp نیز راه‌حل نیست. این کپی‌ها در لحظات متفاوتی گرفته می‌شوند؛ بنابراین فایل WAL که ذخیره کرده‌اید ممکن است توصیف‌کننده نسخه‌هایی از صفحات باشد که با فایل اصلی ذخیره‌شده مطابقت ندارند. در این صورت، SQLite تلاش می‌کند یکی را با دیگری بازیابی کند که نتیجه نهایی نادرست خواهد بود. شما خیلی دیر متوجه این موضوع خواهید شد:

Error: database disk image is malformed

ابزار .backup از این مشکل جلوگیری می‌کند، زیرا از Online Backup API در SQLite استفاده می‌کند؛ روشی که طبق مستندات خود SQLite، راه استاندارد برای کپی کردن پایگاه داده‌ای است که ممکن است در حال استفاده فعال باشد. این ابزار صفحات را تحت یک read lock می‌خواند و اگر در حین عملیات، نویسنده‌ای فایل را تغییر دهد، فرآیند را از نو آغاز می‌کند. بنابراین آنچه روی دیسک ذخیره می‌شود، یک نسخه کاملاً منسجم از یک لحظه خاص است.

تهیه نسخه پشتیبان از دیتابیس با دستور sqlite3 .backup

sudo apt update && sudo apt install -y sqlite3
sudo install -d -m 700 /var/backups/vaultwarden
OUT=/var/backups/vaultwarden/db-$(date '+%Y%m%d-%H%M').sqlite3
sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 ".backup '$OUT'"
sudo sqlite3 "$OUT" "PRAGMA integrity_check;"

دستور آخر، ok را در یک خط جداگانه چاپ می‌کند. هر خروجی دیگری به این معناست که نسخه پشتیبان قابل استفاده نیست؛ بنابراین آن را نگه ندارید و نسخه قبلی را نیز حذف نکنید. کل این فرآیند روی سروری که در حال اجراست انجام می‌شود، بنابراین هیچ کاربری از سیستم خارج نمی‌شود و هیچ containerای ری‌استارت نخواهد شد.

ابزار sqlite3 درون container مربوط به Vaultwarden وجود ندارد. این image بر پایه debian:trixie-slim و با استفاده از ca-certificates، curl، libmariadb3، libpq5 و openssl ساخته شده است، بنابراین docker exec vaultwarden sqlite3 ... با خطای زیر مواجه می‌شود:

exec: "sqlite3": executable file not found in $PATH

به جای آن، دستور را روی host و برای مسیر mount شده اجرا کنید؛ کاری که دستورات بالا انجام می‌دهند. اگر داده‌ها در یک named volume قرار دارند، docker volume inspect <name> مسیر host را در زیر /var/lib/docker/volumes/ نمایش می‌دهد.

Vaultwarden از نسخه 1.32.1 به بعد، دستور پشتیبان‌گیری اختصاصی خود را نیز ارائه کرده است. روی سرور خود:

docker exec -it vaultwarden /vaultwarden backup

این دستور VACUUM INTO را اجرا کرده و db_YYYYMMDD_HHMMSS.sqlite3 را در پوشه داده‌ها می‌نویسد. دو نکته در اینجا وجود دارد: اول اینکه نسخه کپی‌شده در کنار فایل اصلی و روی همان دیسک قرار می‌گیرد، بنابراین این یک مرحله میانی (staging) است و هنوز یک نسخه پشتیبان کامل محسوب نمی‌شود. دوم اینکه این قابلیت فقط برای SQLite است: در صورت استفاده از MariaDB یا PostgreSQL، عملیات با خطای The database type is not SQLite. Backups only works for SQLite databases متوقف می‌شود.

فایل‌هایی که فراموش می‌شوند

attachments/ متن رمزنگاری‌شده را با نام‌های مبهم نگهداری می‌کند. ردیف دیتابیس برای هر پیوست، نام فایل رمزنگاری‌شده و کلید مورد نیاز کلاینت برای رمزگشایی آن را در خود دارد. پیوست‌های بدون دیتابیس، داده‌های غیرقابل خواندن هستند و دیتابیس بدون پیوست‌ها، آیتم‌هایی را به کاربر نشان می‌دهد که دانلود آن‌ها با شکست مواجه می‌شود. هر دو را در یک مرحله پشتیبان‌گیری کنید.

config.json تمام تنظیماتی را که از صفحه مدیریت ذخیره کرده‌اید در خود نگه می‌دارد و مقادیر آن بر متغیرهای محیطی (environment variables) مشابه اولویت دارند. این موضوع دو جنبه دارد: بازیابی یک config.json قدیمی، تنظیمات فایل compose شما را بی‌سروصدا نادیده می‌گیرد و خود فایل نیز حساس است، زیرا می‌تواند رمز عبور SMTP و توکن مدیریت شما را در خود داشته باشد. آن توکن را به‌جای متن ساده، به‌صورت یک رشته Argon2id PHC (مسابقه هش کردن رمز عبور) ذخیره کنید. docker run --rm -it vaultwarden/server /vaultwarden hash یک نمونه برای شما تولید می‌کند.

rsa_key.pem توکن‌های وب JSON (JWT) را که وضعیت ورود کلاینت‌ها را حفظ می‌کنند، امضا می‌کند. اگر این فایل هنگام راه‌اندازی موجود نباشد، Vaultwarden یک کلید جدید تولید می‌کند؛ در نتیجه تمام توکن‌هایی که با کلید قدیمی امضا شده‌اند دیگر معتبر نخواهند بود و تمام کلاینت‌ها از سیستم خارج (logout) می‌شوند. محتویات Vault از این اتفاق جان سالم به در می‌برند، زیرا با کلیدهایی که از رمز عبور اصلی (master password) مشتق شده‌اند، رمزنگاری شده‌اند. بازیابی فایل کلید از خروج دسته‌جمعی کاربران جلوگیری می‌کند.

sends/ فایل‌های مربوط به لینک‌های Send را نگهداری می‌کند. نبودن این فایل‌ها فقط باعث از کار افتادن دانلودهای مربوط به این لینک‌ها می‌شود و تأثیر دیگری ندارد.

همه چیز را در یک اسکریپت قرار دهید

#!/bin/bash
set -euo pipefail

DATA=/opt/vaultwarden/data
DEST=/var/backups/vaultwarden
STAMP=$(date '+%Y%m%d-%H%M%S')
STAGE=$(mktemp -d /tmp/vw-stage.XXXXXX)

install -d -m 700 "$DEST"
sqlite3 "$DATA/db.sqlite3" ".backup '$STAGE/db.sqlite3'"
test "$(sqlite3 "$STAGE/db.sqlite3" 'PRAGMA integrity_check;')" = "ok"
cp -a "$DATA"/rsa_key* "$STAGE/"
for extra in config.json attachments sends; do
  if [ -e "$DATA/$extra" ]; then cp -a "$DATA/$extra" "$STAGE/"; fi
done
tar -C "$STAGE" -czf "$DEST/vw-$STAMP.tar.gz" .
chmod 600 "$DEST/vw-$STAMP.tar.gz"
rm -rf "$STAGE"
tar -tzf "$DEST/vw-$STAMP.tar.gz"

آن را با نام /usr/local/sbin/vw-backup.sh ذخیره کنید، با دستور chmod 700 به آن مجوز اجرا بدهید و به عنوان root اجرا کنید. خط test کار اصلی را انجام می‌دهد: sqlite3 حتی زمانی که PRAGMA integrity_check خرابی داده را گزارش می‌کند، کد خروج 0 برمی‌گرداند؛ بنابراین مقایسه خروجی با ok همان چیزی است که باعث می‌شود یک کپی ناقص به یک اسکریپت شکست‌خورده تبدیل شود. سپس set -euo pipefail همه چیز را متوقف می‌کند، به جای اینکه اجازه دهد tar یک آرشیو مرتب حول یک دیتابیس خراب بسازد.

دستور نهایی tar -tzf آنچه را که واقعاً ضبط کرده‌اید فهرست می‌کند. آن را برای اولین بار بررسی کنید. شما به دنبال ./db.sqlite3، ./rsa_key.pem و ./attachments/ هستید، به علاوه ./config.json اگر تا به حال تنظیماتی را از صفحه مدیریت ذخیره کرده باشید، و همچنین به دنبال عدم وجود ./db.sqlite3-wal. برنامه Vaultwarden فقط زمانی config.json را ایجاد می‌کند که تنظیماتی را در آنجا ذخیره کنید، بنابراین نصبی که کاملاً از طریق متغیرهای محیطی پیکربندی شده باشد فاقد آن است و اسکریپت از آن صرف‌نظر می‌کند. اگر خروجی journalctl و یک unit که خرابی را گزارش می‌کند می‌خواهید، آن را به جای cron با یک سرویس و تایمر systemd به صورت شبانه اجرا کنید.

تأیید نسخه پشتیبان از طریق بازیابی در یک دایرکتوری موقت

نسخه پشتیبانی که تست نشده باشد، تنها یک حدس است. بازیابی در یک دایرکتوری موقت تنها یک دقیقه زمان می‌برد و هیچ تغییری در محیط عملیاتی ایجاد نمی‌کند.

sudo install -d -m 700 /tmp/vw-check
sudo tar -C /tmp/vw-check -xzf /var/backups/vaultwarden/vw-20260805-030000.tar.gz
ls -l /tmp/vw-check
sudo sqlite3 /tmp/vw-check/db.sqlite3 "PRAGMA integrity_check;"
sudo sqlite3 /tmp/vw-check/db.sqlite3 "select count(*) from users;"
sudo sqlite3 /tmp/vw-check/db.sqlite3 "select count(*) from ciphers;"
sudo du -sh /tmp/vw-check/attachments

چهار نتیجه اهمیت دارند. integrity_check خروجی ok را چاپ می‌کند. تعداد کاربران باید با تعداد حساب‌هایی که می‌شناسید مطابقت داشته باشد. تعداد رمزنگاری‌ها باید به عدد موجود در محیط عملیاتی از طریق sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select count(*) from ciphers;" نزدیک باشد. عدد صفر تنها در صورتی درست است که مقدار در محیط عملیاتی نیز صفر باشد؛ برای مثال، یک vault که در حال استفاده است ممکن است هیچ آیتمی نداشته باشد، مانند زمانی که یک vault سازمانی پاک‌سازی شده باشد. اگر مقدار در محیط عملیاتی صفر نباشد اما در نسخه پشتیبان صفر گزارش شود، یعنی کپی ناقص است. حجم دایرکتوری پیوست‌ها (attachments) باید تقریباً همان اندازه‌ای باشد که انتظار دارید؛ اگر کسی پیوستی آپلود نکرده باشد، می‌توانید این مورد را نادیده بگیرید. سپس sudo rm -rf /tmp/vw-check را اجرا کنید، زیرا آن دایرکتوری اکنون شامل کپی دوم از همه چیز است.

یک قانون کلی هنگام بازیابی پایگاه داده‌ای که با .backup یا VACUUM INTO تهیه شده است (که شامل دستور پشتیبان‌گیری داخلی نیز می‌شود) این است: پیش از شروع سرور، هرگونه db.sqlite3-wal و db.sqlite3-shm را در پوشه داده‌ها حذف کنید. در غیر این صورت، SQLite تلاش می‌کند پایگاه داده بازیابی‌شده را با استفاده از لاگی که متعلق به کپی دیگری است بازیابی کند، و این کار می‌تواند پایگاه داده‌ای را که سالم بازیابی شده است، دچار خرابی کند. کپی مستقیم فایل یک استثنا است. اگر db.sqlite3 را به همراه db.sqlite3-wal متناظر آن کپی کرده‌اید، هر دو را با هم بازیابی کنید، زیرا آن فایل WAL ممکن است حاوی تراکنش‌های ثبت‌شده‌ای باشد که فایل اصلی هنوز آن‌ها را دریافت نکرده است و حذف آن باعث از دست رفتن داده‌ها می‌شود. فایل -shm هرگز نیازی به بازیابی ندارد. آرشیوهای تولیدشده توسط اسکریپت بالا هرگز حاوی WAL نیستند، زیرا .backup یک پایگاه داده کامل را می‌نویسد.

بازیابی روی سرور

این عملیات روی سرور شخصی شما و در حالی که container متوقف است، انجام می‌شود. Vaultwarden نباید در زمانی که پوشه داده‌ها در حال تغییر است، عملیات نوشتن انجام دهد.

cd /opt/vaultwarden
docker compose stop vaultwarden
sudo mv data data.old.$(date '+%Y%m%d-%H%M%S')
sudo install -d -m 700 data
sudo tar -C data -xzf /var/backups/vaultwarden/vw-20260805-030000.tar.gz
sudo chown -R root:root data
docker compose start vaultwarden
docker compose logs --tail 20 vaultwarden

در chown باید کاربری که container با آن اجرا می‌شود، مشخص گردد. image پیش‌فرض با کاربر root اجرا می‌شود، بنابراین root:root صحیح است، مگر اینکه شما در فایل compose خود مقدار user: را تنظیم کرده باشید که در آن صورت باید از همان uid و gid استفاده کنید. اگر پوشه داده‌ها توسط سرور قابل نوشتن نباشد، صفحه ورود نمایش داده می‌شود اما تمام درخواست‌ها با خطا مواجه خواهند شد و لاگ‌ها نیز این موضوع را گزارش می‌کنند.

یک شروع موفق با خط Rocket به پایان می‌رسد:

[INFO] Rocket has launched from http://0.0.0.0:80

سپس از طریق مرورگر وارد شوید، یک آیتم را باز کنید و یکی از پیوست‌ها را دانلود نمایید. اگر ورود به سیستم موفقیت‌آمیز است اما دانلود پیوست‌ها با خطا مواجه می‌شود، به این معناست که آرشیو شامل دیتابیس بوده اما attachments/ منتقل نشده است. تا زمانی که تمام موارد بررسی و تایید نشده‌اند، data.old.* را نگه دارید و پس از اطمینان، آن را حذف کنید. بازگشت به وضعیت قبلی (Rollback) با همان سه مرحله و جابه‌جایی مسیر دایرکتوری‌ها انجام می‌شود.

اگر مسیرهای شما با مسیرهای ذکر شده در اینجا مطابقت ندارند، راهنمای نصب Vaultwarden روی VPS فایل compose مورد استفاده در این دستورات را نشان می‌دهد.

کجا نباید از بک‌آپ نگهداری کرد

• روی همان دیسکی که پوشهٔ داده‌ها قرار دارد، بک‌آپ نگیرید. خرابی یک volume باعث از دست رفتن هر دو نسخه می‌شود؛ همین اتفاق با یک rm -rf اشتباه در مسیر نیز رخ می‌دهد.
• روی همان سرور بک‌آپ نگیرید، حتی اگر روی volume دوم باشد. مهاجمی که به دسترسی root برسد، در همان نشست به بک‌آپ‌های شما نیز دسترسی پیدا می‌کند.
• بدون رمزنگاری در object storage ذخیره نکنید؛ زیرا آرشیو شامل آدرس‌های ایمیل، راهنمای رمز عبور، کدهای بازیابی و متن رمزنگاری‌شدهٔ vault است که می‌تواند به‌صورت آفلاین مورد حمله قرار گیرد.
• فقط به snapshotهای ارائه‌دهندهٔ سرویس خود تکیه نکنید. آن‌ها سریع بازیابی می‌شوند و داشتنشان مفید است، اما در همان حسابی قرار دارند که سرور در آن است؛ بنابراین بروز مشکل در حساب کاربری، بک‌آپ‌ها را نیز از بین می‌برد.

یک نسخهٔ offsite جایی است که restic کاربرد پیدا می‌کند، زیرا مخزن restic پیش از هرگونه آپلود، روی خود ماشین رمزنگاری می‌شود. روی سرور خود:

sudo apt install -y restic
export RESTIC_REPOSITORY=s3:https://s3.example.com/vaultwarden-backups
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /var/backups/vaultwarden --tag vaultwarden
restic snapshots --tag vaultwarden
restic forget --tag vaultwarden --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

restic را به سمت دایرکتوری آرشیو هدایت کنید، نه پوشهٔ داده‌های زنده؛ بنابراین آنچه آپلود می‌شود، همان نسخهٔ منسجمی است که قبلاً بررسی کرده‌اید. رمز عبور مخزن را در جایی غیر از سروری که از آن محافظت می‌کند نگه دارید: طبق طراحی، با گم‌شدن آن رمز عبور، snapshotها غیرقابل خواندن خواهند بود. در جایی که فضای ذخیره‌سازی پشتیبانی می‌کند، به سرور اعتبارنامه‌هایی بدهید که فقط اجازهٔ نوشتن داشته باشند و نه حذف؛ تا در صورت نفوذ به سرور، مهاجم نتواند تاریخچهٔ بک‌آپ‌های خود را پاک کند. راه‌اندازی بک‌آپ‌های restic روی VPS مخزن و زمان‌بندی را به‌طور کامل پوشش می‌دهد و مقایسه restic با BorgBackup اگر هنوز انتخابی نکرده‌اید، به شما کمک می‌کند.

تست بازیابی طبق زمان‌بندی

یک روز در ماه را انتخاب کنید. جدیدترین snapshot را با استفاده از restic restore latest --tag vaultwarden --target /tmp/vw-check به یک دایرکتوری موقت منتقل کنید، همان PRAGMA integrity_check را اجرا کنید، تعداد ردیف‌ها را بشمارید و سپس تاریخ و تعداد ردیف‌ها را یادداشت کنید. پشتیبانی که در 6 ماه گذشته بازیابی نشده باشد، وضعیتی نامشخص دارد؛ شما وضعیت آن را در زمان بروز قطعی متوجه می‌شوید که بدترین زمان ممکن برای این کار است.

سالی یک‌بار، نسخه کامل را تست کنید. یک container دوم Vaultwarden را روی یک پورت آزاد با پوشه داده‌های بازیابی‌شده اجرا کنید و با یک حساب کاربری واقعی وارد شوید. این کار مسیر master password را به‌طور کامل تأیید می‌کند، کاری که شمارش ردیف‌ها قادر به انجام آن نیست. اجرای restic check --read-data-subset=10% طبق همین زمان‌بندی، تأیید می‌کند که داده‌های ذخیره‌شده صرفاً در لیست وجود ندارند، بلکه واقعاً قابل خواندن هستند.

FAQ

آیا می‌توانم فایل db.sqlite3 را در حالی که Vaultwarden در حال اجراست با دستور cp کپی کنم؟

خیر. Vaultwarden از SQLite در حالت WAL استفاده می‌کند، بنابراین نوشته‌های اخیر در db.sqlite3-wal قرار دارند و هنوز به db.sqlite3 منتقل نشده‌اند. تهیه cp تنها از فایل اصلی باعث از دست رفتن بی‌سروصدای این داده‌ها می‌شود و کپی کردن جداگانه این دو فایل می‌تواند منجر به ایجاد یک جفت ناهماهنگ شود که بعداً به صورت Error: database disk image is malformed ظاهر می‌شود. به‌جای آن از sqlite3 /path/db.sqlite3 ".backup '/path/out.sqlite3'" استفاده کنید. این ابزار از Online Backup API در SQLite بهره می‌برد و در حالی که سرور به سرویس‌دهی ادامه می‌دهد، یک فایل منسجم تولید می‌کند.

آیا برای تهیه نسخه پشتیبان باید کانتینر Vaultwarden را متوقف کنم؟

خیر، و این دقیقاً هدف استفاده از .backup است. کپی پایگاه داده در حالی که سرور در حال اجراست، ایمن است. فایل‌های پیوست و Send زمانی نوشته می‌شوند که کاربر آن‌ها را آپلود کند؛ بنابراین فایلی که بین کپی پایگاه داده و tar اضافه شود، ممکن است در آرشیو آن شب قرار نگیرد که در بدترین حالت منجر به از دست رفتن یک پیوست می‌شود. اگر چند ثانیه قطعی سرویس برای شما مشکلی ایجاد نمی‌کند، اجرای docker compose stop پیش از اسکریپت و docker compose start پس از آن، حتی همین احتمال اندک را نیز از بین می‌برد.

اگر بدون فایل‌های rsa_key عملیات بازیابی را انجام دهم چه می‌شود؟

Vaultwarden در زمان شروع به کار یک کلید جدید تولید می‌کند. آن کلید، توکن‌های وب JSON (JWT) را که نشست‌ها را فعال نگه می‌دارند امضا می‌کند؛ بنابراین تمام توکن‌های موجود دیگر معتبر نخواهند بود، تمام کلاینت‌ها از حساب خود خارج می‌شوند و باید دوباره وارد شوند. محتویات Vault تحت تأثیر قرار نمی‌گیرند، زیرا آن‌ها با کلیدهایی رمزنگاری شده‌اند که از رمز عبور اصلی هر کاربر مشتق شده‌اند، نه با کلید RSA. اگر rsa_key.pem را همراه با سایر محتویات پوشه داده بازیابی کنید، هیچ‌کس متوجه عملیات بازیابی نخواهد شد.

آیا آرشیو پشتیبان برای آپلود مستقیم در فضای ذخیره‌سازی شیء (Object Storage) ایمن است؟

خیر. نام آیتم‌ها، رمزهای عبور و یادداشت‌ها به صورت متن رمزنگاری‌شده (ciphertext) هستند، اما آدرس‌های ایمیل، نام حساب‌ها، راهنمای رمز عبور و کدهای بازیابی دو مرحله‌ای در پایگاه داده به صورت متن ساده (plain text) قرار دارند و یک مهاجم آفلاین می‌تواند با سرعت دلخواه خود، متن رمزنگاری‌شده را کرک کند. پیش از آنکه آرشیو از سرور خارج شود، آن را رمزنگاری کنید. یک مخزن restic این کار را برای شما انجام می‌دهد و gpg --symmetric --cipher-algo AES256 vw-20260805-030000.tar.gz یک فایل رمزنگاری‌شده واحد تولید می‌کند که می‌توانید آن را به هر فضای ذخیره‌سازی بسپارید.

چگونه از Vaultwarden روی PostgreSQL یا MariaDB نسخه پشتیبان تهیه کنم؟

مراحل مربوط به SQLite در اینجا کاربرد ندارند و دستور داخلی برنامه با خطای The database type is not SQLite. Backups only works for SQLite databases مواجه می‌شود. از پایگاه داده با استفاده از ابزار بومی آن، یعنی pg_dump یا mysqldump، خروجی (Dump) بگیرید و سایر قوانین را به همان شکل رعایت کنید. این خروجی باید در یک آرشیو واحد به همراه attachments/، sends/، config.json و فایل‌های rsa_key قرار گیرد، در یک نوبت تهیه شود، رمزنگاری گردد و در مکانی غیر از سروری که آن را تولید کرده است، ذخیره شود.