إدارة أنظمة لينكس

التخزين: الأقراص والأقسام وأنظمة الملفات

22 دقيقة الدرس 3 من 28

التخزين: الأقراص والأقسام وأنظمة الملفات

كل خادم إنتاجي ستتعامل معه يخزّن بياناته على أجهزة كتلة — تسلسلات خام من القطاعات ذات الحجم الثابت يكشفها النواة كـ /dev/sda أو /dev/nvme0n1 أو /dev/xvdb وما شابهها. قبل أن يكون جهاز الكتلة قابلاً للاستخدام يجب تقسيمه وتهيئته. فهم هذه الطبقات أمر لا غنى عنه لمهندس DevOps: التقسيم الخاطئ يعني فقدان بيانات لا رجعة فيه، وسطر خاطئ في /etc/fstab قد يمنع الخادم من الإقلاع تماماً.

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

فحص أجهزة الكتلة باستخدام lsblk

lsblk (عرض قائمة أجهزة الكتلة) هو دائماً أداتك الأولى. يقرأ شجرة sysfs الخاصة بالنواة ويعرض كل قرص وأقسامه ونقاط توصيله — دون الحاجة إلى صلاحيات root.

# عرض كل أجهزة الكتلة في شكل شجري مع نوع نظام الملفات والحجم ونقطة التوصيل
lsblk -f

# مثال على المخرجات في VM سحابية نموذجية:
# NAME        FSTYPE   LABEL UUID                                 MOUNTPOINTS
# nvme0n1
# ├─nvme0n1p1 vfat           XXXX-XXXX                            /boot/efi
# ├─nvme0n1p2 ext4           xxxxxxxx-xxxx-...                    /
# └─nvme0n1p3 swap           xxxxxxxx-xxxx-...                    [SWAP]
# nvme1n1                                                          (خام — غير مقسَّم)

# مفيد أيضاً: عرض الأحجام بصيغة مقروءة للإنسان
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT,UUID

# معلومات تفصيلية لكل جهاز (الهندسة والنوع وحجم القطاع)
sudo fdisk -l /dev/nvme1n1

الحقول الأساسية: NAME اسم جهاز النواة؛ FSTYPE نوع نظام الملفات (فارغ يعني غير مهيَّأ)؛ MOUNTPOINTS يُظهر مكان إمكانية الوصول في شجرة المجلدات. الجهاز الذي لا يحمل FSTYPE ولا نقطة توصيل هو تخزين خام — مساحة قرص غير مخصصة.

إنشاء الأقسام باستخدام fdisk

fdisk هو محرر الأقسام التفاعلي المعياري للأقراص MBR وGPT. على أي قرص أكبر من 2 تيرابايت، أو على أي نظام يستخدم UEFI، أنشئ دائماً جدول أقسام من نوع GPT — فـ MBR لا يستطيع التعامل مع أكثر من 2 تيرابايت ولا يدعم إلا أربعة أقسام رئيسية.

# تقسيم قرص بيانات جديد (غير تفاعلي، باستخدام here-document)
# /dev/nvme1n1 هو القرص غير المقسَّم الذي حدّدناه بـ lsblk أعلاه.
# تحذير: يمسح هذا القرص بالكامل. تحقق من اسم الجهاز قبل التنفيذ.

sudo fdisk /dev/nvme1n1 <<'EOF'
g
n
1


w
EOF

# شرح المفاتيح المُرسَلة إلى fdisk:
#   g  — إنشاء جدول أقسام GPT جديد (يمسح البيانات الموجودة)
#   n  — قسم جديد
#   1  — رقم القسم 1
#   (سطران Enter فارغان) — قبول القطاع الأول والأخير الافتراضيين (كامل القرص)
#   w  — كتابة التغييرات والخروج

# التحقق من النتيجة
lsblk /dev/nvme1n1
# NAME        MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
# nvme1n1     259:1    0 100G  0 disk
# └─nvme1n1p1 259:2    0 100G  0 part

قاعدة إنتاجية — تحقق من اسم الجهاز قبل كل أمر تدميري. في VM سحابية، قد يكون /dev/sda هو قرص النظام الجذري. تشغيل fdisk على الجهاز الخطأ يعني فقدان بيانات فورياً لا يمكن إصلاحه. تحقق دائماً بـ lsblk وراجع الحجم وحالة التوصيل الحالية أولاً. نمط شائع في Google وAmazon: ضع تسمية على أقراص البيانات (mkfs -L data-vol-1) وأشِر إليها بالتسمية لا بمسار الجهاز الذي قد يتغير عند الإقلاع.

التهيئة: mkfs

بعد التقسيم يجب تهيئة القسم بنظام ملفات. mkfs هو الأمر الشامل؛ الأداة الفعلية هي متغيّر mkfs.النوع. اختر نظام ملفاتك حسب حالة الاستخدام:

ext4 — الافتراضي لمعظم أحمال عمل Linux. ناضج ومزود بسجل وسلوك fsck معروف. مفضل لأحجام الجذر وأقراص البيانات للأغراض العامة.
xfs — مفضل في RHEL/Amazon Linux للملفات الكبيرة وأحمال العمل عالية الإنتاجية (قواعد البيانات، تجميع السجلات). يتوسع بشكل أفضل عند أحجام متعددة التيرابايت؛ كتابة ملفات كبيرة أسرع.
tmpfs — مدعوم بالذاكرة العشوائية RAM، يُستخدم للمجلدات المؤقتة (/run، /tmp). يُحجَّم تلقائياً بجزء من الذاكرة العشوائية؛ يُمسح عند إعادة التشغيل.
btrfs / ZFS — أنظمة ملفات copy-on-write مدمجة مع اللقطات والمجاميع الاختبارية. شائعة في NAS وبرامج تشغيل Kubernetes CSI؛ التشغيل أكثر تعقيداً.

# تهيئة القسم الجديد كـ ext4 مع تسمية مقروءة
sudo mkfs.ext4 -L data-vol-1 /dev/nvme1n1p1

# لـ XFS (مفضل في RHEL/Amazon Linux لأقراص قواعد البيانات):
# sudo mkfs.xfs -L db-vol-1 /dev/nvme1n1p1

# التحقق من النتيجة — يجب أن يكون FSTYPE الآن ext4
lsblk -f /dev/nvme1n1

التوصيل: mount و /etc/fstab

يُوصَّل نظام الملفات المُهيَّأ بمسار مجلد (نقطة التوصيل). التوصيلات المؤقتة تعيش حتى إعادة التشغيل؛ /etc/fstab يجعل التوصيلات دائمة عبر عمليات إعادة التشغيل.

# إنشاء مجلد نقطة التوصيل
sudo mkdir -p /data

# توصيل مؤقت (يُفقد عند إعادة التشغيل)
sudo mount /dev/nvme1n1p1 /data

# التأكد من التوصيل
mount | grep /data
# أو
df -hT /data

# --- جعله دائماً في /etc/fstab ---
# الحصول على UUID (لا تستخدم مسارات الأجهزة كـ /dev/nvme1n1p1 في fstab — قد تتغير)
sudo blkid /dev/nvme1n1p1
# المخرجات: /dev/nvme1n1p1: LABEL="data-vol-1" UUID="a1b2c3d4-..." TYPE="ext4"

# أضف هذا السطر إلى /etc/fstab:
# UUID=a1b2c3d4-...   /data   ext4   defaults,nofail   0   2
#
# شرح الحقول (مفصولة بمسافات أو تبويبات):
#  1  UUID=...       — معرّف نظام الملفات (UUID ثابت؛ مسار الجهاز ليس كذلك)
#  2  /data          — نقطة التوصيل
#  3  ext4           — نوع نظام الملفات
#  4  defaults,nofail — خيارات التوصيل:
#                       defaults = rw,suid,dev,exec,auto,nouser,async
#                       nofail   = لا تعطّل الإقلاع إذا غاب القرص (حرج في VMs سحابية)
#  5  0              — علم النسخ الاحتياطي dump (دائماً 0 في الإعدادات الحديثة)
#  6  2              — ترتيب فحص fsck (1=الجذر، 2=غيره، 0=تخطَّ)

# اختبر سطر fstab بدون إعادة التشغيل:
sudo mount -a    # يوصّل كل ما في fstab ولم يوصَّل بعد
sudo df -hT      # تحقق من توصيل /data

استخدم دائماً nofail للأحجام غير الجذرية في VMs السحابية. إذا وصلت حجم EBS وأخذت لقطة منه ثم استعدت إلى نسخة جديدة دون إعادة توصيل الحجم، سيتوقف الإقلاع إلى أجل غير مسمى عند "A start job is running for..." بدون nofail. فقد مهندسو الاستجابة للحوادث ساعات في هذا. استخدم nofail لكل توصيل ثانوي في fstab.

LVM: مدير الأحجام المنطقية

الأقسام الخام لها قيد رئيسي: تغيير الحجم يتطلب إلغاء التوصيل (أو إعادة التشغيل). يحل LVM هذا بإدراج طبقة مرنة بين التخزين المادي وأنظمة الملفات. إنه الطبقة المعيارية للتخزين في أنظمة Linux المؤسسية وواجهات الأحجام الدائمة في Kubernetes وأي حمل عمل يحتاج نمو القرص بشكل ديناميكي دون توقف.

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

الثلاث تجريدات في LVM:

الحجم المادي (PV) — قرص خام أو قسم يُهيَّأ بـ pvcreate. يكتب LVM بيانات وصفه في بداية الـ PV.
مجموعة الأحجام (VG) — واحد أو أكثر من الـ PVs تُجمَّع معاً بـ vgcreate. فكّر في الـ VG كحوض تخزين واحد كبير.
الحجم المنطقي (LV) — شريحة مُسمّاة من الـ VG تُنشأ بـ lvcreate. يظهر كـ /dev/vg-name/lv-name. هيّئه وصِله تماماً مثل القسم العادي.

# سير عمل LVM الكامل: قرصان -> مجموعة أحجام واحدة -> حجمان منطقيان

# 1. تهيئة الأحجام المادية
sudo pvcreate /dev/nvme1n1 /dev/nvme2n1
sudo pvs        # التحقق من الـ PVs

# 2. إنشاء مجموعة أحجام باسم vg-data
sudo vgcreate vg-data /dev/nvme1n1 /dev/nvme2n1
sudo vgs        # التحقق من الـ VG (يجب إظهار الحجم المدمج)

# 3. إنشاء الأحجام المنطقية
sudo lvcreate -L 50G  -n lv-app  vg-data
sudo lvcreate -L 150G -n lv-logs vg-data
sudo lvs        # التحقق من الـ LVs

# 4. التهيئة والتوصيل (تماماً مثل قسم عادي)
sudo mkfs.ext4 /dev/vg-data/lv-app
sudo mkfs.xfs  /dev/vg-data/lv-logs
sudo mkdir -p /app /var/log/app
sudo mount /dev/vg-data/lv-app  /app
sudo mount /dev/vg-data/lv-logs /var/log/app

# 5. الإضافة إلى /etc/fstab باستخدام مسار الجهاز (مسارات LVM ثابتة — UUID ليس إلزامياً،
#    لكنه لا يزال جيداً وأكثر قابلية للنقل):
# /dev/vg-data/lv-app   /app            ext4  defaults,nofail  0  2
# /dev/vg-data/lv-logs  /var/log/app    xfs   defaults,nofail  0  2

# --- تغيير الحجم أثناء التشغيل (بدون توقف لأحجام LVM) ---
# توسيع lv-logs بـ 50 جيجابايت (أضف مساحة حرة للـ VG أولاً إذا لزم)
sudo lvextend -L +50G /dev/vg-data/lv-logs
# توسيع نظام ملفات XFS ليملأ حجم الـ LV الجديد
sudo xfs_growfs /var/log/app

# لـ ext4، استخدم resize2fs بدلاً من ذلك:
# sudo resize2fs /dev/vg-data/lv-app

لقطة LVM للنسخ الاحتياطية بدون توقف. قبل تشغيل نسخة احتياطية لقاعدة بيانات أو ترحيل مخطط محفوف بالمخاطر، أنشئ لقطة: sudo lvcreate -L 10G -s -n lv-app-snap /dev/vg-data/lv-app. صِل اللقطة للقراءة فقط وشغّل النسخة الاحتياطية عليها، ثم احذفها. الحجم الحي لا يُقفَل أبداً، ولديك نسخة متسقة في نقطة زمنية محددة. هذه هي الطريقة التي تنفّذ بها خدمات قواعد البيانات المدارة (RDS، AlloyDB) واجهات برمجة اللقطات تحت الغطاء.

أنماط الفشل الشائعة في الإنتاج

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

امتلاء حجم الجذر: تتوقف التطبيقات عن كتابة السجلات، تتعطل قواعد البيانات، قد يعمل SSH لكن تقريباً لا شيء آخر يعمل. شخّص المشكلة بـ df -hT. راحة فورية: journalctl --vacuum-size=200M (انظر الدرس 2)، ثم ابحث عن الملفات الكبيرة واحذفها أو أرشفها بـ du -sh /* 2>/dev/null | sort -rh | head.
جهاز خاطئ في fstab: النظام لا يستطيع إيجاد UUID عند الإقلاع، ينتهي بصدفة الاسترداد الطارئ. صحّح من وحدة تحكم الاسترداد بتعديل /etc/fstab وتصحيح UUID. شغّل دائماً sudo mount -a بعد تعديل fstab لاكتشاف الأخطاء قبل إعادة التشغيل.
فساد نظام الملفات: بعد انقطاع مفاجئ للتيار، يعالج سجل ext4 عادةً نفسه عند التوصيل التالي. إن لم يفعل: sudo fsck -n /dev/nvme1n1p1 (فحص للقراءة فقط أولاً)، ثم sudo fsck -y /dev/nvme1n1p1 (الإصلاح). لا تشغّل fsck أبداً على نظام ملفات موصول.
عدم تطابق بيانات LVM الوصفية بعد إساءة استخدام اللقطات: الإزالة غير المكتملة للقطة قد تُفسد بيانات الـ VG الوصفية. احذف اللقطات دائماً بـ lvremove صراحةً؛ لا تدعها تمتلئ (اللقطة الممتلئة تصبح غير صالحة).