Restic سے VPS کا بیک اپ دوسرے سرور پر بھیجیں

ایک ہی سرور پر موجود بیک اپ، بیک اپ نہیں ہوتا

Restic ایک مفت، اوپن سورس بیک اپ ٹول ہے جو آپ کی فائلوں کے encrypted اور deduplicated snapshots کسی دوسرے مقام پر موجود repository میں بھیجتا ہے: دوسرے VPS، گھر کی کسی مشین، یا S3-compatible object storage میں۔ یہ رہنما Ubuntu 24.04 پر اس کی تنصیب سے لے کر SFTP کے ذریعے repository بنانے، پہلے بیک اپ، رات کے وقت چلنے والے systemd timer، retention policy، اور restore drill تک تمام مراحل بیان کرتا ہے، جس سے ثابت ہوتا ہے کہ پورا نظام کام کرتا ہے۔ منزل کے طور پر دوسری مشین کا ہونا ضروری ہے، کیونکہ اسی سرور پر موجود copy سرور کے ساتھ ہی ختم ہو جاتی ہے۔

جس مشین کا بیک اپ لیا جا رہا ہو، اسی پر موجود backup/ directory آپ کو صرف ایک مسئلے سے بچاتی ہے: غلطی سے فائل حذف ہونے سے۔ یہ failed disk سے محفوظ نہیں رہتی، کیونکہ وہ اسی disk پر موجود تھی۔ یہ root رکھنے والے attacker سے محفوظ نہیں رہتی، کیونکہ وہ پہلے copies حذف کر دیتا ہے۔ یہ اس account کی غلطی سے بھی محفوظ نہیں رہتی جس کے نتیجے میں پورا VPS حذف ہو جائے۔ دنیا کا سب سے کم مؤثر datacenter اسی array پر موجود data کے ساتھ رکھی ہوئی backup_final_v2_REAL نام کی tarball کا مذاق اڑاتا ہے، اور یہ مذاق اس لیے مؤثر ہے کہ ہم میں سے بہت سے لوگوں نے بالکل یہی کیا ہے۔ بیک اپ کو سرور سے باہر رکھنا اصول ہے، اور اس پر عمل کرنے کا کم سے کم تکلیف دہ طریقہ restic ہے۔

چار بنیادی تصورات میں Restic

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

Snapshot۔ یہ ان files کی ایک مخصوص وقت کی تصویر ہے جن کا آپ نے backup لیا تھا۔ ہر backup run ایک snapshot بناتا ہے، ہر snapshot کو الگ restore کیا جا سکتا ہے، اور ہر snapshot اس وقت آپ کے data کی مکمل copy کی طرح کام کرتا ہے۔

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

By default encryption۔ restic repository ہمیشہ encrypted ہوتی ہے (AES-256)، اور ہر command کے لیے repository password درکار ہوتا ہے۔ backup host یا storage provider کو صرف encrypted blobs دکھائی دیتے ہیں۔ اس کا اہم نتیجہ یہ ہے کہ password ضائع ہونے پر data مستقل طور پر ختم ہو جاتا ہے، اور یہ اسی design کا حصہ ہے۔ Password کی ایک copy کسی ایسی جگہ رکھیں جو اس 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) ریلیز اپنے package versions کو منجمد رکھتی ہے۔ اس معاملے میں اس فرق کی اہمیت نہیں، کیونکہ 0.16.4 اس گائیڈ کے تمام کام انجام دیتا ہے۔ اگر آپ رفتار میں بہتری کے لیے جدید ترین ریلیز چاہتے ہیں تو restic پروجیکٹ کے GitHub releases صفحے سے سرکاری single-binary build ڈاؤن لوڈ کریں، اسے bunzip2 سے unpack کریں، اور /usr/local/bin/restic میں انسٹال کریں۔ restic کی انسٹالیشن کے لیے اس کے علاوہ کچھ درکار نہیں۔

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

آپ کو ایک destination machine درکار ہے۔ عام طور پر دوسرا چھوٹا VPS اس کے لیے کافی ہوتا ہے، اور SSH server اور اضافی disk رکھنے والی کوئی بھی machine کام کرے گی۔ Restic، SFTP (SSH کے ذریعے file transfer) استعمال کرتا ہے، اس لیے backup host پر کچھ بھی install کرنے کی ضرورت نہیں۔ اس guide میں backup host 10.0.0.12 ہے، جس پر restic نام کا user ہے۔ اس user کا نام backup نہ رکھیں۔ Ubuntu اور Debian ہر installation پر backup نام کا reserved system account (uid 34، login shell کے بغیر) فراہم کرتے ہیں، اس لیے adduser backup ناکام ہو جاتا ہے اور ssh backup@...، nologin میں پہنچ جاتا ہے۔

رات کو چلنے والا job اس server پر root کے طور پر چلے گا جس کا backup لیا جا رہا ہے، اس لیے root کو backup host پر key کے ذریعے login کی اجازت درکار ہے۔ passphrase کے بغیر ایک dedicated key بنائیں، کیونکہ رات 3am پر اسے داخل کرنے کے لیے کوئی شخص موجود نہیں ہوگا، پھر اسے copy کریں:

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

اگر SSH keys آپ کے لیے نئی ہیں تو SSH key management کی بنیادی باتیں model، permissions اور بعد میں key revoke کرنے کا طریقہ بیان کرتا ہے۔

اب repository password بنائیں۔ اسے صرف root کے قابلِ رسائی file میں ایک مضبوط password کے طور پر generate کریں:

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

اب مزید آگے بڑھنے سے پہلے اس password کو اپنے password manager میں copy کریں۔ اگر یہ VPS ناکام ہو جائے تو repository اور یہ password مل کر تمام data بحال کر دیتے ہیں؛ password کے بغیر repository کچھ بھی بحال نہیں کر سکتی۔

repository کو initialize کریں:

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

متبادل destination، S3-compatible object storage ہے۔ جب آپ دوسری machine چلانا نہ چاہیں تو یہی مناسب انتخاب ہے۔ ہر S3-compatible bucket اسی طرح کام کرتا ہے؛ صرف address اور دو credential variables تبدیل ہوتے ہیں:

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 کے بعد کا تمام حصہ دونوں destinations کے لیے یکساں ہے۔ اس guide کے باقی حصے میں SFTP address دکھایا گیا ہے؛ اپنا address استعمال کریں۔

خارج رکھ کر پہلی بیک اپ

اس ڈیٹا کا بیک اپ لیں جسے آپ دوبارہ انسٹال نہیں کر سکتے، پورے filesystem کا نہیں۔ آپریٹنگ سسٹم دوبارہ انسٹال کرنے سے واپس آ جاتا ہے؛ آپ کی configuration اور data واپس نہیں آتے۔ عام VPS کے لیے اس میں /etc، /home، اور وہ مقامات شامل ہیں جہاں آپ کی applications اپنی state محفوظ رکھتی ہیں، جیسے /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

پہلی بار چلانے پر تمام data upload ہوتا ہے، اس لیے کچھ وقت لگتا ہے۔ یہی command دوبارہ چلائیں تو یہ چند seconds میں مکمل ہو جاتی ہے۔ اس دوران چند تبدیل شدہ files اور شامل کیے گئے چند MiB کی اطلاع ملے گی، کیونکہ deduplication صرف نئے chunks upload کرتی ہے۔ دستیاب snapshots کی فہرست دیکھیں:

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

ہر snapshot میں ایک ID، وقت، اور اس میں شامل paths دکھائے جاتے ہیں۔ restore کے لیے یہی IDs استعمال ہوتی ہیں۔

systemd timer کے ساتھ ہر رات چلنے والے کام

ہر command میں repository کا address لکھنا جلد ہی دشوار ہو جاتا ہے، اور ہاتھ سے چلایا جانے والا backup ایک ماہ کے اندر رک جاتا ہے۔ دونوں مسائل ایک script اور ایک timer سے حل ہو جاتے ہیں۔ یہ script وہ دو environment variables مقرر کرتی ہے جنہیں restic پڑھتا ہے، RESTIC_REPOSITORY اور RESTIC_PASSWORD_FILE، اس لیے اس کے اندر ہر command مختصر رہتی ہے:

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 والی سطروں کی وضاحت اگلے دو sections میں کی گئی ہے۔ اب schedule دیکھیں: ایک oneshot service script چلاتی ہے، اور ایک timer اسے ہر رات 03:00 بجے چلاتا ہے۔ یہاں timer، cron line سے بہتر ہے کیونکہ run کا log journal میں محفوظ ہوتا ہے، اور Persistent=true downtime کے بعد server دوبارہ دستیاب ہوتے ہی چھوٹا ہوا backup چلا دیتا ہے۔

# /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 کو ایک بار ہاتھ سے چلائیں اور اس کی کارکردگی monitor کریں:

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 خود لکھنے کے بجائے دونوں files بھی generate کر سکتے ہیں:

ان دونوں files کے پیچھے مکمل طریقہ، جس میں calendar syntax اور وہ hardening directives شامل ہیں جو service استعمال کر سکتی ہے، VPS پر program کو systemd service کے طور پر چلانا میں بیان کیا گیا ہے۔

بحالِ دیگر بحالی تک بیک اپ محض ایک دعویٰ ہے

اس جملے کو ایک اصول سمجھیں۔ ہر رات کامیابی سے مکمل ہونے والا بیک اپ جاب صرف یہ ثابت کرتا ہے کہ جاب چلا تھا؛ یہ ثابت نہیں کرتا کہ آپ کا ڈیٹا واپس بحال ہو سکتا ہے۔ دو جانچیں اس خلا کو پُر کرتی ہیں۔

اول، restic check، جسے اسکرپٹ پہلے ہی ہر رات چلاتا ہے۔ یہ repository کے ڈھانچے اور index کی تصدیق کرتا ہے، اس لیے بیک اپ host پر ہونے والی خاموش خرابی restore کے دن کے بجائے اگلی رات ہی پکڑی جاتی ہے۔ مہینے میں ایک بار اس کا زیادہ گہرا ورژن چلائیں، جو اصل ڈیٹا کے بے ترتیب دسویں حصے کو download کرکے 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%

چونکہ ہر بار منتخب کیا جانے والا حصہ بے ترتیب ہوتا ہے، اس لیے ماہانہ runs مکمل download کی لاگت اٹھائے بغیر رفتہ رفتہ پوری repository کا احاطہ کر لیتے ہیں۔

دوم، restore drill۔ اوپر سے موجود root shell میں رہتے ہوئے، تازہ ترین snapshot سے ایک حقیقی directory کو scratch location پر restore کریں اور اسے live files کے ساتھ compare کریں:

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

diff کا کچھ بھی print نہ کرنا اس بات کی نشاندہی کرتا ہے کہ ہر byte بالکل یکساں واپس آیا ہے، اور یہی واحد قابلِ اعتماد ثبوت ہے۔ اس کے بعد /srv/restore-drill کو delete کریں۔ یہ drill ہر ماہ کریں، اور سال میں ایک یا دو بار مکمل طریقہ انجام دیں: تازہ ترین snapshot کو مکمل طور پر ایک scratch VPS پر restore کریں اور جانچیں کہ آپ کی application واقعی وہاں سے start ہوتی ہے۔ جس دن دباؤ کے تحت یہ کام کرنا ضروری ہو، آپ چاہتے ہیں کہ یہ پہلے سے انجام دیا ہوا معمول بن چکا ہو۔

Retention: بھولنا اور صاف کرنا

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

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

ڈیٹا بیسز: پہلے dump بنائیں، پھر dump کا بیک اپ لیں

Restic فائلوں کو پڑھتے وقت کاپی کرتا ہے، جبکہ ڈیٹا بیس اپنی فائلوں میں مسلسل لکھتا رہتا ہے۔ لکھائی کے دوران درمیان سے حاصل کی گئی فعال ڈیٹا بیس فائل بحال ہونے پر خراب ڈیٹا بیس بن جاتی ہے، کیونکہ اس کاپی میں لکھائی سے پہلے اور بعد کے صفحات شامل ہوتے ہیں۔ معیاری حل یہ ہے: ڈیٹا بیس انجن سے فائل میں ایک مستقل export بنوائیں، پھر restic سے اس فائل کا بیک اپ لیں۔

PostgreSQL کے لیے restic-backup.sh کے شروع میں، restic backup کمانڈ سے پہلے، dump کی ایک سطر شامل کریں، اور بیک اپ کے paths میں dump directory بھی شامل کریں:

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

mysqldump MariaDB اور MySQL کے لیے یہی کام کرتا ہے۔ پورے طریقے کی عملی مثال کے لیے Nextcloud کے بیک اپ کا حصہ maintenance mode فعال کرتا ہے، Postgres کا dump بناتا ہے، اور فائلوں کو ایک مستقل مجموعے کے طور پر کاپی کرتا ہے۔ یہی وہ مجموعہ ہے جسے restic کو ہر رات server سے باہر منتقل کرنا چاہیے۔ SQLite میں بھی یہی اصول ہے، لیکن طریقہ آسان ہے: Vaultwarden کی رہنمائی چند سیکنڈ کے لیے container روکتی ہے تاکہ db.sqlite3 کی cold copy بنائی جا سکے، اور restic اسی archive کو server سے باہر منتقل کرتا ہے۔

FAQ

کیا restic بیک اپ encrypted ہوتے ہیں؟

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

کیا restic incremental backups بناتا ہے؟

ہر restic snapshot مکمل backup کی طرح کام کرتا ہے، لیکن incremental storage استعمال کرتا ہے۔ Restic files کو chunks میں تقسیم کرتا ہے اور صرف وہ chunks upload کرتا ہے جو repository میں پہلے سے موجود نہ ہوں۔ اس لیے nightly run تقریباً اتنا ہی منتقل کرتا ہے جتنا اس دن تبدیل ہوا ہو۔ روایتی incremental schemes کے برعکس، snapshots کو دوبارہ چلانے کے لیے کوئی chain نہیں ہوتی۔ کوئی بھی snapshot براہ راست restore کیا جا سکتا ہے، اور پرانا snapshot delete کرنے سے نیا snapshot متاثر نہیں ہوتا۔

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

snapshot ID معلوم کرنے کے لیے restic snapshots چلائیں، پھر اسے restore کرنے کے لیے restic restore <id> --target /some/empty/dir چلائیں۔ صرف اس کے ایک حصے کو restore کرنے کے لیے --include /path شامل کریں۔ ID کی جگہ latest بھی کام کرتا ہے۔ Restic اصل directory structure کو target کے اندر دوبارہ بناتا ہے، اس لیے /etc/ssh کو restore کرنے سے files /some/empty/dir/etc/ssh میں پہنچتی ہیں۔ اس عمل کی ضرورت سے پہلے مشق کریں، کیونکہ جس backup کی جانچ نہ ہوئی ہو وہ صرف ایک دعویٰ ہے۔

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

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

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

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