VPS-এ Vaultwarden ব্যাকআপ ও restore করার নিয়ম

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

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

Docker install-এ data folder হলো /data-এ mount করা folder। এটি host-এর একটি path অথবা named volume হতে পারে। bind mount এবং named volume-এর পার্থক্য নির্ধারণ করে 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-এ যুক্ত না করা পর্যন্ত সাম্প্রতিক 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-এ দেখায়। দ্বিতীয়টি একটি item name দেখায়, যা দেখতে এমন:

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

Item name, username, password এবং note client-এর মাধ্যমে পাঠানোর আগে encrypt করা হয়। তাই server এমন ciphertext সংরক্ষণ করে, যা server পড়তে পারে না। 2. prefix-টি Bitwarden-এর encryption type নির্দেশ করে। এর পরে থাকে initialisation vector (IV), ciphertext এবং MAC (message authentication code)। প্রতিটি base64-এ encoded এবং | দিয়ে আলাদা করা থাকে। এটি decrypt করার key account-এর master password থেকে তৈরি হয়। master password কখনো ব্যবহারযোগ্য form-এ 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-গুলোর ভিত্তি: server থেকে copy সরানোর আগে সেটিকে encrypt করতে হবে। একই সমস্যার অন্য অংশ হলো admin token, এবং self-hosted Vaultwarden hardening-এর ধাপগুলো—এ দুটিই দেখানো হয়েছে।

Vaultwarden চলার সময় db.sqlite3 কপি করা কেন backup নয়

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

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

Error: database disk image is malformed

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

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 দেখায়। অন্য যেকোনো ফলাফলের অর্থ হলো কপিটি ব্যবহারযোগ্য নয়। তাই এটি সংরক্ষণ করবেন না এবং আগের কপিটি মুছবেন না। পুরো ক্রমটি চালু সার্ভারের ওপর চলে। ফলে কাউকে লগআউট হতে হয় না এবং কোনো container restart হয় না।

sqlite3 tool-টি Vaultwarden container-এর ভেতরে নেই। Image-টি debian:trixie-slim-এর ওপর ca-certificates, curl, libmariadb3, libpq5 এবং openssl দিয়ে তৈরি। তাই docker exec vaultwarden sqlite3 ... চালালে এই ত্রুটি দেখা যায়:

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

পরিবর্তে mounted path-এর ওপর host-এ এটি চালান। ওপরের কমান্ডগুলো এভাবেই কাজ করে। ডেটা যদি named volume-এ থাকে, docker volume inspect <name> /var/lib/docker/volumes/-এর অধীনে host path দেখায়।

Vaultwarden version 1.32.1 থেকে নিজস্ব backup command-ও সরবরাহ করছে। আপনার সার্ভারে:

docker exec -it vaultwarden /vaultwarden backup

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

config.json-এ admin page থেকে সংরক্ষণ করা সবকিছু থাকে, এবং এর values সংশ্লিষ্ট environment variable-এর ওপর অগ্রাধিকার পায়। এর উভয় দিক আছে: পুরোনো 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 আপনার জন্য একটি তৈরি করে।

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-গুলো ব্যর্থ হয়; অন্য কিছু প্রভাবিত হয় না।

সবকিছু একটি 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 0 exit করে। তাই 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 ব্যবহার করে এটি প্রতি রাতে চালান।

ব্যাকআপটি 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 প্রদর্শন করে। আপনি যে account-গুলোর কথা জানেন, user count তার সঙ্গে মেলে। 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 ভিন্ন একটি copy-এর log ব্যবহার করে restore করা database পুনরুদ্ধারের চেষ্টা করবে। এতে অক্ষত অবস্থায় পাওয়া database-ও corrupt হয়ে যায়। উপরের script তৈরি করা archive-এ ওই file-গুলো কখনো থাকে না, কারণ .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 হিসেবে চলে, তার নাম থাকতে হবে। stock image root হিসেবে চলে। তাই user: আপনার compose file-এ সেট না করলে root:root সঠিক। server কোনো 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.* রেখে দিন। তারপর এটি delete করুন। Rollback করতে একই 3টি ধাপ অনুসরণ করুন, তবে directory-গুলোর দিক উল্টো করে ব্যবহার করুন।

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

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

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

Offsite copy-এর জন্য restic উপযোগী। কারণ কোনো কিছু upload করার আগে restic repository মেশিনেই encrypted হয়। আপনার 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-কে archive directory-তে নির্দেশ করুন, live data folder-এ নয়। তাহলে এটি আপনার ইতিমধ্যে যাচাই করা consistent copy upload করবে। repository password server ছাড়া অন্য কোথাও সংরক্ষণ করুন। password হারালে design অনুযায়ী snapshot-গুলো unreadable হয়ে যাবে। storage এটি সমর্থন করলে server-কে এমন credential দিন, যা write করতে পারে কিন্তু delete করতে পারে না। তাহলে box compromise হলেও attacker তার নিজের history মুছে ফেলতে পারবে না। 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 ব্যবহার করে একটি spare 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 request পরিবেশন চালিয়ে গেলেও একটি সামঞ্জস্যপূর্ণ ফাইল তৈরি করে।

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

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

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

Vaultwarden startup-এর সময় নতুন key তৈরি করে। এই key সেই JSON web token (JWT) স্বাক্ষর করে, যা session চালু রাখে। তাই বিদ্যমান প্রতিটি token আর validation পাস করবে না। সব client থেকে user-কে log out করা হবে এবং আবার 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-এর ওপর brute-force চেষ্টা চালাতে পারে। Machine থেকে archive সরানোর আগে সেটি encrypt করুন। restic repository আপনার হয়ে এটি করে। আর gpg --symmetric --cipher-algo AES256 vw-20260805-030000.tar.gz একটি encrypted ফাইল তৈরি করে, যা যেকোনো 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 encrypt করুন এবং এটি তৈরি করা server ছাড়া অন্য কোথাও সংরক্ষণ করুন।