Restic দিয়ে VPS ব্যাকআপ করার নিয়ম

কেন একই সার্ভারে ব্যাকআপ রাখা ব্যাকআপ নয়

Restic হলো একটি ফ্রি এবং ওপেন সোর্স ব্যাকআপ টুল। এটি আপনার ফাইলগুলোর এনক্রিপ্টেড এবং ডিডুপ্লিকেটেড স্ন্যাপশট অন্য কোনো রিপোজিটরিতে পাঠায়: যেমন একটি দ্বিতীয় VPS, আপনার বাসার কোনো মেশিন, অথবা S3-compatible অবজেক্ট স্টোরেজ। এই গাইডটিতে Ubuntu 24.04-এ এটি সেটআপ করার পদ্ধতি দেখানো হয়েছে। এতে ইনস্টলেশন থেকে শুরু করে SFTP-এর মাধ্যমে রিপোজিটরি তৈরি, প্রথম ব্যাকআপ, একটি নাইটলি systemd টাইমার, রিটেনশন পলিসি এবং পুরো প্রক্রিয়াটি কাজ করছে কিনা তা যাচাই করার জন্য রিস্টোর করার পদ্ধতি অন্তর্ভুক্ত করা হয়েছে। ডেস্টিনেশন অবশ্যই অন্য একটি মেশিন হতে হবে, কারণ একই সার্ভারে থাকা কপি সার্ভারটি নষ্ট হয়ে গেলে হারিয়ে যায়।

ব্যাকআপ করা মেশিনেই একটি backup/ ডিরেক্টরি থাকলে তা আপনাকে কেবল একটি বিপদ থেকে রক্ষা করে: ভুলবশত কোনো ফাইল মুছে ফেলা। এটি ডিস্ক ফেইলর থেকে রক্ষা করতে পারে না, কারণ ফাইলটি সেই ডিস্কেই ছিল। এটি রুট অ্যাক্সেস সম্পন্ন কোনো অ্যাটাকার থেকে রক্ষা করতে পারে না, কারণ তারা প্রথমেই কপিগুলো মুছে ফেলে। এটি VPS নিজেই মুছে ফেলার মতো কোনো অ্যাকাউন্টের ভুল থেকেও রক্ষা করতে পারে না। The world's least efficient datacenter মজা করে বলেছে যে, ডেটার একই অ্যারেতে backup_final_v2_REAL নামের একটি tarball রাখা হচ্ছে; এই রসিকতাটি কার্যকর কারণ আমাদের অনেকেই ঠিক এই ভুলটি করেছি। ব্যাকআপ অবশ্যই মেশিনের বাইরে রাখতে হবে, আর restic এটি মেনে চলার সবচেয়ে সহজ উপায়।

চারটি ধারণায় Restic

Repository. এটি এমন একটি স্থান যেখানে restic ডেটা লিখে রাখে। এটি restic-এর নিজস্ব ফরম্যাটে তৈরি একটি directory, যা এনক্রিপ্টেড blobs-এ পূর্ণ। শুধুমাত্র restic এটি পড়তে পারে। আপনি কখনোই এটি ম্যানুয়ালি এডিট করবেন না; আপনি restic commands এবং -r address-এর মাধ্যমে এটি ব্যবহার করবেন।

Snapshot. আপনার ব্যাকআপ করা ফাইলগুলোর একটি নির্দিষ্ট সময়ের চিত্র। প্রতিটি ব্যাকআপ রান একটি snapshot তৈরি করে। প্রতিটি snapshot আলাদাভাবে রিস্টোর করা সম্ভব এবং প্রতিটি আপনার ডেটার সেই মুহূর্তের একটি সম্পূর্ণ কপি হিসেবে কাজ করে।

Deduplication. Restic ফাইলগুলোকে content-defined chunks-এ বিভক্ত করে এবং শুধুমাত্র সেই chunks গুলো আপলোড করে যা repository আগে কখনো দেখেনি। প্রথম ব্যাকআপে সবকিছু আপলোড হয়; এর পরের প্রতিটি রান-এ শুধুমাত্র পরিবর্তিত অংশটুকু আপলোড হয়। উদাহরণস্বরূপ, ২০ GB ডেটার একটি nightly snapshot যেখানে ৫০ MB পরিবর্তন হয়েছে, তার জন্য মাত্র ৫০ MB খরচ হবে। এই কারণেই অনেকগুলো snapshot সংরক্ষণ করা সাশ্রয়ী।

Encryption by default. একটি restic repository সবসময় এনক্রিপ্টেড (AES-256) থাকে এবং প্রতিটি command-এর জন্য repository password প্রয়োজন হয়। ব্যাকআপ হোস্ট বা স্টোরেজ প্রোভাইডার শুধুমাত্র এনক্রিপ্টেড blobs দেখতে পায়। এর কঠোর ফলাফল হলো: পাসওয়ার্ড হারিয়ে ফেললে ডেটা চিরতরে হারিয়ে যাবে, যা এই সিস্টেমের ডিজাইন। পাসওয়ার্ডের একটি কপি এই সার্ভার ছাড়া অন্য কোথাও সংরক্ষণ করুন। এটি অত্যন্ত গুরুত্বপূর্ণ, যা নিচে আরও দুবার উল্লেখ করা হয়েছে।

Ubuntu 24.04-এ restic install করুন

sudo apt update && sudo apt install -y restic
restic version

Ubuntu 24.04-এ এটি restic 0.16.4 install করে, যেখানে বর্তমান upstream release হলো 0.19.1। এই পার্থক্যের কারণ হলো LTS (long term support) release-এর package version freeze করা থাকে। তবে এখানে এটি কোনো সমস্যা নয়: 0.16.4 ভার্সনটি এই guide-এর সমস্ত কাজ করতে সক্ষম। আপনি যদি speed improvement-এর জন্য একদম নতুন release চান, তবে restic project-এর GitHub releases page থেকে official single-binary build ডাউনলোড করুন, bunzip2 দিয়ে unpack করুন, এবং /usr/local/bin/restic-এ install করুন; restic install করার জন্য এর বাইরে আর কিছু করার প্রয়োজন নেই।

SFTP ব্যবহার করে অন্য সার্ভারে repository তৈরি করুন

আপনার একটি গন্তব্য মেশিন প্রয়োজন: সাধারণত একটি দ্বিতীয় ছোট VPS ব্যবহার করা হয়, তবে SSH server এবং অতিরিক্ত disk আছে এমন যেকোনো মেশিন ব্যবহার করা সম্ভব। Restic, SFTP (SSH এর মাধ্যমে file transfer) সমর্থন করে, তাই backup host-এ কোনো কিছু ইনস্টল করার প্রয়োজন নেই। এই নির্দেশিকায় backup host হলো 10.0.0.12 এবং ব্যবহারকারীর নাম হলো restic। ব্যবহারকারীর নাম backup রাখবেন না: Ubuntu এবং Debian প্রতিটি ইনস্টলেশনে backup নামে একটি সংরক্ষিত system account (uid 34, no login shell) প্রদান করে, যার ফলে adduser backup ফেইল করবে এবং ssh backup@... সরাসরি nologin ফোল্ডারে চলে যাবে।

Nightly job টি যে সার্ভারটি backup করা হচ্ছে সেখানে root হিসেবে চলবে, তাই backup host-এ root-এর জন্য key login প্রয়োজন। একটি passphrase ছাড়া ডেডিকেটেড key তৈরি করুন, কারণ রাত ৩টায় passphrase টাইপ করার জন্য কোনো মানুষ উপস্থিত থাকবে না, এবং সেটি কপি করে নিন:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

আপনি যদি key ব্যবহারের বিষয়ে নতুন হন, তবে SSH key management basics এ এর মডেল, permissions এবং পরবর্তীতে একটি key কীভাবে বাতিল করতে হয় তা ব্যাখ্যা করা হয়েছে।

এরপর, repository password। একটি শক্তিশালী পাসওয়ার্ড তৈরি করে সেটি শুধুমাত্র root ব্যবহার করতে পারে এমন একটি ফাইলে সংরক্ষণ করুন:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

পরবর্তী ধাপে যাওয়ার আগে পাসওয়ার্ডটি আপনার password manager-এ কপি করে রাখুন। যদি এই VPS নষ্ট হয়ে যায়, তবে repository এবং এই পাসওয়ার্ড থাকলে সবকিছু পুনরুদ্ধার করা সম্ভব; পাসওয়ার্ড ছাড়া repository দিয়ে কিছুই উদ্ধার করা যাবে না।

Repository ইনিশিয়ালাইজ করুন:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

বিকল্প গন্তব্য হলো S3-compatible object storage, যা দ্বিতীয় কোনো মেশিন চালাতে না চাইলে সঠিক পছন্দ। যেকোনো S3-compatible bucket একইভাবে কাজ করে; শুধুমাত্র address এবং দুটি credential variable পরিবর্তন হবে:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

init এর পরের সব ধাপ উভয় গন্তব্যেই identical বা একই রকম। এই গাইডের বাকি অংশে SFTP address দেখানো হয়েছে; আপনি আপনার নিজস্ব address ব্যবহার করুন।

প্রথম ব্যাকআপ, এক্সক্লুড (excludes) ব্যবহার করে

পুরো filesystem ব্যাকআপ না করে শুধুমাত্র সেই ডেটা ব্যাকআপ নিন যা পুনরায় ইনস্টল করা সম্ভব নয়। অপারেটিং সিস্টেম পুনরায় ইনস্টল করা যায়; কিন্তু আপনার কনফিগারেশন এবং ডেটা তা পারে না। একটি সাধারণ VPS-এর ক্ষেত্রে এর মানে হলো /etc, /home, এবং আপনার অ্যাপ্লিকেশনগুলো যেখানে ডেটা জমা রাখে, যেমন /srv বা /var/www। ক্যাশ (caches) ফাইলগুলো এক্সক্লুড করুন, কারণ এগুলো অনেক বড় হয়, প্রতিদিন পরিবর্তিত হয় এবং এগুলো নিজে থেকেই পুনরায় তৈরি হতে পারে:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

প্রথমবার রান করার সময় সবকিছু আপলোড হয়, তাই এতে কিছুটা সময় লাগে। একই কমান্ড পুনরায় রান করলে এটি কয়েক সেকেন্ডের মধ্যে শেষ হয়ে যাবে। এটি মাত্র কিছু পরিবর্তিত ফাইল এবং কিছু MiB ডেটা যোগ করার রিপোর্ট দেখাবে, কারণ deduplication শুধুমাত্র নতুন chunk গুলো আপলোড করে। আপনার কাছে কী আছে তা দেখতে নিচের কমান্ডটি ব্যবহার করুন:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

প্রতিটি snapshot-এ একটি ID, একটি সময় এবং এর অন্তর্ভুক্ত পাথ (paths) দেখায়। এই ID গুলো ব্যবহার করেই আপনি ডেটা রিস্টোর করতে পারবেন।

systemd timer ব্যবহার করে nightly run করা

প্রতিটি কমান্ডে repository address টাইপ করা ক্লান্তিকর, এবং হাতে চালানো backup এক মাসের মধ্যেই বন্ধ হয়ে যায়। এই দুটি সমস্যার সমাধান হলো একটি script এবং একটি timer। script-টি restic ব্যবহার করা দুটি environment variable, RESTIC_REPOSITORY এবং RESTIC_PASSWORD_FILE সেট করে রাখে, যার ফলে এর ভেতরের প্রতিটি কমান্ড ছোট রাখা সম্ভব হয়:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

পরবর্তী দুটি সেকশনে forget এবং check লাইন দুটি ব্যাখ্যা করা হয়েছে। এবার সময়সূচী বা schedule: একটি oneshot service যা script-টি চালায়, এবং একটি timer যা প্রতি রাতে 03:00 মিনিটে এটি চালু করে। এখানে cron-এর চেয়ে timer বেশি কার্যকর কারণ এর run logs journal-এ জমা হয়, এবং সার্ভার ডাউন থাকার কারণে কোনো backup মিস হলে সার্ভার চালু হওয়ার সাথে সাথে Persistent=true সেটি পুনরায় চালায়।

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Timer-টি enable করুন, তারপর service-টি একবার হাতে চালিয়ে কাজ করার প্রক্রিয়াটি দেখুন:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers নির্দেশ করে পরবর্তী run কখন শুরু হবে। আপনি ফাইল দুটি হাতে টাইপ করার পরিবর্তে সরাসরি unit files জোড়া তৈরি করে নিতে পারেন:

calendar syntax এবং service-এর hardening directives সহ এই দুটি ফাইলের সম্পূর্ণ প্যাটার্ন সম্পর্কে জানতে VPS-এ systemd service হিসেবে প্রোগ্রাম চালানো দেখুন।

ব্যাকআপ ততক্ষণ পর্যন্ত কেবল একটি গুজব, যতক্ষণ না আপনি এটি restore করতে পারছেন

এই বাক্যটিকে একটি আদেশ হিসেবে বিবেচনা করুন। প্রতি রাতে একটি backup job সফলভাবে সম্পন্ন হওয়া মানে কেবল এটিই যে কাজটি চলেছে; এটি প্রমাণ করে না যে আপনার data ফিরে আসবে। এই ব্যবধান দূর করতে দুটি পরীক্ষা প্রয়োজন।

প্রথমটি হলো restic check, যা script ইতিমধ্যেই প্রতি রাতে চালায়। এটি repository structure এবং index যাচাই করে, ফলে backup host-এ কোনো silent corruption থাকলে তা restore করার দিন নয়, বরং পরের রাতেই ধরা পড়ে। প্রতি মাসে একবার আরও গভীরতর সংস্করণটি চালান, যা প্রকৃত data-র যেকোনো ১০ শতাংশ random ভাবে ডাউনলোড এবং cryptographically verify করে:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

যেহেতু প্রতিবার subset-টি random হয়, তাই পুরো repository-তে একবার করে সব data যাচাই করা সম্ভব হয়, এবং এর জন্য পুরো data ডাউনলোড করার প্রয়োজন হয় না।

দ্বিতীয়টি হলো restore drill। উপরের root shell থেকেই, সর্বশেষ snapshot থেকে একটি real directory একটি scratch location-এ restore করুন এবং সেটিকে live files-এর সাথে তুলনা করুন:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

diff কোনো আউটপুট না দেওয়ার অর্থ হলো প্রতিটি byte হুবহু ফিরে এসেছে, যা একমাত্র নির্ভরযোগ্য প্রমাণ। এরপর /srv/restore-drill ডিলিট করে দিন। প্রতি মাসে এই drill-টি করুন, এবং বছরে একবার বা দুবার পূর্ণাঙ্গ সংস্করণটি করুন: সর্বশেষ সম্পূর্ণ snapshot একটি scratch VPS-এ restore করুন এবং আপনার application সেখান থেকে সঠিকভাবে চালু হচ্ছে কিনা তা পরীক্ষা করুন। যে দিন আপনার চাপের মুখে এটি কাজ করার প্রয়োজন হবে, সেদিন এটি আপনার জন্য একটি পরিচিত routine হওয়া উচিত।

Retention: forget এবং prune

কোনো policy না থাকলে, snapshots ক্রমাগত বাড়তে থাকে এবং repository-এর আকারও বাড়তে থাকে। script-এর forget line প্রতি রাতে একটি policy প্রয়োগ করে: --keep-daily 7 গত সাত দিনের জন্য প্রতিদিনের একটি snapshot রাখে, --keep-weekly 4 চার সপ্তাহের জন্য প্রতি সপ্তাহের একটি snapshot রাখে, এবং --keep-monthly 6 ছয় মাসের জন্য প্রতি মাসের একটি snapshot রাখে। যে snapshot গুলো কোনো rule দ্বারা protected নয়, সেগুলো forget হয়ে যায়।

শুধুমাত্র forget ব্যবহার করলে শুধুমাত্র snapshot records মুছে যায়; data chunks গুলো repository-তে থেকে যায় যতক্ষণ না কোনো প্রক্রিয়া সেগুলো delete করে। --prune এই কাজটি করে: এটি এমন সব chunk খুঁজে বের করে যেগুলোর কোনো snapshot reference আর নেই এবং সেগুলো delete করে দেয়, যার ফলে প্রকৃতপক্ষে disk space খালি হয়। Prune সরাসরি repository-তে কাজ করে, তাই বড় repository-র ক্ষেত্রে কিছু মানুষ forget nightly এবং --prune weekly চালান; সাধারণ VPS সাইজের ক্ষেত্রে nightly চালানোই যথেষ্ট।

Databases: প্রথমে dump করুন, তারপর dump ফাইলটি back up করুন

Restic ফাইল পড়ার সময় ফাইল কপি করে, কিন্তু একটি database ক্রমাগত তার ফাইলগুলোতে লিখছে থাকে। যদি কোনো database ফাইল লেখার মাঝপথে capture করা হয়, তবে সেটি corrupt হয়ে যাবে; কারণ কপি করার সময় ফাইলটিতে লেখার আগের এবং পরের page গুলোর মিশ্রণ ঘটে। এর সমাধান হলো: database engine দিয়ে প্রথমে একটি consistent export ফাইল তৈরি করে নিন, তারপর restic দিয়ে সেই ফাইলটি back up করুন।

PostgreSQL-এর ক্ষেত্রে, restic-backup.sh ফাইলের শুরুতে, restic backup command-এর আগে একটি dump লাইন যোগ করুন এবং backup paths-এ dump directory-টি অন্তর্ভুক্ত করুন:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

MariaDB এবং MySQL-এর ক্ষেত্রে mysqldump একই কাজ করে। এই পুরো pattern-টির একটি উদাহরণ পেতে Nextcloud backup section দেখুন। এটি maintenance mode চালু করে, Postgres dump করে এবং ফাইলগুলোকে একটি consistent set হিসেবে কপি করে; এটিই হলো সেই set যা প্রতি রাতে restic-এর মাধ্যমে সার্ভার থেকে সরিয়ে নেওয়া উচিত। SQLite-এর ক্ষেত্রে পদ্ধতিটি একই কিন্তু আরও সহজ: Vaultwarden guide কয়েক সেকেন্ডের জন্য container-টি বন্ধ করে db.sqlite3-এর একটি cold copy নেয়, এবং সেই archive-টিই restic সার্ভার থেকে পাঠিয়ে দেয়।

FAQ

restic ব্যাকআপ কি এনক্রিপ্টেড?

হ্যাঁ, সবসময়। প্রতিটি restic repository AES-256 দিয়ে এনক্রিপ্টেড করা থাকে; এতে কোনো আন-এনক্রিপ্টেড মোড নেই এবং প্রতিটি কমান্ডের জন্য repository password প্রয়োজন হয়। যে মেশিন বা প্রোভাইডার repository সংরক্ষণ করে, তারা শুধুমাত্র এনক্রিপ্টেড blobs ধারণ করে, তাই ব্যাকআপ হোস্ট হ্যাক হলেও আপনার ফাইলগুলো উন্মুক্ত হয় না। এর একটি কঠোর নিয়ম আছে: পাসওয়ার্ড ছাড়া কেউ ডেটা রিকভার করতে পারবে না, তাই পাসওয়ার্ডের একটি কপি সার্ভার থেকে দূরে সংরক্ষণ করুন।

restic কি ইনক্রিমেন্টাল ব্যাকআপ করে?

প্রতিটি restic snapshot একটি ফুল ব্যাকআপের মতো কাজ করে, কিন্তু এটি ইনক্রিমেন্টাল স্টোরেজ খরচ করে। Restic ফাইলগুলোকে chunks-এ ভাগ করে এবং শুধুমাত্র সেই chunks গুলো আপলোড করে যা repository-তে আগে থেকে নেই; ফলে প্রতিদিনের ব্যাকআপে শুধুমাত্র সেই পরিবর্তনগুলোই ট্রান্সফার হয় যা ওই দিন ঘটেছে। প্রথাগত ইনক্রিমেন্টাল পদ্ধতির মতো এখানে কোনো চেইন রিকভার করার প্রয়োজন হয় না: যেকোনো snapshot সরাসরি রিস্টোর করা যায় এবং পুরনো snapshot ডিলিট করলে নতুনটির কোনো ক্ষতি হয় না।

আমি restic ব্যাকআপ থেকে ফাইল কীভাবে রিস্টোর করব?

Snapshot ID খুঁজে পেতে restic snapshots চালান, তারপর সেটি রিস্টোর করতে restic restore <id> --target /some/empty/dir চালান; শুধুমাত্র নির্দিষ্ট অংশ রিস্টোর করতে --include /path যোগ করুন। ID-এর পরিবর্তে latest ব্যবহার করা যায়। Restic টার্গেট ডিরেক্টরির নিচে মূল ডিরেক্টরি স্ট্রাকচারটি পুনরায় তৈরি করে, তাই /etc/ssh রিস্টোর করলে তা /some/empty/dir/etc/ssh-এ জমা হবে। প্রয়োজন হওয়ার আগেই এটি প্র্যাকটিস করে নিন, কারণ পরীক্ষা না করা ব্যাকআপ কেবল একটি গুজব মাত্র।

আমার কত ঘনঘন restic backup চালানো উচিত?

সার্ভারের জন্য প্রতিদিন রাতে চালানো একটি যুক্তিসঙ্গত সর্বনিম্ন সীমা, এবং deduplication এর কারণে এটি সাশ্রয়ী: প্রতিটি রান শুধুমাত্র গতবারের পর থেকে পরিবর্তিত chunks গুলো আপলোড করে। যে ডেটা দ্রুত পরিবর্তিত হয়, অথবা একদিনের জন্য হারিয়ে গেলেও ক্ষতি হতে পারে, সেগুলো একই টাইমার প্যাটার্নে প্রতি কয়েক ঘণ্টা অন্তর চালানো যেতে পারে। ফ্রিকোয়েন্সি নির্ধারণ করা সহজ; তবে নিয়মিত restic check চালান এবং প্রতি মাসে একবার রিস্টোর ড্রিল করুন, কারণ যাচাইকরণ ছাড়া শিডিউল কেবল একটি মিথ্যা সান্ত্বনা।

আমি যদি আমার restic repository password হারিয়ে ফেলি তাহলে কী হবে?

ব্যাকআপগুলো আর রিকভার করা সম্ভব হবে না। Restic-এর এনক্রিপশনে কোনো ব্যাক ডোর বা রিসেট করার সুবিধা নেই, তাই পাসওয়ার্ডটি ব্যাকআপের মতোই গুরুত্বপূর্ণ। পাসওয়ার্ডটি আপনার password manager-এ এবং ব্যাকআপ করা সার্ভারটি ছাড়া অন্য কোনো টেকসই স্থানে সংরক্ষণ করুন। যতক্ষণ আপনার অ্যাক্সেস আছে, ততক্ষণ একই repository-র জন্য দ্বিতীয় একটি পাসওয়ার্ড রেজিস্টার করতে restic key add ব্যবহার করতে পারেন, যা আপনাকে একটি অতিরিক্ত পাসওয়ার্ড দেবে।