SSD Nodes Learn 🎉 VPS $4.99/মাস থেকে
নির্দেশিকা Matt Connorদ্বারা Matt Connor

VPS-এ Vaultwarden ব্যাকআপ ও restore করার সঠিক পদ্ধতি

sqlite3 .backup দিয়ে live Vaultwarden vault কপি করুন। attachments, config.json ও rsa_key ফাইল রাখুন এবং বিপদের আগে restore পরীক্ষা করে নিশ্চিত হন।

Vaultwarden ব্যাকআপে যা অবশ্যই থাকতে হবে

Vaultwarden ব্যাকআপ হলো সম্পূর্ণ data folder-এর একটি কপি। এর ভেতরের database সঠিক পদ্ধতিতে কপি করতে হবে। cp-এর পরিবর্তে sqlite3 db.sqlite3 ".backup out.sqlite3" চালান, কারণ লেখা হচ্ছে এমন database সরাসরি কপি করলে এমন একটি file তৈরি হতে পারে যা আর খোলা যাবে না। এরপর database-এর পাশে থাকা অন্য file-গুলোও সংরক্ষণ করুন। অনেকেই এই অংশটি ভুলে যান।

Docker install-এ data folder হলো /data-এ mount করা folder। এটি host-এর একটি path অথবা named volume হতে পারে। bind mount এবং named volume-এর পার্থক্য disk-এ আপনার vault আসলে কোথায় থাকে, তা নির্ধারণ করে। এই 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-এ একীভূত না করা পর্যন্ত সাম্প্রতিক write এখানে থাকে।
  • attachments/: ব্যবহারকারীরা vault item-এ সংযুক্ত করা file। এগুলো encrypted অবস্থায়, প্রতিটি item-এর জন্য আলাদা directory-তে থাকে।
  • sends/: Bitwarden Send link-এর পেছনে থাকা file।
  • config.json: admin page থেকে সংরক্ষণ করা প্রতিটি setting।
  • rsa_key.pem, এবং পুরোনো install-এ rsa_key.der ও rsa_key.pub.der: login token sign করার key।
  • icon_cache/: download করা website icon। শুধু এই directory বাদ দিতে পারেন, কারণ Vaultwarden প্রয়োজন হলে এগুলো আবার fetch করে।

আমার Vaultwarden database কি নিরাপদ? ফাইলটিতে আসলে কী থাকে

এটি জানার জন্য দুটি command যথেষ্ট, এবং আপনি এখনই দুটিই চালাতে পারেন।

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-টি আপনার ব্যবহারকারীদের email address cleartext-এ দেখায়। দ্বিতীয় command-টি একটি item name দেখায়। ফলাফলটি এমন:

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

Item name, username, password এবং note client-এর মাধ্যমে পাঠানোর আগে encrypted হয়। তাই server এমন ciphertext সংরক্ষণ করে, যা সে পড়তে পারে না। 2. prefix হলো Bitwarden-এর encryption type। এর পরে থাকে initialisation vector (IV), ciphertext এবং MAC (message authentication code)। প্রতিটি অংশ base64-এ থাকে এবং | দিয়ে আলাদা করা হয়। এটি decrypt করার key account-এর master password থেকে তৈরি হয়। master password কখনো ব্যবহারযোগ্য রূপে server-এ পৌঁছায় না। Vaultwarden চালালেও বা official server চালালেও এই অংশ একই থাকে, যেমন Vaultwarden এবং self-hosted Bitwarden-এর তুলনায় বিস্তারিতভাবে দেখানো হয়েছে।

Database-এর বাকি অংশ encrypted নয়। Email address, account name, password hint এবং two-factor recovery code plain text হিসেবে সংরক্ষিত হয়। এগুলোর পাশে creation time এবং কোনো item-এর মালিক কোন organisation—এ ধরনের metadata-ও থাকে। তাই backup file নিজেই একটি secret। যার কাছে এই file থাকে, সে আপনার ব্যবহারকারীরা কারা তা জানতে পারে। সে নিজের hardware-এর সামর্থ্য অনুযায়ী encrypted blob-এর বিরুদ্ধে offline attack চালাতেও পারে। এই একটি বিষয়ই পরের storage rule-এর কারণ: copy-টি server থেকে বাইরে যাওয়ার আগে encrypted করতে হবে।

Vaultwarden চলমান অবস্থায় db.sqlite3 কপি করা ব্যাকআপ নয়

Vaultwarden ডিফল্টভাবে SQLite-কে WAL mode-এ চালায় (ENABLE_DB_WAL=true)। কোনো write প্রথমে db.sqlite3-wal-এ লেখা হয়, এবং checkpoint হলেই তা db.sqlite3-এ যুক্ত হয়। শুধু db.sqlite3 কপি করলে সর্বশেষ checkpoint-এর সময়কার database পাওয়া যায়। ফলে দশ মিনিট আগে সংরক্ষণ করা password কোনো সতর্কতা ছাড়াই archive থেকে বাদ পড়তে পারে।

cp দিয়ে তিনটি file একসঙ্গে কপি করলেও সমস্যার সমাধান হয় না। কপিগুলো সামান্য ভিন্ন সময়ে তৈরি হয়। তাই সংরক্ষিত WAL এমন page version নির্দেশ করতে পারে, যা সংরক্ষিত main file-এর অবস্থার সঙ্গে আর মেলে না। এরপর SQLite এক file থেকে অন্যটি recover করে, এবং ফলাফল ভুল হয়। আপনি বিষয়টি অনেক পরে জানতে পারেন:

Error: database disk image is malformed

.backup এই সমস্যা এড়ায়, কারণ এটি SQLite-এর Online Backup API ব্যবহার করে। সক্রিয়ভাবে ব্যবহৃত database কপি করার উপায় হিসেবে SQLite এই API-ই নথিভুক্ত করেছে। এটি read lock-এর অধীনে page পড়ে। কোনো writer একই সময়ে file পরিবর্তন করলে এটি আবার শুরু করে। ফলে disk-এ লেখা কপিটি একটি সামঞ্জস্যপূর্ণ সময়ের অবস্থাকে প্রতিনিধিত্ব করে।

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 প্রিন্ট করে। অন্য যেকোনো output হলে কপিটি ব্যবহারযোগ্য নয়। তাই এটি রেখে দেবেন না এবং আগের কপিটিও মুছবেন না। পুরো sequence-টি একটি চলমান server-এর ওপর কাজ করে। ফলে কাউকে 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 থেকে এটি চালান। ওপরের command-গুলো এই কাজই করে। Data যদি named volume-এ থাকে, docker volume inspect <name> /var/lib/docker/volumes/-এর অধীনে host path প্রিন্ট করে।

Vaultwarden version 1.32.1 থেকে নিজস্ব backup command-ও সরবরাহ করে। আপনার server-এ চালান:

docker exec -it vaultwarden /vaultwarden backup

এটি VACUUM INTO চালায় এবং data folder-এ db_YYYYMMDD_HHMMSS.sqlite3 লেখে। এর দুটি বিষয় মনে রাখতে হবে। কপিটি একই 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 ছাড়া attachment-গুলো অপাঠ্য noise হয়ে যায়, আর attachment ছাড়া database থাকলে users এমন item দেখতে পান যার download ব্যর্থ হয়। একই run-এ দুটিই নিন।

config.json-এ admin page থেকে সংরক্ষণ করা সবকিছু থাকে, এবং matching environment variable-এর তুলনায় এর value-গুলো অগ্রাধিকার পায়। এর ভালো ও খারাপ—দুই দিকই আছে: পুরোনো 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 client-কে logged in রাখে এমন JSON web token (JWT) sign করে। startup-এর সময় file-টি না থাকলে Vaultwarden নতুন key তৈরি করে। ফলে পুরোনো key দিয়ে sign করা প্রতিটি token আর validate হয় না এবং সব client logged out হয়ে যায়। Vault-এর contents এতে প্রভাবিত হয় না, কারণ সেগুলো master password থেকে derived key দিয়ে encrypted থাকে। key file restore করলে ব্যাপক logout এড়ানো যায়।

sends/ Send link-এর পেছনে থাকা file-গুলো ধারণ করে। এগুলো না থাকলে সেই download-গুলো ব্যর্থ হয়, অন্য কিছু নয়।

সবকিছু একটি স্ক্রিপ্টে রাখুন

#!/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 দেয়। তাই 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 না থাকার বিষয়টি নিশ্চিত করুন। প্রতি রাতে cron-এর পরিবর্তে একটি systemd service ও timer ব্যবহার করে এটি চালান, যদি journalctl output এবং failure report করা একটি unit চান।

ব্যাকআপটি scratch directory-তে restore করে যাচাই করুন

পরীক্ষা না করা ব্যাকআপের ওপর নির্ভর করা যায় না। 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 প্রদর্শিত হয়। user count আপনার জানা account-এর সংখ্যার সঙ্গে মিলে যায়। cipher count sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select count(*) from ciphers;" থেকে পাওয়া live সংখ্যার কাছাকাছি থাকে এবং ব্যবহারাধীন vault-এ কখনো zero হয় না। attachments directory আপনার প্রত্যাশিত আকারের কাছাকাছি থাকে; কেউ attachment upload না করলে এই পরীক্ষা বাদ দিতে পারেন। এরপর sudo rm -rf /tmp/vw-check চালান, কারণ ওই directory-তে এখন সবকিছুর দ্বিতীয় একটি copy রয়েছে।

হাতে copy করা যেকোনো data folder restore করার সময় একটি নিয়ম মেনে চলুন: server চালু করার আগে db.sqlite3-wal এবং db.sqlite3-shm মুছে দিন। অন্যথায় SQLite ভিন্ন একটি copy-এর log ব্যবহার করে restored database recover করার চেষ্টা করবে। এতে অক্ষত অবস্থায় আসা database-ও corrupt হয়ে যেতে পারে। উপরের script তৈরি করা archive-এ এই file-গুলো থাকে না, কারণ .backup একটি সম্পূর্ণ database লেখে।

সার্ভারে পুনরুদ্ধার

কনটেইনার বন্ধ থাকা অবস্থায় নিজের সার্ভারে এগুলো চালান। ডেটা ফোল্ডার পরিবর্তনের সময় 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-এ কনটেইনার যে user হিসেবে চলে, সেই user-এর নাম দিতে হবে। ডিফল্ট image root হিসেবে চলে। তাই আপনি compose file-এ user: সেট না করলে root:root সঠিক। সে ক্ষেত্রে ওই uid এবং gid ব্যবহার করুন। সার্ভার যে data folder-এ লিখতে পারে না, সেটি ব্যবহার করলে এমন login page পাবেন যেখানে প্রতিটি request ব্যর্থ হবে। লগেও এর কারণ দেখা যাবে।

সফলভাবে শুরু হলে শেষে Rocket-এর এই line দেখা যাবে:

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

এরপর browser থেকে login করুন, একটি item খুলুন এবং একটি attachment download করুন। Login কাজ করলেও attachment download ব্যর্থ হলে বুঝতে হবে archive-এ database ছিল, কিন্তু attachments/ ছিল না। সবকিছু যাচাই না হওয়া পর্যন্ত data.old.* রেখে দিন। তারপর সেটি মুছে দিন। Rollback করার ক্ষেত্রেও একই তিনটি ধাপ অনুসরণ করুন, তবে directory দুটির দিক উল্টে দিন।

আপনার path এখানে দেওয়া path-এর সঙ্গে না মিললে VPS-এর জন্য Vaultwarden install guide-এ এই command-গুলো যে compose file ধরে নেয়, সেটি দেখানো আছে।

ব্যাকআপ কোথায় রাখবেন না

  • ডেটা ফোল্ডারের একই ডিস্কে নয়। একটি volume নষ্ট হলে উভয় কপি নষ্ট হবে। ভুল path-এ একটি rm -rf হলেও একই ফল হবে।
  • একই সার্ভারে নয়, দ্বিতীয় volume হলেও নয়। কোনো আক্রমণকারী root-এ পৌঁছালে একই session-এ আপনার ব্যাকআপেও পৌঁছে যাবে।
  • encryption ছাড়া object storage-এ নয়। কারণ archive-এ email address, password hint, recovery code এবং vault ciphertext থাকে, যেগুলো offline আক্রমণের শিকার হতে পারে।
  • শুধু আপনার provider-এর snapshot-এ নয়। এগুলো দ্রুত restore হয়, তাই রাখা উপযোগী। তবে এগুলো সার্ভারের একই account-এ থাকে। ফলে account-সংক্রান্ত সমস্যায় snapshot-গুলোও প্রভাবিত হবে।

একটি offsite copy-এর জন্য restic উপযোগী। কারণ কোনো কিছু upload করার আগে restic repository মেশিনেই encrypted হয়। আপনার সার্ভারে:

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-কে archive directory-তে নির্দেশ করুন, live data folder-এ নয়। এতে upload হবে সেই consistent copy, যা আপনি আগে পরীক্ষা করেছেন। repository password সুরক্ষিত সার্ভারের বাইরে অন্য কোথাও রাখুন। সেই password হারালে নকশা অনুযায়ী snapshot পড়া যাবে না। storage এটি সমর্থন করলে সার্ভারকে এমন credentials দিন, যেগুলো দিয়ে write করা যায় কিন্তু delete করা যায় না। এতে সার্ভার compromised হলেও আক্রমণকারী তার নিজের পুরোনো backup মুছে ফেলতে পারবে না। VPS-এ restic backup সেটআপ করা-এ repository এবং schedule সম্পূর্ণভাবে ব্যাখ্যা করা হয়েছে। আপনি এখনও সিদ্ধান্ত না নিয়ে থাকলে BorgBackup-এর সঙ্গে restic-এর তুলনা-এ পছন্দের বিষয়টি ব্যাখ্যা করা হয়েছে।

মাসিক সময়সূচিতে restore পরীক্ষা করুন

মাসে একটি দিন নির্ধারণ করুন। restic restore latest --tag vaultwarden --target /tmp/vw-check ব্যবহার করে সর্বশেষ snapshot একটি অস্থায়ী directory-তে আনুন, একই PRAGMA integrity_check চালান, একই row count পরীক্ষা করুন, তারপর তারিখ ও count লিখে রাখুন। ছয় মাস ধরে যে backup কেউ restore করেনি, তার বর্তমান অবস্থা অজানা। outage-এর সময় সেই অবস্থা জানতে হলে সেটি জানার জন্য সবচেয়ে খারাপ সময়ে জানতে হবে।

বছরে একবার সম্পূর্ণ পরীক্ষা করুন। restore করা data folder ব্যবহার করে একটি অতিরিক্ত port-এ দ্বিতীয় Vaultwarden container চালু করুন এবং একটি প্রকৃত account দিয়ে login করুন। এতে শুরু থেকে শেষ পর্যন্ত master password-এর কার্যপ্রবাহ যাচাই হয়; কোনো row count এটি করতে পারে না। একই সময়সূচিতে restic check --read-data-subset=10% চালালে সংরক্ষিত data শুধু তালিকাভুক্ত নয়, পড়া যাচ্ছে কি না তাও যাচাই হয়।

FAQ

আমি কি Vaultwarden চলমান অবস্থায় cp দিয়ে db.sqlite3 কপি করতে পারি?

না। Vaultwarden SQLite-কে WAL mode-এ চালায়। তাই সাম্প্রতিক write-গুলো db.sqlite3-wal-এ থাকে এবং এখনও db.sqlite3-এ লেখা হয় না। শুধু মূল ফাইলের একটি cp নিলে এই write-গুলো নীরবে হারিয়ে যায়। দুটি ফাইল আলাদাভাবে কপি করলেও পরে Error: database disk image is malformed হিসেবে ধরা পড়তে পারে এমন অসামঞ্জস্যপূর্ণ জোড়া তৈরি হতে পারে। এর পরিবর্তে sqlite3 /path/db.sqlite3 ".backup '/path/out.sqlite3'" ব্যবহার করুন। এটি SQLite-এর Online Backup API ব্যবহার করে এবং server চালু রেখে একটি সামঞ্জস্যপূর্ণ ফাইল তৈরি করে।

Backup নেওয়ার জন্য কি Vaultwarden container বন্ধ করতেই হবে?

না, এবং .backup ব্যবহারের মূল কারণ এটাই। চলমান server-এ database কপি করা নিরাপদ। কোনো user attachment বা Send file upload করলে তা লেখা হয়। তাই database কপি এবং tar-এর মাঝখানে কোনো file যোগ হলে সেই রাতের archive-এ তা নাও থাকতে পারে। সর্বোচ্চ একটি attachment হারানোর ঝুঁকি থাকে। কয়েক সেকেন্ডের downtime সমস্যা না হলে script-এর আগে docker compose stop এবং পরে docker compose start চালান। এতে ওই ঝুঁকিটুকুও দূর হয়।

rsa_key ফাইল ছাড়া restore করলে কী হবে?

Vaultwarden startup-এর সময় একটি নতুন key তৈরি করে। এই key sessions সচল রাখার JSON web token (JWT)-এ স্বাক্ষর করে। তাই আগের সব token validation-এ ব্যর্থ হবে। সব client থেকে user-দের লগআউট হয়ে আবার sign in করতে হবে। Vault-এর contents প্রভাবিত হবে না, কারণ সেগুলো RSA key দিয়ে নয়, প্রতিটি user-এর master password থেকে derived key দিয়ে encrypted থাকে। বাকি data folder-এর সঙ্গে rsa_key.pem-ও restore করুন। তাহলে কেউ restore হওয়া বুঝতে পারবে না।

Backup archive সরাসরি object storage-এ upload করা কি নিরাপদ?

না। Item name, password এবং note-গুলো ciphertext। কিন্তু email address, account name, password hint এবং two-factor recovery code database-এ plain text হিসেবে থাকে। কোনো offline attacker নিজের সুবিধামতো সময় নিয়ে ciphertext-এর ওপর অনুমানভিত্তিক পরীক্ষা চালাতে পারে। Machine ছাড়ার আগে archive encrypted করুন। 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 দেখিয়ে কাজ করতে অস্বীকার করবে। Native tool দিয়ে database dump নিন: pg_dump বা mysqldump। বাকি সব নিয়ম একই রাখুন। একই run-এ নেওয়া dump-টি attachments/, sends/, config.json এবং rsa_key ফাইলের সঙ্গে একটি archive-এ রাখুন। Archive encrypted করে যে server এটি তৈরি করেছে তার বাইরে অন্য কোথাও সংরক্ষণ করুন।

#vaultwarden#backups#sqlite#self-hosted#security