Restic backup setup guide for VPS

ایک ہی سرور پر بیک اپ رکھنا بیک اپ کیوں نہیں ہے

Restic ایک مفت اور اوپن سورس بیک اپ ٹول ہے جو آپ کی فائلوں کے انکرپٹڈ اور ڈی ڈپلیکیٹڈ اسنیپ شاٹس کو کسی دوسری جگہ بھیجتا ہے: جیسے کہ دوسرا VPS، گھر پر موجود کوئی مشین، یا S3-compatible object storage۔ یہ گائیڈ اسے Ubuntu 24.04 پر سیٹ اپ کرنے کا طریقہ بتاتی ہے۔ اس میں انسٹالیشن سے لے کر SFTP پر ریپوزٹری، پہلا بیک اپ، نائٹلی systemd ٹائمر، ریٹینشن پالیسی، اور ری اسٹور کرنے کا طریقہ شامل ہے تاکہ یہ ثابت ہو سکے کہ پورا سسٹم کام کر رہا ہے۔ منزل (destination) کا کوئی دوسرا مشین ہونا ضروری ہے، کیونکہ اگر کاپی اسی سرور پر ہوگی تو سرور کے ساتھ ہی ختم ہو جائے گی۔

بیک اپ لینے والی مشین پر موجود backup/ ڈائریکٹری آپ کو صرف ایک چیز سے بچاتی ہے: غلطی سے فائل ڈیلیٹ ہو جانا۔ یہ ہارڈ ڈسک کے خراب ہونے کی صورت میں کام نہیں آتی، کیونکہ وہ فائل اسی ڈسک پر ہوتی ہے۔ یہ روٹ (root) ایکسیس رکھنے والے حملہ آور سے بھی نہیں بچاتی، کیونکہ وہ سب سے پہلے کاپیز ڈیلیٹ کرتے ہیں۔ یہ اکاؤنٹ کی ایسی غلطی سے بھی نہیں بچاتی جس سے خود VPS ہی ختم ہو جائے۔ دنیا کا سب سے کم کارآمد ڈیٹا سینٹر اس مذاق کا ذکر کرتا ہے کہ ایک tarball جس کا نام backup_final_v2_REAL ہے، وہ ڈیٹا کے ساتھ ہی ایک ہی ایرے (array) پر موجود ہے، اور یہ مذاق اس لیے درست ہے کیونکہ ہم میں سے بہت سے لوگ بالکل یہی غلطی کر چکے ہیں۔ اصول یہ ہے کہ بیک اپ مشین سے باہر ہونا چاہیے، اور restic اس اصول پر عمل کرنے کا سب سے آسان طریقہ ہے۔

Restic کے چار بنیادی تصورات

Repository. وہ جگہ جہاں restic ڈیٹا لکھتا ہے۔ یہ restic کے اپنے فارمیٹ میں ایک directory ہوتی ہے، جو encrypted blobs سے بھری ہوتی ہے، اور اسے صرف restic ہی پڑھ سکتا ہے۔ آپ اسے کبھی بھی دستی طور پر (manually) ایڈٹ نہ کریں؛ آپ restic commands اور -r address کے ذریعے اس سے رابطہ کرتے ہیں۔

Snapshot. آپ کے بیک اپ کیے گئے files کا ایک مخصوص وقت کا عکس۔ ہر backup run ایک snapshot تخلیق کرتا ہے، ہر snapshot کو علیحدہ سے ری اسٹور کیا جا سکتا ہے، اور ہر snapshot اس وقت کے آپ کے ڈیٹا کی ایک مکمل کاپی کی طرح کام کرتا ہے۔

Deduplication. Restic files کو content-defined chunks میں تقسیم کرتا ہے اور صرف وہی chunks اپ لوڈ کرتا ہے جو repository میں پہلے سے موجود نہ ہوں۔ پہلا backup سب کچھ اپ لوڈ کرتا ہے؛ اس کے بعد ہر run میں تقریباً وہی ڈیٹا اپ لوڈ ہوتا ہے جو تبدیل ہوا ہو۔ اگر 20 GB کا nightly snapshot ہو اور اس میں صرف 50 MB ڈیٹا تبدیل ہوا ہو، تو اس کا خرچ تقریباً 50 MB ہی ہوگا، اسی لیے درجنوں snapshots رکھنا سستا ہے۔

Encryption by default. Restic repository ہمیشہ encrypted (AES-256) ہوتی ہے، اور ہر command کے لیے repository password درکار ہوتا ہے۔ backup host یا storage provider کو صرف encrypted blobs نظر آتے ہیں۔ اس کا سخت نتیجہ یہ ہے کہ: اگر آپ password کھو دیتے ہیں تو ڈیٹا ہمیشہ کے لیے ختم ہو جائے گا، کیونکہ یہ اس کا ڈیزائن ہے۔ Password کی ایک کاپی اس server کے علاوہ کسی اور جگہ محفوظ رکھیں۔ یہ معاملہ اتنا اہم ہے کہ نیچے مزید دو بار اس کا ذکر آئے گا۔

Ubuntu 24.04 پر restic انسٹال کریں

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

Ubuntu 24.04 پر restic 0.16.4 انسٹال ہوتا ہے، جبکہ موجودہ upstream ریلیز 0.19.1 ہے۔ یہ فرق اس وجہ سے ہے کیونکہ LTS (long term support) ریلیز اپنے پیکج ورژنز کو فریز کر دیتی ہے۔ تاہم اس سے کوئی فرق نہیں پڑتا کیونکہ 0.16.4 اس گائیڈ کے تمام کام مکمل کر سکتا ہے۔ اگر آپ بہتر رفتار کے لیے تازہ ترین ریلیز چاہتے ہیں، تو restic پروجیکٹ کے GitHub releases پیج سے آفیشل single-binary بلڈ ڈاؤن لوڈ کریں۔ اسے bunzip2 کے ذریعے unpack کریں اور /usr/local/bin/restic میں انسٹال کریں؛ restic انسٹالیشن کے لیے اس کے علاوہ کسی اور چیز کی ضرورت نہیں ہے۔

SFTP کے ذریعے دوسرے سرور پر ریپوزٹری بنائیں

آپ کو ایک منزل (destination) مشین کی ضرورت ہے: عام طور پر دوسرا چھوٹا VPS استعمال کیا جاتا ہے، لیکن کوئی بھی مشین جس میں SSH سرور اور اضافی ڈسک ہو، کام کر سکتی ہے۔ Restic، SFTP (SSH کے ذریعے فائل ٹرانسفر) استعمال کرتا ہے، اس لیے بیک اپ ہوسٹ پر کسی بھی سافٹ ویئر کی انسٹالیشن کی ضرورت نہیں ہے۔ اس گائیڈ میں، بیک اپ ہوسٹ 10.0.0.12 ہے اور اس کا یوزر restic ہے۔ اس یوزر کا نام backup نہ رکھیں: Ubuntu اور Debian ہر انسٹالیشن کے ساتھ backup نام کا ایک سسٹم اکاؤنٹ (uid 34, no login shell) فراہم کرتے ہیں، جس کی وجہ سے adduser backup فیل ہو جائے گا اور ssh backup@...، nologin میں چلا جائے گا۔

نائٹلی جاب (nightly job) بیک اپ کیے جانے والے سرور پر root کے طور پر چلے گی، اس لیے بیک اپ ہوسٹ کے لیے root کے پاس کی (key) کے ذریعے لاگ ان کرنے کی صلاحیت ہونی چاہیے۔ بغیر پاس فریز (passphrase) کے ایک مخصوص کی (key) بنائیں، کیونکہ رات 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

اگر آپ کے لیے کیز (keys) نیا تصور ہے، تو SSH key management basics اس ماڈل، پرمیشنز، اور بعد میں کی (key) کو منسوخ کرنے کا طریقہ سمجھاتا ہے۔

اگلا مرحلہ، ریپوزٹری پاس ورڈ ہے۔ ایک مضبوط پاس ورڈ بنائیں اور اسے صرف root کے لیے مخصوص فائل میں محفوظ کریں:

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

مزید آگے بڑھنے سے پہلے، اس پاس ورڈ کو اپنے پاس ورڈ مینیجر میں کاپی کر لیں۔ اگر یہ VPS ختم ہو جاتا ہے، تو ریپوزٹری اور یہ پاس ورڈ سب کچھ واپس لے آتے ہیں؛ پاس ورڈ کے بغیر ریپوزٹری کچھ بھی واپس نہیں لا سکتی۔

ریپوزٹری کو انیشلائز (initialise) کریں:

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 اسی طرح کام کرتا ہے؛ صرف ایڈریس اور دو کرڈنشل (credential) ویری ایبلز تبدیل ہوتے ہیں:

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۔ کیش (cache) فائلوں کو شامل نہ کریں، کیونکہ وہ سائز میں بڑی ہوتی ہیں، روزانہ تبدیل ہوتی ہیں، اور خود بخود دوبارہ بن جاتی ہیں:

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 صرف نئے chunks کو اپ لوڈ کرتا ہے۔ اپنی فائلوں کی فہرست دیکھیں:

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

ہر snapshot ایک ID، وقت، اور اس میں موجود paths دکھاتا ہے۔ ان IDs کے ذریعے ہی آپ ڈیٹا ری اسٹور (restore) کرتے ہیں۔

Nightly runs with a systemd timer

ہر بار کمانڈ میں ریپوزٹری ایڈریس ٹائپ کرنا مشکل ہو جاتا ہے، اور ہاتھ سے کیے جانے والے بیک اپ عموماً ایک ماہ کے اندر رک جاتے ہیں۔ ان دونوں مسائل کا حل ایک اسکرپٹ اور ایک ٹائمر ہے۔ اسکرپٹ میں وہ دو environment variables سیٹ کیے جاتے ہیں جنہیں 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 کے مقابلے میں ٹائمر بہتر ہے کیونکہ اس کے لاگز journal میں محفوظ ہوتے ہیں، اور 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

ٹائمر کو enable کریں، پھر سروس کو ایک بار دستی طور پر چلا کر اس کے کام کرنے کا طریقہ دیکھیں:

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 بتاتا ہے کہ اگلی بار یہ کب چلے گا۔ آپ ان یونٹ فائلوں کو خود ٹائپ کرنے کے بجائے انہیں جنریٹ بھی کر سکتے ہیں:

ان دونوں فائلوں کے پیچھے مکمل طریقہ کار، بشمول کیلنڈر سنٹیکس اور سروس کے لیے استعمال ہونے والی hardening directives، running a program as a systemd service on a VPS میں موجود ہے۔

بیک اپ تب تک محض ایک افواہ ہے جب تک آپ اسے ری اسٹور نہ کر لیں

اس جملے کو ایک حکم سمجھیں۔ اگر کوئی بیک اپ جاب ہر رات کامیابی سے (green) مکمل ہو رہی ہے، تو اس کا مطلب صرف یہ ہے کہ جاب چل گئی ہے؛ اس کا یہ مطلب ہرگز نہیں کہ آپ کا ڈیٹا واپس مل جائے گا۔ اس کمی کو پورا کرنے کے لیے دو چیکنگ کے طریقے ضروری ہیں۔

پہلا طریقہ restic check ہے، جو اسکرپٹ پہلے ہی ہر رات چلا رہا ہے۔ یہ ریپوزٹری اسٹرکچر اور انڈیکس کی تصدیق کرتا ہے، تاکہ بیک اپ ہوسٹ پر ہونے والی خاموش خرابی (silent corruption) کا پتہ اگلے ہی دن چل جائے، نہ کہ ری اسٹور کرنے کے دن۔ ماہانہ بنیادوں پر، زیادہ گہرائی والا ورژن چلائیں، جو اصل ڈیٹا کے 10 فیصد حصے کو ڈاؤن لوڈ اور کرپٹوگرافک طور پر ویریفائی کرتا ہے:

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%

چونکہ ہر بار ڈیٹا کا یہ حصہ رینڈم (random) ہوتا ہے، اس لیے ماہانہ بنیادوں پر چلنے والے یہ عمل پورے ریپوزٹری کو کور کر لیتے ہیں، اور اس میں پورا ڈیٹا ڈاؤن لوڈ کرنے کی ضرورت نہیں پڑتی۔

دوسرا طریقہ، ری اسٹور کرنے کی مشق ہے۔ اوپر دیے گئے روٹ شیل (root shell) میں رہتے ہوئے، تازہ ترین اسنیپ شاٹ سے ایک اصل ڈائریکٹری کو عارضی لوکیشن (scratch location) پر ری اسٹور کریں اور اس کا موازنہ لائیو فائلوں سے کریں:

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

اگر diff کچھ بھی پرنٹ نہیں کرتا، تو اس کا مطلب ہے کہ ہر بائٹ بالکل ویسا ہی واپس آیا ہے، اور یہی واحد ثبوت ہے جو اہمیت رکھتا ہے۔ اس کے بعد /srv/restore-drill کو ڈیلیٹ کر دیں۔ یہ مشق ہر ماہ کریں، اور سال میں ایک یا دو بار مکمل ورژن آزمائیں: پورے تازہ ترین اسنیپ شاٹ کو ایک عارضی VPS پر ری اسٹور کریں اور چیک کریں کہ آپ کی ایپلی کیشن اس سے کامیابی سے شروع ہو رہی ہے یا نہیں۔ جس دن آپ کو دباؤ میں اس کی ضرورت پڑے گی، آپ کے پاس اسے کرنے کا پہلے سے تجربہ ہونا چاہیے۔

Retention: forget plus prune

بغیر کسی پالیسی کے، snapshots مسلسل جمع ہوتے رہتے ہیں اور repository کا سائز بڑھتا جاتا ہے۔ اس اسکرپٹ کی forget لائن ہر رات ایک پالیسی لاگو کرتی ہے: --keep-daily 7 گزشتہ 7 دنوں کے لیے روزانہ کا ایک snapshot رکھتا ہے، --keep-weekly 4 4 ہفتوں کے لیے ہفتہ وار ایک snapshot رکھتا ہے، اور --keep-monthly 6 6 مہینوں کے لیے ماہانہ ایک snapshot رکھتا ہے۔ وہ تمام چیزیں جو کسی رول کے تحت محفوظ نہیں ہیں، انہیں ختم کر دیا جاتا ہے۔

صرف forget استعمال کرنے سے صرف snapshot records ختم ہوتے ہیں؛ data chunks repository میں تب تک رہتے ہیں جب تک کوئی انہیں ڈیلیٹ نہ کر دے۔ --prune یہی کام کرتا ہے: یہ ان chunks کو تلاش کرتا ہے جن کا کوئی snapshot reference باقی نہیں رہا اور انہیں ڈیلیٹ کر دیتا ہے، جس سے اصل میں disk space خالی ہوتی ہے۔ Prune، repository پر حقیقی کام کرتا ہے، اس لیے بڑے repository کے لیے کچھ لوگ forget روزانہ اور --prune ہفتہ وار چلاتے ہیں؛ عام VPS سائز کے لیے، روزانہ چلانا کافی ہے۔

Databases: پہلے dump کریں، پھر dump کا backup لیں

Restic فائلوں کو پڑھتے وقت ہی ان کی کاپی بناتا ہے، جبکہ database مسلسل فائلوں میں ڈیٹا لکھتا رہتا ہے۔ اگر database کی فائل کو لکھائی کے دوران (mid-write) capture کیا جائے تو وہ corrupt ہو جاتی ہے، کیونکہ کاپی میں لکھائی سے پہلے اور بعد کے pages مکس ہو جاتے ہیں۔ اس کا حل standard ہے: database engine سے فائل میں ایک consistent export حاصل کریں، اور پھر restic کو اس فائل کا backup لینے دیں۔

PostgreSQL کے لیے، restic-backup.sh کے شروع میں، restic backup command سے پہلے، ایک dump line شامل کریں، اور 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 کو ہر رات server سے لے جانا چاہیے۔ SQLite کے لیے بھی یہی طریقہ ہے لیکن زیادہ سادہ ہے: Vaultwarden guide db.sqlite3 کی cold copy لینے کے لیے container کو چند سیکنڈ کے لیے روک دیتا ہے، اور restic اسی archive کو server سے بھیجتا ہے۔

FAQ

کیا restic backups encrypted ہوتے ہیں؟

جی ہاں، ہمیشہ۔ ہر restic repository AES-256 کے ساتھ encrypted ہوتی ہے۔ اس میں کوئی unencrypted mode موجود نہیں ہے، اور ہر command کے لیے repository password ضروری ہے۔ وہ machine یا provider جو repository کو store کرتا ہے، اس کے پاس صرف encrypted blobs ہوتے ہیں، اس لیے backup host کے compromised ہونے سے آپ کی files ظاہر نہیں ہوتیں۔ یہ ایک یقینی اصول ہے: password کے بغیر کوئی بھی data recover نہیں کر سکتا، اس لیے اس کی ایک copy server سے دور محفوظ رکھیں۔

کیا restic incremental backups کرتا ہے؟

ہر restic snapshot ایک full backup کی طرح کام کرتا ہے، جبکہ storage صرف incremental استعمال ہوتی ہے۔ Restic files کو chunks میں تقسیم کرتا ہے اور صرف وہی chunks upload کرتا ہے جو repository میں پہلے سے موجود نہیں ہیں۔ اس طرح nightly run میں صرف وہی data transfer ہوتا ہے جو اس دن change ہوا ہو۔ Traditional incremental schemes کے برعکس، یہاں کوئی chain replay کرنے کی ضرورت نہیں ہوتی: کوئی بھی snapshot براہ راست restore ہو جاتا ہے اور پرانے snapshot کو delete کرنے سے نیا snapshot خراب نہیں ہوتا۔

میں restic backup سے files کیسے restore کر سکتا ہوں؟

Snapshot ID معلوم کرنے کے لیے restic snapshots چلائیں، پھر اسے restore کرنے کے لیے restic restore <id> --target /some/empty/dir استعمال کریں، اور صرف مخصوص حصہ restore کرنے کے لیے --include /path کا اضافہ کریں۔ latest کو ID کے متبادل کے طور پر استعمال کیا جا سکتا ہے۔ Restic target location کے تحت اصل directory structure کو دوبارہ بناتا ہے، اس لیے /etc/ssh کو restore کرنے پر وہ /some/empty/dir/etc/ssh میں جائے گا۔ ضرورت پڑنے سے پہلے اس کی practice کر لیں، کیونکہ بغیر test کیا ہوا backup صرف ایک افواہ ہے۔

مجھے restic backup کتنا بار چلانا چاہیے؟

Server کے لیے nightly run ایک مناسب حد ہے، اور deduplication اسے سستا بناتا ہے: ہر run میں صرف وہی chunks upload ہوتے ہیں جو پچھلے run کے بعد change ہوئے ہوں۔ وہ data جو تیزی سے تبدیل ہوتا ہے، یا جسے ایک دن کے لیے بھی کھونا نقصان دہ ہو، اسے اسی timer pattern کے ساتھ ہر چند گھنٹوں بعد چلایا جا سکتا ہے۔ Frequency کا تعین کرنا آسان ہے؛ لیکن باقاعدگی سے restic check بھی چلائیں اور ماہانہ بنیادوں پر restore drill کریں، کیونکہ بغیر verification کے schedule صرف ایک جھوٹی تسلی ہے۔

اگر میں اپنا restic repository password کھو دوں تو کیا ہوگا؟

Backups ناقابلِ واپسی (unrecoverable) ہو جائیں گے۔ Restic encryption میں کوئی back door یا reset کا آپشن نہیں ہے، اس لیے password اتنا ہی اہم ہے جتنا کہ خود backups۔ اس کی ایک copy اپنے password manager میں اور کسی بھی محفوظ جگہ پر رکھیں جو backed-up server نہ ہو۔ جب تک آپ کے پاس access ہے، restic key add اسی repository کے لیے دوسرا password register کر سکتا ہے، جو آپ کو ایک spare فراہم کرتا ہے۔