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

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

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

যে সার্ভারের ব্যাকআপ নেওয়া হচ্ছে, সেই একই সার্ভারে থাকা একটি backup/ ডিরেক্টরি আপনাকে কেবল একটি বিষয় থেকেই সুরক্ষা দেয়: ভুলবশত কোনো ফাইল মুছে ফেলা। এটি ডিস্ক নষ্ট হলে কোনো কাজে আসে না, কারণ ব্যাকআপটিও সেই একই ডিস্কে থাকে। এটি এমন কোনো আক্রমণকারীর হাত থেকে রক্ষা করে না যার কাছে root অ্যাক্সেস আছে, কারণ তারা সবার আগে কপিগুলো মুছে ফেলবে। এমনকি VPS মুছে ফেলার মতো অ্যাকাউন্টের ভুল থেকেও এটি সুরক্ষা দেয় না। বিশ্বের সবচেয়ে অকার্যকর ডেটাসেন্টার-এ backup_final_v2_REAL নামের একটি tarball সম্পর্কে কৌতুক করা হয়, যা মূল ডেটার সাথে একই অ্যারেতে রাখা থাকে। এই কৌতুকটি জনপ্রিয় হওয়ার কারণ হলো, আমাদের অনেকেই ঠিক এই কাজটিই করে থাকি। সার্ভারের বাইরে ব্যাকআপ রাখা একটি নিয়ম, আর Restic হলো এই নিয়মটি মেনে চলার সবচেয়ে সহজ উপায়।

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

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

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

Deduplication. Restic ফাইলগুলোকে কন্টেন্ট-ভিত্তিক অংশে বিভক্ত করে এবং শুধুমাত্র সেই অংশগুলো আপলোড করে যা রিপোজিটরিতে আগে থেকে নেই। প্রথম ব্যাকআপে সবকিছু আপলোড হয়; এরপরের প্রতিটি রানে শুধুমাত্র পরিবর্তিত অংশগুলো আপলোড হয়। 20 GB-এর একটি রাতের স্ন্যাপশটে যদি 50 MB পরিবর্তিত হয়, তবে খরচ হবে মাত্র 50 MB, আর এই কারণেই ডজন ডজন স্ন্যাপশট রাখা সাশ্রয়ী।

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

Ubuntu 24.04-এ restic ইনস্টল করা

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

Ubuntu 24.04-এ এটি restic 0.16.4 সংস্করণ ইনস্টল করে, যেখানে বর্তমান আপস্ট্রিম রিলিজটি হলো 0.19.1। এই পার্থক্যের কারণ হলো একটি LTS (লং টার্ম সাপোর্ট) রিলিজ তার প্যাকেজ সংস্করণগুলোকে নির্দিষ্ট রাখে, তবে এখানে এটি কোনো সমস্যা নয়: এই গাইডের সবকিছু 0.16.4 সংস্করণে সম্পন্ন করা সম্ভব। আপনি যদি গতির উন্নতির জন্য নতুন রিলিজটি ব্যবহার করতে চান, তবে restic প্রজেক্টের GitHub রিলিজ পেজ থেকে অফিসিয়াল সিঙ্গেল-বাইনারি বিল্ডটি ডাউনলোড করুন, bunzip2 ব্যবহার করে তা আনপ্যাক করুন এবং /usr/local/bin/restic-এ ইনস্টল করুন; restic ইনস্টলেশনের জন্য এর বাইরে আর কিছু করার প্রয়োজন নেই।

SFTP-এর মাধ্যমে অন্য সার্ভারে রিপোজিটরি তৈরি করা

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

প্রতিরাতের ব্যাকআপ জবটি যে সার্ভারের ব্যাকআপ নেওয়া হচ্ছে সেখানে root হিসেবে চলবে, তাই ব্যাকআপ হোস্টে root-এর জন্য কী-ভিত্তিক লগইন প্রয়োজন। কোনো পাসফ্রেজ ছাড়া একটি ডেডিকেটেড কী তৈরি করুন, কারণ রাত 3টায় এটি টাইপ করার জন্য কোনো মানুষ উপস্থিত থাকবে না, এবং এটি কপি করুন:

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 কী ম্যানেজমেন্টের মৌলিক বিষয়সমূহ-এ এর মডেল, পারমিশন এবং পরবর্তীতে কীভাবে কী বাতিল করতে হয় তা ব্যাখ্যা করা হয়েছে।

এরপর, রিপোজিটরি পাসওয়ার্ড। একটি শক্তিশালী পাসওয়ার্ড তৈরি করে শুধুমাত্র root-এর জন্য সংরক্ষিত একটি ফাইলে রাখুন:

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

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

রিপোজিটরি ইনিশিয়ালাইজ করুন:

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-সামঞ্জস্যপূর্ণ অবজেক্ট স্টোরেজ ব্যবহার করা যায়, যা তখন সঠিক পছন্দ যখন আপনি দ্বিতীয় কোনো মেশিন চালাতে চান না। যেকোনো S3-সামঞ্জস্যপূর্ণ বাকেট একইভাবে কাজ করে; শুধুমাত্র ঠিকানা এবং দুটি ক্রেডেনশিয়াল ভেরিয়েবল পরিবর্তিত হয়:

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-এর পরবর্তী সবকিছু উভয় গন্তব্যের জন্যই অভিন্ন। এই নির্দেশিকার বাকি অংশে SFTP ঠিকানা দেখানো হয়েছে; আপনার ক্ষেত্রে সেটি পরিবর্তন করে নিন।

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

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

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) শুধুমাত্র নতুন অংশগুলোই আপলোড করে। আপনার কাছে কী কী আছে তা তালিকাভুক্ত করুন:

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

প্রতিটি স্ন্যাপশট একটি ID, একটি সময় এবং এতে থাকা পাথগুলো প্রদর্শন করে। এই ID-গুলো ব্যবহার করেই আপনি রিস্টোর করতে পারবেন।

systemd টাইমার ব্যবহার করে প্রতিদিনের ব্যাকআপ

প্রতিটি কমান্ডে রিপোজিটরির ঠিকানা টাইপ করা বিরক্তিকর, এবং হাতে করা ব্যাকআপ সাধারণত এক মাসের মধ্যেই বন্ধ হয়ে যায়। একটি স্ক্রিপ্ট এবং একটি টাইমার ব্যবহার করে এই উভয় সমস্যার সমাধান করা সম্ভব। স্ক্রিপ্টটি সেই দুটি এনভায়রনমেন্ট ভেরিয়েবল সেট করে যা restic পড়ে, অর্থাৎ 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 লাইনগুলো পরবর্তী দুটি সেকশনে ব্যাখ্যা করা হয়েছে। এখন সময়সূচীর পালা: একটি oneshot সার্ভিস যা স্ক্রিপ্টটি চালায়, এবং একটি টাইমার যা প্রতি রাতে 03:00 টায় এটি কার্যকর করে। এখানে cron লাইনের চেয়ে টাইমার বেশি কার্যকর কারণ এটি জার্নালে লগ রাখে এবং সার্ভার ডাউনটাইমের পর চালু হলে 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

টাইমারটি এনাবল করুন, তারপর সার্ভিসটি একবার হাতে চালিয়ে দেখুন এটি কাজ করছে কিনা:

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 কমান্ডটি দেখাবে পরবর্তী রান কখন হবে। আপনি চাইলে এই দুটি ইউনিট ফাইল টাইপ না করে জেনারেটও করতে পারেন:

এই দুটি ফাইলের পেছনের সম্পূর্ণ প্যাটার্ন, যার মধ্যে ক্যালেন্ডার সিনট্যাক্স এবং সার্ভিসের জন্য প্রয়োজনীয় হার্ডেনিং ডিরেক্টিভ অন্তর্ভুক্ত, তা VPS-এ systemd সার্ভিস হিসেবে প্রোগ্রাম চালানো সেকশনে রয়েছে।

ব্যাকআপ পুনরুদ্ধার না করা পর্যন্ত তা কেবল একটি গুজব

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

প্রথমত, restic check, যা স্ক্রিপ্টটি ইতিমধ্যে প্রতি রাতে চালায়। এটি রিপোজিটরির গঠন এবং ইনডেক্স যাচাই করে, যাতে ব্যাকআপ হোস্টে কোনো নীরব ডেটা করাপশন থাকলে তা পুনরুদ্ধারের দিনের পরিবর্তে পরের রাতেই ধরা পড়ে। মাসে একবার, গভীরতর সংস্করণটি চালান, যা প্রকৃত ডেটার দশ ভাগের এক ভাগ র‍্যান্ডমলি ডাউনলোড করে এবং ক্রিপ্টোগ্রাফিকভাবে যাচাই করে:

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%

যেহেতু প্রতিটি সাবসেট প্রতিবার র‍্যান্ডম হয়, তাই মাসিক রানগুলো পুরো রিপোজিটরি জুড়ে কাজ করে, অথচ পুরো ডেটা ডাউনলোডের খরচ ছাড়াই এটি সম্পন্ন হয়।

দ্বিতীয়ত, পুনরুদ্ধারের মহড়া। উপরে উল্লিখিত root শেল থেকেই, সর্বশেষ স্ন্যাপশট থেকে একটি প্রকৃত ডিরেক্টরি একটি স্ক্র্যাচ লোকেশনে পুনরুদ্ধার করুন এবং লাইভ ফাইলগুলোর সাথে তুলনা করুন:

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

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

রিটেনশন: ফরগেট (forget) এবং প্রুন (prune)

কোনো পলিসি না থাকলে, স্ন্যাপশটগুলো চিরকাল জমতে থাকে এবং রিপোজিটরি কেবল বড়ই হতে থাকে। স্ক্রিপ্টের forget লাইনটি প্রতি রাতে একটি পলিসি প্রয়োগ করে: --keep-daily 7 গত সাত দিনের জন্য প্রতিদিন একটি করে স্ন্যাপশট রাখে, --keep-weekly 4 চার সপ্তাহের জন্য প্রতি সপ্তাহে একটি করে রাখে এবং --keep-monthly 6 ছয় মাসের জন্য প্রতি মাসে একটি করে স্ন্যাপশট রাখে। কোনো নিয়মের অধীনে সুরক্ষিত নয় এমন সবকিছু ফরগেট (forget) করে দেওয়া হয়।

forget শুধুমাত্র স্ন্যাপশটের রেকর্ডগুলো মুছে ফেলে; ডেটা চাঙ্কগুলো রিপোজিটরিতেই থেকে যায় যতক্ষণ না অন্য কিছু সেগুলোকে মুছে ফেলে। --prune ঠিক এই কাজটিই করে: এটি এমন চাঙ্কগুলো খুঁজে বের করে যেগুলোর কোনো স্ন্যাপশট রেফারেন্স নেই এবং সেগুলোকে মুছে ফেলে, যার ফলে ডিস্কের জায়গা খালি হয়। প্রুন (prune) রিপোজিটরিতে প্রকৃত কাজ করে, তাই বড় রিপোজিটরির ক্ষেত্রে কেউ কেউ forget প্রতিদিন এবং --prune সাপ্তাহিক ভিত্তিতে চালায়; সাধারণ VPS সাইজের ক্ষেত্রে, প্রতিদিন চালানোই যথেষ্ট।

ডেটাবেস: প্রথমে ডাম্প করুন, তারপর ডাম্পটির ব্যাকআপ নিন

Restic ফাইল পড়ার সাথে সাথেই সেগুলোর কপি তৈরি করে, কিন্তু একটি ডেটাবেস ক্রমাগত তার ফাইলে লিখতে থাকে। রাইট অপারেশনের মাঝপথে ক্যাপচার করা একটি লাইভ ডেটাবেস ফাইল পুনরুদ্ধার করলে তা ত্রুটিপূর্ণ ডেটাবেস হিসেবে গণ্য হয়, কারণ এই কপিতে রাইট অপারেশনের আগের এবং পরের পেজগুলো মিশ্রিত থাকে। এর সমাধানটি প্রচলিত: ডেটাবেস ইঞ্জিনকে একটি সামঞ্জস্যপূর্ণ এক্সপোর্ট ফাইলে রূপান্তর করতে দিন, তারপর restic-কে সেই ফাইলের ব্যাকআপ নিতে দিন।

PostgreSQL-এর ক্ষেত্রে, restic-backup.sh-এর শুরুতে restic backup কমান্ডের আগে একটি ডাম্প লাইন যোগ করুন এবং ব্যাকআপ পাথগুলোতে ডাম্প ডিরেক্টরিটি অন্তর্ভুক্ত করুন:

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

MariaDB এবং MySQL-এর ক্ষেত্রে mysqldump একই ভূমিকা পালন করে। পুরো পদ্ধতির একটি কার্যকর উদাহরণের জন্য, Nextcloud ব্যাকআপ সেকশন দেখুন; এটি মেইনটেন্যান্স মোড চালু করে, Postgres ডাম্প করে এবং ফাইলগুলোকে একটি সামঞ্জস্যপূর্ণ সেট হিসেবে কপি করে, যা ঠিক সেই সেটটিই যা restic-এর প্রতি রাতে সার্ভার থেকে সরিয়ে নেওয়া উচিত। SQLite-এর ক্ষেত্রেও একই ধারণা প্রযোজ্য, তবে পদ্ধতিটি আরও সহজ: Vaultwarden গাইড দেখুন; এটি db.sqlite3-এর একটি কোল্ড কপি নেওয়ার জন্য কয়েক সেকেন্ডের জন্য কন্টেইনারটি বন্ধ করে দেয় এবং সেই আর্কাইভটিই restic সার্ভার থেকে সরিয়ে নেয়।

FAQ

Are restic backups encrypted?

Yes, always. Every restic repository is encrypted with AES-256, there is no unencrypted mode, and every command requires the repository password. The machine or provider storing the repository only ever holds encrypted blobs, so a compromised backup host does not expose your files. The trade is absolute: without the password the data cannot be recovered by anyone, so store a copy of it away from the server.

Does restic do incremental backups?

Every restic snapshot behaves like a full backup, while costing incremental storage. Restic splits files into chunks and uploads only chunks the repository has not already stored, so a nightly run transfers roughly what changed that day. Unlike traditional incremental schemes, there is no chain to replay: any snapshot restores directly and deleting an old snapshot never breaks a newer one.

How do I restore files from a restic backup?

Run restic snapshots to find the snapshot ID, then restic restore <id> --target /some/empty/dir to restore it, adding --include /path to restore only part of it. latest works in place of an ID. Restic recreates the original directory structure under the target, so restoring /etc/ssh lands in /some/empty/dir/etc/ssh. Practice this before you need it, because an untested backup is a rumor.

How often should I run restic backup?

Nightly is the sensible floor for a server, and deduplication makes it cheap: each run uploads only the chunks that changed since the last one. Data that changes fast, or that would hurt to lose even a day of, can run every few hours with the same timer pattern. Frequency is the easy half; also run restic check regularly and a restore drill monthly, because schedule without verification is false comfort.

What happens if I lose my restic repository password?

The backups are unrecoverable. Restic's encryption has no back door and no reset, so the password is as important as the backups themselves. Keep a copy in your password manager and anywhere else durable that is not the backed-up server. While you still have access, restic key add can register a second password for the same repository, which gives you a spare.