Linux سرور maintenance checklist اور ماہانہ checks

Linux سرور کی maintenance سے حقیقتاً کیا مراد ہے

Linux سرور کی maintenance مقررہ schedule کے مطابق کی جانے والی مختصر checks کی فہرست ہے، نہ کہ ایسا project جس کا کبھی اختتام نہ ہو۔ ہر ہفتے تصدیق کریں کہ updates install ہو چکی ہیں، disk میں کافی جگہ موجود ہے، کوئی service بند نہیں ہوئی، اور backup job مکمل ہو گئی ہے۔ ہر ماہ restore کی جانچ کریں، certificate کی expiry دیکھیں، accounts اور keys کا audit کریں، اور پرانے kernels اور logs صاف کریں۔ ہر distribution release کے وقت version upgrade کی منصوبہ بندی کریں اور وہ reboot کریں جسے آپ مسلسل مؤخر کر رہے ہیں۔

سرور بنانا ایک مختلف کام ہے، اور نئے VPS پر پہلے دس منٹ میں اس حصے کا احاطہ کیا گیا ہے۔ یہ صفحہ اس کے بعد آنے والے سال سے متعلق ہے۔ ذیل میں ہر item اس failure کی نشاندہی کرتا ہے جسے وہ روکتا ہے، کیونکہ consequences کے بغیر checklist ایسی چیز ہے جسے لوگ خاموشی سے چلانا چھوڑ دیتے ہیں۔

یہاں دی گئی commands بطور مثال ہیں اور انہیں run کرنے سے پہلے پڑھنے کے لیے دی گئی ہیں۔ ان کے output کا اپنے سرور کے output سے موازنہ کریں، کیونکہ free space یا process count کی صحت مند value اس بات پر منحصر ہوتی ہے کہ سرور کیا کام کرتا ہے۔ جہاں checks distributions کے درمیان مختلف ہوں، وہاں متن میں اس کی وضاحت کی گئی ہے۔ مثالوں میں Debian اور Ubuntu کے ساتھ apt استعمال کیا گیا ہے۔ RHEL family میں tooling dnf ہے اور کئی paths مختلف ہیں۔

ایسا Linux server maintenance cadence کیسے منتخب کریں جسے آپ برقرار رکھ سکیں

ہفتہ وار checks ان چیزوں کا احاطہ کرتے ہیں جو آپ کی مداخلت کے بغیر تبدیل ہوتی رہتی ہیں: packages، disk usage، service state اور scheduled jobs۔ یہ خود بخود تبدیل ہوتی رہتی ہیں، اس لیے ایک ہفتہ وہ زیادہ سے زیادہ مدت ہے جس میں آپ انہیں بغیر پڑھے چھوڑ سکتے ہیں۔

ماہانہ checks سست رفتاری سے ہونے والی خرابی کا احاطہ کرتے ہیں: وہ certificates جن کی expiry قریب آ رہی ہو، وہ accounts جنہیں کسی نے remove نہیں کیا، /boot میں جمع ہوتے kernels، اور وہ log files جو اس rotation rule سے زیادہ بڑھ گئی ہوں جس کا match ہونا بند ہو چکا ہے۔ ان میں سے کوئی بھی چیز کل خرابی پیدا نہیں کرتی۔ لیکن آخرکار سب خرابی پیدا کرتی ہیں۔

Release checks کیلنڈر کے مطابق کیے جاتے ہیں۔ Distribution release واحد maintenance item ہے جس کی بیرونی deadline ہوتی ہے، کیونکہ آپ کے موجودہ version کی support ختم ہو جاتی ہے، چاہے آپ تیار ہوں یا نہ ہوں۔

اس کام کے لیے ایک مقررہ وقت رکھیں: weekly pass کے لیے Monday morning اور monthly pass کے لیے مہینے کی پہلی تاریخ۔ Checklist کو "جب وقت ملے گا" کے اصول پر چلانا checklist نہیں ہے۔ چند machines سے زیادہ ہونے پر یہ کام ہاتھ سے کرنے کے بجائے ایک ہی جگہ سے چلائیں۔ اسی موضوع پر ایک ہی جگہ سے متعدد Linux servers کا انتظام میں بات کی گئی ہے۔

ہفتہ وار: کیا updates واقعی install ہوئے؟

unattended-upgrades کو enable کرنا اس بات کے برابر نہیں کہ آپ کو معلوم ہو کہ یہ چلا بھی تھا۔ service masked ہو سکتی ہے، configuration کسی ایسے origin تک محدود ہو سکتی ہے جسے آپ استعمال نہیں کرتے، اور ایک held package اس کے بعد ہونے والے ہر run کو ناکام بنا سکتا ہے۔ اسے install کرنے کا طریقہ Ubuntu پر automatic security updates میں دیا گیا ہے۔ ہفتہ وار job یہ ثابت کرتی ہے کہ آپ کے install کیے ہوئے automation نے واقعی کام کیا۔

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable قابلِ اعتماد پیمانہ ہے، کیونکہ یہ ارادے کے بجائے موجودہ state رپورٹ کرتا ہے۔ اگر security updates اب بھی اس فہرست میں موجود ہیں تو automation اپنا کام نہیں کر رہا۔ اس لیے یہ فرض کرنے سے پہلے کہ machine patched ہے، log پڑھیں۔ apt-mark hold کے ذریعے pinned package ہمیشہ skip ہو جاتا ہے اور کوئی اطلاع نہیں دیتا۔ اسی لیے apt-mark showhold کو بھی اسی pass میں شامل کرنا چاہیے۔

اس سے یہ failure روکا جاتا ہے: کئی ماہ تک known-vulnerable package چلتا رہتا ہے، جبکہ آپ سمجھتے رہتے ہیں کہ updates خودکار طور پر install ہو رہے ہیں۔

ہفتہ وار: disk اور inode کی گنجائش

root filesystem بھر جانے سے ایسی خرابیاں پیدا ہوتی ہیں جو بظاہر disk سے متعلق نہیں لگتیں۔ database لکھنے سے انکار کر دیتا ہے، logging رک جاتی ہے، package upgrade آدھی configuration کے بعد ناکام ہو جاتا ہے، اور بعض setups میں نیا session بھی نہیں کھلتا کیونکہ وہ اپنی files نہیں لکھ سکتا۔

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i وہ نصف ہے جسے زیادہ تر لوگ نظرانداز کر دیتے ہیں۔ Inodes مقررہ تعداد میں موجود وہ structures ہیں جو file metadata محفوظ رکھتے ہیں، اور filesystem ان سے اس وقت محروم ہو سکتا ہے جب df -h اب بھی free gigabytes دکھا رہا ہو۔ اس کے بعد writes، جگہ باقی ہونے کا output دکھائی دینے کے باوجود، No space left on device کے ساتھ ناکام ہو جاتی ہیں۔ پہلی بار ایسا ہونے پر وجہ سمجھنے میں ایک الجھن بھرا گھنٹہ لگ سکتا ہے۔ عموماً اس کی وجہ stuck mail queue یا ایسی session directory ہوتی ہے جسے کوئی prune نہیں کرتا اور جس میں لاکھوں چھوٹی files جمع ہو جاتی ہیں۔

du -xh ایک ہی filesystem پر رہتا ہے، اور bind mounts یا attached storage والے server پر یہی مطلوب ہوتا ہے۔ Docker host پر عموماً وجہ image layers اور dead volumes میں ہوتی ہے۔ انہیں VPS پر Docker disk usage کو prune کرنا میں بیان کردہ طریقے سے صاف کیا جا سکتا ہے۔

Free space آپ کو capacity کے بارے میں بتاتی ہے۔ اس کے نیچے موجود storage اپنے الگ schedule کے مطابق fail ہوتی ہے، اس لیے اس کی جانچ الگ سے کرنا ضروری ہے، جسے VPS پر disk health monitoring میں بیان کیا گیا ہے۔

ہفتہ وار: کون سی چیز خاموشی سے بند ہو گئی؟

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

جو unit crash ہو کر اپنی restart limit تک پہنچ جاتی ہے، وہ failed حالت میں رہتی ہے اور اسی طرح خاموش پڑی رہتی ہے۔ کوئی آپ کو اس کے بارے میں email نہیں بھیجتا۔ list-timers زیادہ مفید حصہ ہے: یہ دکھاتا ہے کہ ہر timer آخری بار کب چلا تھا اور اگلی بار کب چلے گا، اس لیے اگر LAST کی قدر خود timer کے interval سے زیادہ پرانی ہو تو وہ job بالکل نہیں چلی۔

unit کو restart کرنے سے پہلے journalctl -u <unit> -n 100 --no-pager کے ذریعے اس کا journal پڑھیں۔ restart علامت کو دور کر دیتا ہے، اور پھر آپ کے پاس دوبارہ دیکھنے کی کوئی وجہ نہیں رہتی، جب تک یہی مسئلہ کسی زیادہ نامناسب وقت پر دوبارہ پیش نہ آ جائے۔

اس سے جس failure کی روک تھام ہوتی ہے، وہ یہ ہے: monitoring agent، queue worker یا backup service جو تین ہفتے پہلے memory spike کے بعد سے بند پڑی ہو۔

ہفتہ وار: کیا backup job واقعی مکمل ہوئی؟

شیڈول کے مطابق backup چلنا اور backup کا مکمل ہونا دو الگ حقائق ہیں، اور restore صرف مکمل backup سے ہوتا ہے۔ تکمیل کی تصدیق کریں۔

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

دو چیزوں کی تصدیق کریں۔ آخری run کا exit status zero ہو، اور جدید ترین archive حالیہ ہو اور اس کا سائز متوقع سائز کے تقریباً برابر ہو۔ جو backup file اچانک اپنے معمول کے سائز کے دسویں حصے کے برابر رہ جائے، وہ failed dump ہے جس نے پھر بھی file لکھ دی۔ یہ backup failure کی سب سے خطرناک صورت ہے، کیونکہ اس کے بعد کے تمام مراحل معمول کے مطابق دکھائی دیتے ہیں۔

اگر آپ کی script dump کو compressor میں pipe کرتی ہے تو شروع میں set -o pipefail شامل کریں۔ اس کے بغیر pipeline کا exit status compressor کا ہوتا ہے، اور compressor کامیاب رہا: اس نے error message کو compress کر دیا۔ اس کے بعد job ہر رات کامیابی رپورٹ کرتی رہتی ہے، جبکہ ایک ایسی چھوٹی archive لکھتی ہے جس میں کچھ بھی نہیں ہوتا۔

ماہانہ: backup کو کسی اور جگہ restore کریں

یہ وہ مرحلہ ہے جسے زیادہ تر لوگ چھوڑ دیتے ہیں، حالانکہ یہی طے کرتا ہے کہ فہرست کے باقی مراحل واقعی اہم تھے یا نہیں۔

backup کو کسی دوسری machine یا نئے container میں restore کریں، live data پر کبھی نہیں۔ پھر restore کیا ہوا data کھول کر تصدیق کریں کہ وہ حقیقی اور قابلِ استعمال ہے۔ کسی table میں rows گنیں۔ کوئی document کھولیں۔ restored application میں login کریں۔ Extraction کا مکمل ہونا صرف یہ ثابت کرتا ہے کہ archive پڑھا جا سکتا ہے، اس سے زیادہ کچھ نہیں۔

Repository tools کی اپنی verification ہوتی ہے: restic check --read-data-subset=5% اور borg check --verify-data index کے بجائے stored data پڑھتے ہیں۔ انہیں چلائیں، لیکن smoke test کے طور پر استعمال کریں، متبادل کے طور پر نہیں۔ Verification یہ جانچتی ہے کہ bytes محفوظ رہے۔ Restore یہ جانچتا ہے کہ bytes وہی ہیں جن کی آپ کی application کو ضرورت ہے۔

لوگ دو باتیں عموماً مشکل تجربے سے سیکھتے ہیں۔ Decryption passphrase ایسی machine پر آزمائیں جس میں key پہلے سے کسی agent میں موجود نہ ہو، کیونکہ جس backup کو آپ decrypt نہ کر سکیں وہ backup نہیں ہے۔ Restore کا وقت بھی ناپیں، کیونکہ یہی آپ کا حقیقی recovery time ہے، اور عموماً اس کا پتا outage کے دوران چلتا ہے۔

ماہانہ: کون سے certificates جلد expire ہونے والے ہیں؟

Renewal automation خاموشی سے ناکام ہو سکتی ہے۔ certbot timer disk پر موجود file کو renew کر دیتا ہے، جبکہ web server memory میں موجود پرانا certificate فراہم کرتا رہتا ہے، کیونکہ service کو reload کرنے والا deploy hook نہیں چلا۔ اس لیے server کے باہر سے معلوم کریں کہ running server اس وقت کیا فراہم کر رہا ہے۔

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

-servername flag SNI (server name indication) مقرر کرتا ہے۔ ایک سے زیادہ sites کی میزبانی کرنے والے ہر address پر یہ ضروری ہے۔ بصورت دیگر آپ کو اپنے certificate کے بجائے default certificate ملے گا۔ اگر certbot کو snap سے install کیا گیا ہو تو timer کا نام مختلف ہوتا ہے۔ اس لیے اپنی فرض کردہ unit کے بجائے لفظ کی بنیاد پر match کریں۔

ان certificates کو بھی یاد رکھیں جن کے لیے کوئی automation موجود نہیں، مثلاً mail server، VPN اور internal certificate authority کے certificates۔ یہی certificates عموماً weekend پر expire ہوتے ہیں۔ browsers اور clients انہیں warning دینے کے بجائے براہِ راست مسترد کر دیتے ہیں۔

ماہانہ: صارفین، sudo رسائی اور SSH keys

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T ہر Include کے merge ہونے کے بعد مؤثر configuration دکھاتا ہے۔ یہی configuration daemon حقیقت میں استعمال کرے گا۔ حالیہ Ubuntu images میں /etc/ssh/sshd_config.d/ کے اندر drop-in files شامل ہوتی ہیں، اور یہ main file کو override کر سکتی ہیں۔ اس لیے صرف sshd_config پڑھنے سے حقیقت کے برعکس نتیجہ مل سکتا ہے۔ RHEL family میں administrative group wheel ہے، sudo نہیں۔ اس لیے getent line کو اسی کے مطابق تبدیل کریں۔

پھر authorized_keys files کو خود پڑھیں۔ رسائی account کے بجائے key کے ذریعے دی جاتی ہے۔ اس لیے چھ ماہ پہلے کام مکمل کر چکے contractor کی چھوڑی ہوئی key ایک فعال login ہو سکتی ہے، جسے users کی کوئی فہرست ظاہر نہیں کرے گی۔ Keys میں comment field ہوتی ہے۔ اسے استعمال کریں، اور ایسی ہر key حذف کریں جسے کسی شخص سے منسوب نہ کیا جا سکے۔

Login history کے لیے journalctl -t sshd --since "30 days ago" | grep -i accepted unit name کے بجائے syslog identifier سے match کرتا ہے۔ یہ اس لیے اہم ہے کہ Ubuntu 24.04 SSH کو socket کے ذریعے activate کرتا ہے۔ اس لیے ہر connection کو connection-specific generated unit کے تحت log کیا جاتا ہے، اور سادہ journalctl -u ssh ان entries کو نظرانداز کر سکتا ہے۔

ماہانہ: پرانے kernels اور بھرا ہوا /boot

/boot عام طور پر stock VPS image میں چند سو megabytes کا الگ partition ہوتا ہے۔ ہر kernel update اس میں ایک image اور ایک initramfs شامل کرتا ہے۔ جب یہ بھر جاتا ہے تو اگلا upgrade درمیان میں ناکام ہو جاتا ہے اور packages unconfigured رہ جاتے ہیں۔ جمعہ کے دن اچانک ایسی حالت کا سامنا کرنا مناسب نہیں۔

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

پہلے ہمیشہ uname -r چلائیں۔ یہ اس وقت استعمال ہونے والے kernel کا نام بتاتا ہے، اور آپ جو کچھ بھی remove کریں، اس kernel کو برقرار رہنا چاہیے۔ Debian اور Ubuntu میں معمول کی صورت حال کو apt autoremove سنبھالتا ہے، کیونکہ kernels کو automatically installed کے طور پر نشان زد کیا جاتا ہے اور موجودہ kernel محفوظ رہتا ہے۔ غیر معمولی صورتیں، یعنی manually installed kernel یا ایسا /boot جو apt کو بھی روکنے کے لیے پہلے ہی کافی بھر چکا ہو، Ubuntu میں پرانے kernels صاف کرنا میں بیان کی گئی ہیں۔

ماہانہ: log growth اور systemd journal

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug ایک dry run ہے اور کچھ بھی نہیں لکھتا، اس لیے اسے live box پر محفوظ طور پر چلایا جا سکتا ہے۔ اسے چلانا مفید ہے، کیونکہ rotation rules، paths کی بنیاد پر match ہوتے ہیں: اگر کسی upgrade کے دوران application نے اپنے log کا location تبدیل کر لیا ہو تو وہ اپنی مخصوص rule کے دائرے میں نہیں رہتی، اور وہ file بغیر کسی حد کے بڑھتی رہتی ہے، یہاں تک کہ disk بھر جاتی ہے۔

systemd، journal کے حجم کی حد مقرر کرتا ہے، لیکن یہ حد آپ کے منتخب کردہ عدد کے بجائے filesystem کے ایک حصے کی بنیاد پر ہوتی ہے۔ اگر آپ مخصوص maximum حد مقرر کرنا چاہتے ہیں تو /etc/systemd/journald.conf میں SystemMaxUse= set کریں اور systemd-journald restart کریں۔ sudo journalctl --vacuum-time=14d فوراً جگہ خالی کرتا ہے۔ یہ policy کے بجائے one-time action ہے، اس لیے اسے configuration change کے ساتھ استعمال کریں۔

ہر ریلیز کے بعد: وہ reboot جسے آپ مسلسل مؤخر کرتے ہیں

Disk پر موجود updated kernel package، running kernel نہیں ہوتا۔ reboot ہونے تک machine پرانا kernel ہی چلا رہی ہوتی ہے، اور جہاں live patching دستیاب ہو بھی، وہاں یہ صرف fixes کے ایک محدود حصے کا احاطہ کرتی ہے۔

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

یہ flag file package scripts کے ذریعے لکھی جانے والی Debian اور Ubuntu کی convention ہے۔ RHEL family systems اسے نہیں بناتے۔ وہاں یہی سوال needs-restarting -r سے حل ہوتا ہے، جو dnf-utils سے حاصل ہوتا ہے۔ needrestart، جو حالیہ Ubuntu server images میں default طور پر installed ہوتا ہے، kernel سے نچلی سطح کا جواب فراہم کرتا ہے: یہ ان processes کی فہرست دکھاتا ہے جو اب بھی اس library کو map کر رہے ہیں جسے disk پر replace کیا جا چکا ہے۔ اسی وجہ سے patched OpenSSL اس وقت تک مؤثر نہیں ہوتا جب تک اسے استعمال کرنے والی services restart نہ ہوں۔

reboot سے بچنے کے بجائے اسے schedule کریں۔ /etc/apt/apt.conf.d/50unattended-upgrades، Unattended-Upgrade::Automatic-Reboot "true"; اور Unattended-Upgrade::Automatic-Reboot-Time "03:00"; میں فیصلہ اپنے منتخب کردہ وقت کے حوالے کریں۔ planned reboot ہی اس بات کا واحد test بھی ہے کہ box دوبارہ start ہوتا ہے یا نہیں، کیونکہ خراب fstab entry یا وہ service جسے آپ نے کبھی enable نہیں کیا، boot کے وقت ظاہر ہو جاتی ہے اور کسی اور جگہ نہیں۔

ہر ریلیز کے لیے: distribution upgrade کی منصوبہ بندی

Ubuntu LTS releases کو standard support کے پانچ سال ملتے ہیں، جبکہ interim releases کو نو ماہ ملتے ہیں۔ اس لیے یہ انتخاب کئی سال تک آپ کے upgrade workload کا تعین کرتا ہے۔ یہ فرق سرور پر LTS اور interim releases میں بیان کیا گیا ہے۔

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade اس file کو پڑھتا ہے، جبکہ Prompt=lts اسے صرف LTS-to-LTS moves تک محدود کرتا ہے۔ LTS-to-LTS path عموماً نئے version کے release day کے بجائے اس کے پہلے point release پر دستیاب ہوتا ہے۔ اس لیے اپنی فرض کردہ تاریخ کے مطابق منصوبہ بندی کرنے کے بجائے دیکھیں کہ آپ کی machine کو حقیقتاً کون سا option پیش کیا جا رہا ہے۔ upgrade کے طریقۂ کار کی تفصیل Ubuntu 24.04 کو 26.04 میں upgrade کرنا میں ہے۔

تین ماہ کا اضافی margin رکھیں۔ ایسا snapshot لیں جس کی restoration آپ نے test کی ہو، اپنے third-party apt repositories کی فہرست بنائیں، کیونکہ upgrade انہیں disable کر دیتا ہے اور ہر repository کے لیے نئی release کا نیا target درکار ہوتا ہے، اور شروع کرنے سے پہلے rollback کا فیصلہ کریں۔ August 2026 تک Ubuntu 24.04 LTS کو April 2029 تک standard support حاصل ہے، اس لیے یہ scheduling کا معاملہ ہے، emergency کا نہیں۔

کیا خودکار بنانا ہے اور کیا دستی رکھنا ہے

ان فیصلوں کو خودکار بنائیں جو آپ پہلے ہی کر چکے ہیں: security updates، log rotation، certificate renewal اور backup jobs۔ alerting بھی خودکار بنائیں، کیونکہ ایسا check جس کے لیے آپ کو اسے یاد رکھنا پڑے، وہ رات 2 بجے نہیں ہو سکے گا۔ بیرونی monitor، مثلاً Uptime Kuma کے ذریعے self-hosted status monitoring، اس مسئلے کو پکڑ لیتا ہے جس کی اطلاع on-box script نہیں دے سکتی: server کا unreachable ہونا۔

دو کام دستی رکھیں: restore test اور account audit۔ دونوں میں کسی شخص کو فیصلہ کرنا ہوتا ہے کہ نتیجہ درست ہے یا نہیں۔ اگر آپ terminal کے بجائے browser میں machine state پڑھنا پسند کرتے ہیں تو server management کے لیے Cockpit اور Webmin کا موازنہ ان دونوں عام web consoles کا تقابل پیش کرتا ہے۔

اس کے بعد automation کو بھی اپنی جانچ درکار ہوتی ہے، اسی لیے اس فہرست کا پہلا weekly item updater کی تصدیق ہے۔ خاموشی سے fail ہونے والی automation، automation نہ ہونے سے بھی بدتر ہے، کیونکہ یہ failure اور اسے دیکھنے کی عادت، دونوں ایک ساتھ ختم کر دیتی ہے۔

تمام چیک لسٹ ایک ہی جگہ

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Linux server maintenance کتنی بار چلانی چاہیے؟

جو چیزیں خود تبدیل ہوتی رہتی ہیں، انہیں ہفتہ وار چیک کریں: update status، disk اور inode headroom، failed units، اور یہ کہ backup job مکمل ہوئی یا نہیں۔ آہستہ آہستہ خراب ہونے والی چیزیں ماہانہ چیک کریں: restore test، certificate expiry، account اور SSH key audit، old kernels، اور log growth۔ version upgrade اور موجودہ kernel پر reboot کے لیے ہر distribution release کے وقت ایک بار چیک کریں۔ صحت مند سرور پر ہفتہ وار جائزہ چند منٹ لیتا ہے۔ اسی لیے اسے ہفتہ وار چلانا بہتر ہے، نہ کہ صرف اس وقت جب کوئی خرابی دکھائی دے۔

اگر backup job کامیاب ہونے کی اطلاع دے تو restore test کیوں کریں؟

کیونکہ job اپنی exit status کے بارے میں اطلاع دیتی ہے، اور archive کے ناقابل استعمال ہونے کے باوجود یہ status درست ہو سکتا ہے۔ set -o pipefail کے بغیر compressor کو pipe کیا گیا dump compressor کا status واپس کرتا ہے۔ اس لیے failed dump صرف error message پیدا کرنے کے باوجود zero کے ساتھ exit کر سکتا ہے اور ایک چھوٹی file لکھ سکتا ہے۔ Restore کسی دوسری machine پر کریں، data کھولیں، اور کسی چیز کی تعداد گنیں۔ Restore کا وقت بھی record کریں۔ یہی مدت آپ کا حقیقی recovery time ہے۔

کیا ہر kernel update کے بعد reboot کرنا ضروری ہے؟

نئے kernel کے running kernel بننے سے پہلے reboot کرنا ضروری ہے۔ Debian اور Ubuntu میں /var/run/reboot-required کی موجودگی بتاتی ہے کہ کسی package نے reboot کی درخواست کی ہے، اور /var/run/reboot-required.pkgs بتاتا ہے کہ کس package نے یہ درخواست کی۔ RHEL family میں یہ file موجود نہیں ہوتی، اور needs-restarting -r، dnf-utils سے یہی سوال کا جواب دیتا ہے۔ /etc/apt/apt.conf.d/50unattended-upgrades میں automatic reboot window مقرر کریں، اسے غیر معینہ مدت تک مؤخر نہ کریں۔ ایک ایسی machine جس نے ایک سال سے reboot نہیں کیا، اس میں old kernel کے ساتھ untested boot path بھی موجود ہوتا ہے۔

ان checks میں سے کنہیں محفوظ طریقے سے automate کیا جا سکتا ہے؟

وہ actions automate کریں جن کے بارے میں فیصلہ پہلے ہی طے ہے: security updates، log rotation، certificate renewal، اور scheduled backups۔ Notification بھی automate کریں، تاکہ failed unit یا بھرنے والی disk کی اطلاع آپ تک انسان کے command چلائے بغیر پہنچ جائے۔ Restore test اور key audit manual رکھیں، کیونکہ ہر ایک میں کسی شخص کو یہ فیصلہ کرنا ہوتا ہے کہ نتیجہ درست ہے یا نہیں۔ اس کے بعد automation پر خود ایک check شامل کریں، کیونکہ خاموش updater failure بالکل ایسا دکھائی دیتا ہے جیسے سب کچھ درست طور پر کام کر رہا ہو۔