Vaultwarden VPS backup மற்றும் restore செய்வது எப்படி?

Vaultwarden backup-ல் என்னென்ன இருக்க வேண்டும்

Vaultwarden backup என்பது முழு தரவு கோப்புறையின் (data folder) நகலாகும். அதனுள் இருக்கும் database-ஐ சரியான முறையில் நகலெடுக்க வேண்டும். cp-க்கு பதிலாக sqlite3 db.sqlite3 ".backup out.sqlite3" கட்டளையை இயக்கவும். ஏனெனில், தரவு எழுதப்பட்டுக்கொண்டிருக்கும்போது சாதாரண நகல் எடுத்தால், அந்த கோப்பு திறக்கப்படாமல் போக வாய்ப்புள்ளது. அதன் பிறகு, அதனுடன் இருக்கும் கோப்புகளையும் சேர்த்து வைத்திருக்க வேண்டும்; இதைத்தான் பலர் மறந்துவிடுகிறார்கள்.

Docker நிறுவலில், data folder என்பது நீங்கள் /data-ல் mount செய்த இடமாகும். இது host-ல் உள்ள ஒரு பாதையாகவோ அல்லது named volume-ஆகவோ இருக்கலாம். bind mounts மற்றும் named volumes-க்கு இடையிலான வேறுபாடு உங்கள் vault வட்டில் எங்குள்ளது என்பதைத் தீர்மானிக்கிறது. அதில் உள்ளவை பின்வருமாறு:

• db.sqlite3: ஒவ்வொரு கணக்கு, ஒவ்வொரு vault உருப்படி, ஒவ்வொரு கோப்புறை மற்றும் ஒவ்வொரு அமைப்பு. இந்தக் கோப்பை இழந்தால் vault-ஐயும் இழக்க நேரிடும்.
• db.sqlite3-wal மற்றும் db.sqlite3-shm: write-ahead log (WAL) மற்றும் அதன் shared memory index. SQLite இவற்றை முதன்மைக் கோப்பில் சேர்க்கும் வரை, சமீபத்திய தரவுகள் இங்கேதான் இருக்கும்.
• attachments/: பயனர்கள் vault உருப்படிகளுடன் இணைத்த கோப்புகள். இவை உருப்படிக்கு ஒரு கோப்புறை என்ற அடிப்படையில் குறியாக்கம் (encrypted) செய்யப்பட்டு இருக்கும்.
• sends/: Bitwarden Send இணைப்புகளுக்குப் பின்னால் உள்ள கோப்புகள்.
• config.json: admin பக்கத்திலிருந்து நீங்கள் சேமித்த அனைத்து அமைப்புகளும்.
• rsa_key.pem, மற்றும் பழைய நிறுவல்களில் rsa_key.der மற்றும் rsa_key.pub.der: login tokens-ஐ sign செய்யும் key.
• icon_cache/: பதிவிறக்கம் செய்யப்பட்ட இணையதளச் சின்னங்கள் (icons). இதை நீங்கள் தவிர்த்துவிடலாம், ஏனெனில் Vaultwarden தேவைப்படும்போது இவற்றை மீண்டும் பதிவிறக்கம் செய்துகொள்ளும்.

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

இதற்கு இரண்டு கட்டளைகள் பதிலளிக்கின்றன, அவற்றை நீங்கள் இப்போதே இயக்கலாம்.

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;"

முதலாவது கட்டளை உங்கள் பயனர்களின் மின்னஞ்சல் முகவரிகளை plain text-ல் அச்சிடும். இரண்டாவது கட்டளை ஒரு item-ன் பெயரை அச்சிடும், அது பின்வருமாறு இருக்கும்:

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

Item பெயர்கள், பயனர்பெயர்கள், கடவுச்சொற்கள் மற்றும் குறிப்புகள் ஆகியவை server-க்கு அனுப்பப்படுவதற்கு முன்பே client-ஆல் குறியாக்கம் (encrypt) செய்யப்படுகின்றன. எனவே, server-ஆல் படிக்க முடியாத ciphertext-ஐ மட்டுமே அது சேமிக்கிறது. 2. முன்னொட்டு என்பது Bitwarden-ன் குறியாக்க வகையைக் குறிக்கிறது. அதைத் தொடர்ந்து ஒரு initialization vector (IV), ciphertext மற்றும் ஒரு MAC (message authentication code) ஆகியவை இருக்கும். இவை ஒவ்வொன்றும் base64 வடிவில் இருந்து | மூலம் பிரிக்கப்பட்டிருக்கும். இதை decrypt செய்யும் திறவுகோல் (key), அந்த கணக்கின் master password-லிருந்து பெறப்படுகிறது. இது எந்தவொரு பயன்பாட்டு வடிவிலும் server-க்குச் செல்வதில்லை. Vaultwarden மற்றும் self-hosted Bitwarden ஒப்பீடு பகுதியில் விளக்கியுள்ளபடி, நீங்கள் Vaultwarden-ஐ இயக்கினாலும் அல்லது அதிகாரப்பூர்வ server-ஐ இயக்கினாலும் இந்த அம்சம் ஒரே மாதிரியாகவே இருக்கும்.

Database-ன் மற்ற பகுதிகள் குறியாக்கம் செய்யப்படுவதில்லை. மின்னஞ்சல் முகவரிகள், கணக்கு பெயர்கள், கடவுச்சொல் குறிப்புகள் (hints) மற்றும் two-factor recovery codes ஆகியவை plain text-ஆக சேமிக்கப்படுகின்றன. அவற்றுடன், உருவாக்கப்பட்ட நேரம் மற்றும் ஒரு item எந்த அமைப்பிற்கு (organisation) சொந்தமானது போன்ற metadata-க்களும் சேமிக்கப்படுகின்றன. எனவே, அந்த backup கோப்பே ஒரு ரகசியமாகும். அதை வைத்திருக்கும் எவரும் உங்கள் பயனர்கள் யார் என்பதை அறிந்துகொள்ள முடியும். மேலும், அந்த encrypted blobs-ஐத் தங்கள் வன்பொருள் அனுமதிக்கும் வேகத்தில் offline-ல் தாக்குதலுக்கு உள்ளாக்க முடியும். இந்த ஒரே காரணத்திற்காகவே, கீழே கொடுக்கப்பட்டுள்ள சேமிப்பு விதிகள் மிக முக்கியமானவை: server-ஐ விட்டு வெளியேறும் முன்பே அந்த நகல் குறியாக்கம் செய்யப்பட வேண்டும்.

Vaultwarden இயங்கும்போது db.sqlite3-ஐ நகலெடுப்பது ஏன் காப்புப்பிரதி (backup) ஆகாது

Vaultwarden இயல்பாகவே SQLite-ஐ WAL mode-ல் இயக்குகிறது (ENABLE_DB_WAL=true). ஒரு தரவு மாற்றம் முதலில் 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 மூலம் பக்கங்களைப் படிக்கிறது; நகலெடுக்கும்போது ஏதேனும் மாற்றம் நடந்தால், இது மீண்டும் தொடங்குகிறது. எனவே, வட்டில் சேமிக்கப்படும் தரவு ஒரு குறிப்பிட்ட தருணத்தின் சீரான நகலாக இருக்கும்.

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-ல் நடப்பதால், பயனர்கள் வெளியேற்றப்பட மாட்டார்கள் மற்றும் எந்த container-ம் restart செய்யப்படாது.

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

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

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

பதிப்பு 1.32.1 முதல் Vaultwarden தனது சொந்த backup கட்டளையையும் வழங்குகிறது. உங்கள் server-ல்:

docker exec -it vaultwarden /vaultwarden backup

இது VACUUM INTO-ஐ இயக்கி, db_YYYYMMDD_HHMMSS.sqlite3-ஐ தரவு கோப்புறையில் (data folder) எழுதும். இதில் இரண்டு விஷயங்களைக் கவனிக்க வேண்டும். இந்த நகல் அசல் கோப்பிற்கு அருகிலேயே அதே disk-ல் சேமிக்கப்படுவதால், இது ஒரு தற்காலிகச் சேமிப்பு (staging) மட்டுமே, முழுமையான backup அல்ல. மேலும் இது SQLite-க்கு மட்டுமே பொருந்தும்: MariaDB அல்லது PostgreSQL-ல் இது The database type is not SQLite. Backups only works for SQLite databases பிழையுடன் நின்றுவிடும்.

மறந்துவிடக்கூடிய கோப்புகள்

attachments/ என்பது மறைமுகமான பெயர்களில் குறியாக்கம் செய்யப்பட்ட தரவுகளை (ciphertext) வைத்திருக்கிறது. ஒவ்வொரு இணைப்பிற்கான (attachment) database வரிசையும், அதன் குறியாக்கம் செய்யப்பட்ட கோப்புப் பெயரையும், பயனர் கோப்பை மறைகுறியாக்கம் (decrypt) செய்யத் தேவையான முக்கியத் தகவலையும் (key material) கொண்டுள்ளது. Database இல்லாமல் இணைப்புகளைப் பார்த்தால் அவை வாசிக்க முடியாத இரைச்சலாகவே இருக்கும்; இணைப்புகள் இல்லாமல் database-ஐ மட்டும் பயன்படுத்தினால், பயனர்கள் பதிவிறக்கம் செய்ய முயலும்போது தோல்வியடையும். எனவே, இரண்டையும் ஒரே நேரத்தில் காப்புப்பிரதி (backup) எடுக்கவும்.

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

rsa_key.pem என்பது வாடிக்கையாளர்கள் (clients) உள்நுழைந்திருப்பதை உறுதிப்படுத்தும் JSON web tokens (JWT)-ஐ கையொப்பமிடுகிறது (sign). தொடக்கத்தின்போது இந்தக் கோப்பு இல்லையென்றால், Vaultwarden புதிய key-ஐ உருவாக்கிவிடும். இதனால் பழைய key மூலம் கையொப்பமிடப்பட்ட அனைத்து tokens-ம் செல்லாததாகி, அனைத்து வாடிக்கையாளர்களும் வெளியேற்றப்படுவார்கள் (log out). Vault-ல் உள்ள தரவுகள், master password மூலம் பெறப்பட்ட சாவிகளால் குறியாக்கம் செய்யப்பட்டுள்ளதால் அவை அழியாது. இந்தக் கோப்பை மீட்டெடுப்பதன் மூலம் பயனர்கள் அனைவரும் ஒரே நேரத்தில் வெளியேற்றப்படுவதைத் தவிர்க்கலாம்.

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 எனச் சேமித்து, chmod 700 செய்து, root பயனராக இயக்கவும். test வரிதான் உண்மையான வேலையைச் செய்கிறது: PRAGMA integrity_check தரவு சிதைந்திருப்பதாக (corruption) அறிவித்தாலும் sqlite3 ஆனது 0 என்ற exit code-ஐயே தரும், எனவே அதன் வெளியீட்டை ok உடன் ஒப்பிடுவதுதான் தவறான நகலை தோல்வியடைந்த script-ஆக மாற்றுகிறது. set -euo pipefail கட்டளை, சிதைந்த database-ஐ வைத்துக்கொண்டு tar ஒரு முழுமையான archive-ஐ உருவாக்குவதைத் தடுத்து, அனைத்தையும் நிறுத்திவிடும்.

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

Backup-ஐ ஒரு scratch directory-ல் restore செய்து சரிபார்த்தல்

சோதிக்கப்படாத backup என்பது வெறும் ஊகம் மட்டுமே. ஒரு scratch directory-ல் restore செய்வது ஒரு நிமிடம் மட்டுமே எடுக்கும், மேலும் இது நேரடித் தரவுகளைப் பாதிக்காது.

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;"-ல் உள்ள நேரடித் தரவுகளுடன் நெருக்கமாக இருக்க வேண்டும், பயன்பாட்டில் உள்ள vault-க்கு இது ஒருபோதும் பூஜ்ஜியமாக இருக்காது. Attachments directory-ன் அளவு நீங்கள் எதிர்பார்த்த அளவில் இருக்க வேண்டும்; யாரும் கோப்புகளைப் பதிவேற்றவில்லை என்றால் இதைத் தவிர்க்கலாம். அதன் பிறகு sudo rm -rf /tmp/vw-check கட்டளையை இயக்கவும், ஏனெனில் அந்த directory இப்போது அனைத்தின் இரண்டாவது நகலையும் கொண்டுள்ளது.

கைமுறையாக நகலெடுக்கப்பட்ட எந்தவொரு தரவு கோப்புறையையும் (data folder) restore செய்யும்போது ஒரு விதி உள்ளது: server-ஐத் தொடங்குவதற்கு முன் db.sqlite3-wal மற்றும் db.sqlite3-shm ஆகியவற்றை நீக்கிவிட வேண்டும். இல்லையெனில், SQLite வேறொரு நகலுக்குச் சொந்தமான log-ஐப் பயன்படுத்தி restore செய்யப்பட்ட database-ஐ மீட்டெடுக்க முயற்சிக்கும்; இது சரியாக இருக்கும் database-ஐச் சிதைத்துவிடும். மேலே உள்ள script மூலம் உருவாக்கப்பட்ட archives-ல் அந்த கோப்புகள் ஒருபோதும் இருக்காது, ஏனெனில் .backup ஒரு முழுமையான database-ஐ மட்டுமே எழுதும்.

சர்வரில் தரவை மீட்டமைத்தல்

கண்டெய்னர் நிறுத்தப்பட்ட நிலையில், உங்கள் சொந்த சர்வரில் இவற்றை இயக்க வேண்டும். தரவு கோப்புறை (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 என்பது கண்டெய்னரை இயக்கும் பயனரின் பெயரைக் கொண்டிருக்க வேண்டும். ஸ்டாக் இமேஜ் (stock image) root பயனராக இயங்குகிறது, எனவே root:root சரியானது. உங்கள் compose கோப்பில் user: அமைப்பை நீங்கள் மாற்றியிருந்தால், அந்த uid மற்றும் gid-ஐ பயன்படுத்தவும். சர்வரால் எழுத முடியாத தரவு கோப்புறை இருந்தால், லாகின் பக்கம் ஒவ்வொரு கோரிக்கையையும் நிராகரிக்கும், இது லாக் கோப்புகளில் பதிவாகும்.

சரியான தொடக்கம் Rocket வரியுடன் முடிவடையும்:

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

பிறகு பிரவுசரில் லாகின் செய்து, ஒரு உருப்படியைத் திறந்து, ஒரு இணைப்பை (attachment) தரவிறக்கம் செய்யவும். லாகின் வேலை செய்து, ஆனால் இணைப்பு தரவிறக்கம் தோல்வியடைந்தால், தரவுத்தளம் காப்பகத்தில் உள்ளது, ஆனால் attachments/ இல்லை என்று அர்த்தம். அனைத்தும் சரியாகச் சரிபார்க்கப்படும் வரை data.old.*-ஐ வைத்திருக்கவும், அதன் பிறகு அதை நீக்கவும். பழைய நிலைக்குத் திரும்புவதும் (rolling back) இதே மூன்று படிகளை உள்ளடக்கியது, ஆனால் கோப்பகங்களை (directories) மாற்றியமைக்க வேண்டும்.

உங்கள் பாதைகள் (paths) இங்கே உள்ளவற்றுடன் பொருந்தவில்லை என்றால், VPS-க்கான Vaultwarden நிறுவல் வழிகாட்டி இந்த கட்டளைகள் எதிர்பார்க்கும் compose கோப்பைக் காட்டுகிறது.

காப்புப்பிரதியை (backup) எங்கு வைக்கக்கூடாது

• தரவு கோப்புறை (data folder) இருக்கும் அதே வட்டில் (disk) வைக்கக்கூடாது. ஒரு volume செயலிழந்தால் இரண்டு பிரதிகளும் அழிந்துவிடும்; தவறான பாதையில் ஒரு rm -rf கட்டளையை இயக்கினாலும் இதுவே நிகழும்.
• ஒரே server-ல் வைக்கக்கூடாது, இரண்டாவது volume-ல் இருந்தாலும் சரி. root அணுகலைப் பெறும் ஒரு தாக்குதல், அதே அமர்வில் (session) உங்கள் காப்புப்பிரதிகளையும் அடைந்துவிடும்.
• குறியாக்கம் (encryption) செய்யாமல் object storage-ல் வைக்கக்கூடாது. ஏனெனில், அந்த காப்பகத்தில் (archive) மின்னஞ்சல் முகவரிகள், கடவுச்சொல் குறிப்புகள், மீட்பு குறியீடுகள் மற்றும் vault ciphertext ஆகியவை இருக்கும்; இவற்றை ஆஃப்லைனில் தாக்குதலுக்கு உள்ளாக்க முடியும்.
• உங்கள் சேவை வழங்குநரின் (provider) snapshots-ல் மட்டும் வைக்கக்கூடாது. அவை விரைவாக மீட்கக்கூடியவை என்பதால் பயனுள்ளவை, ஆனால் அவை server இருக்கும் அதே கணக்கில் (account) இருப்பதால், கணக்கில் ஏதேனும் சிக்கல் ஏற்பட்டால் காப்புப்பிரதிகளும் அழிந்துவிடும்.

ஒரு offsite பிரதி தேவைப்படும்போது restic பொருத்தமானதாக இருக்கும். ஏனெனில், எதையும் பதிவேற்றுவதற்கு முன்பே restic repository அந்த இயந்திரத்திலேயே குறியாக்கம் செய்யப்படுகிறது. உங்கள் 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) சுட்டிக்காட்டவும். அப்போதுதான் நீங்கள் ஏற்கனவே சரிபார்த்த சீரான பிரதி பதிவேற்றப்படும். repository கடவுச்சொல்லை அது பாதுகாக்கும் server-ல் வைக்காமல் வேறு இடத்தில் வைத்திருக்கவும்: அந்தக் கடவுச்சொல்லை இழந்தால், வடிவமைப்பின்படி snapshots-ஐ வாசிக்க முடியாது. சேமிப்பகம் (storage) அனுமதிக்கும் பட்சத்தில், server-க்கு எழுத மட்டுமே அனுமதி அளித்து, நீக்க அனுமதி அளிக்காத credentials-ஐ வழங்கவும். இதன் மூலம், server சமரசம் செய்யப்பட்டாலும் (compromise) அதன் வரலாற்றை (history) அழிக்க முடியாது. VPS-ல் restic காப்புப்பிரதிகளை அமைத்தல் பகுதி repository மற்றும் கால அட்டவணையை முழுமையாக விளக்குகிறது. நீங்கள் இன்னும் தேர்வு செய்யவில்லை என்றால், restic மற்றும் BorgBackup ஒப்பீடு பகுதி உங்களுக்கு உதவும்.

அட்டவணைப்படி restore சோதனையை மேற்கொள்ளுதல்

மாதத்திற்கு ஒரு நாளைத் தேர்வு செய்யவும். restic restore latest --tag vaultwarden --target /tmp/vw-check-ஐப் பயன்படுத்தி புதிய snapshot-ஐ ஒரு scratch directory-க்கு எடுக்கவும். அதே PRAGMA integrity_check-ஐ இயக்கவும், அதே row counts-ஐச் சரிபார்க்கவும், பின்னர் அந்தத் தேதியையும் எண்ணிக்கையையும் குறித்து வைக்கவும். ஆறு மாதங்களாக restore செய்யப்படாத backup என்பது அதன் தற்போதைய நிலை அறியப்படாத ஒன்று. ஒரு outage ஏற்படும்போது அதன் நிலையை அறிவது மிகவும் மோசமான சூழலாகும்.

ஆண்டுக்கு ஒருமுறை, முழுமையான சோதனையைச் செய்யவும். மீட்கப்பட்ட தரவு கோப்புறையுடன் (data folder) ஒரு கூடுதல் port-ல் இரண்டாவது Vaultwarden container-ஐத் தொடங்கவும், பின்னர் ஒரு உண்மையான கணக்கைப் பயன்படுத்தி உள்நுழையவும். இது master password பாதையை முழுமையாக உறுதிப்படுத்தும், இதை row count மூலம் செய்ய முடியாது. அதே அட்டவணையில் restic check --read-data-subset=10%-ஐ இயக்குவது, சேமிக்கப்பட்ட தரவு வெறும் பட்டியலிடப்படுவது மட்டுமல்லாமல், வாசிக்கக்கூடிய நிலையில் இருப்பதையும் உறுதிப்படுத்தும்.

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-ன் நோக்கமே. சர்வர் இயங்கிக்கொண்டிருக்கும்போதே தரவுத்தள நகல் எடுப்பது பாதுகாப்பானது. பயனர் ஒரு கோப்பை பதிவேற்றும்போதுதான் Attachments மற்றும் Send கோப்புகள் எழுதப்படுகின்றன. தரவுத்தள நகல் எடுப்பதற்கும் tar-க்கும் இடைப்பட்ட நேரத்தில் சேர்க்கப்படும் ஒரு கோப்பு அந்த நாள் காப்பகத்தில் விடுபடலாம்; இது அதிகபட்சம் ஒரு கோப்பு இழப்பை மட்டுமே ஏற்படுத்தும். சில நொடிகள் சர்வர் இயங்காமல் இருப்பது உங்களுக்குப் பிரச்சினையில்லை என்றால், ஸ்கிரிப்ட் தொடங்குவதற்கு முன் docker compose stop-ஐயும், முடிந்த பிறகு docker compose start-ஐயும் பயன்படுத்தினால் அந்தச் சிறிய சிக்கலும் இருக்காது.

rsa_key கோப்புகள் இல்லாமல் தரவை மீட்டெடுத்தால் என்னவாகும்?

Vaultwarden தொடங்கும்போதே புதிய சாவியை (key) உருவாக்கும். அந்தச் சாவிதான் அமர்வுகளை (sessions) உயிர்ப்புடன் வைத்திருக்கும் JSON web tokens (JWT)-ஐ கையொப்பமிடுகிறது. எனவே, ஏற்கனவே உள்ள அனைத்து டோக்கன்களும் செல்லாததாகிவிடும்; பயனர்கள் அனைவரும் வெளியேற்றப்பட்டு மீண்டும் உள்நுழைய வேண்டியிருக்கும். Vault-ல் உள்ள தரவுகள் பாதிக்கப்படாது, ஏனெனில் அவை RSA சாவியால் அல்லாமல், ஒவ்வொரு பயனரின் master password-லிருந்து பெறப்பட்ட சாவிகளால் குறியாக்கம் (encrypt) செய்யப்படுகின்றன. தரவு கோப்புறையுடன் சேர்த்து rsa_key.pem-ஐயும் மீட்டெடுத்தால், பயனர்களுக்கு எந்த மாற்றமும் தெரியாது.

பேக்கப் காப்பகத்தை அப்படியே ஆப்ஜெக்ட் ஸ்டோரேஜில் பதிவேற்றுவது பாதுகாப்பானதா?

இல்லை. உருப்படிகளின் பெயர்கள், கடவுச்சொற்கள் மற்றும் குறிப்புகள் குறியாக்கம் செய்யப்பட்டிருக்கும். ஆனால், மின்னஞ்சல் முகவரிகள், கணக்கு பெயர்கள், கடவுச்சொல் குறிப்புகள் மற்றும் two-factor recovery குறியீடுகள் தரவுத்தளத்தில் சாதாரண உரையாகவே (plain text) இருக்கும். ஒரு தாக்குதல் நடத்துபவர் ஆஃப்லைனில் அந்த குறியாக்கத்தை எளிதில் உடைக்க முடியும். காப்பகத்தை சர்வரிலிருந்து வெளியேற்றும் முன் குறியாக்கம் செய்யவும். ஒரு restic repository இதை உங்களுக்காகச் செய்யும், மேலும் 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 மூலம் டம்ப் (dump) செய்யவும். மற்ற அனைத்து விதிகளும் அப்படியே பொருந்தும். அந்த டம்ப் கோப்பை attachments/, sends/, config.json மற்றும் rsa_key கோப்புகளுடன் ஒரே காப்பகத்தில் வைத்து, ஒரே நேரத்தில் குறியாக்கம் செய்து, அதை உருவாக்கிய சர்வரைத் தவிர வேறு இடத்தில் சேமிக்கவும்.