بالکل کیا کاپی کرنا چاہیے

ہم آپ کی مشین کے خودکار بیک اپ نہیں بناتے: پینل میں بھی اسٹیٹ اسنیپ شاٹس موجود نہیں ہوتے، اور OS دوبارہ انسٹال کرنے سے ڈسک مکمل طور پر صاف ہو جاتی ہے۔ اس کا مطلب ہے کہ بیک اپ مکمل طور پر آپ کی ذمہ داری ہے، اور آپ کو پہلے ہی دن سے شروع کرنا ہوگا، نقصان کے بعد نہیں۔

آپ کو کس چیز کا بیک اپ لینا چاہیے

• ایپلیکیشن ڈیٹا — Docker والیومز، سائٹ ڈائریکٹریز، صارف کے اپلوڈ کردہ فائلز۔
• ڈیٹا بیس ڈمپس — خاص طور پر ڈمپس، لائیو ڈیٹا بیس فائلز نہیں (نیچے مزید تفصیل)۔
• کنفیگریشن — /etc/nginx، /etc/caddy، systemd یونٹس، compose.yaml اور .env فائلز، فائر وال رولز۔
• سرٹیفکیٹس اور کیز — /etc/letsencrypt، ایپلیکیشن کیز، میل سرور DKIM کیز۔
• شیڈولڈ جابز — بیک اپ لینے سے پہلے crontab -l > /root/crontab.txt چلائیں، ورنہ آپ شیڈول کے سوا سب کچھ ری اسٹور کر لیں گے۔
• انسٹال شدہ پیکجز کی فہرست — dpkg --get-selections > /root/packages.txt۔ چند کلو بائٹس لیتی ہے، گھنٹے بچاتی ہے۔

آپ کو کس چیز کا بیک اپ لینے کی ضرورت نہیں

OS، پیکجز اور Docker امیجز دوبارہ انسٹال کر کے اور کمانڈز چلا کر بحال ہو جاتے ہیں — یہ جگہ اور وقت کے قابل نہیں۔ /proc، /sys، /dev، /var/lib/docker مکمل طور پر، کیش ڈائریکٹریز یا swap فائلز کا بیک اپ نہ لیں۔

ایک معقول اصول: بیک اپ میں وہ سب کچھ ہونا چاہیے جو انٹرنیٹ پر نہیں ہے اور جو آپ ہدایات سے دوبارہ نہیں بنا سکتے۔

ڈیٹا بیسز

آپ چلتے ہوئے ڈیٹا بیس کی فائلز کاپی نہیں کر سکتے: آپ کو رائٹ کے درمیان لی گئی اسنیپ شاٹ ملے گی جو شاید کھل ہی نہیں۔ صحیح طریقہ ڈیٹا بیس کے اپنے ٹولز سے ڈمپ لینا ہے۔

docker compose exec -T db pg_dump -U postgres app | gzip > /backup/app-$(date +%F).sql.gz
docker compose exec -T db mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --single-transaction app | gzip > /backup/app-$(date +%F).sql.gz
sqlite3 /data/app.db ".backup '/backup/app-$(date +%F).db'"

PostgreSQL اور MySQL کے لیے آپ کو سروس روکنے کی ضرورت نہیں۔ SQLite کے لیے .backup استعمال کریں، cp نہیں: چلتی ہوئی فائل کاپی کرنے سے ڈیٹا بیس خراب ہو جاتا ہے۔

جس بیک اپ سے آپ نے کبھی ری اسٹور نہ کیا ہو، وہ بیک اپ شمار نہیں ہوتا۔ اسے خالی مشین پر یا الگ کنٹینر میں ٹیسٹ کریں — دیکھیں ری اسٹور ڈرل۔

مکمل سیٹ کی مثال

#!/bin/bash
set -euo pipefail
DEST=/backup/$(date +%F)
mkdir -p "$DEST"

docker compose -f /opt/myapp/compose.yaml exec -T db pg_dump -U postgres app | gzip > "$DEST/db.sql.gz"
tar czf "$DEST/etc.tar.gz" /etc/nginx /etc/letsencrypt /opt/myapp/compose.yaml /opt/myapp/.env
tar czf "$DEST/uploads.tar.gz" /var/www/uploads
crontab -l > "$DEST/crontab.txt"
dpkg --get-selections > "$DEST/packages.txt"

اسکرپٹ کو /usr/local/bin/backup.sh میں رکھیں، اسے chmod 700 پرمیشنز دیں اور اسے شیڈول میں شامل کریں۔ پھر آپ کو بیک اپ کسی دوسری جگہ بھیجنا ہوگا — آپ کے ڈیٹا کے ساتھ پڑی فائل آپ کو کسی چیز سے نہیں بچاتی۔

کتنے عرصے تک رکھیں

آسان الفاظ میں “3-2-1” اصول: کم از کم دو کاپیاں، کم از کم ایک اس مشین سے باہر۔ ریٹینشن کے لیے سات روزانہ، چار ہفتہ وار اور تین ماہانہ کافی ہیں — یہ کسی خاموش ناکامی سے پہلے کی حالت تک واپس جانے کے لیے کافی ہے جسے آپ نے فوراً محسوس نہ کیا ہو۔

اپنی جگہ کا پہلے سے منصوبہ بنائیں: VDS-1 میں 40 GB ڈسک ہے، اور اس پر بیک اپ ہسٹری رکھنے کی جگہ ہی نہیں — دیکھیں ڈسک اسپیس۔

عام غلطیاں

• بیک اپ اسی مشین پر ہے۔ دوبارہ انسٹال، رسائی کا ختم ہونا، rm -rf کی غلطی — اور بیک اپ ڈیٹا کے ساتھ ہی غائب ہو جاتا ہے۔
• آپ .env بھول گئے۔ ڈیٹا آپ کے پاس ہے، لیکن اس کے پاس ورڈز اور کیز گم ہو گئیں۔
• چلتے ہوئے ڈیٹا بیس والیوم کاپی کرنا۔ ری اسٹور خراب فائل پر ناکام ہو جاتا ہے۔ صرف ڈمپس۔
• کسی کو معلوم نہیں کہ بیک اپ بننا بند ہو گیا۔ Uptime Kuma میں پش چیک سیٹ اپ کریں: اسکرپٹ کامیابی کے بعد ایک ایڈریس کو پنگ کرتا ہے، اور ایک دن کی خاموشی الرٹ بجا دیتی ہے۔