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 disk पर वास्तव में कहाँ स्थित है। इसमें निम्नलिखित चीजें होती हैं।

• db.sqlite3: प्रत्येक account, प्रत्येक vault item, प्रत्येक folder और प्रत्येक organisation। इस file के खोने का मतलब है vault का खो जाना।
• db.sqlite3-wal और db.sqlite3-shm: write-ahead log (WAL) और इसका shared memory index। हाल ही में किए गए बदलाव तब तक यहाँ रहते हैं जब तक SQLite उन्हें मुख्य file में शामिल नहीं कर लेता।
• attachments/: vault items के साथ users द्वारा attach की गई files, जो 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 में होते हैं और | द्वारा अलग किए जाते हैं। इसे डिक्रिप्ट करने वाली कुंजी खाते के मास्टर पासवर्ड से प्राप्त होती है, जो कभी भी उपयोगी रूप में सर्वर तक नहीं पहुँचता है। यह हिस्सा Vaultwarden या आधिकारिक सर्वर, दोनों में समान है, जैसा कि Vaultwarden और self-hosted Bitwarden की तुलना में बताया गया है।

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

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 के लिए डेटाबेस पंक्ति में उसका एन्क्रिप्टेड फाइल नाम और वह key material होता है जिसकी क्लाइंट को फाइल डिक्रिप्ट करने के लिए आवश्यकता होती है। डेटाबेस के बिना attachments अपठनीय शोर (noise) हैं, और attachments के बिना डेटाबेस उपयोगकर्ताओं को ऐसी वस्तुएं देता है जिनके डाउनलोड विफल हो जाते हैं। दोनों को एक ही रन में लें।

config.json वह सब कुछ रखता है जिसे आपने admin पेज से सेव किया है, और इसके मान मेल खाने वाले environment variables पर प्राथमिकता लेते हैं। यह दोनों तरह से काम करता है: एक पुराने config.json को रिस्टोर करने से आपके compose फाइल की सेटिंग्स चुपचाप ओवरराइड हो जाती हैं, और फाइल स्वयं संवेदनशील है क्योंकि इसमें आपका SMTP पासवर्ड और admin टोकन हो सकता है। उस टोकन को plain text के बजाय Argon2id PHC (password hashing competition) स्ट्रिंग के रूप में स्टोर करें। docker run --rm -it vaultwarden/server /vaultwarden hash आपके लिए एक प्रिंट करता है।

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

sends/ Send लिंक्स के पीछे की फाइलों को रखता है। उन्हें खोने से केवल वे डाउनलोड टूट जाते हैं और कुछ नहीं।

पूरी प्रक्रिया को एक ही 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 के रूप में save करें, इसे chmod 700 करें, और root के रूप में चलाएँ। test लाइन वास्तविक कार्य करती है: sqlite3 तब भी 0 exit status देता है जब PRAGMA integrity_check corruption की रिपोर्ट करता है, इसलिए output की तुलना ok से करना ही एक खराब copy को विफल script में बदल देता है। set -euo pipefail फिर सब कुछ रोक देता है, बजाय इसके कि tar एक टूटे हुए database के चारों ओर एक व्यवस्थित archive बनाए।

अंतिम tar -tzf उन फाइलों की सूची दिखाता है जिन्हें आपने वास्तव में capture किया है। इसे पहली बार ध्यान से पढ़ें। आप ./db.sqlite3, ./rsa_key.pem, ./config.json और ./attachments/ की तलाश कर रहे हैं, और यह सुनिश्चित कर रहे हैं कि ./db.sqlite3-wal मौजूद न हो। यदि आप journalctl output और विफलता की रिपोर्ट करने वाली unit चाहते हैं, तो इसे cron के बजाय a systemd service and 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 प्रिंट करता है। यूजर काउंट उन अकाउंट्स की संख्या से मेल खाना चाहिए जिनके बारे में आप जानते हैं। साइफर काउंट 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 एक पूर्ण डेटाबेस लिखता है।

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

ये कमांड्स आपके अपने सर्वर पर चलते हैं, जब container बंद हो। Vaultwarden को तब तक नहीं लिखना चाहिए जब तक कि data folder में बदलाव हो रहा हो।

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 लाइन के साथ समाप्त होती है:

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

इसके बाद browser से login करें, एक item खोलें, और एक attachment download करें। यदि login काम करता है लेकिन attachment download विफल हो जाता है, तो इसका मतलब है कि archive में database तो आ गया है लेकिन attachments/ नहीं। जब तक सब कुछ सही ढंग से काम न करे, तब तक data.old.* को सुरक्षित रखें, उसके बाद ही उसे delete करें। rollback करने के लिए इन्हीं तीन steps को directories को आपस में बदलकर दोहराएं।

यदि आपके paths यहाँ दिए गए paths से मेल नहीं खाते हैं, तो VPS के लिए Vaultwarden install guide वह compose file दिखाती है जिसे ये commands आधार मानकर चलते हैं।

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

• डेटा फोल्डर वाली डिस्क पर ही बैकअप न रखें। एक वॉल्यूम फेल होने पर दोनों प्रतियाँ नष्ट हो जाएंगी, और गलत पाथ पर 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 को लाइव डेटा फोल्डर के बजाय आर्काइव डायरेक्टरी पर पॉइंट करें, ताकि जो अपलोड हो वह वही सुसंगत (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 के बीच जोड़ी गई कोई फ़ाइल उस रात के आर्काइव में छूट सकती है, जिससे अधिक से अधिक एक attachment का नुकसान हो सकता है। यदि कुछ सेकंड का डाउनटाइम आपको परेशान नहीं करता है, तो स्क्रिप्ट से पहले docker compose stop और उसके बाद docker compose start चलाने से यह समस्या भी खत्म हो जाती है।

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

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

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

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