Vaultwarden کا مکمل بیک اپ اور بحالی کا طریقہ

Vaultwarden بیک اپ میں کیا کچھ شامل ہونا چاہیے

Vaultwarden کا بیک اپ پورے ڈیٹا فولڈر کی ایک نقل ہوتا ہے، اور اس کے اندر موجود ڈیٹا بیس کو درست طریقے سے کاپی کرنا ضروری ہے۔ cp کے بجائے sqlite3 db.sqlite3 ".backup out.sqlite3" چلائیں، کیونکہ جس ڈیٹا بیس میں ڈیٹا لکھا جا رہا ہو اس کی سادہ کاپی کرنے سے ایسی فائل مل سکتی ہے جو کھلے گی نہیں۔ اس کے بعد اس کے ساتھ موجود دیگر فائلیں بھی محفوظ کریں، یہ وہ کام ہے جسے اکثر لوگ بھول جاتے ہیں۔

Docker انسٹالیشن میں ڈیٹا فولڈر وہی ہوتا ہے جسے آپ نے /data پر ماؤنٹ کیا ہوتا ہے۔ یہ یا تو ہوسٹ پر کوئی پاتھ ہوتا ہے یا کوئی named volume، اور bind mounts اور named volumes کے درمیان فرق یہ طے کرتا ہے کہ آپ کا والٹ ڈسک پر اصل میں کہاں موجود ہے۔ اس میں درج ذیل چیزیں شامل ہوتی ہیں۔

• db.sqlite3: ہر اکاؤنٹ، ہر والٹ آئٹم، ہر فولڈر اور ہر آرگنائزیشن۔ اس فائل کے کھو جانے کا مطلب والٹ کا کھو جانا ہے۔
• db.sqlite3-wal اور db.sqlite3-shm: write-ahead log (WAL) اور اس کا شیئرڈ میموری انڈیکس۔ حالیہ تبدیلیاں تب تک یہاں رہتی ہیں جب تک SQLite انہیں مرکزی فائل میں ضم نہیں کر دیتا۔
• attachments/: وہ فائلیں جو صارفین نے والٹ آئٹمز کے ساتھ منسلک کی ہوتی ہیں، یہ انکرپٹڈ ہوتی ہیں اور ہر آئٹم کے لیے ایک الگ ڈائریکٹری میں ہوتی ہیں۔
• 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=

آئٹم کے نام، یوزر نیم، پاس ورڈز اور نوٹس کلائنٹ کی طرف سے بھیجے جانے سے پہلے انکرپٹ (encrypt) کر دیے جاتے ہیں، لہذا سرور صرف ایسا سائفر ٹیکسٹ (ciphertext) اسٹور کرتا ہے جسے وہ پڑھ نہیں سکتا۔ 2. کا سابقہ (prefix) Bitwarden کی انکرپشن کی قسم ہے، جس کے بعد ایک انیشلائزیشن ویکٹر (IV)، سائفر ٹیکسٹ، اور ایک MAC (میسج اتھنٹیکیشن کوڈ) آتا ہے، جو ہر ایک base64 میں ہوتا ہے اور | سے الگ کیا جاتا ہے۔ اسے ڈکرپٹ کرنے والی کلید اکاؤنٹ کے ماسٹر پاس ورڈ سے اخذ کی جاتی ہے، جو کبھی بھی قابل استعمال شکل میں سرور تک نہیں پہنچتا۔ یہ حصہ بالکل ایک جیسا ہے چاہے آپ Vaultwarden چلائیں یا آفیشل سرور، جیسا کہ Vaultwarden اور self-hosted Bitwarden کا موازنہ میں تفصیل موجود ہے۔

ڈیٹا بیس کا باقی حصہ انکرپٹڈ نہیں ہوتا۔ ای میل ایڈریسز، اکاؤنٹ کے نام، پاس ورڈ کے اشارے (hints) اور ٹو-فیکٹر ریکوری کوڈز سادہ متن میں محفوظ ہوتے ہیں، ساتھ ہی میٹا ڈیٹا جیسے کہ تخلیق کے اوقات اور یہ کہ کون سی تنظیم کسی آئٹم کی مالک ہے۔ لہذا بیک اپ فائل خود ایک راز ہے۔ جو بھی اسے حاصل کرتا ہے وہ جان لیتا ہے کہ آپ کے صارفین کون ہیں، اور وہ انکرپٹڈ بلاکس پر آف لائن حملہ کر سکتا ہے، جس کی رفتار اس کے ہارڈویئر پر منحصر ہے۔ یہی ایک حقیقت نیچے دیے گئے اسٹوریج کے اصولوں کی بنیاد ہے: سرور سے باہر جانے سے پہلے کاپی کو انکرپٹ کیا جاتا ہے۔ ایڈمن ٹوکن اسی مسئلے کا دوسرا نصف ہے، اور self-hosted Vaultwarden کے لیے ہارڈننگ کا عمل ان دونوں پر کام کرتا ہے۔

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

Vaultwarden بائی ڈیفالٹ SQLite کو WAL موڈ میں چلاتا ہے (ENABLE_DB_WAL=true)۔ ایک write پہلے db.sqlite3-wal میں جاتا ہے، اور صرف ایک checkpoint اسے db.sqlite3 میں ضم کرتا ہے۔ اگر آپ صرف db.sqlite3 کو کاپی کریں گے تو آپ کو آخری checkpoint تک کا ڈیٹا بیس ملے گا، لہذا دس منٹ پہلے محفوظ کیا گیا پاس ورڈ آپ کے آرکائیو سے غائب ہو سکتا ہے اور آپ کو کوئی انتباہ بھی نہیں ملے گا۔

ان تینوں فائلوں کو cp کے ساتھ کاپی کرنا بھی کوئی حل نہیں ہے۔ کاپیاں تھوڑے مختلف لمحات پر لی جاتی ہیں، اس لیے جو WAL آپ نے محفوظ کیا ہے وہ ان صفحات کے ورژنز کو بیان کر سکتا ہے جن سے آپ کی محفوظ کردہ مین فائل اب مطابقت نہیں رکھتی۔ پھر SQLite ایک کو دوسرے سے ریکور کرتا ہے اور نتیجہ غلط نکلتا ہے۔ آپ کو اس کا پتہ بہت دیر بعد چلتا ہے:

Error: database disk image is malformed

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

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 پرنٹ کرتی ہے۔ اس کے علاوہ کوئی بھی نتیجہ ظاہر کرے کہ کاپی قابلِ استعمال نہیں ہے، لہذا اسے نہ رکھیں اور پچھلی کاپی کو بھی حذف نہ کریں۔ یہ پورا عمل ایک لائیو سرور پر چلتا ہے، اس لیے کوئی بھی صارف لاگ آؤٹ نہیں ہوتا اور کوئی کنٹینر ری اسٹارٹ نہیں ہوتا۔

sqlite3 ٹول Vaultwarden کنٹینر کے اندر موجود نہیں ہے۔ یہ امیج debian:trixie-slim پر ca-certificates، curl، libmariadb3، libpq5 اور openssl کے ساتھ بلڈ کی گئی ہے، اس لیے docker exec vaultwarden sqlite3 ... درج ذیل غلطی کے ساتھ ناکام ہو جاتا ہے:

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

اس کے بجائے اسے ہوسٹ پر ماؤنٹ شدہ پاتھ (mounted path) کے خلاف چلائیں، جیسا کہ اوپر دی گئی کمانڈز کرتی ہیں۔ اگر ڈیٹا ایک 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/ مبہم ناموں کے تحت سائفر ٹیکسٹ (ciphertext) کو محفوظ رکھتی ہے۔ ہر اٹیچمنٹ کے لیے ڈیٹا بیس کی قطار میں اس کا انکرپٹڈ فائل نام اور وہ کلیدی مواد (key material) موجود ہوتا ہے جس کی کلائنٹ کو فائل ڈکرپٹ کرنے کے لیے ضرورت ہوتی ہے۔ ڈیٹا بیس کے بغیر اٹیچمنٹس ناقابلِ مطالعہ شور (noise) ہیں، اور اٹیچمنٹس کے بغیر ڈیٹا بیس صارفین کو ایسی اشیاء دیتا ہے جن کی ڈاؤن لوڈ ناکام ہو جاتی ہے۔ دونوں کا بیک اپ ایک ہی رن میں لیں۔

config.json وہ سب کچھ محفوظ رکھتی ہے جو آپ نے ایڈمن پیج سے سیو کیا ہے، اور اس کی ویلیوز متعلقہ انوائرمنٹ ویری ایبلز (environment variables) پر فوقیت رکھتی ہیں۔ یہ دو طرفہ عمل ہے: ایک پرانی config.json کو بحال کرنا خاموشی سے آپ کی compose فائل کی سیٹنگز کو اوور رائڈ (override) کر دیتا ہے، اور یہ فائل بذاتِ خود حساس ہے کیونکہ اس میں آپ کا SMTP پاس ورڈ اور ایڈمن ٹوکن ہو سکتا ہے۔ اس ٹوکن کو سادہ ٹیکسٹ کے بجائے Argon2id PHC (پاس ورڈ ہیشنگ کمپیٹیشن) سٹرنگ کے طور پر اسٹور کریں۔ docker run --rm -it vaultwarden/server /vaultwarden hash آپ کے لیے ایک سٹرنگ پرنٹ کر دیتا ہے۔

rsa_key.pem ان JSON web tokens (JWT) پر دستخط کرتی ہے جو کلائنٹس کو لاگ ان رکھتے ہیں۔ اگر اسٹارٹ اپ پر یہ فائل موجود نہ ہو تو Vaultwarden ایک نئی کلید تیار کر لیتا ہے، جس کی وجہ سے پرانی کلید سے دستخط شدہ ہر ٹوکن کی توثیق رک جاتی ہے اور تمام کلائنٹس لاگ آؤٹ ہو جاتے ہیں۔ والٹ (Vault) کا مواد محفوظ رہتا ہے کیونکہ وہ ماسٹر پاس ورڈ سے اخذ کردہ کلیدوں کے ساتھ انکرپٹڈ ہوتا ہے۔ کلید فائل کو بحال کرنے سے بڑے پیمانے پر لاگ آؤٹ سے بچا جا سکتا ہے۔

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 تب بھی 0 exit دیتا ہے جب PRAGMA integrity_check کرپشن کی اطلاع دیتا ہے، لہذا آؤٹ پٹ کا موازنہ ok سے کرنا ہی ایک خراب کاپی کو ناکام اسکرپٹ میں بدل دیتا ہے۔ set -euo pipefail پھر سب کچھ روک دیتا ہے، بجائے اس کے کہ tar کو ایک ٹوٹے ہوئے ڈیٹا بیس کے گرد صاف ستھرا آرکائیو بنانے دیا جائے۔

حتمی tar -tzf ان چیزوں کی فہرست دیتا ہے جو آپ نے درحقیقت کیپچر کی ہیں۔ اسے پہلی بار پڑھیں۔ آپ ./db.sqlite3، ./rsa_key.pem، ./config.json اور ./attachments/ کو تلاش کر رہے ہیں، اور ./db.sqlite3-wal کی عدم موجودگی کو یقینی بنا رہے ہیں۔ اگر آپ 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;" سے حاصل کردہ لائیو اعداد و شمار کے قریب ہونی چاہیے، اور استعمال میں موجود والٹ کے لیے یہ کبھی صفر نہیں ہونی چاہیے۔ اٹیچمنٹس ڈائریکٹری کا سائز تقریباً اتنا ہی ہونا چاہیے جس کی آپ توقع رکھتے ہیں، اگر کوئی اٹیچمنٹ اپ لوڈ نہیں کرتا تو آپ اس مرحلے کو چھوڑ سکتے ہیں۔ اس کے بعد sudo rm -rf /tmp/vw-check چلائیں، کیونکہ اس ڈائریکٹری میں اب ہر چیز کی دوسری کاپی موجود ہے۔

ہاتھ سے کاپی کیے گئے کسی بھی ڈیٹا فولڈر کو بحال کرتے وقت ایک اصول یاد رکھیں: سرور شروع کرنے سے پہلے db.sqlite3-wal اور db.sqlite3-shm کو ڈیلیٹ کر دیں۔ بصورت دیگر SQLite بحال شدہ ڈیٹا بیس کو ایک ایسے لاگ کا استعمال کرتے ہوئے ریکور کرنے کی کوشش کرے گا جو اس کی کسی دوسری کاپی سے تعلق رکھتا ہے، اور یہ اس ڈیٹا بیس کو کرپٹ کر دے گا جو درست حالت میں پہنچا تھا۔ اوپر دی گئی اسکرپٹ سے تیار کردہ آرکائیوز میں یہ فائلیں کبھی شامل نہیں ہوتیں، کیونکہ .backup ایک مکمل ڈیٹا بیس لکھتی ہے۔

سرور پر بحالی

یہ عمل آپ کے اپنے سرور پر، کنٹینر کو روک کر انجام دیا جاتا ہے۔ ڈیٹا فولڈر میں تبدیلی کے دوران Vaultwarden کو لکھنا (write) نہیں چاہیے۔

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 میں اس صارف کا نام ہونا چاہیے جس کے تحت کنٹینر چلتا ہے۔ اسٹاک امیج root کے طور پر چلتی ہے، لہذا root:root درست ہے، سوائے اس کے کہ اگر آپ نے اپنی compose فائل میں user: سیٹ کیا ہو، ایسی صورت میں وہ uid اور gid استعمال کریں۔ اگر سرور ڈیٹا فولڈر میں لکھ نہیں سکتا تو لاگ ان صفحہ ہر درخواست کو ناکام بنا دے گا، اور لاگز میں اس کا ذکر موجود ہوگا۔

ایک کامیاب آغاز Rocket لائن پر ختم ہوتا ہے:

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

اس کے بعد براؤزر سے لاگ ان کریں، کوئی آئٹم کھولیں، اور ایک اٹیچمنٹ ڈاؤن لوڈ کریں۔ اگر لاگ ان کام کر رہا ہو لیکن اٹیچمنٹ ڈاؤن لوڈ ناکام ہو جائے تو اس کا مطلب ہے کہ آرکائیو میں ڈیٹا بیس تو موجود ہے لیکن attachments/ نہیں۔ جب تک سب کچھ درست طریقے سے چیک نہ ہو جائے data.old.* کو محفوظ رکھیں، اس کے بعد اسے حذف کر دیں۔ رول بیک (rollback) کا عمل بھی انہی تین مراحل پر مشتمل ہے، بس ڈائریکٹریز کو الٹ دیا جاتا ہے۔

اگر آپ کے پاتھ یہاں دیے گئے پاتھ سے میل نہیں کھاتے، تو VPS کے لیے Vaultwarden انسٹالیشن گائیڈ وہ compose فائل دکھاتی ہے جسے یہ کمانڈز فرض کرتی ہیں۔

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

• ڈیٹا فولڈر والی ڈسک پر نہ رکھیں۔ ایک خراب والیوم دونوں کاپیاں ضائع کر دیتا ہے، اور غلط پاتھ پر ایک rm -rf بھی یہی کام کرتا ہے۔
• اسی سرور پر نہ رکھیں، چاہے دوسرے والیوم پر ہی کیوں نہ ہو۔ جو حملہ آور root تک پہنچ جاتا ہے، وہ اسی سیشن میں آپ کے بیک اپ تک بھی پہنچ سکتا ہے۔
• انکرپشن کے بغیر آبجیکٹ اسٹوریج میں نہ رکھیں، کیونکہ آرکائیو میں ای میل ایڈریسز، پاس ورڈ ہنٹس، ریکوری کوڈز اور والٹ کا سائفر ٹیکسٹ ہوتا ہے جس پر آف لائن حملہ کیا جا سکتا ہے۔
• صرف اپنے پرووائیڈر کے اسنیپ شاٹس پر انحصار نہ کریں۔ وہ تیزی سے بحال ہو جاتے ہیں، جو کہ ایک اچھی بات ہے، لیکن وہ اسی اکاؤنٹ میں رہتے ہیں جس میں سرور ہے، لہذا اکاؤنٹ کا مسئلہ انہیں بھی ختم کر سکتا ہے۔

ایک آف سائٹ کاپی کے لیے 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 کو لائیو ڈیٹا فولڈر کے بجائے آرکائیو ڈائریکٹری کی طرف پوائنٹ کریں، تاکہ جو کچھ اپ لوڈ ہو وہ وہی مستقل کاپی ہو جس کی آپ پہلے ہی تصدیق کر چکے ہیں۔ ریپوزٹری کا پاس ورڈ سرور کے علاوہ کسی اور جگہ محفوظ رکھیں: اس پاس ورڈ کو کھونے کا مطلب ہے کہ اسنیپ شاٹس ناقابلِ مطالعہ ہو جائیں گے، اور یہ ڈیزائن کے عین مطابق ہے۔ جہاں اسٹوریج سپورٹ کرے، سرور کو ایسی اسناد (credentials) دیں جو صرف لکھ (write) سکیں لیکن ڈیلیٹ نہ کر سکیں، تاکہ سرور کے ہیک ہونے کی صورت میں وہ اپنی ہسٹری کو مٹا نہ سکے۔ VPS پر restic بیک اپ ترتیب دینا میں ریپوزٹری اور شیڈول کی مکمل تفصیل موجود ہے، اور restic بمقابلہ BorgBackup میں اس انتخاب کا موازنہ کیا گیا ہے اگر آپ نے ابھی تک فیصلہ نہیں کیا ہے۔

شیڈول کے مطابق بحالی (restore) کا ٹیسٹ کریں

مہینے میں ایک دن کا انتخاب کریں۔ restic restore latest --tag vaultwarden --target /tmp/vw-check کے ذریعے تازہ ترین اسنیپ شاٹ کو ایک scratch ڈائریکٹری میں لائیں، وہی PRAGMA integrity_check چلائیں، وہی row counts چیک کریں، اور پھر تاریخ اور counts کو نوٹ کر لیں۔ ایسا بیک اپ جسے چھ ماہ سے کسی نے بحال (restore) نہ کیا ہو، اس کی حالت غیر یقینی ہوتی ہے۔ اگر آپ اس کی حالت کسی خرابی (outage) کے دوران جانیں گے، تو یہ سب سے برا وقت ہوگا۔

سال میں ایک بار، مکمل عمل دہرائیں۔ بحال شدہ ڈیٹا فولڈر کے ساتھ ایک اضافی پورٹ پر دوسرا Vaultwarden کنٹینر شروع کریں، اور ایک اصلی اکاؤنٹ کے ساتھ لاگ ان کریں۔ یہ عمل master password کے پورے راستے کی تصدیق کرتا ہے، جو کہ صرف row count سے ممکن نہیں ہے۔ اسی شیڈول پر restic check --read-data-subset=10% چلانے سے یہ تصدیق ہوتی ہے کہ ذخیرہ شدہ ڈیٹا صرف فہرست میں موجود نہیں بلکہ پڑھنے کے قابل بھی ہے۔

FAQ

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

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

کیا بیک اپ لینے کے لیے مجھے Vaultwarden کنٹینر کو روکنا ہوگا؟

نہیں۔ .backup کا مقصد ہی یہی ہے۔ چلتے ہوئے سرور پر ڈیٹا بیس کی کاپی محفوظ ہے۔ اٹیچمنٹس اور Send فائلیں تب لکھی جاتی ہیں جب صارف انہیں اپ لوڈ کرتا ہے، لہذا ڈیٹا بیس کی کاپی اور tar کے درمیان شامل کی گئی فائل اس رات کے آرکائیو میں شامل ہونے سے رہ سکتی ہے، جس کا زیادہ سے زیادہ نقصان صرف ایک اٹیچمنٹ کا ضیاع ہے۔ اگر آپ کو چند سیکنڈ کی ڈاؤن ٹائم سے مسئلہ نہیں ہے، تو اسکرپٹ سے پہلے docker compose stop اور بعد میں docker compose start کرنے سے یہ معمولی خطرہ بھی ختم ہو جاتا ہے۔

اگر میں rsa_key فائلوں کے بغیر بحالی (restore) کروں تو کیا ہوگا؟

Vaultwarden اسٹارٹ اپ پر ایک نئی کلید (key) تیار کرتا ہے۔ یہ کلید JSON web tokens (JWT) پر دستخط کرتی ہے جو سیشنز کو فعال رکھتے ہیں، لہذا ہر موجودہ ٹوکن کی توثیق ختم ہو جاتی ہے اور تمام کلائنٹس لاگ آؤٹ ہو جاتے ہیں اور انہیں دوبارہ لاگ ان کرنا پڑتا ہے۔ والٹ (Vault) کا مواد متاثر نہیں ہوتا، کیونکہ وہ RSA کلید کے بجائے ہر صارف کے ماسٹر پاس ورڈ سے اخذ کردہ کلیدوں کے ذریعے انکرپٹ ہوتا ہے۔ ڈیٹا فولڈر کے باقی حصوں کے ساتھ rsa_key.pem کو بھی بحال کریں تاکہ کسی کو بحالی کا پتہ نہ چلے۔

کیا بیک اپ آرکائیو کو اسی حالت میں آبجیکٹ اسٹوریج پر اپ لوڈ کرنا محفوظ ہے؟

نہیں۔ آئٹم کے نام، پاس ورڈز اور نوٹس سائفر ٹیکسٹ ہوتے ہیں، لیکن ای میل ایڈریس، اکاؤنٹ کے نام، پاس ورڈ ہنٹس اور ٹو-فیکٹر ریکوری کوڈز ڈیٹا بیس میں سادہ متن (plain text) میں ہوتے ہیں، اور ایک آف لائن حملہ آور اپنی رفتار سے سائفر ٹیکسٹ کو توڑنے کی کوشش کر سکتا ہے۔ آرکائیو کو مشین سے باہر بھیجنے سے پہلے انکرپٹ کریں۔ ایک restic ریپوزٹری آپ کے لیے یہ کام کرتی ہے، اور gpg --symmetric --cipher-algo AES256 vw-20260805-030000.tar.gz ایک واحد انکرپٹڈ فائل تیار کرتا ہے جسے آپ کسی بھی اسٹوریج پر رکھ سکتے ہیں۔

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

SQLite کے مراحل یہاں لاگو نہیں ہوتے، اور بلٹ ان کمانڈ The database type is not SQLite. Backups only works for SQLite databases کے ساتھ انکار کر دیتی ہے۔ ڈیٹا بیس کو اس کے مقامی ٹول، pg_dump یا mysqldump کے ذریعے ڈمپ کریں، اور باقی تمام اصول وہی رکھیں۔ ڈمپ کو attachments/، sends/، config.json اور rsa_key فائلوں کے ساتھ ایک ہی آرکائیو میں ہونا چاہیے، جسے ایک ہی رن میں لیا جائے، انکرپٹ کیا جائے، اور اسے بنانے والے سرور کے علاوہ کہیں اور محفوظ کیا جائے۔