VPS वर Vaultwarden बॅकअप आणि restore कसे करावे

Vaultwarden बॅकअपमध्ये काय असणे आवश्यक आहे

Vaultwarden बॅकअप म्हणजे संपूर्ण data folder ची प्रत. त्यातील database ची प्रत योग्य पद्धतीने घेणे आवश्यक आहे. cp ऐवजी sqlite3 db.sqlite3 ".backup out.sqlite3" चालवा. लिहिला जात असलेल्या database ची साधी प्रत घेतल्यास उघडता न येणारी file तयार होऊ शकते. त्यासोबत असलेल्या इतर files देखील जतन करा. हा भाग अनेकदा विसरला जातो.

Docker install मध्ये data folder म्हणजे तुम्ही /data वर mount केलेला folder. तो 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. SQLite त्यांना मुख्य file मध्ये समाविष्ट करेपर्यंत अलीकडील writes येथे साठतात.
• attachments/: वापरकर्त्यांनी vault items सोबत जोडलेल्या files. त्या encrypted असतात आणि प्रत्येक item साठी स्वतंत्र directory मध्ये ठेवलेल्या असतात.
• sends/: Bitwarden Send links मागील files.
• config.json: admin page वरून जतन केलेली प्रत्येक setting.
• rsa_key.pem, तसेच जुन्या installs मध्ये rsa_key.der आणि rsa_key.pub.der: login tokens वर स्वाक्षरी करणारी key.
• icon_cache/: डाउनलोड केलेले website icons. ही एकमेव directory वगळू शकता, कारण Vaultwarden गरजेनुसार ती पुन्हा fetch करतो.

तुमचा Vaultwarden database सुरक्षित आहे का? फाइलमध्ये नेमके काय असते

याचे उत्तर दोन commands देतात. तुम्ही दोन्ही 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 चे नाव दाखवतो. त्याचा परिणाम असा दिसतो:

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 पासून तयार होते. हा 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 आणि एखाद्या item ची मालकी कोणत्या organisation कडे आहे यांसारखा metadata साठवला जातो. त्यामुळे backup file स्वतः एक secret असते. ती file ज्याच्याकडे असेल त्याला तुमचे users कोण आहेत हे समजते. तसेच तो encrypted blobs वर hardware ज्या वेगाने परवानगी देईल त्या वेगाने offline attack करू शकतो. या एकाच कारणामुळे पुढील storage नियम ठरतात: copy server सोडण्यापूर्वी encrypt केली जाते.

Vaultwarden चालू असताना db.sqlite3 कॉपी करणे हा backup का नाही

Vaultwarden डीफॉल्टनुसार SQLite WAL मोडमध्ये चालवते (ENABLE_DB_WAL=true). लेखन प्रथम db.sqlite3-wal मध्ये होते आणि checkpoint झाल्यावरच ते db.sqlite3 मध्ये समाविष्ट होते. केवळ db.sqlite3 कॉपी केल्यास, शेवटच्या checkpointच्या वेळची database मिळते. त्यामुळे दहा मिनिटांपूर्वी जतन केलेला password archive मध्ये नसू शकतो आणि याची कोणतीही सूचना मिळत नाही.

cp वापरून तिन्ही files कॉपी करणे हाही उपाय नाही. या copies थोड्या वेगवेगळ्या क्षणी घेतल्या जातात. त्यामुळे जतन केलेली WAL file अशा page versionsचे वर्णन करू शकते, ज्या तुम्ही जतन केलेल्या main file शी आता जुळत नाहीत. त्यानंतर SQLite एका file मधून दुसरी file recover करते आणि चुकीचा परिणाम मिळतो. हे तुम्हाला बरेच उशिरा कळते:

Error: database disk image is malformed

.backup ही समस्या टाळते, कारण ती SQLite च्या Online Backup API चा वापर करते. सक्रिय वापरात असलेली database कॉपी करण्याची हीच पद्धत असल्याचे SQLite documentation मध्ये नमूद केले आहे. ती read lock अंतर्गत pages वाचते. writer ने त्याच वेळी file मध्ये बदल केल्यास ती प्रक्रिया पुन्हा सुरू करते. त्यामुळे disk वर एकाच सुसंगत क्षणाची database लिहिली जाते.

sqlite3 .backup वापरून database ची प्रत तयार करा

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 स्वतंत्र ओळीवर ok प्रिंट करते. याशिवाय दुसरे काहीही दिसल्यास प्रत वापरण्यायोग्य नाही. त्यामुळे ती ठेवू नका आणि आधीची प्रत हटवू नका. ही संपूर्ण प्रक्रिया live server वर चालते. त्यामुळे कोणालाही logout केले जात नाही आणि कोणताही container restart होत नाही.

sqlite3 tool Vaultwarden container मध्ये नाही. ही image debian:trixie-slim वर ca-certificates, curl, libmariadb3, libpq5 आणि openssl सह build केली आहे. त्यामुळे docker exec vaultwarden sqlite3 ... ही command खालील त्रुटीसह fail होते:

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

त्याऐवजी mounted path वर host वर ती चालवा. वरील commands हेच करतात. Data named volume मध्ये असल्यास, docker volume inspect <name> command /var/lib/docker/volumes/ अंतर्गत host path प्रिंट करते.

Version 1.32.1 पासून Vaultwarden स्वतःची backup command देखील देते. तुमच्या server वर:

docker exec -it vaultwarden /vaultwarden backup

ही command VACUUM INTO चालवते आणि db_YYYYMMDD_HHMMSS.sqlite3 data folder मध्ये लिहिते. याचे दोन परिणाम आहेत. प्रत मूळ file च्या शेजारी, त्याच disk वर तयार होते. त्यामुळे ही 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 आणि client ला file decrypt करण्यासाठी आवश्यक key material असते. database शिवाय attachments वाचता येत नाहीत. attachments शिवाय database असल्यास users ना असे items दिसतात ज्यांचे downloads fail होतात. दोन्हींचा backup एकाच run मध्ये घ्या.

config.json मध्ये admin page वरून save केलेली सर्व माहिती असते. त्यातील values संबंधित environment variables वर precedence घेतात. याचे दोन्ही परिणाम होतात: जुना config.json restore केल्यास तो compose file मधील settings शांतपणे override करतो. तसेच या file मध्ये तुमचा SMTP password आणि admin token असू शकतो, त्यामुळे ती sensitive आहे. हा token plain text ऐवजी Argon2id PHC (password hashing competition) string म्हणून store करा. docker run --rm -it vaultwarden/server /vaultwarden hash तुमच्यासाठी अशी string तयार करतो.

rsa_key.pem clients ना logged in ठेवणाऱ्या JSON web tokens (JWT) वर sign करते. startup वेळी ही file नसल्यास Vaultwarden नवीन key generate करतो. त्यामुळे जुन्या key ने signed केलेले सर्व tokens validate होणे थांबते आणि सर्व clients logged out होतात. Vault contents यामुळे सुरक्षित राहतात, कारण ते master password पासून derived keys ने encrypted असतात. key file restore केल्यास हा mass logout टाळता येतो.

sends/ मध्ये Send links मागील files असतात. त्या files नसल्यास हे downloads fail होतात; इतर कोणत्याही कार्यावर परिणाम होत नाही.

संपूर्ण प्रक्रिया एका स्क्रिप्टमध्ये ठेवा

#!/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 status देते. त्यामुळे output ची ok शी तुलना केल्यावरच खराब प्रत स्क्रिप्टला अपयशी ठरवते. त्यानंतर set -euo pipefail सर्व प्रक्रिया थांबवते. त्यामुळे बिघडलेल्या database भोवती tar व्यवस्थित archive तयार करत नाही.

अंतिम tar -tzf मध्ये प्रत्यक्षात काय capture झाले आहे ते दाखवले जाते. ते पहिल्याच वेळी वाचा. तुम्ही ./db.sqlite3, ./rsa_key.pem, ./config.json आणि ./attachments/ शोधत आहात; तसेच ./db.sqlite3-wal अनुपस्थित आहे याची खात्री करा. journalctl output आणि अपयश दर्शवणारे 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 दाखवते. वापरकर्त्यांची संख्या तुम्हाला माहीत असलेल्या खात्यांच्या संख्येशी जुळली पाहिजे. 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 मध्ये आता प्रत्येक गोष्टीची दुसरी प्रत आहे.

हाताने कॉपी केलेला कोणताही data folder restore करताना एक नियम पाळा: server सुरू करण्यापूर्वी db.sqlite3-wal आणि db.sqlite3-shm हटवा. अन्यथा SQLite वेगळ्या प्रतीशी संबंधित log वापरून restore केलेला database recover करण्याचा प्रयत्न करेल. त्यामुळे अखंड स्वरूपात मिळालेला database corrupt होऊ शकतो. वरील script ने तयार केलेल्या archives मध्ये या files कधीही नसतात, कारण .backup एक पूर्ण database लिहिते.

सर्व्हरवर पुनर्स्थापना करा

हे आदेश तुमच्या स्वतःच्या सर्व्हरवर चालवा आणि container थांबवलेला असू द्या. डेटा 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 मध्ये container ज्या user म्हणून चालतो तो user नमूद करणे आवश्यक आहे. Stock image root म्हणून चालते. त्यामुळे root:root योग्य आहे, जोपर्यंत तुम्ही compose file मध्ये user: सेट केलेले नसेल. तसे केले असल्यास त्यातील uid आणि gid वापरा. सर्व्हरला लिहिता न येणारा data folder असल्यास प्रत्येक request अयशस्वी होणारे login page दिसते. Logs मध्ये याची नोंद असते.

यशस्वीपणे सुरू झाल्यावर शेवटी Rocket line दिसते:

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

त्यानंतर browser मधून login करा, एखादा item उघडा आणि एक attachment download करा. Login यशस्वी होत असेल, पण attachment downloads अयशस्वी होत असतील, तर archive मध्ये database आहे, पण attachments/ नाही. सर्व तपासण्या पूर्ण होईपर्यंत data.old.* ठेवा. त्यानंतर ते delete करा. Rollback करण्यासाठी हीच तीन पावले घ्या, फक्त directories ची दिशा उलटी ठेवा.

तुमचे paths येथे दिलेल्या paths शी जुळत नसतील, तर VPS साठी Vaultwarden install guide मध्ये या commands साठी अपेक्षित compose file दिलेली आहे.

बॅकअप कुठे ठेवू नये

• डेटा फोल्डर असलेल्या त्याच डिस्कवर ठेवू नका. एक volume निकामी झाल्यास दोन्ही प्रती नष्ट होतील. चुकीच्या path वरील एक rm -rf देखील हाच परिणाम घडवू शकतो.
• त्याच server वर ठेवू नका, दुसऱ्या volume वरसुद्धा नाही. root पर्यंत पोहोचणारा हल्लेखोर त्याच session मध्ये तुमच्या बॅकअपपर्यंतही पोहोचू शकतो.
• encryption शिवाय object storage मध्ये ठेवू नका, कारण archive मध्ये email addresses, password hints, recovery codes आणि vault ciphertext असतात. त्यांच्यावर offline हल्ला करता येतो.
• केवळ तुमच्या provider च्या snapshots वर अवलंबून राहू नका. ते जलद restore होतात आणि ते असणे उपयुक्त आहे. परंतु ते server च्या त्याच account मध्ये असतात. त्यामुळे account मधील समस्या त्यांनाही प्रभावित करते.

offsite प्रत तयार करण्यासाठी restic योग्य आहे, कारण काहीही upload करण्यापूर्वी restic repository 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 कडे निर्देशित करा. त्यामुळे ते तुम्ही आधी तपासलेली consistent copy upload करेल. repository चा password संरक्षित server व्यतिरिक्त इतरत्र ठेवा. तो password हरवल्यास snapshots डिझाइननुसार unreadable राहतील. storage याला समर्थन देत असल्यास, server ला write करू शकतील पण delete करू शकणार नाहीत अशी credentials द्या. त्यामुळे box compromise झाल्यास हल्लेखोर त्याचा स्वतःचा इतिहास पुसू शकणार नाही. VPS वर restic बॅकअप सेट करणे येथे repository आणि schedule ची संपूर्ण माहिती आहे. तुम्ही अद्याप निवड केली नसेल, तर restic आणि BorgBackup ची तुलना येथे हा पर्याय समजावला आहे.

वेळापत्रकानुसार restore ची चाचणी घ्या

महिन्यातील एक दिवस निवडा. restic restore latest --tag vaultwarden --target /tmp/vw-check वापरून सर्वात नवीन snapshot एका scratch directory मध्ये आणा. त्यावर तेच PRAGMA integrity_check चालवा. तेच row counts पुन्हा तपासा. त्यानंतर तारीख आणि counts नोंदवा. सहा महिन्यांत एकदाही restore न केलेला backup कोणत्या स्थितीत आहे हे माहीत नसते. outage झाल्यावर त्याची स्थिती समजते. ती तपासणी करण्यासाठी तो सर्वात चुकीचा वेळ असतो.

वर्षातून एकदा पूर्ण चाचणी करा. restore केलेल्या data folder सह spare port वर दुसरा Vaultwarden container सुरू करा. त्यानंतर वास्तविक account ने login करा. यामुळे master password path end to end कार्यरत असल्याचे सिद्ध होते. कोणतीही row count ही खात्री देऊ शकत नाही. त्याच वेळापत्रकानुसार restic check --read-data-subset=10% चालवल्यास stored data केवळ सूचीबद्ध नाही, तर वाचता येण्यासारखा आहे, हे पडताळता येते.

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 चा उद्देश हाच आहे. चालू सर्व्हरवरील database कॉपी सुरक्षित असते. वापरकर्ता attachment किंवा Send फाइल अपलोड करतो तेव्हा ती लिहिली जाते. त्यामुळे database कॉपी आणि tar यांच्या दरम्यान एखादी फाइल जोडली गेल्यास ती त्या रात्रीच्या archive मध्ये समाविष्ट न होण्याची शक्यता असते. जास्तीत जास्त एक attachment गमावला जाऊ शकतो. काही सेकंदांचा downtime चालत असल्यास, script च्या आधी docker compose stop आणि नंतर docker compose start करा. त्यामुळे ही शक्यताही दूर होते.

rsa_key फाइल्सशिवाय restore केल्यास काय होते?

Vaultwarden startup वेळी नवीन key तयार करते. ही key sessions सुरू ठेवणाऱ्या JSON web tokens (JWT) वर स्वाक्षरी करते. त्यामुळे सर्व विद्यमान tokens ची पडताळणी अयशस्वी होते. सर्व clients मधून logout होते आणि त्यांना पुन्हा sign in करावे लागते. Vault मधील contents वर परिणाम होत नाही. कारण ते RSA key ऐवजी प्रत्येक वापरकर्त्याच्या 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 वर अंदाज आजमावू शकतो. Archive मशीनबाहेर पाठवण्यापूर्वी ते encrypt करा. restic repository हे तुमच्यासाठी करते. तसेच gpg --symmetric --cipher-algo AES256 vw-20260805-030000.tar.gz एकच encrypted file तयार करते, जी कोणत्याही storage कडे पाठवता येते.

PostgreSQL किंवा MariaDB वर Vaultwarden चा backup कसा घ्यावा?

SQLite साठीच्या पायऱ्या लागू होत नाहीत. Built-in command The database type is not SQLite. Backups only works for SQLite databases सह अपयशी होते. Database चे native tool वापरून dump घ्या: pg_dump किंवा mysqldump. इतर सर्व नियम तसेच ठेवा. Dump हा attachments/, sends/, config.json आणि rsa_key files सोबत एकाच archive मध्ये ठेवा. हे सर्व एकाच run मध्ये घ्या, encrypt करा आणि backup तयार करणाऱ्या server व्यतिरिक्त इतरत्र साठवा.