VPN سرور کی ڈسک میں اضافہ کہاں سے آتا ہے اور اسے کیسے محدود کریں

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

بڑھنے والا ذخیرہ اور وہ رفتار تلاش کریں جس سے وہ بڑھا

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

df -h /var
df -i /var

پھر افزائش کو مالک سے منسوب کریں۔ journal کی اپنی استعمال کی تعداد صرف journal کو محیط ہے، اور یہ کبھی اس ڈیمون کو نہیں دیکھے گی جو اپنی کنفیگریشن فائل کے کسی راستے پر لکھتا ہے۔

journalctl --disk-usage

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

روٹیشن کھلی فائل کے ساتھ کیا کرتا ہے

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

lsof +L1 | head

پالیسی اسی حصے کی ہے جو فائل لکھتا ہے۔ journal اپنی ذخیرہ کاری کی حدیں اپنی کنفیگریشن فائل سے نافذ کرتا ہے، جبکہ فائل پر مبنی سروس عام طور پر logrotate پر انحصار کرتی ہے، یا تو بنانے کے قاعدے اور دوبارہ کھولنے کے اشارے کے ساتھ، یا جب لکھنے والا دوبارہ نہ کھول سکے تو موقع پر ہی تراشنے کی صورت میں۔ پہلے کچھ بدلے بغیر فیصلہ کی تصدیق کریں:

logrotate -d /etc/logrotate.conf

حد کہاں ہونی چاہیے اور کتنی بڑی

حد وہاں رکھیں جہاں لکھنے والا کنفیگر ہے، ماؤنٹ پوائنٹ پر نہیں۔ پورے والیوم پر کوٹا ہوسٹ کی حفاظت کرتا ہے مگر یہ نہیں بتاتا کہ کون سی سروس پہلے ناکام ہوگی، اور عالمی صفائی سکرپٹ اگلی واردات کے لیے ضروری ثبوت حذف کرنے کی طرف مائل ہوتی ہے۔ journal کی حد، زیادہ سے زیادہ حجم کے ساتھ روٹیشن کی تعداد، اور ایپلیکیشن سطح کی حفاظت، ہر ایک ایک پیدا کنندہ کو باندھتی ہے۔ مل کر وہ کل کو باندھتی ہیں؛ الگ الگ ہر ایک اندازہ ہے۔

وہ حد اسی حفاظتی مدت سے مقرر کریں جس کا آپ دفاع کر سکتے ہیں، دستیاب خالی جگہ سے نہیں۔ اگر جائزے کو ایک ہفتے کی کنکشن کوششیں درکار ہوں تو journal کو مصروف ترین متوقع رفتار پر ایک ہفتہ رکھنا ہوگا، اور وہ رفتار وہی عدد ہے جو پہلے ناپا گیا۔

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

دوبارہ آغاز کے بعد حد کی جانچ کریں

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

systemctl restart systemd-journald
journalctl --disk-usage

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

اگلی ریڈنگ کا اس سے موازنہ کریں

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

بیک اپ اسی والیوم سے باہر رکھیں، یا مان لیں کہ ایک بھری ڈسک بیک اپ کو بھی ساتھ لے جائے گی۔ جو نقل اسی ہوسٹ پر لکھی جائے جس کی یہ حفاظت کرتی ہے وہ بحالی منصوبہ نہیں، اور اس کی حفاظت کو اپنا جواب چاہیے۔

کیا، کہاں، کتنی مدت رکھا جاتا ہے اور کون اسے ہٹاتا ہے، لکھ لیں۔ وہی جملہ نتیجہ ہے، اور یہ اس کام کا واحد حصہ ہے جو اگلے دوبارہ آغاز تک بچتا ہے۔