VPS پر Vaultwarden backup اور restore کا طریقہ

Vaultwarden backup میں کیا شامل ہونا چاہیے

Vaultwarden backup پورے data folder کی copy ہوتی ہے، اور اس کے اندر موجود database کو درست طریقے سے copy کرنا ضروری ہے۔ cp کے بجائے sqlite3 db.sqlite3 ".backup out.sqlite3" چلائیں، کیونکہ زیرِ تحریر database کی عام copy ایسی file بنا سکتی ہے جو کھلے ہی نہ۔ اس کے ساتھ موجود دوسری files بھی محفوظ رکھیں۔ یہی حصہ اکثر نظرانداز ہو جاتا ہے۔

Docker installation میں data folder وہی ہوتا ہے جسے آپ نے /data پر mount کیا ہو۔ یہ host پر موجود path یا named volume ہو سکتا ہے، اور bind mounts اور named volumes کے درمیان فرق سے طے ہوتا ہے کہ آپ کا vault disk پر کہاں موجود ہے۔ اس folder میں یہ چیزیں شامل ہوتی ہیں۔

• db.sqlite3: ہر account، ہر vault item، ہر folder اور ہر organisation۔ یہ file ضائع ہونے سے vault ضائع ہو جاتا ہے۔
• db.sqlite3-wal اور db.sqlite3-shm: write-ahead log (WAL) اور اس کا shared memory index۔ حالیہ writes یہاں اس وقت تک رہتی ہیں جب تک SQLite انہیں main file میں شامل نہیں کر دیتا۔
• attachments/: vault items کے ساتھ attach کی گئی files، encrypted حالت میں، ہر item کے لیے الگ directory میں۔
• sends/: Bitwarden Send links کے پیچھے موجود files۔
• config.json: admin page سے محفوظ کی گئی ہر setting۔
• rsa_key.pem، اور پرانی installations میں rsa_key.der اور rsa_key.pub.der بھی: login tokens پر دستخط کرنے والی key۔
• icon_cache/: downloaded website icons۔ یہ واحد directory ہے جسے چھوڑا جا سکتا ہے، کیونکہ Vaultwarden ضرورت کے وقت انہیں دوبارہ fetch کر لیتا ہے۔

کیا میرا Vaultwarden database محفوظ ہے؟ فائل میں اصل میں کیا موجود ہے

دو commands اس کا جواب دیتی ہیں، اور آپ دونوں ابھی چلا سکتے ہیں۔

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;"

پہلی command آپ کے users کے email addresses کو cleartext میں دکھاتی ہے۔ دوسری command ایک item name دکھاتی ہے، جو اس طرح نظر آتا ہے:

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

Item names، usernames، passwords اور notes کو client بھیجنے سے پہلے encrypt کرتا ہے، اس لیے server ایسا ciphertext محفوظ کرتا ہے جسے وہ پڑھ نہیں سکتا۔ 2. prefix، Bitwarden کی encryption type ہے۔ اس کے بعد initialisation vector (IV)، ciphertext اور MAC (message authentication code) آتے ہیں۔ یہ سب base64 میں ہوتے ہیں اور | سے الگ کیے جاتے ہیں۔ اسے decrypt کرنے والی key account کے master password سے اخذ کی جاتی ہے، جو کبھی بھی server تک قابلِ استعمال شکل میں نہیں پہنچتا۔ یہ حصہ Vaultwarden یا official server چلانے کی صورت میں یکساں رہتا ہے، جیسا کہ Vaultwarden اور self-hosted Bitwarden کا موازنہ میں بیان کیا گیا ہے۔

Database کا باقی حصہ encrypted نہیں ہوتا۔ Email addresses، account names، password hints اور two-factor recovery codes plain text میں محفوظ ہوتے ہیں۔ ان کے ساتھ creation times اور یہ metadata بھی موجود ہوتا ہے کہ کسی item کی ملکیت کس organisation کے پاس ہے۔ اس لیے backup file خود ایک secret ہے۔ جس کے پاس یہ file ہو، وہ جان لیتا ہے کہ آپ کے users کون ہیں، اور encrypted blobs پر offline attack اتنی رفتار سے کر سکتا ہے جتنی اس کا hardware اجازت دے۔ یہی ایک حقیقت نیچے بیان کردہ storage rules کی بنیاد ہے: copy کو server سے باہر جانے سے پہلے encrypt کیا جاتا ہے۔

Vaultwarden کے چلتے ہوئے db.sqlite3 کو کاپی کرنا بیک اپ کیوں نہیں ہے

Vaultwarden پہلے سے SQLite کو WAL mode میں چلاتا ہے (ENABLE_DB_WAL=true)۔ تحریر پہلے db.sqlite3-wal میں لکھی جاتی ہے، اور صرف checkpoint کے دوران اسے db.sqlite3 میں شامل کیا جاتا ہے۔ صرف db.sqlite3 کو کاپی کرنے سے آپ کو آخری checkpoint تک کی database ملتی ہے۔ اس لیے دس منٹ پہلے محفوظ کیا گیا password آپ کے archive میں شامل نہ ہو، اور آپ کو اس بارے میں کوئی اطلاع بھی نہ ملے۔

cp کے ذریعے تینوں فائلوں کو کاپی کرنا بھی حل نہیں ہے۔ یہ copies قدرے مختلف اوقات میں بنتی ہیں۔ اس لیے محفوظ کیا گیا WAL ایسے page versions بیان کر سکتا ہے جو محفوظ کی گئی main file سے مطابقت نہیں رکھتے۔ پھر SQLite ایک فائل سے دوسری فائل کو recover کرتا ہے، اور نتیجہ غلط ہو جاتا ہے۔ آپ کو اس کا پتا کافی دیر بعد چلتا ہے:

Error: database disk image is malformed

.backup اس مسئلے سے بچاتا ہے، کیونکہ یہ SQLite کا Online Backup API استعمال کرتا ہے۔ SQLite کے مطابق فعال استعمال میں موجود database کو کاپی کرنے کا یہی درست طریقہ ہے۔ یہ read lock کے تحت pages پڑھتا ہے، اور اگر writer اسی دوران فائل تبدیل کرے تو عمل دوبارہ شروع کرتا ہے۔ اس طرح disk پر ایک ہی consistent لمحے کی database محفوظ ہوتی ہے۔

sqlite3 .backup کے ذریعے database کی copy لیں

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;"

آخری command ایک الگ line پر ok دکھاتی ہے۔ اس کے علاوہ کسی بھی نتیجے کا مطلب ہے کہ copy قابل استعمال نہیں، اس لیے اسے نہ رکھیں اور پچھلی copy حذف نہ کریں۔ پوری sequence live server پر چلتی ہے، اس لیے کسی user کا session ختم نہیں ہوتا اور کوئی container restart نہیں ہوتا۔

sqlite3 tool Vaultwarden container کے اندر موجود نہیں ہے۔ image debian:trixie-slim پر ca-certificates، curl، libmariadb3، libpq5 اور openssl کے ساتھ build کی گئی ہے، اس لیے docker exec vaultwarden sqlite3 ... اس error کے ساتھ ناکام ہوتی ہے:

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

اسے host پر mounted path کے خلاف چلائیں، جیسا کہ اوپر دی گئی commands کرتی ہیں۔ اگر data named volume میں موجود ہو تو docker volume inspect <name>، /var/lib/docker/volumes/ کے تحت host path دکھاتی ہے۔

Vaultwarden نے version 1.32.1 سے اپنی backup command بھی شامل کی ہے۔ اپنے server پر:

docker exec -it vaultwarden /vaultwarden backup

یہ VACUUM INTO چلاتی ہے اور db_YYYYMMDD_HHMMSS.sqlite3 کو data folder میں لکھتی ہے۔ اس کے دو نتائج ہیں۔ copy اسی disk پر original کے ساتھ محفوظ ہوتی ہے، اس لیے یہ staging step ہے، مکمل backup نہیں۔ یہ صرف SQLite کے لیے ہے؛ MariaDB یا PostgreSQL پر یہ The database type is not SQLite. Backups only works for SQLite databases کے ساتھ رک جاتی ہے۔

جن فائلوں کو لوگ بھول جاتے ہیں

attachments/ میں غیر واضح ناموں کے تحت ciphertext محفوظ ہوتا ہے۔ ہر attachment کے لیے database row میں اس کا encrypted file name اور وہ key material موجود ہوتا ہے جس کی client کو file decrypt کرنے کے لیے ضرورت ہوتی ہے۔ database کے بغیر attachments ناقابلِ مطالعہ noise بن جاتی ہیں، اور attachments کے بغیر database میں users کو ایسی items نظر آتی ہیں جن کے downloads fail ہو جاتے ہیں۔ دونوں کو ایک ہی run میں backup کریں۔

config.json میں admin page سے محفوظ کی گئی تمام settings موجود ہوتی ہیں، اور اس کی values متعلقہ environment variables پر ترجیح رکھتی ہیں۔ اس کے دونوں پہلو ہیں: پرانی config.json بحال کرنے سے compose file میں موجود settings خاموشی سے override ہو جاتی ہیں، اور یہ file حساس ہے کیونکہ اس میں SMTP password اور admin token موجود ہو سکتے ہیں۔ اس token کو plain text کے بجائے Argon2id PHC (password hashing competition) string کے طور پر محفوظ کریں۔ docker run --rm -it vaultwarden/server /vaultwarden hash آپ کے لیے ایسی string بناتا ہے۔

rsa_key.pem ان JSON web tokens (JWT) پر دستخط کرتی ہے جو clients کو logged in رکھتے ہیں۔ startup کے وقت file موجود نہ ہو تو Vaultwarden نئی key بناتا ہے، اس لیے پرانی key سے signed ہر token کی validation ناکام ہو جاتی ہے اور تمام clients log out ہو جاتے ہیں۔ Vault contents اس سے محفوظ رہتے ہیں، کیونکہ وہ master password سے اخذ کردہ keys کے ذریعے encrypted ہوتے ہیں۔ key file بحال کرنے سے mass logout سے بچا جا سکتا ہے۔

sends/ میں Send links کے پیچھے موجود files محفوظ ہوتی ہیں۔ ان کے missing ہونے سے یہ downloads fail ہو جاتے ہیں، باقی کسی چیز پر اثر نہیں پڑتا۔

پورا کام ایک ہی script میں کریں

#!/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 اس وقت بھی 0 خارج کرتا ہے جب PRAGMA integrity_check خرابی کی اطلاع دے، اس لیے output کا ok سے موازنہ ہی خراب copy کو failed script میں تبدیل کرتا ہے۔ اس کے بعد set -euo pipefail سب کچھ روک دیتا ہے، بجائے اس کے کہ tar خراب database کے گرد ایک باضابطہ archive بنا دے۔

حتمی tar -tzf ان چیزوں کی فہرست دکھاتا ہے جنہیں آپ نے واقعی capture کیا ہے۔ اسے پہلی بار ہی غور سے پڑھیں۔ آپ کو ./db.sqlite3، ./rsa_key.pem، ./config.json اور ./attachments/ تلاش کرنے ہیں، اور ./db.sqlite3-wal کی عدم موجودگی کی تصدیق کرنی ہے۔ اگر آپ journalctl output اور failure report کرنے والی unit چاہتے ہیں تو اسے cron کے بجائے رات کو systemd service اور timer کے ذریعے چلائیں۔

بیک اپ کو scratch directory میں restore کر کے اس کی تصدیق کریں

غیر آزمودہ بیک اپ صرف ایک اندازہ ہوتا ہے۔ اسے scratch directory میں restore کرنے میں ایک منٹ لگتا ہے اور live ماحول میں کوئی تبدیلی نہیں ہوتی۔

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 کو print کرتا ہے۔ صارفین کی تعداد ان accounts کی تعداد کے برابر ہونی چاہیے جن کے بارے میں آپ جانتے ہیں۔ cipher کی تعداد sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select count(*) from ciphers;" سے حاصل ہونے والی live تعداد کے قریب ہونی چاہیے، اور زیرِ استعمال vault میں یہ کبھی صفر نہیں ہونی چاہیے۔ attachments directory کا حجم تقریباً آپ کی توقع کے مطابق ہونا چاہیے۔ اگر کوئی attachments upload نہیں کرتا تو آپ یہ جانچ چھوڑ سکتے ہیں۔ اس کے بعد sudo rm -rf /tmp/vw-check چلائیں، کیونکہ اس directory میں اب ہر چیز کی دوسری copy موجود ہے۔

جب بھی ہاتھ سے copy کیے گئے data folder کو restore کریں، server شروع کرنے سے پہلے db.sqlite3-wal اور db.sqlite3-shm حذف کر دیں۔ ورنہ SQLite بحال کیے گئے database کو ایسی log کے ذریعے recover کرنے کی کوشش کرے گا جو database کی کسی دوسری copy سے متعلق ہے۔ اس سے صحیح حالت میں پہنچنے والا database بھی corrupt ہو جاتا ہے۔ اوپر دیے گئے script سے بننے والے archives میں یہ files کبھی شامل نہیں ہوتیں، کیونکہ .backup ایک مکمل database لکھتا ہے۔

سرور پر بحال کریں

یہ کمانڈز اپنے سرور پر چلائیں، اور اس دوران container بند ہونا چاہیے۔ Data folder میں تبدیلی کے دوران 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 میں وہ user درج ہونا چاہیے جس کے طور پر container چلتا ہے۔ Stock image root کے طور پر چلتی ہے، اس لیے root:root درست ہے، الاّ یہ کہ آپ نے compose file میں user: مقرر کیا ہو۔ ایسی صورت میں وہی uid اور gid استعمال کریں۔ اگر server data folder میں نہیں لکھ سکتا تو login page ہر request پر ناکام ہو گا، اور logs میں اس کی وجہ درج ہو گی۔

درست start کا اختتام Rocket line پر ہوتا ہے:

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

اس کے بعد browser سے login کریں، کوئی item کھولیں، اور ایک attachment download کریں۔ اگر login کامیاب ہو لیکن attachment downloads ناکام ہوں تو archive میں database موجود ہے، مگر attachments/ موجود نہیں۔ جب تک یہ تمام checks کامیاب نہ ہو جائیں، data.old.* محفوظ رکھیں، پھر اسے delete کر دیں۔ Rollback کے لیے بھی یہی تین steps ہیں، لیکن directories کو دوسری سمت میں swap کریں۔

اگر آپ کے paths یہاں دیے گئے paths سے مختلف ہیں تو VPS کے لیے Vaultwarden installation guide میں وہ compose file موجود ہے جسے یہ کمانڈز فرض کرتی ہیں۔

بیک اپ کہاں نہیں رکھنا چاہیے

• ڈیٹا فولڈر والی اسی disk پر نہیں۔ ایک volume ناکام ہونے سے دونوں copies ضائع ہو جاتی ہیں، اور غلط path پر ایک rm -rf بھی یہی نتیجہ دے سکتا ہے۔
• اسی server پر نہیں، چاہے دوسری volume ہی کیوں نہ ہو۔ جس attacker کو root تک رسائی مل جائے، وہ اسی session میں آپ کے backups تک بھی پہنچ جاتا ہے۔
• encryption کے بغیر object storage میں نہیں، کیونکہ archive میں email addresses، password hints، recovery codes اور vault ciphertext شامل ہوتے ہیں، جن پر offline حملہ کیا جا سکتا ہے۔
• صرف اپنے provider کے snapshots پر انحصار نہ کریں۔ وہ تیزی سے restore ہو جاتے ہیں، اس لیے انہیں رکھنا مفید ہے، لیکن وہ اسی account میں موجود ہوتے ہیں جس میں server ہوتا ہے۔ account کا مسئلہ انہیں بھی متاثر کرتا ہے۔

Offsite copy کے لیے restic موزوں ہے، کیونکہ restic repository کسی بھی چیز کے upload ہونے سے پہلے machine پر encrypted ہو جاتی ہے۔ اپنے server پر:

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 کو live data folder کے بجائے archive directory کی طرف point کریں، تاکہ upload ہونے والی چیز وہ consistent copy ہو جسے آپ پہلے ہی چیک کر چکے ہیں۔ repository کا password اس server کے علاوہ کسی دوسری جگہ رکھیں جس کی حفاظت یہ repository کرتی ہے۔ یہ password کھو جائے تو design کے مطابق snapshots ناقابلِ مطالعہ ہو جائیں گے۔ جہاں storage اس کی سہولت دے، server کو ایسی credentials دیں جو write کر سکیں لیکن delete نہ کر سکیں، تاکہ server کے compromise ہونے سے وہ اپنی سابقہ history مٹا نہ سکے۔ VPS پر restic backups ترتیب دینا repository اور schedule کی مکمل وضاحت کرتا ہے، جبکہ restic کا BorgBackup سے موازنہ اس انتخاب میں مدد دیتا ہے اگر آپ نے ابھی فیصلہ نہیں کیا۔

شیڈول کے مطابق restore کی جانچ کریں

ماہانہ ایک دن مقرر کریں۔ جدید ترین snapshot کو restic restore latest --tag vaultwarden --target /tmp/vw-check کے ذریعے عارضی directory میں لائیں، وہی PRAGMA integrity_check چلائیں، وہی row counts چلائیں، پھر تاریخ اور counts درج کریں۔ جس backup کو چھ ماہ میں کسی نے restore نہ کیا ہو، اس کی حالت نامعلوم ہوتی ہے۔ outage کے دوران اس کی حالت معلوم کرنا پڑتی ہے، اور یہ جانچ کرنے کا بدترین وقت ہوتا ہے۔

سال میں ایک بار مکمل طریقہ انجام دیں۔ restore شدہ data folder کے ساتھ spare port پر دوسرا Vaultwarden container شروع کریں، اور حقیقی account سے login کریں۔ اس سے master password کا پورا end-to-end راستہ ثابت ہوتا ہے، جو کوئی row count ثابت نہیں کر سکتا۔ اسی schedule پر restic check --read-data-subset=10% چلانے سے تصدیق ہوتی ہے کہ stored data واقعی readable ہے، نہ کہ صرف فہرست میں دکھائی دے رہا ہے۔

FAQ

کیا Vaultwarden کے چلتے ہوئے cp کے ذریعے db.sqlite3 کاپی کر سکتا ہوں؟

نہیں۔ Vaultwarden SQLite کو WAL mode میں چلاتا ہے، اس لیے حالیہ writes db.sqlite3-wal میں موجود ہوتی ہیں اور ابھی db.sqlite3 میں شامل نہیں ہوتیں۔ صرف مرکزی فائل کی cp انہیں خاموشی سے ضائع کر دیتی ہے، جبکہ دونوں فائلوں کو الگ الگ کاپی کرنے سے ایسا غیر مطابقت رکھنے والا جوڑا بن سکتا ہے جو بعد میں Error: database disk image is malformed کی صورت میں ظاہر ہو۔ اس کے بجائے sqlite3 /path/db.sqlite3 ".backup '/path/out.sqlite3'" استعمال کریں۔ یہ SQLite کی Online Backup API استعمال کرتا ہے اور ایک مستقل فائل بناتا ہے، جبکہ server سروس فراہم کرتا رہتا ہے۔

کیا backup لینے کے لیے Vaultwarden container کو روکنا ضروری ہے؟

نہیں، اور یہی .backup کا مقصد ہے۔ چلتے ہوئے server پر database copy محفوظ ہے۔ Attachments اور Send files اس وقت لکھی جاتی ہیں جب کوئی user انہیں upload کرتا ہے، اس لیے database copy اور tar کے درمیان شامل ہونے والی فائل اس رات کے archive میں شامل نہ ہو سکے گی۔ بدترین صورت میں آپ ایک attachment سے محروم ہوں گے۔ اگر چند seconds کا downtime قابلِ قبول ہو تو script سے پہلے docker compose stop اور اس کے بعد docker compose start چلانے سے یہ امکان بھی ختم ہو جاتا ہے۔

اگر میں rsa_key files کے بغیر restore کروں تو کیا ہوگا؟

Vaultwarden startup کے وقت نئی key بناتا ہے۔ یہ key ان JSON web tokens (JWT) پر دستخط کرتی ہے جو sessions کو فعال رکھتے ہیں، اس لیے تمام موجودہ tokens کی توثیق ناکام ہو جاتی ہے، اور تمام clients logout ہو کر دوبارہ sign in کرنے پر مجبور ہوتے ہیں۔ Vault contents متاثر نہیں ہوتے، کیونکہ انہیں RSA key کے بجائے ہر user کے master password سے اخذ کردہ keys کے ذریعے encrypt کیا جاتا ہے۔ باقی data folder کے ساتھ rsa_key.pem بھی restore کریں، تو کسی کو restore کا علم نہیں ہوگا۔

کیا backup archive کو جوں کا توں object storage پر upload کرنا محفوظ ہے؟

نہیں۔ Item names، passwords اور notes ciphertext ہوتی ہیں، لیکن email addresses، account names، password hints اور two-factor recovery codes database میں plain text کی صورت میں موجود ہوتی ہیں۔ Offline attacker اپنی رفتار سے ciphertext کو آزمائش کے ذریعے decrypt کرنے کی کوشش کر سکتا ہے۔ Archive کو machine سے باہر بھیجنے سے پہلے encrypt کریں۔ restic repository یہ کام آپ کے لیے کرتی ہے، جبکہ gpg --symmetric --cipher-algo AES256 vw-20260805-030000.tar.gz ایک encrypted فائل بناتا ہے جسے آپ کسی بھی storage provider کے حوالے کر سکتے ہیں۔

PostgreSQL یا MariaDB پر Vaultwarden کا backup کیسے لوں؟

SQLite کے مراحل یہاں لاگو نہیں ہوتے، اور built-in command The database type is not SQLite. Backups only works for SQLite databases کے ساتھ ناکام ہو جاتی ہے۔ Database کو اس کے native tool، pg_dump یا mysqldump، کے ذریعے dump کریں، اور باقی تمام اصول برقرار رکھیں۔ Dump کو attachments/، sends/، config.json اور rsa_key files کے ساتھ ایک ہی archive میں شامل کریں۔ یہ تمام چیزیں اسی run میں حاصل کی جائیں، encrypt کی جائیں، اور اس server کے علاوہ کسی دوسری جگہ محفوظ کی جائیں جس نے backup بنایا ہو۔