Vaultwarden का backup और restore कैसे करें

Vaultwarden backup में क्या शामिल होना चाहिए

Vaultwarden backup पूरे data folder की एक प्रतिलिपि होती है, और इसके अंदर मौजूद database को सही तरीके से copy किया जाना चाहिए। cp के बजाय sqlite3 db.sqlite3 ".backup out.sqlite3" चलाएं, क्योंकि जिस database में data लिखा जा रहा हो, उसकी साधारण copy करने से ऐसी file मिल सकती है जो खुलेगी नहीं। इसके बाद, उसके साथ वाली files को सुरक्षित रखें, जिसे अक्सर लोग भूल जाते हैं।

Docker install पर data folder वह होता है जिसे आपने /data पर mount किया है। यह host पर कोई path या named volume हो सकता है, और bind mounts और named volumes के बीच का अंतर यह तय करता है कि आपका vault डिस्क पर वास्तव में कहाँ स्थित है। इसमें निम्नलिखित चीजें होती हैं।

• db.sqlite3: प्रत्येक account, प्रत्येक vault item, प्रत्येक folder और प्रत्येक organisation। इस file के खोने का मतलब है vault का खो जाना।
• db.sqlite3-wal और db.sqlite3-shm: write-ahead log (WAL) और इसका shared memory index। हाल के writes तब तक यहाँ रहते हैं जब तक SQLite उन्हें मुख्य file में शामिल नहीं कर लेता।
• attachments/: वे files जो users ने vault items के साथ attach की हैं, जो encrypted होती हैं और प्रति item एक directory में रहती हैं।
• sends/: Bitwarden Send links के पीछे की files।
• config.json: admin page से save की गई आपकी प्रत्येक setting।
• rsa_key.pem, और पुराने installs पर rsa_key.der तथा rsa_key.pub.der: वह key जो login tokens को sign करती है।
• icon_cache/: download की गई website icons। यह एकमात्र directory है जिसे आप छोड़ सकते हैं, क्योंकि Vaultwarden जरूरत पड़ने पर इन्हें फिर से fetch कर लेता है।

क्या मेरा 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 में होते हैं और | द्वारा अलग किए जाते हैं। इसे डिक्रिप्ट करने वाली की (key) अकाउंट के मास्टर पासवर्ड से प्राप्त होती है, जो कभी भी उपयोग योग्य रूप में सर्वर तक नहीं पहुँचता है। यह हिस्सा Vaultwarden या आधिकारिक सर्वर, दोनों में समान है, जैसा कि Vaultwarden और self-hosted Bitwarden की तुलना में विस्तार से बताया गया है।

डेटाबेस का बाकी हिस्सा एन्क्रिप्टेड नहीं होता है। ईमेल पते, अकाउंट के नाम, पासवर्ड हिंट और टू-फैक्टर रिकवरी कोड सादे टेक्स्ट के रूप में स्टोर किए जाते हैं, साथ ही मेटाडेटा जैसे कि निर्माण का समय और यह जानकारी कि कौन सा संगठन किसी आइटम का स्वामी है। इसलिए बैकअप फ़ाइल स्वयं एक रहस्य है। जिसके पास भी यह फ़ाइल है, उसे पता चल जाता है कि आपके उपयोगकर्ता कौन हैं, और वह एन्क्रिप्टेड ब्लब्स (blobs) पर अपनी हार्डवेयर क्षमता के अनुसार ऑफ़लाइन हमला कर सकता है। यही एकमात्र तथ्य नीचे दिए गए स्टोरेज नियमों को निर्धारित करता है: सर्वर से बाहर जाने से पहले कॉपी को एन्क्रिप्ट किया जाता है। एडमिन टोकन इसी समस्या का दूसरा आधा हिस्सा है, और 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 इसके नीचे फाइल को बदल देता है तो यह प्रक्रिया फिर से शुरू कर देता है, इसलिए डिस्क पर जो डेटा आता है वह एक सुसंगत (consistent) स्थिति का होता है।

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

इसके बजाय इसे होस्ट पर माउंट किए गए पाथ के विरुद्ध चलाएं, जैसा कि ऊपर दिए गए कमांड्स करते हैं। यदि डेटा एक 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 को सुरक्षित रखता है। प्रत्येक attachment के लिए database row में उसका encrypted फाइल नाम और वह key material होता है जिसकी client को फाइल decrypt करने के लिए आवश्यकता होती है। database के बिना attachments केवल अपठनीय शोर (noise) हैं, और attachments के बिना database उपयोगकर्ताओं को ऐसी वस्तुएं देता है जिन्हें download करना विफल हो जाता है। दोनों को एक ही बार में backup करें।

config.json admin page से आपके द्वारा save की गई हर चीज़ को रखता है, और इसके मान (values) मेल खाने वाले environment variables से अधिक प्राथमिकता रखते हैं। यह दोनों तरफ काम करता है: एक पुराने config.json को restore करने से आपके compose फाइल की settings चुपचाप override हो जाती हैं, और यह फाइल स्वयं संवेदनशील है क्योंकि इसमें आपका SMTP password और admin token हो सकता है। उस token को plain text के बजाय Argon2id PHC (password hashing competition) string के रूप में store करें। docker run --rm -it vaultwarden/server /vaultwarden hash आपके लिए एक string print करता है।

rsa_key.pem उन JSON web tokens (JWT) को sign करता है जो clients को logged in रखते हैं। यदि startup के समय यह फाइल मौजूद नहीं होती है, तो Vaultwarden एक नई key generate करता है, जिससे पुरानी key द्वारा sign किया गया हर token validate होना बंद हो जाता है और सभी clients logout हो जाते हैं। Vault की सामग्री सुरक्षित रहती है, क्योंकि वे master password से प्राप्त keys के साथ encrypted होती हैं। key फाइल को restore करने से सामूहिक logout से बचा जा सकता है।

sends/ Send links के पीछे की फाइलों को रखता है। इनके खो जाने से केवल वे downloads काम करना बंद कर देते हैं, बाकी सब ठीक रहता है।

पूरी प्रक्रिया को एक स्क्रिप्ट में रखें

#!/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 लाइन वास्तविक कार्य करती है: PRAGMA integrity_check द्वारा corruption की रिपोर्ट करने पर भी sqlite3, 0 exit code देता है, इसलिए आउटपुट की तुलना ok से करना ही एक खराब कॉपी को विफल स्क्रिप्ट में बदल देता है। set -euo pipefail फिर सब कुछ रोक देता है, बजाय इसके कि tar एक टूटे हुए डेटाबेस के चारों ओर एक व्यवस्थित आर्काइव बनाए।

अंतिम tar -tzf उन फाइलों की सूची देता है जिन्हें आपने वास्तव में कैप्चर किया है। इसे पहली बार ध्यान से पढ़ें। आप ./db.sqlite3, ./rsa_key.pem, ./config.json और ./attachments/ की तलाश कर रहे हैं, और यह सुनिश्चित कर रहे हैं कि ./db.sqlite3-wal मौजूद न हो। यदि आप journalctl आउटपुट और विफलता की रिपोर्ट करने वाली यूनिट चाहते हैं, तो इसे cron के बजाय systemd service और timer के साथ nightly चलाएं।

बैकअप को एक स्क्रैच डायरेक्टरी में रिस्टोर करके सत्यापित करें

बिना टेस्ट किया हुआ बैकअप केवल एक अनुमान है। एक स्क्रैच डायरेक्टरी में रिस्टोर करने में केवल एक मिनट लगता है और इससे लाइव डेटा प्रभावित नहीं होता है।

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) की संख्या sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select count(*) from ciphers;" से प्राप्त लाइव आंकड़े के करीब होनी चाहिए, और उपयोग में आने वाले वॉल्ट (vault) के लिए यह कभी भी शून्य नहीं होती है। अटैचमेंट डायरेक्टरी का आकार लगभग उतना ही होना चाहिए जितना आप उम्मीद करते हैं, जिसे आप छोड़ सकते हैं यदि कोई अटैचमेंट अपलोड नहीं करता है। इसके बाद sudo rm -rf /tmp/vw-check चलाएं, क्योंकि उस डायरेक्टरी में अब हर चीज की दूसरी कॉपी मौजूद है।

किसी भी हाथ से कॉपी किए गए डेटा फोल्डर को रिस्टोर करते समय एक नियम का पालन करें: सर्वर शुरू करने से पहले db.sqlite3-wal और db.sqlite3-shm को डिलीट कर दें। अन्यथा, SQLite रिस्टोर किए गए डेटाबेस को एक ऐसे लॉग का उपयोग करके रिकवर करने का प्रयास करेगा जो उसकी किसी दूसरी कॉपी से संबंधित है, और इससे वह डेटाबेस करप्ट हो जाएगा जो सही सलामत रिस्टोर हुआ था। ऊपर दी गई स्क्रिप्ट द्वारा बनाए गए आर्काइव में ये फाइलें कभी नहीं होती हैं, क्योंकि .backup एक पूर्ण डेटाबेस लिखता है।

सर्वर पर रिस्टोर करना

ये कमांड्स आपके अपने सर्वर पर चलते हैं, जब कंटेनर बंद हो। डेटा फोल्डर में बदलाव करते समय 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 में उस यूजर का नाम होना चाहिए जिसके रूप में कंटेनर चलता है। स्टॉक इमेज root के रूप में चलती है, इसलिए root:root सही है, जब तक कि आपने अपने compose file में user: सेट न किया हो; उस स्थिति में उस uid और gid का उपयोग करें। यदि सर्वर डेटा फोल्डर में लिख नहीं सकता, तो लॉगिन पेज हर रिक्वेस्ट को फेल कर देगा, और लॉग्स में यह जानकारी दिखाई देगी।

एक सफल स्टार्ट Rocket लाइन के साथ समाप्त होता है:

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

इसके बाद ब्राउज़र से लॉगिन करें, एक आइटम खोलें, और एक अटैचमेंट डाउनलोड करें। यदि लॉगिन काम करता है लेकिन अटैचमेंट डाउनलोड फेल हो जाते हैं, तो इसका मतलब है कि आर्काइव में डेटाबेस तो आ गया लेकिन attachments/ नहीं आया। जब तक सब कुछ सही ढंग से काम न करने लगे, तब तक data.old.* को सुरक्षित रखें, उसके बाद ही उसे डिलीट करें। रोलबैक करने के लिए इन्हीं तीन स्टेप्स को अपनाएं और डायरेक्टरीज को आपस में बदल दें।

यदि आपके पाथ यहाँ दिए गए पाथ से मेल नहीं खाते हैं, तो VPS के लिए Vaultwarden इंस्टॉल गाइड वह compose file दिखाती है जिसे ये कमांड्स आधार मानकर चलते हैं।

बैकअप कहाँ न रखें

• डेटा फोल्डर वाली डिस्क पर ही बैकअप न रखें। एक वॉल्यूम फेल होने पर दोनों प्रतियाँ नष्ट हो जाती हैं, और गलत पाथ पर एक rm -rf भी यही परिणाम देता है।
• एक ही सर्वर पर बैकअप न रखें, भले ही वह दूसरे वॉल्यूम पर हो। जो हमलावर root एक्सेस प्राप्त कर लेता है, वह उसी सत्र में आपके बैकअप तक भी पहुँच सकता है।
• एन्क्रिप्शन के बिना ऑब्जेक्ट स्टोरेज में न रखें, क्योंकि आर्काइव में ईमेल पते, पासवर्ड हिंट, रिकवरी कोड और वॉल्ट का ciphertext होता है जिसे ऑफलाइन अटैक किया जा सकता है।
• केवल अपने प्रोवाइडर के स्नैपशॉट्स पर निर्भर न रहें। वे तेजी से रिस्टोर होते हैं, जो कि उपयोगी है, लेकिन वे सर्वर वाले अकाउंट में ही रहते हैं, इसलिए अकाउंट संबंधी समस्या होने पर वे भी साथ ही चले जाते हैं।

एक ऑफसाइट कॉपी के लिए 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 को लाइव डेटा फोल्डर के बजाय आर्काइव डायरेक्टरी पर पॉइंट करें, ताकि जो अपलोड हो वह वही सुसंगत (consistent) कॉपी हो जिसे आपने पहले ही चेक कर लिया है। रिपॉजिटरी पासवर्ड को उस सर्वर के अलावा कहीं और रखें जिसकी यह सुरक्षा करता है: यदि वह पासवर्ड खो गया, तो डिज़ाइन के अनुसार स्नैपशॉट्स को पढ़ा नहीं जा सकेगा। जहाँ स्टोरेज इसका समर्थन करता है, वहाँ सर्वर को ऐसे क्रेडेंशियल्स दें जो केवल लिख (write) सकें लेकिन डिलीट न कर सकें, ताकि सर्वर के ब्रीच होने पर वह अपना इतिहास खुद मिटा न सके। VPS पर restic बैकअप सेट अप करना में रिपॉजिटरी और शेड्यूल के बारे में पूरी जानकारी दी गई है, और restic बनाम BorgBackup में चुनाव के बारे में बताया गया है यदि आपने अभी तक निर्णय नहीं लिया है।

नियमित अंतराल पर रिस्टोर का परीक्षण करें

महीने में एक दिन चुनें। restic restore latest --tag vaultwarden --target /tmp/vw-check का उपयोग करके सबसे नया स्नैपशॉट एक स्क्रैच डायरेक्टरी में लाएं, वही PRAGMA integrity_check चलाएं, वही रो काउंट (row counts) जांचें, और फिर तारीख तथा काउंट को नोट कर लें। जिस बैकअप को छह महीने से रिस्टोर नहीं किया गया है, उसकी स्थिति अज्ञात है। यदि आप किसी आउटेज के दौरान इसकी स्थिति का पता लगाते हैं, तो यह सबसे खराब समय होता है।

साल में एक बार, पूर्ण संस्करण का परीक्षण करें। रिस्टोर किए गए डेटा फोल्डर के साथ एक अतिरिक्त पोर्ट पर दूसरा Vaultwarden कंटेनर शुरू करें, और एक वास्तविक अकाउंट से लॉग इन करें। यह एंड-टू-एंड मास्टर पासवर्ड पाथ को प्रमाणित करता है, जो केवल रो काउंट से संभव नहीं है। इसी शेड्यूल पर restic check --read-data-subset=10% चलाने से यह सुनिश्चित होता है कि संग्रहीत डेटा केवल लिस्ट ही नहीं, बल्कि पढ़ने योग्य भी है।

FAQ

क्या मैं Vaultwarden चलते समय cp का उपयोग करके db.sqlite3 को कॉपी कर सकता हूँ?

नहीं। Vaultwarden, SQLite को WAL मोड में चलाता है, इसलिए हाल के 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 का उपयोग करता है और सर्वर के चलते रहने के दौरान ही एक सुसंगत फ़ाइल तैयार करता है।

क्या बैकअप लेने के लिए मुझे Vaultwarden कंटेनर को रोकना होगा?

नहीं, और यही .backup का मुख्य उद्देश्य है। चलते हुए सर्वर पर डेटाबेस की कॉपी सुरक्षित रहती है। Attachments और Send फ़ाइलें तब लिखी जाती हैं जब कोई उपयोगकर्ता उन्हें अपलोड करता है, इसलिए डेटाबेस कॉपी और tar के बीच जोड़ी गई कोई फ़ाइल उस रात के आर्काइव में छूट सकती है, जिससे अधिकतम एक अटैचमेंट का नुकसान हो सकता है। यदि आपको कुछ सेकंड का डाउनटाइम स्वीकार्य है, तो स्क्रिप्ट से पहले docker compose stop और उसके बाद docker compose start चलाने से यह छोटी सी समस्या भी दूर हो जाती है।

यदि मैं rsa_key फ़ाइलों के बिना रिस्टोर करूँ तो क्या होगा?

Vaultwarden स्टार्टअप पर एक नई की (key) जेनरेट करता है। वह की उन JSON web tokens (JWT) को साइन करती है जो सेशन को सक्रिय रखते हैं, इसलिए सभी मौजूदा टोकन अमान्य हो जाएंगे और सभी क्लाइंट्स लॉग आउट हो जाएंगे, जिन्हें फिर से साइन इन करना होगा। वॉल्ट की सामग्री प्रभावित नहीं होती है, क्योंकि वे RSA की के बजाय प्रत्येक उपयोगकर्ता के मास्टर पासवर्ड से प्राप्त कीज़ के साथ एन्क्रिप्टेड होती हैं। डेटा फ़ोल्डर के बाकी हिस्सों के साथ rsa_key.pem को भी रिस्टोर करें, इससे किसी को रिस्टोर का पता नहीं चलेगा।

क्या बैकअप आर्काइव को वैसे ही ऑब्जेक्ट स्टोरेज पर अपलोड करना सुरक्षित है?

नहीं। आइटम के नाम, पासवर्ड और नोट्स सिफरटेक्स्ट (ciphertext) में होते हैं, लेकिन ईमेल पते, अकाउंट के नाम, पासवर्ड हिंट और टू-फैक्टर रिकवरी कोड डेटाबेस में प्लेन टेक्स्ट में होते हैं, और एक ऑफलाइन हमलावर अपनी गति से सिफरटेक्स्ट को डिक्रिप्ट करने का प्रयास कर सकता है। आर्काइव को मशीन से बाहर भेजने से पहले उसे एन्क्रिप्ट करें। एक 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 फ़ाइलों के साथ एक ही आर्काइव में रखा जाना चाहिए, जिसे एक ही बार में लिया जाए, एन्क्रिप्ट किया जाए और उस सर्वर के अलावा कहीं और स्टोर किया जाए जिसने इसे बनाया है।