حفظ قسم في دبيان عندما حدث خطأ ما

مساء الخير يا عزيزي!

سوف أخبركم بإحدى الطرق السريعة التي قد تؤدي إلى فقد البيانات بشكل كامل على الجهاز الظاهري ، ولكن لا يزال العثور على المخرج هو:

مصدر البيانات:
OS: ديبياب 9 64 بت
FS: ext4 دون LVM
الغرض: لتوسيع FS على جهاز ظاهري من 14 جيجابايت إلى 60 جيجابايت

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


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

هيكل FS على VM:
/ التمهيد - 56MB
/ - كل المساحة المتبقية - ext4

منذ أن تم إنشاء الجهاز الظاهري من قالب ، لا يوجد LVM ، وهذا بالطبع سوف يبسط الإجراء بأكمله.

وهكذا يبدأ المسؤول مساء الخميس في أداء المهمة. كانت خطوته الأولى هي تمهيد VM باستخدام صورة ISO - SystemRescue. بعد تحميل VM بنجاح بمساعدة الصورة iso ، يبدأ المسؤول في العمل وبمساعدة fdisk يحذف القسم / (/ dev / vda2) ، وهو صحيح لأنه يحتاج إلى توسيع. بعد حذف القسم (/ dev / vda2) ، ينشئ المشرف قسمًا جديدًا - / dev / vda2 وهنا يحدث الخطأ الأول - يقوم المشرف بإنشاء قسم ممتد أولاً وبعد ذلك فقط ينشئ الأساسي وبعد مقارنة الترميز الجديد ، يخرج fdisk ويحاول تحميل القسم:



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

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

بعد عدة محاولات لاستعادة القسم من تلقاء نفسه ، أول مسؤول يطلب المساعدة من المشرف الثاني.

أولاً ، يترك المسؤول الثاني جهاز VM وينسخ صورة القرص الحالية باسم vm_bad_disk. بعد ذلك ، ترتفع VM من نفس إصدار نظام التشغيل - Debian 9 64bit وتتصل بالقرص الثاني - vm_bad_disk.

بعد الوصول إلى VM جديد من خلال ssh - نشاهد قائمة الأقراص في VM:
root@recovery:~# fdisk -l
Disk /dev/vda: 4.9 GiB, 5242880000 bytes, 10240000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x09dea38e

Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 499711 497664 243M 83 Linux
/dev/vda2 501758 10237951 9736194 4.7G 5 Extended
/dev/vda5 501760 10237951 9736192 4.7G 83 Linux

Disk /dev/vdb: 58.6 GiB, 62914560000 bytes, 122880000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe8c76303

Device Boot Start End Sectors Size Id Type
/dev/vdb1 * 2048 194559 192512 94M 83 Linux
/dev/vdb2 196606 30717951 30521346 14.6G 5 Extended
/dev/vdb5 198656 30717951 30519296 14.6G 83 Linux


هنا هو / dev / vdb - هذا هو vm_bad_disk الخاص بنا. أول شيء ، يقوم المشرف الثاني بإزالة / dev / vdb2 و / dev / vdb5 ومحاولة إنشاء / dev / vdb2 مع بداية عام 194560 ونهاية تقريبية ، ولكنه يحصل أيضًا على:
سوبربلوك غير صالح .

للعمل مع القسم / dev / vdb ، يتم تثبيت أداة مساعدة مفصولة للعمل بشكل أكثر ملاءمة مع القسم.
نكرر الإجراء مع إزالة / dev / vdb2 بالفعل في افترق وتقديم المساعدة.

يتم توجيه انتباه المسؤول إلى أمر الإنقاذ ، والذي يسمح لك بتعيين بداية القسم ونهيته للعثور على FS عليه. لا يوجد شيء معقد في بناء جملة الأمر:
فقط اكتب في افترقنا:
> الانقاذ
سيسأل النظام:
البداية - أشارت إلى 194560
يحتاج المسؤول الآن إلى حساب نهاية (نهاية القسم). نظرًا لأن المسؤول كان يعلم في البداية أن حجم القرص بالكامل كان 14 غيغابايت وأن قطاع واحد يبلغ 512 بايت ... تتم الحسابات التالية:
14 غيغابايت حوالي 15032385536 بايت ، نحسب عدد القطاعات:
15032385536/512 = 29360128
يجب تحديد هذه القيمة في جزء:
نهاية 29360128

اضغط على Enter بجرأة وانتظر النتيجة ... في هذه الحالة ، لم أكن مضطراً للانتظار طويلاً وأظهر أحدهم أنه تم العثور على FS وما إذا كان الأمر يستحق إجراء التغييرات - نجيب على YES

سيؤدي Parted إلى إجراء التغييرات اللازمة وسيخرج المسؤول من parted.

يعود المسؤول إلى سطر أوامر النظام ويقوم بما يلي:
جبل / ديف / vdb2 / كزاز الرضع

يتم تركيب القسم دون أي مشاكل ويوضح أن حجمه يبلغ حوالي 14 جيجابايت ، وهو أمر صحيح ، حيث لم يتم توسيع FS بعد. يقوم المشرف بفحص الملفات بسرعة وكل شيء يقول إنه لا توجد قطع أثرية وملفات مقطوعة للوهلة الأولى.

نظرًا لأن القسم يظهر بشكل مباشر ، يقوم المسؤول بما يلي: umount / dev / vdb2 ويبدأ:
e2fsck / dev / vdb2 بعد اكتمال الفحص - يقوم بتشغيل الأمر لتوسيع القسم:
resize2fs / dev / vdb2

تمر العملية دون أي مشاكل ويقوم المسؤول بتحديث القسم مرة أخرى للتأكد من أن كل شيء على ما يرام:
جبل / ديف / vdb2 / كزاز الرضع

يتم تثبيت القسم دون أخطاء وباستخدام الأمر df -p ، فإنه يرى قسمًا موسعًا بالفعل.

يتحقق المسؤول مرة أخرى من الملفات والدلائل الموجودة على هذه المجموعة ويقرر أن كل شيء على ما يرام مع FS والملفات.

يقوم المسؤول بتنفيذ الأمر: إيقاف التشغيل - p الآن وإزالة محرك الأقراص المعين من جهاز VM الذي تم تنفيذ الإجراءات به.

يقوم بحفظ صورة قرص VM الأصلية ، والتي بدأ كل شيء منها في وحدة تخزين منفصلة واستبدالها بالصورة الصحيحة للقرص وإرسال VM للتمهيد.

يقوم VM بالتمهيد دون أي مشاكل وجميع البيانات في مكانها الصحيح.

الأخلاقية:
1) خذ لقطة قبل أفعالك
2) التقاط لقطة من الإعدادات المطلوبة (في هذه الحالة ، علامة التقسيم)
3) قبل العمل ، النسخ الاحتياطي للملفات الهامة