VPSలో Vaultwarden backup మరియు restore ఎలా చేయాలి

Vaultwarden backup లో ఉండాల్సినవి

Vaultwarden backup అనేది మొత్తం 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/: users vault items కు జత చేసిన 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: login tokens పై సంతకం చేసే key.
• icon_cache/: download చేసిన website icons. మీరు వదిలేయగల ఏకైక directory ఇదే, ఎందుకంటే అవసరమైనప్పుడు Vaultwarden వాటిని మళ్లీ fetch చేస్తుంది.

నా Vaultwarden database సురక్షితంగా ఉందా? ఆ ఫైల్‌లో నిజంగా ఏమి ఉంటుంది

దీనికి రెండు commands సరిపోతాయి. మీరు రెండింటినీ ఇప్పుడే run చేయవచ్చు.

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 లో చూపిస్తుంది. రెండవది ఒక item name ను చూపిస్తుంది. అది ఇలా కనిపిస్తుంది:

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

Item names, usernames, passwords మరియు notes server కు పంపే ముందు client ద్వారా encrypt అవుతాయి. అందువల్ల server చదవలేని ciphertext ను మాత్రమే store చేస్తుంది. 2. prefix Bitwarden encryption type ను సూచిస్తుంది. దాని తరువాత initialisation vector (IV), ciphertext మరియు MAC (message authentication code) ఉంటాయి. ఇవన్నీ base64 లో ఉంటాయి. వాటిని | వేరు చేస్తుంది. దీన్ని decrypt చేసే key account master password నుంచి derive అవుతుంది. ఆ password usable form లో ఎప్పుడూ server కు చేరదు. మీరు Vaultwarden నడిపినా, official server నడిపినా ఈ భాగం ఒకే విధంగా ఉంటుంది. Vaultwarden మరియు self-hosted Bitwarden పోలికలో దీనిని వివరంగా చూడవచ్చు.

Database లోని మిగతా భాగం encrypted కాదు. Email addresses, account names, password hints మరియు two-factor recovery codes plain text గా store అవుతాయి. Creation times, ఏ organisation ఒక item ను own చేస్తుందో వంటి metadata కూడా వాటి పక్కనే ఉంటుంది. అందువల్ల backup file కూడా ఒక secret. దాన్ని కలిగి ఉన్న ఎవరైనా మీ users ఎవరో తెలుసుకోగలరు. Encrypted blobs పై offline attacks ను వారి hardware అనుమతించే వేగంతో నిర్వహించగలరు. ఈ ఒక్క విషయం కింద ఇచ్చిన storage నియమాలకు ఆధారం: server నుంచి బయటకు వెళ్లే ముందు copy ను encrypt చేయాలి.

Vaultwarden నడుస్తున్నప్పుడు db.sqlite3 ను కాపీ చేయడం backup ఎందుకు కాదు

Vaultwarden డిఫాల్ట్‌గా SQLite ను WAL mode లో నడుపుతుంది (ENABLE_DB_WAL=true). ఒక write ముందుగా db.sqlite3-wal లోకి వెళ్తుంది. Checkpoint జరిగినప్పుడు మాత్రమే అది db.sqlite3 లోకి చేర్చబడుతుంది. db.sqlite3 ను మాత్రమే కాపీ చేస్తే, చివరి checkpoint సమయానికి ఉన్న database మాత్రమే లభిస్తుంది. అందువల్ల పది నిమిషాల క్రితం save చేసిన password మీ archive లో లేకపోవచ్చు. దీనిపై ఎలాంటి హెచ్చరిక కూడా కనిపించదు.

cp తో మూడు files ను కాపీ చేయడం కూడా పరిష్కారం కాదు. ఈ copies కొద్దిగా వేర్వేరు సమయాల్లో తీసుకోబడతాయి. అందువల్ల మీరు save చేసిన WAL, మీరు save చేసిన main file కు సరిపోని page versions ను సూచించవచ్చు. SQLite ఒక file ఆధారంగా మరొకదాన్ని recover చేస్తుంది. ఫలితం తప్పుగా ఉంటుంది. ఇది చాలా ఆలస్యంగా మాత్రమే తెలుస్తుంది:

Error: database disk image is malformed

.backup ఈ సమస్యను నివారిస్తుంది. ఇది SQLite యొక్క Online Backup API ను ఉపయోగిస్తుంది. సక్రియంగా ఉపయోగంలో ఉన్న database ను కాపీ చేయడానికి ఇదే సరైన పద్ధతి అని SQLite documentation పేర్కొంటుంది. ఇది read lock కింద pages ను చదువుతుంది. Writer file ను మార్చితే, ఇది మళ్లీ ప్రారంభమవుతుంది. అందువల్ల disk పై నిల్వ అయ్యేది ఒకే consistent moment కు చెందిన 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;"

చివరి కమాండ్ ఒక ప్రత్యేక పంక్తిలో ok ను ముద్రిస్తుంది. దీనికి బదులుగా మరేదైనా కనిపిస్తే కాపీ ఉపయోగించదగినది కాదు. అందువల్ల దాన్ని ఉంచకండి, మునుపటి కాపీని తొలగించకండి. ఈ మొత్తం క్రమం నడుస్తున్న server పై అమలవుతుంది. కాబట్టి ఎవరూ logout అవ్వరు, 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

దాని బదులుగా mounted path పై hostలో దాన్ని అమలు చేయండి. పై కమాండ్లు ఇదే విధంగా పనిచేస్తాయి. Data named volumeలో ఉంటే, docker volume inspect <name>, /var/lib/docker/volumes/ కింద ఉన్న host pathను ముద్రిస్తుంది.

Version 1.32.1 నుంచి Vaultwarden తన సొంత backup commandను కూడా అందిస్తోంది. మీ serverపై:

docker exec -it vaultwarden /vaultwarden backup

ఇది VACUUM INTO ను అమలు చేసి, db_YYYYMMDD_HHMMSS.sqlite3 ను data folderలో రాస్తుంది. దీని వల్ల రెండు విషయాలు స్పష్టమవుతాయి. కాపీ అసలు database పక్కనే అదే diskపై నిల్వ అవుతుంది. కాబట్టి ఇది staging దశ మాత్రమే; ఇంకా backup కాదు. అలాగే ఇది SQLiteకు మాత్రమే పనిచేస్తుంది. MariaDB లేదా PostgreSQL ఉపయోగించినప్పుడు ఇది The database type is not SQLite. Backups only works for SQLite databases వద్ద ఆగిపోతుంది.

మర్చిపోయే ఫైళ్లు

attachments/ లో స్పష్టమైన అర్థం లేని పేర్ల కింద ciphertext నిల్వ ఉంటుంది. ప్రతి attachment కు సంబంధించిన database row లో దాని encrypted file name మరియు ఆ ఫైల్‌ను decrypt చేయడానికి client కు అవసరమైన key material ఉంటాయి. database లేకపోతే attachments చదవలేని డేటాగా మారతాయి. attachments లేకపోతే database లోని items ను users download చేయలేరు. ఈ రెండింటినీ ఒకే run లో తీసుకోండి.

config.json లో admin page నుంచి మీరు save చేసిన ప్రతిదీ ఉంటుంది. దాని values, సరిపోలే environment variables కంటే ప్రాధాన్యత పొందుతాయి. దీని ప్రభావం రెండు విధాలుగా ఉంటుంది: పాత config.json ను restore చేస్తే మీ compose file లోని settings నిశ్శబ్దంగా override అవుతాయి. ఆ file sensitive కూడా, ఎందుకంటే అందులో మీ SMTP password మరియు admin token ఉండవచ్చు. ఆ token ను plain text గా కాకుండా Argon2id PHC (password hashing competition) string గా నిల్వ చేయండి. docker run --rm -it vaultwarden/server /vaultwarden hash మీ కోసం అలాంటి string ను ఒకదాన్ని print చేస్తుంది.

rsa_key.pem clients ను logged in గా ఉంచే JSON web tokens (JWT) కు sign చేస్తుంది. startup సమయంలో ఈ file కనిపించకపోతే Vaultwarden కొత్త key ను generate చేస్తుంది. అందువల్ల పాత key తో signed చేసిన ప్రతి token validation లో విఫలమవుతుంది, మరియు అన్ని clients logout అవుతాయి. Vault contents మాత్రం దీనివల్ల ప్రభావితం కావు, ఎందుకంటే అవి master password నుంచి derive చేసిన keys తో encrypted గా ఉంటాయి. ఈ key file ను restore చేస్తే mass logout నివారించవచ్చు.

sends/ Send links వెనుక ఉన్న files ను కలిగి ఉంటుంది. ఇవి లేకపోతే ఆ downloads మాత్రమే విఫలమవుతాయి; ఇతర వాటిపై ప్రభావం ఉండదు.

మొత్తం ప్రక్రియను ఒకే 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తో executableగా మార్చి, rootగా run చేయండి. test line వాస్తవంగా ముఖ్యమైన పని చేస్తుంది: PRAGMA integrity_check corruptionను report చేసినా sqlite3 0తో exit అవుతుంది. అందువల్ల outputను okతో compare చేయడమే తప్పుగా copy అయినదాన్ని failed scriptగా మార్చుతుంది. తరువాత set -euo pipefail మొత్తం ప్రక్రియను ఆపుతుంది. లేకపోతే tar దెబ్బతిన్న database చుట్టూ సక్రమంగా కనిపించే archiveను తయారు చేస్తుంది.

చివరి tar -tzf మీరు నిజంగా capture చేసిన అంశాలను list చేస్తుంది. దీన్ని మొదటిసారి తప్పకుండా చదవండి. అందులో ./db.sqlite3, ./rsa_key.pem, ./config.json మరియు ./attachments/ ఉండాలి. ./db.sqlite3-wal ఉండకూడదు. journalctl output మరియు failureను report చేసే unit కావాలంటే, cronకు బదులుగా systemd service మరియు timer ఉపయోగించి దీన్ని ప్రతి రాత్రి run చేయండి.

బ్యాకప్‌ను తాత్కాలిక డైరెక్టరీకి పునరుద్ధరించి ధృవీకరించండి

పరీక్షించని బ్యాకప్ కేవలం ఒక అంచనా మాత్రమే. తాత్కాలిక డైరెక్టరీకి పునరుద్ధరించడానికి ఒక నిమిషం పడుతుంది. దీనివల్ల 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 డైరెక్టరీ పరిమాణం మీరు ఆశించిన దానికి సుమారుగా సరిపోవాలి. ఎవరూ attachments upload చేయకపోతే దీన్ని దాటవేయవచ్చు. తరువాత sudo rm -rf /tmp/vw-check అమలు చేయండి, ఎందుకంటే ఆ డైరెక్టరీలో ఇప్పుడు ప్రతిదానికి రెండో కాపీ ఉంది.

చేతితో కాపీ చేసిన ఏదైనా data folderను పునరుద్ధరించేటప్పుడు ఒక నియమాన్ని పాటించండి: server ప్రారంభించే ముందు db.sqlite3-wal మరియు db.sqlite3-shm ను తొలగించండి. లేకపోతే SQLite పునరుద్ధరించిన databaseను వేరే కాపీకి చెందిన logను ఉపయోగించి recover చేయడానికి ప్రయత్నిస్తుంది. దాంతో సరిగ్గా వచ్చిన 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 లో container ఏ user గా నడుస్తుందో పేర్కొనాలి. ప్రామాణిక image root గా నడుస్తుంది. అందువల్ల మీ compose file లో user: సెట్ చేయకపోతే root:root సరైన విలువ. 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.* ఉంచండి. తర్వాత దాన్ని తొలగించండి. Rollback చేయడానికి ఇదే మూడు దశలను directories ను వ్యతిరేక క్రమంలో మార్చి అమలు చేయాలి.

మీ paths ఇక్కడివాటితో సరిపోలకపోతే, VPS కోసం Vaultwarden install guide ఈ ఆదేశాలు ఆధారపడే compose file ను చూపిస్తుంది.

బ్యాకప్‌ను ఎక్కడ ఉంచకూడదు

• డేటా ఫోల్డర్ ఉన్న అదే డిస్క్‌లో ఉంచకండి. ఒక volume విఫలమైతే రెండు కాపీలు పోతాయి. తప్పు path పై ఉన్న ఒక rm -rf వల్ల కూడా ఇదే జరుగుతుంది.
• రెండవ volume ఉన్నా అదే serverలో ఉంచకండి. root కు చేరుకున్న attacker అదే sessionలో మీ backups కు కూడా చేరుకోగలడు.
• encryption లేకుండా object storageలో ఉంచకండి. archiveలో email addresses, password hints, recovery codes మరియు vault ciphertext ఉంటాయి. వీటిపై offline దాడి చేయవచ్చు.
• మీ provider snapshotsపైనే ఆధారపడకండి. అవి వేగంగా restore అవుతాయి. అందువల్ల వాటిని ఉంచడం ఉపయోగకరం. కానీ అవి server ఉన్న అదే accountలో ఉంటాయి. కాబట్టి account సమస్య వస్తే snapshots కూడా దాని ప్రభావానికి గురవుతాయి.

Offsite copy కోసం restic అనుకూలంగా ఉంటుంది. ఎందుకంటే upload చేయడానికి ముందు restic repositoryని machineపైనే encrypt చేస్తుంది. మీ 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ను చదవడం సాధ్యం కాదు. ఇది ఉద్దేశపూర్వక భద్రతా లక్షణం. Storage దీనికి మద్దతు ఇస్తే, serverకు write చేయగలిగే కానీ delete చేయలేని credentials ఇవ్వండి. అప్పుడు box breach అయినా దాని స్వంత backup historyని తొలగించలేరు. VPSలో restic backups ఏర్పాటు చేయడం repository మరియు scheduleను పూర్తిగా వివరిస్తుంది. మీరు ఇంకా ఎంపిక చేయకపోతే BorgBackupతో resticను పోల్చడం ఆ నిర్ణయానికి సహాయపడుతుంది.

షెడ్యూల్ ప్రకారం restore ను పరీక్షించండి

నెలలో ఒక రోజును నిర్ణయించండి. restic restore latest --tag vaultwarden --target /tmp/vw-check తో తాజా snapshot ను తాత్కాలిక directory లోకి తీసుకురండి, అదే PRAGMA integrity_check ను అమలు చేయండి, అదే row counts ను సేకరించి, తేదీ మరియు counts ను నమోదు చేయండి. ఆరు నెలలుగా ఎవరూ restore చేయని backup ఏ స్థితిలో ఉందో తెలియని backup అవుతుంది. outage సమయంలో దాని స్థితి తెలుస్తుంది. అది తెలుసుకోవడానికి అత్యంత అననుకూల సమయం అదే.

సంవత్సరానికి ఒకసారి పూర్తి పరీక్ష చేయండి. restore చేసిన data folder తో, spare port పై రెండవ Vaultwarden container ను ప్రారంభించి, నిజమైన account తో login చేయండి. ఇది master password మార్గం end-to-end గా పనిచేస్తుందని నిర్ధారిస్తుంది. ఏ row count కూడా దీన్ని నిర్ధారించలేడు. అదే షెడ్యూల్‌లో restic check --read-data-subset=10% ను అమలు చేయడం ద్వారా stored data కేవలం జాబితా చేయబడటమే కాకుండా చదవగలిగేలా ఉందని నిర్ధారించవచ్చు.

FAQ

Vaultwarden నడుస్తున్నప్పుడు cp తో db.sqlite3 ను కాపీ చేయవచ్చా?

లేదు. Vaultwarden SQLite ను WAL mode లో నడుపుతుంది. అందువల్ల ఇటీవలి writeలు db.sqlite3-wal లో ఉంటాయి; అవి ఇంకా db.sqlite3 లోకి చేరి ఉండవు. ప్రధాన file ను మాత్రమే cp చేస్తే ఆ writeలు ఎలాంటి హెచ్చరిక లేకుండా కోల్పోతాయి. రెండు files ను విడిగా కాపీ చేస్తే, తరువాత Error: database disk image is malformed గా బయటపడే అసమకాలిక జత ఏర్పడవచ్చు. దానికి బదులుగా sqlite3 /path/db.sqlite3 ".backup '/path/out.sqlite3'" ఉపయోగించండి. ఇది SQLite యొక్క Online Backup API ను ఉపయోగించి, server సేవలు అందిస్తూనే ఒకే consistent file ను సృష్టిస్తుంది.

Backup తీసుకునేందుకు Vaultwarden container ను ఆపాలా?

లేదు. .backup ఉద్దేశం అదే. నడుస్తున్న server పై database copy సురక్షితం. User attachment లేదా Send file upload చేసినప్పుడు అది write అవుతుంది. కాబట్టి database copy మరియు tar మధ్యలో జోడించిన file ఆ రాత్రి archive లో చేరకపోవచ్చు. అత్యధికంగా ఒక attachment మాత్రమే కోల్పోతారు. కొన్ని seconds downtime ఇబ్బంది కాకపోతే, script ముందు docker compose stop చేసి, దాని తరువాత docker compose start చేయండి. అప్పుడు ఆ చిన్న ప్రమాదం కూడా తొలగుతుంది.

rsa_key files లేకుండా restore చేస్తే ఏమవుతుంది?

Startup సమయంలో Vaultwarden కొత్త key ను సృష్టిస్తుంది. Sessions కొనసాగేందుకు అవసరమైన JSON web tokens (JWT) కు ఆ key signature ఇస్తుంది. అందువల్ల ఇప్పటికే ఉన్న ప్రతి token validation లో విఫలమవుతుంది. అన్ని clients logout అవుతాయి, మళ్లీ sign in చేయాలి. Vault contents పై ప్రభావం ఉండదు. ఎందుకంటే అవి RSA key తో కాకుండా ప్రతి user's 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 పై ప్రయత్నాలు చేయగలడు. Machine నుంచి బయటకు పంపే ముందు archive ను encrypt చేయండి. restic repository దీన్ని మీ కోసం చేస్తుంది. gpg --symmetric --cipher-algo AES256 vw-20260805-030000.tar.gz ఉపయోగిస్తే ఏ storage కు అయినా పంపగల ఒకే encrypted file లభిస్తుంది.

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. మిగిలిన ప్రతి నియమాన్ని అలాగే పాటించండి. అదే run లో తీసుకున్న dump ను attachments/, sends/, config.json మరియు rsa_key files తో కలిసి ఒకే archive లో ఉంచాలి. దాన్ని encrypt చేసి, సృష్టించిన server కాకుండా వేరే ప్రదేశంలో నిల్వ చేయాలి.