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 చేసినది. అది 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/: 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 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 రూపంలో 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, ఒక item ఏ organisation కు చెందినదో వంటి metadata కూడా పక్కనే ఉంటుంది. అందువల్ల backup file కూడా ఒక secret. దాన్ని పొందిన ఎవరైనా మీ users ఎవరో తెలుసుకోగలరు. వారి hardware అనుమతించే వేగంతో encrypted blobs పై offline attacks కూడా చేయగలరు. ఈ ఒక్క విషయం తరువాతి storage rules కు ఆధారం: copy server నుంచి బయటకు వెళ్లే ముందు encrypt చేయాలి. Admin token కూడా ఇదే సమస్యలోని మరో భాగం. self-hosted Vaultwarden hardening ప్రక్రియ ఈ రెండు అంశాలను పరిశీలిస్తుంది.

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

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

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

Error: database disk image is malformed

.backup ఈ సమస్యను నివారిస్తుంది. ఇది SQLite's Online Backup API ను ఉపయోగిస్తుంది. Active useలో ఉన్న databaseను కాపీ చేయడానికి ఇదే పద్ధతి అని SQLite documentationలో పేర్కొంది. ఇది read lock కింద pagesను చదువుతుంది. Writer fileను మార్చితే ఇది మళ్లీ ప్రారంభమవుతుంది. అందువల్ల diskపై రాసేది ఒకే consistent momentకు చెందిన database అవుతుంది.

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

sqlite3 tool Vaultwarden container లో ఉండదు. ఈ image debian:trixie-slim పై ca-certificates, curl, libmariadb3, libpq5 మరియు openssl తో నిర్మించబడింది. అందువల్ల docker exec vaultwarden sqlite3 ... ఈ error తో విఫలమవుతుంది:

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

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

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

docker exec -it vaultwarden /vaultwarden backup

ఇది VACUUM INTO ను నడిపి, db_YYYYMMDD_HHMMSS.sqlite3 ను data folder లో రాస్తుంది. దీని నుంచి రెండు విషయాలు తెలుస్తాయి. కాపీ అదే disk పై original పక్కనే ఉంచబడుతుంది. కాబట్టి ఇది 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 మరియు ఆ file‌ను decrypt చేయడానికి client‌కు అవసరమైన key material ఉంటాయి. database లేకపోతే attachments చదవలేని డేటాగా మారతాయి. attachments లేకపోతే users‌కు downloads విఫలమయ్యే items మాత్రమే కనిపిస్తాయి. రెండింటినీ ఒకే run‌లో తీసుకోండి.

config.jsonలో admin page నుంచి మీరు సేవ్ చేసిన మొత్తం configuration ఉంటుంది. matching environment variables కంటే ఈ configuration విలువలకు ప్రాధాన్యత ఉంటుంది. దీని ప్రభావం రెండు విధాలుగా ఉంటుంది: పాత 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‌ను ప్రింట్ చేస్తుంది.

rsa_key.pem clients‌ను logged in‌గా ఉంచే JSON web tokens (JWT) పై సంతకం చేస్తుంది. startup సమయంలో ఈ file కనిపించకపోతే Vaultwarden కొత్త key‌ను generate చేస్తుంది. అందువల్ల పాత key‌తో signed చేసిన ప్రతి token validationలో విఫలమవుతుంది మరియు అన్ని clients logged out అవుతాయి. Vault contents మాత్రం అలాగే ఉంటాయి, ఎందుకంటే అవి master password నుంచి ఉత్పన్నమైన keys‌తో encrypted అయి ఉంటాయి. ఈ key file‌ను restore చేస్తే పెద్ద సంఖ్యలో users 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 గా సేవ్ చేసి, chmod 700 చేసి, root గా అమలు చేయండి. test line వాస్తవంగా ముఖ్యమైన పని చేస్తుంది: PRAGMA integrity_check corruption ను నివేదించినప్పటికీ sqlite3 exit code 0 ను ఇస్తుంది. అందువల్ల output ను ok తో పోల్చడమే తప్పు copy ను failed script గా మార్చుతుంది. తరువాత set -euo pipefail ప్రతిదానినీ ఆపుతుంది. దాంతో విరిగిపోయిన database చుట్టూ tar సక్రమంగా కనిపించే archive ను రూపొందించదు.

చివరి tar -tzf మీరు నిజంగా capture చేసిన అంశాలను చూపిస్తుంది. దీన్ని మొదటిసారి జాగ్రత్తగా చదవండి. మీరు ./db.sqlite3, ./rsa_key.pem, ./config.json మరియు ./attachments/ కోసం చూడాలి. అలాగే ./db.sqlite3-wal లేకపోవడాన్ని నిర్ధారించాలి. journalctl output మరియు failure ను నివేదించే 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 ను ముద్రిస్తుంది. User count మీకు తెలిసిన accountల సంఖ్యతో సరిపోవాలి. Cipher count, sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select count(*) from ciphers;" నుంచి పొందే live సంఖ్యకు దగ్గరగా ఉండాలి. ఉపయోగంలో ఉన్న vaultలో అది ఎప్పుడూ zero కాకూడదు. Attachments directory పరిమాణం మీరు ఆశించిన దానికి సుమారుగా సరిపోవాలి. ఎవరూ attachments upload చేయకపోతే ఈ తనిఖీని దాటవేయవచ్చు. తరువాత sudo rm -rf /tmp/vw-check అమలు చేయండి. ఆ directoryలో ఇప్పుడు ప్రతిదానికి రెండో copy ఉంది.

చేతితో copy చేసిన data folderను restore చేసేటప్పుడు ఒక నియమాన్ని పాటించండి: server ప్రారంభించే ముందు db.sqlite3-wal మరియు db.sqlite3-shm ను తొలగించండి. లేకపోతే SQLite restore చేసిన databaseను దానికి చెందినది కాని మరో copyకి సంబంధించిన logను ఉపయోగించి recover చేయడానికి ప్రయత్నిస్తుంది. దీనివల్ల intactగా వచ్చిన database corrupt అవుతుంది. పై script రూపొందించిన archivesలో ఆ files ఎప్పుడూ ఉండవు, ఎందుకంటే .backup ఒక complete databaseను రాస్తుంది.

సర్వర్‌లోకి పునరుద్ధరించండి

ఈ ఆదేశాలను మీ స్వంత సర్వర్‌లో, container ఆపివేసిన తర్వాత అమలు చేయండి. data folder మారుతున్న సమయంలో Vaultwarden అందులో data రాయకూడదు.

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 ఉపయోగించండి. server రాయలేని 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 సమస్య వాటినీ ప్రభావితం చేస్తుంది.

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

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

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

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

FAQ

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

లేదు. Vaultwarden SQLite ను WAL mode లో నడుపుతుంది. అందువల్ల ఇటీవలి writes db.sqlite3-wal లో ఉంటాయి. అవి ఇంకా db.sqlite3 లో ఉండవు. Main file ను మాత్రమే cp చేస్తే ఆ writes నిశ్శబ్దంగా పోతాయి. రెండు files ను విడిగా copy చేస్తే సరిపోలని pair ఏర్పడి, తరువాత 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 చేసినప్పుడు అవి రాయబడతాయి. అందువల్ల 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 సంతకం చేస్తుంది. అందువల్ల ఇప్పటికే ఉన్న ప్రతి 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 ను ఎలా back up చేయాలి?

SQLite దశలు ఇక్కడ వర్తించవు. Built-in command The database type is not SQLite. Backups only works for SQLite databases తో విఫలమవుతుంది. Native tool ను ఉపయోగించి database ను dump చేయండి: pg_dump లేదా mysqldump. మిగతా నియమాలన్నీ అలాగే ఉంచండి. Dump ను attachments/, sends/, config.json మరియు rsa_key files తో కలిసి ఒకే archive లో ఉంచాలి. ఇవన్నీ ఒకే run లో తీసుకోవాలి. Archive ను encrypt చేయాలి. దాన్ని సృష్టించిన server కాకుండా మరొక చోట నిల్వ చేయాలి.