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

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

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

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

• db.sqlite3: تمام حساب‌های کاربری، تمام آیتم‌های vault، تمام پوشه‌ها و تمام سازمان‌ها. از دست دادن این فایل به معنای از دست رفتن کل vault است.
• db.sqlite3-wal و db.sqlite3-shm: لاگ write-ahead (WAL) و ایندکس حافظه اشتراکی آن. نوشته‌های اخیر تا زمانی که SQLite آن‌ها را در فایل اصلی ادغام نکند، در اینجا باقی می‌مانند.
• attachments/: فایل‌هایی که کاربران به آیتم‌های vault پیوست کرده‌اند؛ این فایل‌ها به‌صورت رمزنگاری‌شده و در قالب یک دایرکتوری برای هر آیتم ذخیره می‌شوند.
• sends/: فایل‌های مربوط به لینک‌های Bitwarden Send.
• config.json: تمام تنظیماتی که از صفحه مدیریت ذخیره کرده‌اید.
• 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 و سرور رسمی کاملاً یکسان است.

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

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

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

کپی کردن هر سه فایل با 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> مسیر میزبان را در /var/lib/docker/volumes/ چاپ می‌کند.

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

docker exec -it vaultwarden /vaultwarden backup

این دستور VACUUM INTO را اجرا کرده و db_YYYYMMDD_HHMMSS.sqlite3 را در پوشه داده‌ها می‌نویسد. دو نکته در اینجا حائز اهمیت است: اول اینکه نسخه کپی‌شده در کنار فایل اصلی و روی همان دیسک قرار می‌گیرد، بنابراین این یک مرحله آماده‌سازی است و هنوز یک نسخه پشتیبان کامل محسوب نمی‌شود. دوم اینکه این قابلیت فقط برای 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، ./config.json و ./attachments/ باشید و مطمئن شوید که ./db.sqlite3-wal وجود ندارد. اگر به خروجی journalctl و واحدی که خرابی را گزارش می‌کند نیاز دارید، آن را به جای 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 را چاپ می‌کند. تعداد کاربران باید با تعداد حساب‌هایی که می‌شناسید مطابقت داشته باشد. تعداد رمزنگاری‌ها (cipher count) به عدد موجود در محیط عملیاتی از طریق sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select count(*) from ciphers;" نزدیک است و در یک vault فعال، هرگز نباید صفر باشد. حجم دایرکتوری پیوست‌ها (attachments) تقریباً همان‌قدر است که انتظار دارید؛ اگر کسی فایلی آپلود نمی‌کند، می‌توانید از این مورد صرف‌نظر کنید. سپس sudo rm -rf /tmp/vw-check را اجرا کنید، زیرا آن دایرکتوری اکنون نسخه دومی از همه داده‌ها را در خود نگه می‌دارد.

یک قانون کلی هنگام بازیابی هر پوشه داده‌ای که به‌صورت دستی کپی شده است: پیش از راه‌اندازی سرور، db.sqlite3-wal و db.sqlite3-shm را حذف کنید. در غیر این صورت، SQLite تلاش می‌کند دیتابیس بازیابی‌شده را با استفاده از لاگی که متعلق به نسخه دیگری از آن است بازیابی کند؛ این کار باعث خرابی دیتابیسی می‌شود که سالم بازیابی شده بود. آرشیوهایی که توسط اسکریپت بالا تولید می‌شوند، هرگز شامل این فایل‌ها نیستند، زیرا .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 برسد، در همان نشست (session) به نسخه‌های پشتیبان شما نیز دسترسی پیدا می‌کند.
• بدون رمزنگاری در object storage ذخیره نکنید؛ زیرا آرشیو شامل آدرس‌های ایمیل، راهنمای رمز عبور، کدهای بازیابی و متن رمزنگاری‌شده vault است که می‌تواند به‌صورت آفلاین مورد حمله قرار گیرد.
• فقط به snapshotهای ارائه‌دهنده سرویس خود تکیه نکنید. این 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 در صورتی که هنوز انتخاب نکرده‌اید، به شما کمک می‌کند.

تست زمان‌بندی‌شدهٔ بازیابی

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

سالی یک بار، تست کامل را انجام دهید. یک کانتینر 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) ایمن است؟

خیر. نام آیتم‌ها، رمزهای عبور و یادداشت‌ها به صورت متن رمزنگاری‌شده هستند، اما آدرس‌های ایمیل، نام حساب‌ها، راهنمای رمز عبور و کدهای بازیابی دو مرحله‌ای در پایگاه داده به صورت متن ساده (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 تهیه کنید و سایر قوانین را به همان شکل رعایت کنید. این Dump باید در یک آرشیو واحد همراه با attachments/، sends/، config.json و فایل‌های rsa_key قرار گیرد، در یک نوبت تهیه شود، رمزنگاری گردد و در مکانی خارج از سروری که آن را ایجاد کرده است، ذخیره شود.