VPS-ல் Vaultwarden backup மற்றும் restore செய்வது

Vaultwarden backup-ல் இருக்க வேண்டியவை

Vaultwarden backup என்பது முழு data folder-ன் copy ஆகும். அதற்குள் உள்ள database-ஐ சரியான முறையில் copy செய்ய வேண்டும். cp-க்கு பதிலாக sqlite3 db.sqlite3 ".backup out.sqlite3"-ஐ இயக்கவும். எழுதப்பட்டுக் கொண்டிருக்கும் database-ஐ வழக்கமான முறையில் copy செய்தால், திறக்க முடியாத 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 அவற்றை main file-ல் இணைக்கும் வரை சமீபத்திய writes இங்கே இருக்கும்.
• attachments/: பயனர்கள் vault items-க்கு attach செய்த 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-ஐ sign செய்யும் key.
• icon_cache/: download செய்யப்பட்ட website icons. மீண்டும் தேவைப்படும் போது Vaultwarden அவற்றை fetch செய்வதால், skip செய்யக்கூடிய ஒரே directory இதுவாகும்.

என் Vaultwarden database பாதுகாப்பானதா? அந்த file-ல் உண்மையில் என்ன உள்ளது

இதற்கு இரண்டு 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 name-ஐ காட்டும். அதன் வடிவம் இதுபோல் இருக்கும்:

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

Item names, usernames, passwords மற்றும் notes server-க்கு அனுப்பப்படுவதற்கு முன் 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 மற்றும் எந்த organisation ஒரு item-ஐச் சொந்தமாகக் கொண்டுள்ளது போன்ற metadata-வும் அதனுடன் சேமிக்கப்படுகிறது. எனவே backup file தானே ஒரு secret ஆகும். அதை வைத்திருக்கும் எவரும் உங்கள் users யார் என்பதை அறியலாம். மேலும், அவர்களிடம் உள்ள hardware அனுமதிக்கும் வேகத்தில் encrypted blobs மீது offline attack நடத்தலாம். இந்த ஒரு காரணத்தால் கீழே கூறப்படும் storage rules நிர்ணயிக்கப்படுகின்றன: server-ஐ விட்டு வெளியேறும் முன் அந்த copy encrypt செய்யப்பட வேண்டும். Admin token இதே பிரச்சினையின் மற்றொரு பகுதி. self-hosted Vaultwarden-க்கான hardening pass இவ்விரண்டையும் விளக்குகிறது.

Vaultwarden இயங்கிக்கொண்டிருக்கும்போது db.sqlite3-ஐ நகலெடுப்பது ஏன் backup அல்ல

Vaultwarden, default-ஆக SQLite-ஐ WAL mode-ல் இயக்குகிறது (ENABLE_DB_WAL=true). ஒரு write முதலில் db.sqlite3-wal-ல் எழுதப்படும். பின்னர் checkpoint செயல்பாடு மட்டுமே அதை db.sqlite3-ல் இணைக்கும். db.sqlite3-ஐ மட்டும் நகலெடுத்தால், கடைசி checkpoint நேரத்திலிருந்த database மட்டுமே கிடைக்கும். ஆகவே, பத்து நிமிடங்களுக்கு முன் சேமித்த password எந்த எச்சரிக்கையும் இல்லாமல் உங்கள் archive-ல் இல்லாமல் போகலாம்.

cp மூலம் மூன்று files-ஐயும் நகலெடுப்பதும் தீர்வு அல்ல. அந்த copies சிறிது வேறுபட்ட நேரங்களில் உருவாகும். எனவே, நீங்கள் சேமித்த WAL, நீங்கள் சேமித்த main file-க்கு பொருந்தாத page versions-ஐக் குறிக்கலாம். பின்னர் SQLite, ஒரு file-இலிருந்து மற்றொன்றை recover செய்யும். அதன் முடிவு தவறாக இருக்கும். இதை நீங்கள் மிகவும் தாமதமாகத்தான் கண்டுபிடிப்பீர்கள்:

Error: database disk image is malformed

.backup இந்தப் பிரச்சினையைத் தவிர்க்கிறது. இது SQLite-ன் Online Backup API-ஐப் பயன்படுத்துகிறது. Active use-ல் இருக்கும் database-ஐ நகலெடுப்பதற்கான முறையாக SQLite இதை documentation-ல் குறிப்பிடுகிறது. இது read lock-ன் கீழ் pages-ஐப் படிக்கும். இதற்கிடையில் writer file-ஐ மாற்றினால், இது செயல்முறையை மீண்டும் தொடங்கும். எனவே disk-ல் எழுதப்படுவது ஒரே consistent தருணத்தின் நிலையாகும்.

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 என்பதை அச்சிடும். வேறு ஏதேனும் வெளியீடு வந்தால், அந்த நகல் பயன்படுத்தத் தகுதியற்றது. எனவே அதை வைத்திருக்க வேண்டாம்; முந்தைய நகலையும் நீக்க வேண்டாம். முழு sequence-மும் இயங்கிக்கொண்டிருக்கும் server-ல் செயல்படும். ஆகவே எந்த user-மும் logout செய்யப்படாது; எந்த container-மும் restart ஆகாது.

sqlite3 tool, Vaultwarden container-க்குள் இல்லை. அந்த image, debian:trixie-slim மீது ca-certificates, curl, libmariadb3, libpq5 மற்றும் openssl கொண்டு build செய்யப்பட்டுள்ளது. எனவே docker exec vaultwarden sqlite3 ... பின்வரும் பிழையுடன் தோல்வியடையும்:

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

அதற்கு பதிலாக, mounted path-ஐ பயன்படுத்தி host-ல் command-ஐ இயக்கவும். மேலே உள்ள commands இதைத்தான் செய்கின்றன. Data, named volume-ல் இருந்தால், docker volume inspect <name> command /var/lib/docker/volumes/ கீழ் உள்ள host path-ஐ அச்சிடும்.

Vaultwarden, version 1.32.1 முதல் தனிப்பட்ட 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/ opaque பெயர்களின் கீழ் ciphertext-ஐ சேமிக்கிறது. ஒவ்வொரு attachment-க்கும் உரிய database row-ல், அதன் encrypted file name-உம், அந்த file-ஐ decrypt செய்ய client-க்கு தேவையான key material-உம் உள்ளன. Database இல்லாத attachment-கள் வாசிக்க முடியாத noise ஆகிவிடும்; attachment-கள் இல்லாத database-ல், download தோல்வியடையும் items மட்டுமே பயனர்களுக்குக் கிடைக்கும். இரண்டையும் ஒரே run-ல் எடுத்துக்கொள்ளுங்கள்.

config.json admin page-ல் நீங்கள் சேமித்த அனைத்தையும் கொண்டுள்ளது. இதன் values, பொருந்தும் environment variables-ஐ விட முன்னுரிமை பெறும். இதற்கு இரு விளைவுகள் உள்ளன: பழைய config.json-ஐ restore செய்தால், உங்கள் compose file-ல் உள்ள settings அமைதியாக override செய்யப்படும். மேலும், அந்த file-ல் உங்கள் SMTP password மற்றும் admin token இருக்கக்கூடும் என்பதால், அது sensitive ஆகும். அந்த token-ஐ plain text-ஆக அல்லாமல், Argon2id PHC (password hashing competition) string-ஆக சேமிக்கவும். docker run --rm -it vaultwarden/server /vaultwarden hash உங்களுக்காக ஒன்றை உருவாக்கும்.

rsa_key.pem clients-ஐ logged in நிலையில் வைத்திருக்கும் JSON web tokens (JWT)-க்கு sign செய்கிறது. startup நேரத்தில் இந்த file இல்லையெனில், Vaultwarden புதிய key-ஐ உருவாக்கும். இதனால் பழைய key மூலம் signed செய்யப்பட்ட ஒவ்வொரு token-உம் validate ஆகாது; அனைத்து clients-உம் logged out ஆகிவிடும். Vault contents இதனால் பாதிக்கப்படாது, ஏனெனில் அவை master password-லிருந்து பெறப்பட்ட keys மூலம் encrypted செய்யப்பட்டுள்ளன. Key file-ஐ restore செய்தால், பெருமளவிலான 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 permission வழங்கி, root ஆக இயக்கவும். test line உண்மையான பணியைச் செய்கிறது: PRAGMA integrity_check corruption இருப்பதாக தெரிவித்தாலும் sqlite3 0-ஐ return செய்யும். எனவே output-ஐ ok உடன் ஒப்பிடுவதுதான் தவறான copy-ஐ failed script-ஆக மாற்றுகிறது. அதன் பிறகு set -euo pipefail அனைத்தையும் நிறுத்துகிறது. இதனால் tar உடைந்த database-ஐச் சுற்றி சரியான archive உருவாக்க முயலாது.

இறுதி tar -tzf நீங்கள் உண்மையில் capture செய்தவற்றின் பட்டியலைக் காட்டும். அதை முதல் முறையாக கவனமாகப் படிக்கவும். ./db.sqlite3, ./rsa_key.pem, ./config.json மற்றும் ./attachments/ இருப்பதையும், ./db.sqlite3-wal இல்லாததையும் உறுதிப்படுத்த வேண்டும். journalctl output மற்றும் failure-ஐ report செய்யும் unit வேண்டும் என்றால், cron-க்கு பதிலாக systemd service மற்றும் timer மூலம் இதை nightly இயக்கவும்.

backup-ஐ scratch directory-க்கு restore செய்து சரிபார்க்கவும்

சோதிக்கப்படாத backup என்பது ஒரு ஊகம் மட்டுமே. scratch directory-க்கு restore செய்வதற்கு ஒரு நிமிடம் போதும்; live data எதுவும் பாதிக்கப்படாது.

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-ஐ print செய்யும். 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-ஐ delete செய்யவும். இல்லையெனில் SQLite, வேறு copy-க்கு உரிய log-ஐ பயன்படுத்தி restore செய்யப்பட்ட database-ஐ recover செய்ய முயலும். இதனால் முழுமையாகச் சரியாக வந்த database கூட corrupt ஆகும். மேலே உள்ள script உருவாக்கும் archives-ல் அந்த files ஒருபோதும் இருக்காது; ஏனெனில் .backup ஒரு முழுமையான database-ஐ எழுதுகிறது.

Server-க்கு மீட்டமைத்தல்

Container நிறுத்தப்பட்ட நிலையில், இந்த commands-ஐ உங்கள் சொந்த server-ல் இயக்கவும். 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-ஆக இயங்குகிறதோ அந்த user-ஐக் குறிப்பிட வேண்டும். இயல்புநிலை image root-ஆக இயங்கும். ஆகவே, compose file-ல் user: அமைக்கவில்லை என்றால் root:root சரியான value ஆகும். Server-ஆல் எழுத முடியாத data folder இருந்தால், ஒவ்வொரு request-உம் தோல்வியடையும் login page தோன்றும். Logs-லும் இதற்கான காரணம் குறிப்பிடப்படும்.

சரியாகத் தொடங்கிய service, 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 இங்கே உள்ளவற்றுடன் பொருந்தவில்லை என்றால், VPS-க்கான Vaultwarden install guide இந்த commands எதிர்பார்க்கும் compose file-ஐக் காட்டுகிறது.

backup-ஐ எங்கு வைக்கக்கூடாது

• Data folder இருக்கும் அதே disk-ல் வைக்கக்கூடாது. ஒரு volume செயலிழந்தால் இரண்டு copies-உம் இழக்கப்படும்; தவறான path-ல் இருக்கும் ஒரு rm -rf இதே விளைவை ஏற்படுத்தும்.
• அதே server-ல், இரண்டாவது volume-ல் கூட வைக்கக்கூடாது. 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 பொருத்தமானது. ஏனெனில் restic repository-யை upload செய்வதற்கு முன் machine-லேயே encryption செய்கிறது. உங்கள் 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-க்கு point செய்யவும். இதனால் upload செய்யப்படுவது, நீங்கள் ஏற்கனவே சரிபார்த்த consistent copy ஆக இருக்கும். Repository password-ஐ பாதுகாக்கும் server-க்கு வெளியே வேறு இடத்தில் வைத்திருக்கவும். அந்த password-ஐ இழந்தால் snapshots-ஐ வாசிக்க முடியாது; இது திட்டமிட்ட பாதுகாப்பு நடைமுறை. Storage இதை ஆதரித்தால், write செய்ய முடியும் ஆனால் delete செய்ய முடியாத credentials-ஐ server-க்கு வழங்கவும். இதனால் server compromise ஆனாலும், அது தனது backup history-ஐ அழிக்க முடியாது. VPS-ல் restic backups அமைத்தல் 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 மூலம் உள்நுழையவும். எந்த row count-மும் நிரூபிக்க முடியாத வகையில், master password path தொடக்கம் முதல் முடிவு வரை செயல்படுகிறது என்பதை இது நிரூபிக்கும். அதே அட்டவணைப்படி restic check --read-data-subset=10%-ஐ இயக்குவது, சேமிக்கப்பட்ட data வெறுமனே பட்டியலிடப்படுவதல்லாமல் உண்மையில் வாசிக்கக்கூடியதாக உள்ளது என்பதையும் உறுதிப்படுத்தும்.

FAQ

இயங்கிக்கொண்டிருக்கும் Vaultwarden-ல் cp மூலம் db.sqlite3-ஐ நகலெடுக்கலாமா?

இல்லை. Vaultwarden SQLite-ஐ WAL mode-ல் இயக்குகிறது. எனவே சமீபத்திய writes db.sqlite3-wal-ல் இருக்கும்; அவை இன்னும் db.sqlite3-ல் எழுதப்பட்டிருக்காது. Main file-ஐ மட்டும் cp செய்தால், அந்த writes எந்த எச்சரிக்கையும் இல்லாமல் இழக்கப்படும். இரண்டு files-ஐ தனித்தனியாக நகலெடுத்தால், பின்னர் Error: database disk image is malformed ஆக வெளிப்படும் பொருந்தாத pair உருவாகலாம். அதற்குப் பதிலாக sqlite3 /path/db.sqlite3 ".backup '/path/out.sqlite3'"-ஐ பயன்படுத்தவும். இது SQLite-ன் Online Backup API-ஐ பயன்படுத்தி, server தொடர்ந்து சேவை வழங்கிக்கொண்டிருக்கும்போது ஒரே consistent file-ஐ உருவாக்கும்.

Backup எடுக்க Vaultwarden container-ஐ நிறுத்த வேண்டுமா?

இல்லை. அதுவே .backup-ன் நோக்கம். இயங்கிக்கொண்டிருக்கும் server-ல் database-ஐ நகலெடுப்பது பாதுகாப்பானது. ஒரு user attachment அல்லது Send file-ஐ upload செய்யும்போது அது எழுதப்படும். எனவே database copy-க்கும் tar-க்கும் இடையில் சேர்க்கப்பட்ட file அந்த இரவின் archive-ல் இடம்பெறாமல் போகலாம். மோசமான நிலையில் ஒரு attachment மட்டும் இழக்கப்படும். சில விநாடிகளின் downtime பிரச்சினையில்லை என்றால், script-க்கு முன் docker compose stop செய்து, script முடிந்ததும் docker compose start செய்யலாம். இதனால் அந்த வாய்ப்பும் நீங்கும்.

rsa_key files இல்லாமல் restore செய்தால் என்ன நடக்கும்?

Startup நேரத்தில் Vaultwarden புதிய key-ஐ உருவாக்கும். Sessions தொடர்ந்து இயங்குவதற்கான JSON web tokens (JWT)-ஐ அந்த key sign செய்கிறது. எனவே ஏற்கனவே உள்ள ஒவ்வொரு token-உம் validation-ல் தோல்வியடையும். அனைத்து clients-உம் logout செய்யப்பட்டு மீண்டும் sign in செய்ய வேண்டியிருக்கும். Vault contents பாதிக்கப்படாது. காரணம், அவை RSA key-ஐ கொண்டு அல்லாமல், ஒவ்வொரு user's master password-லிருந்து பெறப்படும் keys மூலம் encrypted செய்யப்பட்டுள்ளன. மற்ற 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 machine-ஐ விட்டு வெளியேறுவதற்கு முன் அதை 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. மற்ற அனைத்து விதிகளையும் அப்படியே பின்பற்றவும். Dump-ஐ attachments/, sends/, config.json மற்றும் rsa_key files உடன் ஒரே archive-ல் சேர்க்கவும். இவை அனைத்தும் ஒரே run-ல் எடுக்கப்பட்டு, encrypted செய்யப்பட்டு, அதை உருவாக்கிய server-ஐத் தவிர வேறு இடத்தில் சேமிக்கப்பட வேண்டும்.