VPS-কে off-site backup target হিসেবে ব্যবহার করবেন কীভাবে

আলাদা অবস্থানের backup target আসলে কী

আলাদা অবস্থানের backup target হলো এমন একটি দ্বিতীয় মেশিন, যেখানে আপনার data-এর একটি copy থাকে এবং যা মূল মেশিনের failure থেকে স্বাধীন থাকে। অধিকাংশ পাঠকের জন্য অন্য provider-এর একটি VPS হলো এর সবচেয়ে সাশ্রয়ী বিকল্প। বাস্তবে তিনটি ধরন বেশি ব্যবহারযোগ্য: VPS-এ চলা Proxmox Backup Server, SSH বা S3-এর মাধ্যমে ব্যবহৃত restic repository, অথবা backup host নিজে pull করে এমন একটি rsync mirror। কোনটি উপযুক্ত হবে, তা নির্ভর করে আপনি কী restore করবেন এবং কত দ্রুত তা ফিরিয়ে আনতে হবে তার ওপর। Copy মুছে ফেলার অনুমতি কার আছে, সেটিই পরবর্তী নিরাপত্তা নির্ধারণ করে।

আলাদা অবস্থান বলতে ভিন্ন failure domain বোঝায়। অর্থাৎ ভিন্ন provider এবং এমন একটি account, যেটি আপনার server চালানো account-এর সঙ্গে কোনো login share করে না। একই provider-এর অন্য region-এ থাকা দ্বিতীয় server একটি ভবনের আগুন থেকে টিকে যেতে পারে। কিন্তু compromised control panel login থেকে টিকে থাকতে পারে না, কারণ একই account উভয় copy নিয়ন্ত্রণ করে।

আপনার provider-এর snapshot দ্বিতীয় copy নয়। এটি একই panel password-এর সুরক্ষার পেছনে থাকে। তাই যে ব্যক্তি ওই password পেয়ে যায়, সে একই session-এ server এবং তার snapshot উভয়ই মুছে দিতে পারে। Snapshot service-গুলো প্রতি মাসে প্রতি gigabyte হিসেবে plain disk-এর তুলনায় অনেক বেশি মূল্য নেয়। ফলে নব্বই দিনের snapshot সংরক্ষণ ব্যয়বহুল হয়ে যায়। VPS snapshot এবং backup-এর পার্থক্য-টি পড়ে নিন, তারপর যেকোনো একটি ব্যবস্থার ওপর নির্ভর করুন।

আপনার জন্য কোন তিনটি ধরন উপযুক্ত

• Proxmox Backup Server (PBS): উৎস হলো Proxmox VE (virtual environment), আর পুনরুদ্ধার করেন একটি সম্পূর্ণ virtual machine। এটি disk-image level-এ backup নেয়, এবং এর verify job-গুলো target-এ থাকা data পুনরায় পড়ে পরীক্ষা করে।
• একটি restic repository: উৎস হলো এক বা একাধিক Linux host, আর পুনরুদ্ধার করেন একটি directory বা database dump। এটি client-এ data encrypt করে এবং SSH, S3 ও নিজস্ব REST protocol সমর্থন করে।
• backup host দ্বারা pull করা SSH-এর ওপর rsync: আপনি চান target-এ file-গুলো সাধারণ file হিসেবে থাকুক, যাতে ls ও cat ব্যবহার করে পড়া যায় এবং সেগুলো পুনরুদ্ধারের জন্য client software-এর প্রয়োজন না হয়।

সিদ্ধান্ত নিতে না পারলে restic ব্যবহার করুন। কোনো data machine থেকে বাইরে যাওয়ার আগেই এটি encrypt করে। Target-এ SSH account এবং disk ছাড়া আর কিছু প্রয়োজন হয় না। VPS-এ restic backup সেটআপ করা-এ client side সম্পর্কে আরও বিস্তারিত আছে। আপনি যদি ইতিমধ্যে Borg চালান, তাহলে restic ও BorgBackup পাশাপাশি তুলনা-এ পছন্দ নির্ধারণের নির্দেশনা পাবেন।

টার্গেটের আকার নির্ধারণ: এক মাসের retention-এর খরচ

Deduplication-এর কারণে সংখ্যাগুলো প্রত্যাশার চেয়ে ছোট হয়। restic এবং PBS উভয়ই ফাইলকে পরিবর্তনশীল আকারের chunk-এ ভাগ করে এবং প্রতিটি chunk-এর hash তৈরি করে। প্রতিটি unique chunk একবারই সংরক্ষণ করা হয়। 500 GB dataset-এর দ্বিতীয় backup-এ আরও 500 GB যোগ হয় না। শুধু পরিবর্তিত chunk-গুলো যোগ হয়।

তাই repository-এর আকার snapshot-এর সংখ্যার ওপর নয়, সবচেয়ে পুরোনো snapshot-এর বয়সের ওপর নির্ভর করে। ধরুন, আপনার 500 GB data আছে এবং প্রতিদিন 5 GB নতুন unique data যোগ হয়। তাহলে repository-তে থাকবে 500 GB base, এর সঙ্গে policy-তে রাখা সবচেয়ে পুরোনো snapshot পর্যন্ত প্রতিদিনের জন্য প্রায় 5 GB করে।

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

Dollar কলামে সেই repository-এর মূল্য প্রতি TB প্রতি মাসে 10 US dollars ধরে হিসাব করা হয়েছে। এটি শুধু arithmetic বোঝানোর জন্য একটি placeholder; কোনো provider-এর quotation নয়। তাই আপনি যে plan বিবেচনা করছেন, তার প্রকৃত per-TB price ব্যবহার করুন। এক সপ্তাহের daily backup-এ প্রায় 535 GB থাকে। পুরো এক বছরের history-তে থাকে 2,325 GB, যার মাসিক খরচ $23.25; এক সপ্তাহের জন্য খরচ $5.35। History-এর খরচ কম। মূল copy-টির জন্যই মূলত আপনাকে অর্থ দিতে হচ্ছে।

আগেই compressed বা encrypted হয়ে আসা data-এর ক্ষেত্রে deduplication কোনো সুবিধা দেয় না। একটি gzipped database dump প্রতিবার সম্পূর্ণভাবে পরিবর্তিত হয়। তাই প্রতিটি dump নতুন chunk হিসেবে সংরক্ষিত হয় এবং repository প্রতি রাতে একটি সম্পূর্ণ dump-এর সমপরিমাণ বড় হয়। Dump-টি uncompressed অবস্থায় লিখুন এবং backup tool-কে সেটি compress করতে দিন। কারণ restic 0.14 থেকে compressed repository সমর্থন করে এবং version 0.19-এ fastest ও better zstd mode যোগ হয়েছে। একই কারণে photo ও video library-তে deduplication-এর কার্যকারিতা কম। তাই উপরের সারির ভিত্তিতে নয়, তাদের প্রকৃত growth rate অনুযায়ী আকার নির্ধারণ করুন।

এখানে আপনি CPU নয়, অব্যবহৃত disk কিনছেন। এই পরিস্থিতিতেই একটি storage VPS সাধারণ VPS-এর চেয়ে ভালো।

কেন bandwidth এবং restore time পরিকল্পনা নির্ধারণ করে

Disk সস্তা অংশ। প্রথম upload এবং শেষের restore ব্যয়বহুল অংশ। 500 GB হলো 4 trillion bits, তাই link speed দিয়ে ভাগ করলে একটি full restore সম্পন্ন হতে ন্যূনতম কত সময় লাগবে তার হিসাব পাওয়া যায়।

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

এগুলো protocol overhead ছাড়া line-rate হিসাব। তাই এগুলোকে best case হিসেবে ধরুন। 100 Mbit/s গতিতে data ব্যবহার করার আগে একটি full restore-এর 11.1 ঘণ্টা সময় লাগে। Home upload-এর গতি 40 Mbit/s হলে সময় লাগে 27.8 ঘণ্টা। 1 Gbit/s port-এ একই restore সম্পন্ন হতে 1.1 ঘণ্টা লাগে। অনেক ছোট file থাকলে গাণিতিক হিসাবের চেয়ে গতি কম হয়, কারণ file-এর আকার কয়েকশ kilobyte-এর নিচে নামলে প্রতি-file overhead প্রধান কারণ হয়ে দাঁড়ায়।

এ থেকে দুটি বিষয় বোঝা যায়। আপনার recovery time objective (RTO), অর্থাৎ আপনি যতক্ষণ outage সহ্য করতে পারেন, যদি চার ঘণ্টা হয়, তাহলে 100 Mbit/s link-এর মাধ্যমে 500 GB restore ইতিমধ্যেই সেই সীমা অতিক্রম করেছে; সস্তা disk এতে কোনো সাহায্য করবে না। অধিকাংশ VPS plan outbound transfer-এর জন্য usage গণনা করে। তাই একটি full restore backup host-এর মাসিক allowance থেকে 0.5 TB খরচ করে। Data প্রয়োজন হওয়ার আগে সেই allowance পরীক্ষা করুন। সীমা অতিক্রম করলে provider কী ব্যবস্থা নেয়, তাও পরীক্ষা করুন।

প্রথম backup-এ সম্পূর্ণ dataset থাকে এবং এটিই আপনার করা সবচেয়ে ধীর run হবে। শুক্রবার এটি শুরু করুন এবং rate-limit করুন, যাতে source-এর uplink সম্পূর্ণ capacity-তে না চলে: restic প্রতি সেকেন্ডে --limit-upload KiB নেয়, আর rsync নেয় --bwlimit।

Shape 1: দূরবর্তী datastore হিসেবে Proxmox Backup Server

source যদি Proxmox VE হয় এবং restore-এর একক virtual machine হয়, তাহলে PBS উপযোগী। একটি VPS Proxmox ISO boot করতে পারে না, তাই Debian-এর ওপর PBS ইনস্টল করুন। August 2026 অনুযায়ী Version 4.2 বর্তমান এবং এটি Debian 13 (trixie)-এর ওপর তৈরি।

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

এই checksum-টি Proxmox package repositories page-এ প্রকাশিত মানের সঙ্গে মিলিয়ে দেখুন। আপনি যে key যাচাই করেছেন, apt repository-এর বিশ্বাসযোগ্যতা তার ওপরই নির্ভর করে। এরপর /etc/apt/sources.list.d/proxmox.sources লিখুন:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

datastore-এর জন্য আলাদা filesystem বা আলাদা volume ব্যবহার করুন। datastore পূর্ণ হলে backup বন্ধ হয়ে যায়। datastore যদি root filesystem-এর সঙ্গে ভাগ করা থাকে, সেটি পূর্ণ হলে পুরো server অচল হয়ে যায়।

এরপর source যে account ব্যবহার করবে, সেটি তৈরি করুন এবং password-এর পরিবর্তে তাকে একটি token দিন।

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

token secret একবারই দেখানো হয় এবং পরে তা পড়ে দেখা যায় না। তাই প্রদর্শিত হওয়ার সময় এটি সংরক্ষণ করুন। token-এর মতো role-ও গুরুত্বপূর্ণ। DatastoreBackup নিজের backup তৈরি ও restore করতে পারে, কিন্তু এর কাছে Datastore.Prune privilege নেই। তাই ওই token দিয়ে token-টি ইতিমধ্যে যে snapshot লিখেছে, সেটি মুছে ফেলা যায় না।

PBS-এ retention-এর দুটি অংশ আছে। দ্বিতীয় অংশটি অনেকেই বাদ দেন। Prune snapshot সরিয়ে দেয়। Garbage collection এমন chunk সরিয়ে দেয়, যেগুলো কোনো অবশিষ্ট snapshot আর reference করে না। Free space prune-এর পরে নয়, garbage collection-এর পরে দেখা যায়।

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

যে snapshot-গুলো সরানোর পরিকল্পনা করা হয়েছে, সেগুলোর তালিকা সঠিক মনে হলে --dry-run বাদ দিন। Garbage collection দুটি ধাপে চলে। প্রথমে এটি এখনও referenced থাকা প্রতিটি chunk-এর access time আপডেট করে। এরপর cutoff-এর চেয়ে পুরোনো access time থাকা chunk মুছে দেয়। এই cutoff হলো run শুরু হওয়ার 24 hours and 5 minutes আগের সময়। এই grace period রাখা হয়েছে, যাতে চলমান backup যে chunk লিখছে, সেটি backup শেষ হওয়ার আগে মুছে না যায়। datastore-এ প্রতিদিন prune এবং প্রতি সপ্তাহে garbage collection schedule করুন। পাশাপাশি একটি verify job যোগ করুন, যাতে target নিজস্ব chunk আবার পড়ে এবং restore-এর আগে disk corruption জানায়।

source যদি নিজেই একটি PBS instance হয়, তাহলে off-site box-এ push করার পরিবর্তে সেটি pull করতে পারে।

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

default pull direction ব্যবহার করে VPS-এ ওই sync job চালান। VPS home datastore-এ প্রবেশ করে। এর ফলে home box-এ এমন কোনো credential থাকে না, যা off-site copy-তে পরিবর্তন করতে পারে।

Shape 2: SSH বা S3-এর মাধ্যমে একটি restic repository

Debian এবং Ubuntu উভয়েই restic প্যাকেজ করে, তবে দুটিই upstream-এর তুলনায় পুরোনো version সরবরাহ করে। August 2026 অনুযায়ী বর্তমান version হলো 0.19.1। source host-এ official binary install করুন।

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version version এবং এটি যে Go compiler দিয়ে build করা হয়েছে তা দেখায়। পরবর্তী upgrade-এর জন্য sudo restic self-update ব্যবহার করুন। এটি official binary-তে কাজ করে, কিন্তু apt দিয়ে install করা copy-তে কাজ করে না।

backup VPS-এ এমন একটি account তৈরি করুন, যার অন্য কোনো resource-এর মালিকানা নেই। এরপর source host-এর public key /home/resticsrv/.ssh/authorized_keys-এ কপি করুন।

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

SFTP-এর মাধ্যমে source host থেকে repository initialise করুন।

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

এই password এমন কোথাও সংরক্ষণ করুন, যা এই server বা backup target কোনোটিই নয়। password হারালে repository আর পড়া যাবে না এবং কোনো recovery path থাকবে না। client-side encryption-এর সঙ্গে এটাই আপনার সমঝোতা।

Retention একটি command-এই করা যায়। এর দ্বিতীয় অংশটিই disk space মুক্ত করে।

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget snapshot মুছে দেয়। prune শুধু ওই snapshot-গুলো যেসব pack file reference করত, সেগুলো মুছে দেয়। --prune কোনো কিছু সত্যিই মুছে গেলে এটি স্বয়ংক্রিয়ভাবে চালায়। এটি না থাকলে repository কখনো ছোট হয় না। restic check repository structure যাচাই করে। --read-data-subset=10% pack file-এর এক-দশমাংশ আবার পড়ে hash করে। এতে সবকিছু পড়ার খরচ ছাড়াই target-এ corruption শনাক্ত করা যায়। অন্য form, --read-data-subset=1/10, একটি নির্দিষ্ট এক-দশমাংশ পরীক্ষা করে। তাই প্রতি সপ্তাহে প্রথম number বাড়ালে দশ সপ্তাহে পুরো repository পরীক্ষা করা হয়।

কোনো run বন্ধ করে দেওয়া হলে পরের run repository is already locked exclusively by PID দিয়ে থেমে যায়। কোনো backup চলছে না তা নিশ্চিত করুন। এরপর restic unlock দিয়ে এটি পরিষ্কার করুন।

Object storage ব্যবহার করলে repository string হবে s3:https://s3.example.net/web1। Credentials থাকবে AWS_ACCESS_KEY_ID এবং AWS_SECRET_ACCESS_KEY-এ। অন্য সবকিছু একই থাকবে। এভাবেই restic একই VPS-এ চলা self-hosted MinIO object store-এর সঙ্গে কথা বলে।

শৈলী 3: pull-only key ব্যবহার করে SSH-এর মাধ্যমে rsync

এই শৈলীর নিরাপত্তা মূলত সংযোগের দিকনির্দেশের ওপর নির্ভর করে। backup VPS source-এ সংযোগ করে এবং সেখান থেকে শুধু পড়ে। source-এ কোনো key বা backup host-এ যাওয়ার কোনো route নেই। তাই source compromised হলেও backup-এ কোনোভাবেই পৌঁছাতে পারে না।

backup VPS-এ একটি key pair তৈরি করুন। এরপর forced command ব্যবহার করে public অংশটি source-এ ইনস্টল করুন।

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

Debian 13 এবং Ubuntu 24.04-এ rrsync rsync package-এর মধ্যে /usr/bin/rrsync-এ থাকে। -ro শুধু পড়ার অনুমতি দেয় এবং -no-del কার্যকর করে। তাই এই key source-এ কিছু লিখতে বা সেখানে কোনো কিছু মুছতে পারে না। restrict এখানে প্রয়োজন নেই এমন SSH feature বন্ধ করে, যার মধ্যে port forwarding এবং pty-ও রয়েছে। ফলে এই key ব্যবহার করে interactive login করা যায় না। এরপর path-গুলো আপনার নির্ধারিত directory-এর relative হয়। তাই remote path / source-এ /srv বোঝায়।

এই pull hardlink ব্যবহার করে history সংরক্ষণ করে। নতুন tree-তে অপরিবর্তিত file-গুলো আগের tree-এর hardlink হয়। তাই দ্বিতীয় copy তৈরির বদলে শুধু একটি directory entry লাগে।

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

শেষের rename-ই dated directory-কে নির্ভরযোগ্য করে। rsync 0 exit করার পরেই নামটি দেখা যায়। তাই মাঝপথে transfer বন্ধ হলে সেটিকে সম্পূর্ণ snapshot মনে হয় না। এক লাইনে পুরোনো tree expire করুন এবং ত্রিশটি রেখে দিন।

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

এই শৈলীর খরচ সম্পর্কে পরিষ্কার থাকুন। Hardlink শুধু সম্পূর্ণ file deduplicate করে। তাই 4 GB disk image-এর ভেতরে 1 byte পরিবর্তন হলেও পুরো 4 GB কপি হয়। অন্যদিকে restic এবং PBS কয়েকটি পরিবর্তিত chunk সংরক্ষণ করতে পারে। এছাড়া target-এ আপনার file plaintext অবস্থায় থাকে। তাই backup VPS-এ root access থাকা যে কেউ সেগুলো পড়তে পারে।

ক্লায়েন্ট-সাইড encryption, তাই target কখনো plaintext দেখে না

Backup VPS-কে এমন একটি machine হিসেবে বিবেচনা করুন, যেটির ওপর আপনার পূর্ণ নিয়ন্ত্রণ নেই। এর একজন provider আছে। সেই provider-এর staff আছে। ভবন ছেড়ে যাওয়া failed disk-ও থাকতে পারে।

restic source-এ প্রতিটি chunk পাঠানোর আগে encrypt করে। তাই repository-তে থাকে ciphertext এবং size ও timing-সংক্রান্ত metadata। PBS-এ encryption opt-in। একটি key তৈরি করুন। এরপর প্রতিটি backup-এর সময় সেটি pass করুন।

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Paper key print করে কোনো physical জায়গায় সংরক্ষণ করুন। Proxmox documentation-এ বিষয়টির গুরুত্ব স্পষ্টভাবে বলা হয়েছে: তাদের key ছাড়া backed up file-এ access করা যায় না। Key-টি backup target-এর বাইরে রাখুন। Ciphertext-এর পাশে রাখা key কোনো সুরক্ষা দেয় না।

rsync mirror-এর এ ধরনের কোনো সমতুল্য ব্যবস্থা নেই। File-গুলো সরাসরি file হিসেবেই target-এ যায়। Data sensitive হলে target সেটি পড়তে পারবে—এটি মেনে নিন। নতুবা অন্য দুই ধরনের পদ্ধতির একটি ব্যবহার করুন।

নিজে করা backup মুছে ফেলা থেকে compromised source-কে আটকান

কোনো attacker source-এর নিয়ন্ত্রণ নেওয়ার পর প্রথমে backup খোঁজে। Backup upload করার credential-ও সেই মেশিনেই থাকে। ওই credential দিয়ে delete করাও সম্ভব হলে attacker সেটি ব্যবহার করবে।

PBS roles ব্যবহার করে এই সমস্যার সমাধান করে। শুধু DatastoreBackup থাকা একটি token নতুন snapshot লিখতে এবং নিজের snapshot restore করতে পারে। এটি prune করতে পারে না, কারণ snapshot delete করার জন্য আলাদা Datastore.Prune privilege প্রয়োজন। PBS side থেকে retention চালান। তাহলে source-এ এমন কোনো credential থাকে না, যা কিছু delete করতে পারে।

SFTP-এর উপর restic-এ এ ধরনের বিভাজন নেই। Repository-তে write করার SSH key দিয়েই repository থেকে delete করাও যায়। এর সমাধান হলো REST backend। Backup VPS-এ --append-only সহ rest-server চালান। এটি নতুন backup তৈরির অনুমতি দেয়, কিন্তু বিদ্যমান backup delete বা পরিবর্তন করা প্রতিরোধ করে। এরপর RESTIC_REST_USERNAME এবং RESTIC_REST_PASSWORD ব্যবহার করে client-কে rest:https://backup.example.net:8000/web1-এ নির্দেশ করুন। Source থেকে চালানো restic forget --prune তখন ব্যর্থ হবে। এটিই প্রত্যাশিত ফল। তাই retention নিজস্ব credential ব্যবহার করে দ্বিতীয় একটি মেশিন থেকে চালান। Append-only repository-তে count-based policy-এর পরিবর্তে restic manual --keep-within ব্যবহারের পরামর্শ দেয়। কারণ attacker repository-তে অতিরিক্ত junk snapshot ঢোকালে, count-based policy আপনার আসল snapshot-গুলোকে --keep-last window-এর বাইরে সরিয়ে দিতে পারে।

rsync একই সমস্যার সমাধান গঠনগতভাবে করে pull ব্যবহার করে। তাই source-এ target-এর জন্য কোনো credential থাকে না।

তিন ধরনের ব্যবস্থার ক্ষেত্রেই একটি নিয়ম প্রযোজ্য: backup delete করতে পারে এমন credential অবশ্যই এমন একটি মেশিনে থাকবে, যেটির backup নেওয়া হচ্ছে না।

ক্যালেন্ডারে restore drill-এর সময় নির্ধারণ করুন

আপনি কখনো restore করেননি এমন backup কেবল একটি অনুমান। প্রতি quarter-এ এক ঘণ্টা নির্ধারণ করে এটি পরীক্ষা করুন।

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r কোনো output না দেখালে বোঝায় যে restored tree এবং live tree একই। PBS-এ একই drill হলো proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/; এর সঙ্গে একটি scheduled verify job-ও চালান, যা target-এ chunk পুনরায় পড়ে এবং checksum failure জানায়।

এই drill-এ শুধু byte অক্ষত আছে কি না, তা প্রমাণ করলেই চলবে না।

• source থেকে নয়, তৃতীয় একটি machine থেকে restore করুন। কারণ source-ই ঠিক সেই জিনিস, যা হারিয়ে গেছে বলে আপনি ধরে নিচ্ছেন। তাই repository password বা PBS key-তে source ছাড়াই প্রবেশাধিকার থাকতে হবে।
• restore-এর সময় মেপে সংখ্যাটি লিখে রাখুন। এরপর আপনার নির্ধারিত RTO-এর সঙ্গে তুলনা করুন। উপরের chart-এ transfer-এর সর্বনিম্ন সময় দেখানো হয়েছে। প্রকৃত সময়ের মধ্যে decrypt করে disk-এ লেখার সময় এবং কোন snapshot চেয়েছিলেন তা নির্ধারণ করার সময়ও অন্তর্ভুক্ত থাকে।
• state-সহ কোনো data restore করুন, যেমন একটি database dump restore করে scratch instance-এ load করুন। extract করা যায় এমন tar file প্রমাণ করে না যে application শুরু হবে।

পৃথিবীর সবচেয়ে সস্তা disk-ও একবার restore না করা পর্যন্ত কোনো মূল্য রাখে না।

FAQ

আমার VPS provider-এর snapshot কি off-site backup?

না। Provider-এর snapshot একই account-এ, একই panel login-এর অধীনে এবং যে server-এর copy থেকে তৈরি, তার একই invoice-এর সঙ্গে থাকে। যে ব্যক্তি ওই login পেয়ে যায়, সে একই session-এ server এবং তার সব snapshot মুছে দিতে পারে। ঝুঁকিপূর্ণ upgrade-এর আগে দ্রুত rollback-এর জন্য snapshot উপযোগী। তবে এটি দ্বিতীয় কোনো location নয়। Off-site copy আলাদা account-এর অধীনে থাকে। আদর্শভাবে এটি আলাদা provider-এর কাছে রাখা হয় এবং এর credential source machine-এ সংরক্ষিত থাকে না।

এক মাসের retained backup-এর জন্য কত disk space প্রয়োজন?

Snapshot-এর সংখ্যা নয়, বরং আপনার সবচেয়ে পুরোনো snapshot-এর age অনুযায়ী আকার নির্ধারণ করুন। Deduplicating tool প্রতিটি unique chunk একবারই সংরক্ষণ করে। তাই repository-এর আকার মোটামুটি source-এর আকারের সঙ্গে প্রতিদিনের নতুন unique data-কে retention period-এর দিনের সংখ্যা দিয়ে গুণ করে পাওয়া যায়। 500 GB data প্রতিদিন 5 GB পরিবর্তিত হলে, এক সপ্তাহের daily backup-এর আকার প্রায় 535 GB এবং পুরো এক বছরের history-এর আকার 2,325 GB। এর অতিরিক্ত headroom রাখুন। Disk পূর্ণ হলে পরের backup ব্যর্থ হবে। এছাড়া restic-এর prune pack file পুনর্গঠন করে space ফেরত দেওয়ার আগে free space প্রয়োজন।

Compromised server কি নিজের off-site backup মুছে দিতে পারে?

হ্যাঁ, যদি আপনি এর বিরুদ্ধে ব্যবস্থা না নেন। সাধারণ SSH বা SFTP repository-তে যে key data লেখে, সেটি data মুছতেও পারে। Source-কে এমন credential দিন, যা data মুছতে পারে না: শুধু DatastoreBackup role ধারণকারী PBS API token ব্যবহার করুন, যাতে Datastore.Prune privilege নেই; অথবা --append-only দিয়ে চালু করা rest-server-এর বিরুদ্ধে restic ব্যবহার করুন, যা বিদ্যমান backup মুছতে বা পরিবর্তন করতে দেয় না। Pull design আরও নিরাপদ, কারণ তখন source-এর কাছে backup host-এর কোনো credential থাকে না। Retention এমন দিক থেকে চালান, যা source নয়।

Backup VPS-এ Proxmox Backup Server নাকি restic চালানো উচিত?

যে unit restore করতে চান, tool সেটির সঙ্গে মিলিয়ে নিন। Source যদি Proxmox VE হয় এবং পুরো virtual machine ফিরিয়ে আনতে চান, তাহলে PBS চালান। এটি disk-image level-এ backup নেয় এবং এক ধাপে VM restore করে। Source যদি Linux host হয় এবং files ও database dump ফিরিয়ে আনতে চান, তাহলে restic চালান। এর জন্য target-এ শুধু একটি SSH account প্রয়োজন এবং এটি data পাঠানোর আগে encrypt করে। দুটিই চালানো স্বাভাবিক: hypervisor-এর জন্য PBS এবং hypervisor-এ থাকা নয় এমন server-গুলোর জন্য restic।

VPS backup থেকে restore করতে কতক্ষণ লাগে?

Data size-কে link speed দিয়ে ভাগ করে ন্যূনতম সময় বের করুন। এরপর decryption এবং writing-এর সময় যোগ করুন। 100 Mbit/s link-এ 500 GB data line rate-এ restore করতে 11.1 ঘণ্টা লাগে। একই restore 1 Gbit/s port-এ করতে 1.1 ঘণ্টা লাগে। অনেক ছোট file থাকলে প্রতিটি file-এর overhead-এর কারণে এই হিসাবের চেয়ে গতি কম হয়। একটি বাস্তব restore-এর সময় মাপুন এবং সেই measured number ব্যবহার করুন। আপনার recovery plan যে একমাত্র সংখ্যার ওপর নির্ভর করতে পারে, সেটিই হলো এই measured number।