قائمة فحص صيانة خادم Linux أسبوعياً وشهرياً

ما تعنيه صيانة خادم Linux فعلياً

صيانة خادم Linux هي قائمة قصيرة من الفحوصات تُنفَّذ وفق جدول ثابت، وليست مشروعاً له نهاية. أسبوعياً، تأكد من تثبيت التحديثات، ومن وجود مساحة كافية على القرص، ومن عدم توقف أي خدمة، ومن اكتمال مهمة النسخ الاحتياطي. شهرياً، اختبر استعادة نسخة احتياطية، وتحقق من تاريخ انتهاء الشهادات، وراجع الحسابات والمفاتيح، واحذف النوى والسجلات القديمة. مرة واحدة لكل إصدار من التوزيعة، خطط لترقية الإصدار ونفّذ إعادة التشغيل التي تواصل تأجيلها.

إنشاء الخادم مهمة مختلفة، وتغطي الدقائق العشر الأولى على VPS جديد ذلك الجزء. أما هذه الصفحة فتتناول السنة التالية. يذكر كل بند أدناه العطل الذي يمنعه، لأن قائمة التحقق التي لا توضّح عواقب تجاهلها هي قائمة يتوقف الناس بهدوء عن تنفيذها.

الأوامر هنا توضيحية، ويُفترض أن تقرأها قبل تنفيذها. قارن مخرجاتها بخادمك، لأن القيمة السليمة للمساحة الحرة أو لعدد العمليات تعتمد على وظيفة الخادم. عندما يختلف الفحص بين التوزيعات، يوضّح النص ذلك. تستخدم الأمثلة Debian وUbuntu مع apt. أما عائلة RHEL فتستخدم dnf، وتختلف فيها عدة مسارات.

كيفية اختيار وتيرة صيانة لخادم Linux يمكنك الالتزام بها

تغطي الفحوصات الأسبوعية الأمور التي تتغير من تلقاء نفسها: الحزم، واستخدام القرص، وحالة الخدمات، والمهام المجدولة. تتحرك هذه العناصر دون تدخل منك، لذلك يُعد الأسبوع أطول مدة يمكنك تركها من دون مراجعتها.

تغطي الفحوصات الشهرية التدهور البطيء: الشهادات التي يقترب تاريخ انتهاء صلاحيتها، والحسابات التي لم يحذفها أحد، وإصدارات kernel المتراكمة في /boot، وملفات السجل التي يتجاوز حجمها قاعدة تدوير توقفت عن مطابقتها. لا يتسبب أي من هذه الأمور في عطل غداً. لكنها جميعاً ستتسبب في عطل في النهاية.

تستند فحوصات الإصدارات إلى التقويم. إصدار التوزيعة هو عنصر الصيانة الوحيد ذو الموعد النهائي الخارجي، لأن دعم الإصدار الحالي ينتهي سواء كنت مستعداً أم لا.

حدّد وقتاً ثابتاً للتنفيذ: صباح يوم الاثنين للفحص الأسبوعي، واليوم الأول من الشهر للفحص الشهري. إنجاز قائمة فحص «عندما يتوفر الوقت» لا يُعد قائمة فحص. بعد تجاوز عدد الأجهزة بضع آلات، نفّذ هذه الفحوصات من مكان واحد بدلاً من تنفيذها يدوياً. وهذا هو موضوع إدارة عدة خوادم Linux من مكان واحد.

أسبوعياً: هل ثُبّتت التحديثات فعلاً؟

لا يعني تفعيل unattended-upgrades أنك تعرف أنه عمل. قد تكون الخدمة مقنّعة، أو قد يقتصر الإعداد على مصدر لا تستخدمه، وقد تتسبب حزمة واحدة معلّقة في فشل كل تشغيل لاحق. يوضّح التحديثات الأمنية التلقائية على Ubuntu طريقة تثبيته. أما المهمة الأسبوعية فتتمثل في إثبات أن ما ثبّتَّه نفّذ عمله.

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 المقياس الفعلي، لأنه يعرض الحالة الحالية بدلاً من النية. إذا بقيت التحديثات الأمنية في تلك القائمة، فهذا يعني أن التشغيل الآلي لا يؤدي وظيفته. لذلك اقرأ السجل قبل افتراض أن الجهاز تلقّى التحديثات. تُتخطّى الحزمة المثبّتة باستخدام apt-mark hold إلى الأبد ولا تُبلغ عن أي شيء، ولهذا يجب فحص apt-mark showhold في العملية نفسها.

يمنع ذلك الفشل التالي: تشغيل حزمة معروفة بكونها عرضةً للثغرات لأشهر، مع الاعتقاد بأن التحديثات تلقائية.

أسبوعياً: مساحة الأمان على القرص وinodes

يؤدي امتلاء نظام الملفات الجذري إلى تعطيل أشياء تبدو غير مرتبطة بالقرص. ترفض قاعدة البيانات عمليات الكتابة، ويتوقف التسجيل، ويفشل ترقية الحزم بعد إعدادها جزئياً، وفي بعض الإعدادات لا يمكنك فتح جلسة جديدة لأن النظام لا يستطيع كتابة ملفاته الخاصة.

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

df -i هو الجزء الذي يتجاهله معظم الأشخاص. إنّ inodes هي هياكل ذات عدد ثابت تحتفظ بالبيانات الوصفية للملفات، ويمكن أن ينفد عددها من نظام الملفات بينما لا يزال df -h يعرض غيغابايتات متاحة. عندها تفشل عمليات الكتابة مع No space left on device إلى جانب مخرجات تُظهر وجود مساحة متبقية، وهذا يسبب ساعة من الالتباس في المرة الأولى. ويكون السبب المعتاد ملايين الملفات الصغيرة، مثل ملفات قائمة بريد عالقة أو دليل جلسات لا يحذف محتواه أحد.

يبقى du -xh ضمن نظام ملفات واحد، وهذا هو المطلوب على خادم يستخدم bind mounts أو وحدة تخزين متصلة. على مضيف Docker، يكون السبب عادةً في طبقات الصور ووحدات التخزين المهجورة، ويمكن حذفها كما هو موضح في تقليص استخدام Docker لمساحة القرص على VPS.

توضح المساحة الحرة السعة المتاحة. لكن وحدة التخزين الأساسية قد تتعطل وفق جدولها الخاص، ولذلك يلزم فحص منفصل موضح في مراقبة صحة القرص على VPS.

أسبوعياً: ما الذي توقّف من دون أن يخبرك؟

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

تبقى الوحدة التي تعطّلت وتجاوزت حد إعادة التشغيل في حالة الفشل. وتظل في هذه الحالة بصمت. لا يرسل لك أي شيء بريداً إلكترونياً بشأنها. يُعدّ list-timers الجزء الأكثر فائدة، إذ يعرض آخر وقت عمل فيه كل مؤقت ووقت تشغيله التالي. لذلك، إذا كانت قيمة LAST أقدم من الفاصل الزمني الخاص بالمؤقت، فهذا يعني أن المهمة لم تعمل إطلاقاً.

اقرأ سجل الوحدة قبل إعادة تشغيلها باستخدام journalctl -u <unit> -n 100 --no-pager. تؤدي إعادة التشغيل إلى إزالة العَرَض، وبعد ذلك لن يكون لديك سبب للبحث مجدداً حتى تحدث المشكلة نفسها في وقت أسوأ.

الفشل الذي يمنعه ذلك: وكيل مراقبة، أو عامل قائمة انتظار، أو خدمة نسخ احتياطي متوقفة منذ ارتفاع في استهلاك الذاكرة قبل 3 أسابيع.

أسبوعياً: هل اكتملت مهمة النسخ الاحتياطي فعلاً؟

جدولة النسخ الاحتياطي واكتماله حقيقتان مختلفتان، ولا يمكن الاستعادة إلا من نسخة اكتملت. تحقق من الاكتمال.

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

تحقق من أمرين. يجب أن تكون آخر عملية تشغيل قد انتهت برمز خروج 0، وأن يكون أحدث أرشيف حديثاً وحجمه قريباً من الحجم المتوقع. ملف النسخ الاحتياطي الذي يصبح حجمه عُشر حجمه المعتاد فجأة هو تفريغ فاشل أنشأ ملفاً رغم ذلك. وهذا أخطر أشكال فشل النسخ الاحتياطي لأن كل ما بعده يبدو طبيعياً.

إذا كان البرنامج النصي يمرر ناتج التفريغ إلى ضاغط، فأضف set -o pipefail في بدايته. من دونه تكون حالة خروج خط الأنابيب هي حالة خروج الضاغط، وقد نجح الضاغط: لقد ضغط رسالة الخطأ. ثم تُبلّغ المهمة عن نجاحها كل ليلة، بينما تكتب أرشيفاً صغيراً لا يحتوي على شيء.

شهرياً: استعد نسخة احتياطية في مكان آخر

هذا هو البند الذي يتخطّاه معظم الناس، وهو الذي يحدد ما إذا كانت بقية القائمة ذات أهمية.

استعد النسخة على جهاز مختلف أو داخل حاوية جديدة، ولا تستعدها فوق البيانات الحية مطلقاً. ثم افتح ما استعدته وتأكد من أنه صالح فعلاً. احسب الصفوف في جدول. افتح مستنداً. سجّل الدخول إلى التطبيق المستعاد. اكتمال الاستخراج يثبت أن الأرشيف قابل للقراءة، ولا يثبت أكثر من ذلك.

توفّر أدوات المستودع آليات تحقق خاصة بها: restic check --read-data-subset=5% وborg check --verify-data تقرآن البيانات المخزنة بدلاً من الفهرس. شغّلهما وتعامل مع نتائجهما كاختبار أولي، لا كبديل عن الاستعادة. يتحقق الفحص من بقاء البايتات. أما الاستعادة فتتحقق من أن البايتات هي التي يحتاج إليها تطبيقك.

هناك تفصيلان يتعلمهما الناس بالطريقة الصعبة. اختبر عبارة مرور فك التشفير على جهاز لا يحتفظ بالمفتاح مسبقاً في agent، لأن النسخة الاحتياطية التي لا يمكنك فك تشفيرها ليست نسخة احتياطية. وقِس مدة الاستعادة، لأن هذه المدة هي زمن التعافي الفعلي لديك، وغالباً ما تكتشفه للمرة الأولى أثناء انقطاع الخدمة.

شهرياً: ما الشهادات التي ستنتهي قريباً؟

تفشل أتمتة التجديد بصمت. قد يجدّد مؤقت certbot الملف الموجود على القرص، بينما يواصل خادم الويب تقديم الشهادة القديمة الموجودة في الذاكرة، لأن hook النشر الذي يعيد تحميل الخدمة لم يعمل. لذلك استعلم من الخادم المشغّل عمّا يقدّمه، من خارج الخادم.

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 قيمة SNI (مؤشر اسم الخادم). وهذا مطلوب لأي عنوان يستضيف أكثر من موقع واحد، وإلا فستحصل على الشهادة الافتراضية بدلاً من شهادتك. إذا ثبّتَّ certbot من snap، فسيكون اسم المؤقت مختلفاً. لذلك ابحث عن الكلمة بدلاً من الاعتماد على وحدة افترضت اسمها.

تذكّر الشهادات التي لا تستخدم أي أتمتة على الإطلاق، مثل شهادة خادم البريد، أو VPN، أو المرجع المصدّق الداخلي. هذه هي الشهادات التي تنتهي صلاحيتها في عطلة نهاية الأسبوع، وترفضها المتصفحات والعملاء مباشرة بدلاً من عرض تحذير.

شهرياً: المستخدمون، وصلاحيات sudo، ومفاتيح SSH

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، وهو الإعداد الذي سيستخدمه البرنامج الخفي فعلياً. تتضمن صور Ubuntu الحديثة ملفات إسقاط في /etc/ssh/sshd_config.d/، ويمكن لهذه الملفات تجاوز الملف الرئيسي. لذلك، قد تؤدي قراءة sshd_config وحده إلى نتيجة معاكسة للحقيقة. في عائلة RHEL، تكون المجموعة الإدارية هي wheel بدلاً من sudo، لذا عدّل السطر getent.

ثم اقرأ ملفات authorized_keys نفسها. يُمنح الوصول باستخدام المفتاح، وليس الحساب، لذلك فإن مفتاحاً تركه متعاقد انتهى عمله قبل ستة أشهر يظل وسيلة دخول فعالة، ولن تُظهره أي قائمة بالمستخدمين. تحتوي المفاتيح على حقل تعليق. استخدمه، واحذف أي مفتاح لا يمكنك إسناده إلى شخص.

بالنسبة إلى سجل تسجيل الدخول، يطابق journalctl -t sshd --since "30 days ago" | grep -i accepted معرّف syslog، وليس اسم الوحدة. وهذا مهم لأن Ubuntu 24.04 يفعّل SSH عبر socket، لذلك تُسجَّل كل اتصالات ضمن وحدة مُنشأة لكل اتصال، وقد لا يعثر عليها استخدام journalctl -u ssh عادي.

شهرياً: النوى القديمة وامتلاء /boot

/boot يكون غالباً قسماً منفصلاً بحجم بضع مئات من الميغابايتات في صورة VPS القياسية. يضيف كل تحديث للنواة صورةً وinitramfs إلى هذا القسم. عند امتلائه، تفشل الترقية التالية في منتصفها وتترك الحزم غير مهيّأة. هذه حالة سيئة قد تكتشفها فجأة يوم الجمعة.

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

uname -r أولاً، دائماً: يحدّد اسم النواة التي تشغّلها الآن، ويجب أن تبقى مهما حذفت. يتعامل apt autoremove مع الحالة المعتادة في Debian وUbuntu، لأن النوى تُعلَّم على أنها مثبّتة تلقائياً، وتحظى النواة الحالية بالحماية. تتناول الحالات الطرفية، مثل نواة مثبّتة يدوياً أو /boot ممتلئاً بما يكفي لتعطيل apt نفسه، في إزالة النوى القديمة من Ubuntu.

شهرياً: نمو السجلات وjournal الخاص بـsystemd

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

logrotate --debug هو تشغيل تجريبي ولا يكتب أي شيء، لذلك فهو آمن على خادم قيد التشغيل. من المفيد تشغيله لأن قواعد التدوير تطابق المسارات: إذا غيّر تطبيق موقع سجلّه أثناء الترقية، فلن تعود قاعدته الخاصة تغطيه، وسيستمر ذلك الملف في النمو بلا حد حتى يمتلئ القرص.

يضع systemd حداً لحجم journal، لكن هذا الحد يُحسب كنسبة من نظام الملفات بدلاً من أن يكون رقماً تختاره. عيّن SystemMaxUse= في /etc/systemd/journald.conf ثم أعد تشغيل systemd-journald إذا أردت حداً أقصى محدداً. يستعيد sudo journalctl --vacuum-time=14d المساحة فوراً، لكنه إجراء يُنفَّذ مرة واحدة وليس سياسة، لذلك استخدمه مع تغيير الإعدادات.

لكل إصدار: إعادة التشغيل التي تواصل تأجيلها

حزمة نواة محدَّثة على القرص لا تعني أن النواة قيد التشغيل محدَّثة. إلى أن تعيد التشغيل، يواصل الجهاز تشغيل النواة القديمة. كما أن التصحيح المباشر، حيثما يتوفر، يغطي مجموعة فرعية فقط من الإصلاحات.

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

ملف الراية هذا هو اصطلاح في Debian وUbuntu، وتكتبه نصوص الحزم. لا تنشئه أنظمة عائلة RHEL. ويُجاب عن السؤال المكافئ فيها باستخدام needs-restarting -r، الذي يأتي من dnf-utils. أما needrestart، المثبّت افتراضياً في صور خوادم Ubuntu الحديثة، فيجيب عن المستوى الأدنى من النواة: فهو يسرد العمليات التي لا تزال تربط مكتبة استُبدلت على القرص. لذلك لا يسري تحديث OpenSSL إلى أن تعيد تشغيل الخدمات التي تستخدمه.

جدول إعادة التشغيل بدلاً من تجنّبها. في /etc/apt/apt.conf.d/50unattended-upgrades وUnattended-Upgrade::Automatic-Reboot "true"; وUnattended-Upgrade::Automatic-Reboot-Time "03:00";، فوّض القرار إلى وقت تحدده أنت. كما أن إعادة التشغيل المخططة هي الاختبار الوحيد للتأكد من أن الخادم سيعود للعمل، لأن إدخال fstab معطوباً أو خدمة لم تفعّلها من قبل سيظهر عند الإقلاع، ولا يظهر في أي وقت آخر.

التخطيط لترقية التوزيعة لكل إصدار

تتمتع إصدارات Ubuntu LTS بخمس سنوات من الدعم القياسي، بينما تحصل الإصدارات المؤقتة على تسعة أشهر، لذلك يحدد هذا الاختيار حجم أعمال الترقية لديك لسنوات. راجع إصدارات LTS مقابل الإصدارات المؤقتة على الخادم لفهم هذا المفاضلة.

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

يقرأ do-release-upgrade ذلك الملف، بينما يقيّده Prompt=lts بالترقيات من إصدار LTS إلى إصدار LTS فقط. يُفتح مسار الترقية من إصدار LTS إلى إصدار LTS عادةً عند صدور أول إصدار فرعي من الإصدار الجديد، وليس في يوم إصدار النسخة الأساسية. لذلك تحقّق مما يعرضه خادمك بدلاً من التخطيط وفق تاريخ افترضته. ترد خطوات الترقية في ترقية Ubuntu 24.04 إلى 26.04.

خطط لهامش زمني مدته ثلاثة أشهر. أنشئ snapshot واختبر استعادته، وسجّل مستودعات apt التابعة لجهات خارجية لديك. تعطل الترقية هذه المستودعات، ويحتاج كل مستودع منها إلى هدف جديد للإصدار الجديد. حدّد خطة التراجع قبل البدء. اعتباراً من أغسطس 2026، يستمر الدعم القياسي لـ Ubuntu 24.04 LTS حتى أبريل 2029، لذلك يتعلق الأمر بجدولة الترقية وليس بحالة طارئة.

ما الذي ينبغي أتمتته وما الذي ينبغي إبقاؤه يدوياً

أتمت القرارات التي اتخذتها بالفعل: تحديثات الأمان، وتدوير السجلات، وتجديد الشهادات، ومهام النسخ الاحتياطي. أتمت التنبيهات أيضاً، لأن الفحص الذي يعتمد على تذكّرك له لن يحدث عند الساعة 2 صباحاً. يلتقط نظام مراقبة خارجي، مثل مراقبة الحالة المستضافة ذاتياً باستخدام Uptime Kuma، الحالة الوحيدة التي لا يستطيع أي برنامج نصي على الخادم الإبلاغ عنها، وهي عدم إمكانية الوصول إلى الخادم.

أبقِ أمرين يدويين: اختبار الاستعادة وتدقيق الحسابات. يحتاج كلاهما إلى شخص يقرر ما إذا كانت النتيجة صحيحة. إذا كنت تفضّل قراءة حالة النظام في متصفح بدلاً من الطرفية، تقارن Cockpit مقابل Webmin لإدارة الخوادم بين لوحتي التحكم المعتادتين على الويب.

تحتاج الأتمتة نفسها إلى فحص، ولذلك فإن أول بند أسبوعي في هذه القائمة هو التحقق من أداة التحديث. الأتمتة التي تفشل بصمت أسوأ من عدم وجود الأتمتة، لأنها تلغي الفشل وعادة التحقق منه في الوقت نفسه.

قائمة التحقق كاملة في مكان واحد

# 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؟

أجرِ الفحوص أسبوعياً لكل ما يتغير تلقائياً: حالة التحديثات، والمساحة المتاحة على القرص والـinodes، والوحدات الفاشلة، وما إذا كانت مهمة النسخ الاحتياطي قد اكتملت. أجرِ الفحوص شهرياً للأمور التي تتدهور ببطء: اختبار الاستعادة، وانتهاء صلاحية الشهادة، وتدقيق الحسابات ومفاتيح SSH، والنوى القديمة، ونمو السجلات. أجرِ فحصاً واحداً لكل إصدار من التوزيعة لترقية الإصدار وإعادة التشغيل باستخدام النواة الحالية. يستغرق الفحص الأسبوعي بضع دقائق على خادم سليم، وهذا هو الهدف من إجرائه أسبوعياً بدلاً من الانتظار حتى يبدو أن هناك مشكلة.

لماذا أختبر الاستعادة إذا كانت مهمة النسخ الاحتياطي تشير إلى نجاحها؟

لأن المهمة تبلغ عن حالة خروجها هي، وقد تكون هذه الحالة صحيحة بينما يكون الأرشيف غير صالح للاستخدام. عندما تُمرَّر عملية dump إلى ضاغط من دون set -o pipefail، تُرجع العملية حالة الضاغط، لذلك قد تفشل عملية dump وتنتج رسالة خطأ فقط، ثم تنتهي بحالة صفر وتكتب ملفاً صغيراً. أجرِ الاستعادة على جهاز مختلف، وافتح البيانات، وتحقق من عدد أحد العناصر. كما يقيس اختبار الاستعادة مدته، وهذه المدة هي زمن الاسترداد الفعلي لديك.

هل يجب أن أعيد التشغيل بعد كل تحديث للنواة؟

يجب أن تعيد التشغيل قبل أن تصبح النواة الجديدة هي النواة قيد التشغيل. في Debian وUbuntu، يشير وجود /var/run/reboot-required إلى أن حزمة طلبت إعادة التشغيل، بينما يحدد /var/run/reboot-required.pkgs الحزمة المعنية. في عائلة RHEL، لا يوجد ذلك الملف، ويجيب needs-restarting -r من dnf-utils عن السؤال نفسه. اضبط نافذة لإعادة التشغيل التلقائي في /etc/apt/apt.conf.d/50unattended-upgrades بدلاً من تأجيلها إلى أجل غير محدد، لأن الجهاز الذي لم يُعَد تشغيله منذ عام يملك مسار إقلاع غير مختبر، إضافة إلى نواة قديمة.

ما الفحوص التي يمكنني أتمتتها بأمان؟

أتمت إجراءات حُسم قرارها مسبقاً: تحديثات الأمان، وتدوير السجلات، وتجديد الشهادات، والنسخ الاحتياطية المجدولة. أتمت الإشعارات أيضاً، لكي تصلك معلومات عن وحدة فاشلة أو قرص يمتلئ من دون أن يضطر شخص إلى تشغيل أمر. أبقِ اختبار الاستعادة وتدقيق المفاتيح يدوياً، لأن كلاً منهما يحتاج إلى شخص يحكم على صحة النتيجة. ثم أضف فحصاً واحداً لنظام الأتمتة نفسه، لأن فشل أداة التحديث بصمت يبدو تماماً كأن كل شيء يعمل.