سؤال ما مدى سوء تركيب نظام Linux على قسم كبير؟


سنقوم بتشغيل CentOS 7 على خادمنا الجديد. لدينا محركات الأقراص 6 × 300GB في RAID6 الداخلية إلى الخادم. (يكون التخزين خارجيًا بشكل كبير في شكل مربع غارة بحجم 40 تيرابايت). يأتي الحجم الداخلي إلى 1.3 تيرابايت إذا تمت تهيئته كحجم واحد. مسؤول النظام لدينا يعتقد أنها فكرة سيئة حقا لتثبيت نظام التشغيل على قسم كبير 1.3TB.

أنا عالم أحياء. نقوم دائمًا بتثبيت برنامج جديد للتشغيل والاختبار ، معظمها أراضي في / usr / local. ومع ذلك ، نظرًا لأن لدينا حوالي 12 عالماً بيولوجيًا غير حاسب باستخدام النظام ، فإننا أيضًا نجمع الكثير من الطرق في المنزل أيضًا. كان خادمنا الأخير يحتوي على قسم 200 غيغابايت لـ / ، وبعد مرور 2.5 عام كان 90٪ ممتلئًا. لا أريد أن يحدث ذلك مرة أخرى ، لكنني لا أريد أيضًا أن أعارض نصيحة الخبراء!

كيف يمكننا استخدام 1.3TB بشكل أفضل للتأكد من توفر المساحة متى وأينما كانت مطلوبة ولكن لا تخلق كابوس صيانة لمسؤول النظام؟


92
2017-09-18 08:12


الأصل


استخدم LVM وتغيير حجمها حسب الرغبة - thanasisk
thanasisk في سوف resizability هي أسطورة ، لأنه لا يوجد نظام ملفات على لينكس التي كانت قادرة على أن تتقلص على الانترنت. كان ext2 مثل هذا التصحيح في العصور القديمة. - peterh
PeterHorvath - هل أنت سعيد إذا قمت باستبدال "تغيير الحجم" بـ "توسيع"؟ - thanasisk
من غير الواقعي أن نتوقع أن يكون الإعداد الآن أفضل من 2.5 سنة! وحقيقة أن المستخدمين غير المحنكين يصنعون الفوضى هو سبب إضافي لفصل نظام التشغيل عن البيانات. - JamesRyan
PeterHorvath لقد قرأت تعليقك أكثر من مرة حتى أتمكن من فهمه. لقد كتبت أنك ستكون سعيدًا في حالة وجود نظام ملفات يمكن توسيعه وأشرت إلى نظام ملفات يفعل ذلك. هذا كل شئ. - gparent


الأجوبة:


الأسباب الأساسية (التاريخية) للتقسيم هي:

  • إلى فصل نظام التشغيل عن المستخدم وبيانات التطبيق. حتى صدور RHEL 7 لم يكن هناك دعم مسار الترقية وستتطلب ترقية إصدار رئيسي إعادة تثبيت ثم بعد ذلك على سبيل المثال /home والبيانات الأخرى (التطبيق) على أقسام منفصلة (أو وحدات تخزين LVM) تسمح لك بالحفاظ على بيانات المستخدم وبيانات التطبيق بسهولة ومسح قسم (أقسام) نظام التشغيل.

  • لا يمكن للمستخدمين تسجيل الدخول بشكل صحيح ويبدأ النظام في الفشل بطرق مثيرة للاهتمام عند نفاد مساحة القرص بالكامل. تسمح لك الأقسام المتعددة بتخصيص مساحة قرص محجوزة لنظام التشغيل والحفاظ على ذلك منفصلة عن المنطقة التي يسمح فيها للمستخدمين و / أو التطبيقات المحددة بالكتابة (على سبيل المثال /home /tmp/ /var/tmp/ /var/spool/ /oradata/ وما إلى ذلك) ، تخفيف مخاطر التشغيل من المستخدمين و / أو التطبيقات السيئة التصرف.

  • الحصص. تسمح الحصة النسبية للقرص للمستخدم بمنع مستخدم فردي من استخدام كل المساحة المتوفرة ، مما يؤدي إلى تعطيل الخدمة لجميع المستخدمين الآخرين للنظام. يتم تعيين الحصة النسبية للقرص الفردي لكل نظام ملفات ، لذلك فإن قسمًا واحدًا وبالتالي نظام ملفات واحد لا يعني سوى قرص واحد. أقسام متعددة (LVM) تعني أنظمة ملفات متعددة تسمح بإدارة حصص أكثر حبيبية. استنادًا إلى سيناريو الاستخدام ، قد تحتاج على سبيل المثال إلى السماح لكل مستخدم 10 غيغابايت في دليله الرئيسي ، و 2 تيرابايت في دليل / البيانات على صفيف التخزين الخارجي وإعداد منطقة خدش كبيرة مشتركة حيث يمكن لأي شخص تفريغ مجموعات البيانات كبيرة جدًا بالنسبة إلى دليله الرئيسي وحيث تصبح السياسة "ممتلئ ممتلئ" ولكن عندما يحدث ذلك لا يحدث أي كسر أيضًا.

  • توفير مسارات IO مخصصة. قد يكون لديك مزيج من أقراص SSD و spinning ، وستفعل بشكل جيد لمعالجتها بشكل مختلف. ليست مشكلة كبيرة في خادم للأغراض العامة ، ولكن من الشائع جدا في إعدادات قاعدة البيانات هو أيضا تعيين مغازل معينة (الأقراص) لأغراض مختلفة لمنع تعارض IO ، على سبيل المثال. قرص منفصلة لسجلات المعاملات ، أقراص منفصلة لبيانات قاعدة البيانات الفعلية والأقراص منفصلة عن مساحة temp. .

  • حذاء قد يكون لديك حاجة منفصلة /boot تقسيم. من الناحية التاريخية لمعالجة مشكلات BIOS مع التشغيل خارج حدود 1024 الأسطوانة ، في الوقت الحاضر في كثير من الأحيان مطلب لدعم وحدات التخزين المشفرة ، لدعم وحدات تحكم RAID معينة ، HBA التي لا تدعم عمليات التمهيد من SAN أو أنظمة الملفات غير مدعومة على الفور من قبل المثبت الخ.

  • ضبط قد تحتاج إلى خيارات ضبط مختلفة أو حتى أنظمة ملفات مختلفة تمامًا.

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

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

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

تقلص حجم LVM تافهة ولكن في كثير من الأحيان لا يتم دعم تقلص أنظمة الملفات عليها بشكل جيد وربما ينبغي تجنبها.


104
2017-09-18 09:49



فيما يتعلق بأداء الأداء ، أعتقد أنه من الجدير بالذكر أيضًا أنه في حالة الحاجة إلى نظام ملفوف يتم الرد بسرعة ، فإن "df" سيعرض معلومات مفيدة أسرع بكثير من "du -s $ DIRNAME" - symcbean
لست متأكدًا من أنني أتفق مع "حتى ... RH7 ... لا يوجد مسار الترقية المدعوم"لقد فعلت ترقيات مدعومة منذ وقت الفراغ ، وبالتأكيد ترقية الأنظمة RH4-> 5 فقط RH5-> RH6 التي تفتقر إلى هذا المسار ، على حد علمي - وأحصل على شعور RH حصلت على شامل من قبل مستخدميها لهذا الافتقار. 1+ لبقية إجابة ممتازة ، على الرغم من. - MadHatter
ما الذي تشير إليه مع "حتى إصدار RHEL 7 لم يكن هناك مسار ترقية مدعوم"؟ هل يدعم RHEL ترقيات بين الإصدارات الرئيسية من RHEL 7 وإلى الأمام؟ - Markus Hallmann
الترقيات لا تعمل ، ولكن وفقا ل قبعة حمراء السياسة العامة لا تزال هي: لا يدعم Red Hat الترقيات في المكان بين أي إصدارات رئيسية لـ Red Hat Enterprise Linux.  والفارق بسيط إلى مزيد من أسفل يدعم Red Hat حاليًا ترقيات من Red Hat Enterprise Linux 6 إلى Red Hat Enterprise Linux 7 لحالات استخدام محددة / مستهدفة فقط و هنا الدليل للتأكد - HBruijn


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

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

يمكن منع هذا إذا كنت تستخدم أقسامًا مختلفة للأماكن التي يكتب فيها المستخدمون أو العمليات عادةً (/ home / var / / tmp).

أوصيك بالتحقق من الخادم القديم الذي تميل المجلدات إلى الحصول عليه. يمكنك القيام بذلك على سطر الأوامر مع

du -h -d 1 / 2> /dev/null

سترى المكان الذي يتم فيه تجميع معظم البيانات وتصميم النظام التالي بشكل مناسب. يحدد "-d 1" الإخراج إلى مستوى واحد فقط من عمق المجلد مما يجعله أكثر قابلية للقراءة.


17
2017-09-18 08:38





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

يحتوي جذر المستخدم على مجلده الرئيسي (/root) خارج /home و لهذا. إذا كان نظام الملفات ممتلئًا في بعض الظروف ، فحتى الجذر لا يمكنه تسجيل الدخول ولا يمكنه إصلاح النظام.

هذا هو سبب إنشاء نقاط تثبيت منفصلة لـ /var، /tmp و /home لتتمكن من تسجيل الدخول على الأقل كجذر لإصلاح النظام عند ملء أحد الأقسام الأخرى.


12
2017-09-18 08:23



في بعض أنظمة الملفات (ext3 f.e.) يمكنك الحصول على مساحة محجوزة قليلاً للمستخدم الجذر لمنع هذا السلوك. يجب عليك استخدام نظام الحصص لمنع ذلك ، الشيء نفسه بالنسبة لـ / tmp والذي غالباً ما يُنسى. - Dennis Nolte
DennisNolte لقد نسيت /tmp. شكرا ، سأضيف هذا إلى جوابي. - Uwe Plonus
DennisNolte المساحة المحجوزة ستساعد لكني أعتقد أن الصيانة صعبة أكثر من استخدام أقسام مختلفة كما لديك لإعداد حصص بشكل صحيح. - Uwe Plonus
أعتقد أن هناك سببًا أكثر أهمية بالنسبة إلى /root ليكون في الخارج /home هو أنه في بعض المنشآت /home سيكون على محرك أقراص الشبكة. في حالة وجود مشكلة في تركيبها على الشبكة ، تظل ملفات الجذر قابلة للوصول. (يمكن مقارنة ذلك بكيفية وجود محرر نصوص في عادة /bin، في حال /usr أظن أن هذا السيناريو أكثر شيوعًا في الممارسة ، في هذه الأيام ، من /home يملأ على طول الطريق. - Eliah Kagan


IMHO ، وجود قسم واحد كما / هو معقول جدا.

ولكن يمكنك استخدام lvm (مدير وحدة التخزين المنطقية). استخدم كل القرص كمجموعة lvm ، ولكن قم بإنشاء أقراص منطقية صغيرة لـ / ، / home / / usr ومهما كان النظام sysadmin المفضل لديك. ثم ضع بعض المراقبة ، التي تعرفها ، عندما يبدأ نظامك بالتمدد وتوسيع تلك الأقراص التي تحتاجها. تعد lvresize و resize2fs أدوات عبر الإنترنت ويمكنك القيام بالتوسع دون إعادة تشغيل الخادم. ومع ذلك ، لا يمكنك تقليل الأقراص ، لذلك تحتاج إلى بدء صغير بشكل معقول وزيادة المكان الذي تشاهد الحاجة إليه.


10
2017-09-18 08:22





هناك مشاكل الحد الأدنى حول إعداد قسم واحد كبير من لينكس ، ولكن لديها مكافآت كبيرة.

إن تغيير تخطيط القسم أمر صعب ومخاطر قليلاً ، وهو الأمر الذي لا يمكنك فعله في الغالب دون توقف طويل.

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

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

هناك نظام بسيط اسمه LVM، والتي تمكن على ذبابة تتحرك / تغيير حجم "أقسام" (في المصطلحات الخاصة به ، وحدات التخزين). ولكن على خادم الدائرة المحلية واحد ، عادة ما تكون هناك حاجة IMHO.


9
2017-09-18 08:43



أي نوع من مشرف masochistic الإعجابات للعب مع خرائط التقسيم ؟؟ الجزء الممتع هو بناء النواة ، هل يمكنني الحصول على آمين؟؟؟ - bishop
آمين! الآن حول الحجة التي يرغب المسؤولون في اللعب بها مع الأقسام ، أود فقط مواجهة ذلك بحقيقة أن لينكس لديها على الأرجح 100 نوع مختلف من أنظمة الملفات واعتمادًا على أنماط الاستخدام ، فإن اختيار نظام filre الصحيح لمهمة معينة قد يعني الفرق بين النظام الأمثل والنظام غير الوظيفي. وربما تحتاج فقط إلى نظام الملفات هذا في بعض المجلدات. هناك. - Lennart Rolland


هناك سببان رئيسيان للتقسيم:

  1. للحفاظ على البيانات الساكنة بعيدًا عن البيانات غير الثابتة
  2. للحفاظ على البيانات العامة بعيدًا عن البيانات الخاصة

السبب الأول هو الأكثر وضوحا - تحتاج إلى عزل المناطق التي تملأ مع الملفات من تلك التي لا ، وكنت تريد على وجه الخصوص لحماية / ، لتجنب نظام غير قابل للتمهيد. على سبيل المثال ، عادةً ما يكون الدليل / var هو المكان الذي سيتم تخزين ملفات السجل (var يرمز إلى "variable") وهذا هو السبب / var يميل إلى أن يتم تركيبه على قسم منفصل عن /.

السبب الثاني أعلاه أقل استشهادًا (لقد سمعته من قبل في دورة مدير Veritas Volume Director منذ حوالي 15 عامًا) وهو حقًا ذو صلة بالأنظمة التي يسجّل فيها العديد من الأشخاص الدخول والقيام بالعمل.

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

باعتباري مطور برامج ، فقد سئمت بشكل خاص من بناء الأجهزة الظاهرية في قسم العمليات البصرية من خلال أنظمة التقسيم غير المجدية التي تقيد بشدة حجم / tmp و / home و / var و / ، بغض النظر عن إجمالي مساحة القرص المتاحة ، ولكن دون لا تضع خيارات واضحة مثل / usr أو / opt بشكل منفصل. عادة ما تضع هذه الأجهزة ما تبقى من مساحة القرص التي طلبتها في وحدة تخزين "/ stuff" التي تنتهي في نهاية المطاف بتثبيت وترميز كل شيء في ، ولكن هذا بالكاد عزاء. النتيجة النهائية هي أننا غالباً ما ننفق المزيد من الوقت في خلط الملفات وإرسال رسائل التحذير عبر البريد الإلكتروني بدلاً من القيام بأي عمل حقيقي.

لا يوجد شيء "سيئ" بطبيعته حول وجود قسم واحد. على أي نظام ، يجب عليك مراقبة استخدام القرص بشكل استباقي ، واستخدام استراتيجيات التدبير المنزلي المعقولة (على سبيل المثال ، دوران السجل ، الحصص في الأدلة الرئيسية) ، لذا فإن السؤال الحقيقي الوحيد هو: كم عدد أنظمة الملفات المنفصلة التي تريد القلق بشأنها؟

لذلك أود أن أقول: ما لم تكن متأكدًا بنسبة 100٪ من قدرتك على تقسيم النظام بفعالية لحالة الاستخدام الخاصة بك ، فلا تقسم على الإطلاق.


3
2017-09-18 09:41



بالضبط. حسنًا ، ربما ينبغي أن يتم فصل البيانات بين القطاعين العام والخاص عن طريق الأذونات الموجودة في نظام الملفات وفي خدماتك. - peterh


IMHO الأمر متروك لك تماما. فكر أولاً في بعض الأشياء ، على الرغم من كونها نسبية إلى حد ما.

  • سوف يتم إدارة هذا النظام بشكل متكرر؟
  • هل سيتم استخدام هذا النظام بواسطة مستخدم واحد أو أكثر؟
  • هل سيكون هذا النظام بمثابة سطح مكتب أو خادم أو كليهما؟

بما أن المرء يستطيع أن يأخذ بعين الاعتبار (تقريبًا) أي دليل ، فيجب أن ينظر المرء بعين الاعتبار إلى ما يحتوي على بيانات متنامية إلى حد ما وما يحتوي على بيانات متنامية.

سوف يفاجأ مدى ضآلة نظام لينكس (البيانات المتنامية إلى حد ما) للتشغيل وكم تستهلكه البيانات المتنامية (عادة / var / opt / home / srv)

يعتمد ذلك أيضًا على كيفية تحديد استخدام هذا النظام الذي يحدد متطلبات التقسيم. وشملت استخدام ل LVM.

يتطلب نظام سطح المكتب النموذجي حوالي 20 جيجابايت لتثبيت الكثير من البرامج ، مع جعل كل ما تبقى مخصصًا لبيت / مخصص جيدًا. LVM يسبب الحمل الثانوي على النظام الخاص بك وفي هذه الحالة بالذات ليست ذات فائدة كبيرة. على الرغم من الآراء قد تختلف.

على الخادم ، من المحتمل أن تكون البرامج المثبتة ديناميكية مثل نظام سطح المكتب. كما أنه من الحكمة أن يكون لدينا نقاط تعليق فعلية لمكونات نظام الملفات النموذجية مثل / tmp / var / usr / home / opt / srv أوصى استخدام LVM هنا بعدم القول بأنه إلزامي.

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

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

مونوبوينت /

  • 1 جيجا بايت (في حالة استخدام نقاط تحميل منفصلة لـ / var / usr / opt / home / tmp)
  • +10 أو حتى +20 غيغابايت في حالة استخدام نظام سطح المكتب مع نظام منفصل / المنزل

إذا كنت تستخدم نقطة الاتصال / المنزل

  • تعيين كل المساحة الحرة في حالة استخدامها ، / home ne

إذا كنت تستخدم mountpoint / opt

إذا كنت تستخدم mountpoint / usr

  • هذا هو واحد خادع ويعتمد بشكل كبير على قاعدة البرامج المثبتة

إذا كنت تستخدم mountpoint / var

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

إذا كنت تستخدم mountpoint / تمة

  • النظر في tmpfs موجود ويخصص / تمة إلى ذاكرة الوصول العشوائي
  • النظر في بعض التطبيقات قد يكتب الكثير من البيانات هنا

2
2017-09-18 14:18





أولاً ، يجب أن أتساءل ، لماذا تقوم بنشر هذا السؤال هنا ، كونه عالم أحياء يتجادل مع مسؤول نظام مختص فيما يبدو بشأن النقاط الدقيقة لتقسيم القرص الصلب! (لا جريمة ، فقط أتساءل حقا لماذا لا تثق مسؤول النظام الخاص بك).

إذن ، بعض الملاحظات:

  • 1.3 TB ليس حملة كبيرة بعد الآن. 2 تيرابايت هو حجم محرك SATA قياسي أكثر أو أقل في عالم أجهزة الكمبيوتر المكتبية هذه الأيام.

  • من غير المحتمل أن يتطلب تثبيت أي Linux Distro أكثر من 100 غيغابايت. بالتأكيد ، يجب أن يتم تحديد حجم (/ الجذر) و (المبادلة) بسهولة كأرقام ذات حدود عليا عن طريق الإفراط في تحديد حجمها (الجذر) أو عن طريق إرشادات تكوين النظام (المبادلة).

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

  • ربما ينبغي عليك وضع برنامجك الخاص في وحدة منفصلة (نقطة التحميل لـ / usr / local / bin) حتى تتمكن من الحفاظ على ذلك عبر تحديثات نظام التشغيل ومناديل تقسيم الجذر. وإلا فإنك تواجه احتمال أن تضطر إلى إعادة تثبيت تطبيقات البرامج "الخاصة" الخاصة بك بعد ترقية نظام التشغيل / الإصلاح / أيا كان.

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

  • وبالمثل ، قد ترغب في أن تسأل ما هي الاستراتيجية لحماية بيانات المستخدم من خسائر بيانات أخطاء البرنامج والمستخدم. إن حفظ ملف فارغ على المسودة الرائعة للورقة البحثية الخاصة بك ، أو وجود مستخدم يقوم بكتابة الأمر الخاطئ (rm -rf * على سبيل المثال) سوف يتسبب في فقدان البيانات بنفس قدر ضياع زلزال أو حريق أو أضرار مادية أخرى. تختلف الحلول الخاصة باستعادة الملفات الفردية قليلاً (أو يمكن أن تكون!) من تلك الحلول الأكثر فائدةً لاستعادة البيانات بعد الكوارث.

  • -

2
2017-09-23 13:10





هذا يسمح بالنسخ الاحتياطي أو استعادة أو إعادة تثبيت نظام التشغيل بشكل مستقل عن بيانات المستخدم. هذا يمنحك الحرية والاستقلال والسلامة.

  1. من الأسهل الانتقال إلى توزيع Linux آخر مع الاحتفاظ بالأغلبية المطلقة لبيانات المستخدم.

  2. من السهل إعادة تحديثات buggy عن طريق تطبيق النسخ الاحتياطي لقسم نظام التشغيل (مطلوب التمهيد المزدوج). قد تكون هذه النسخة الاحتياطية قديمة إلى حد ما - يمكنك تطبيقه وتحديثه لاحقًا للإصدار المستقر عن دراية.

  3. من السهل الرجوع إلى الإصدار السابق من نظام التشغيل إذا لم تعجبك "الترقية الرئيسية" التي تم تطبيقها مؤخرًا (مطلوب التمهيد الثنائي).

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


2
2017-09-18 11:13



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


جوابي القصير هو أنه حتى سطح المكتب لا يجب أن يستخدم "قسم كبير". لقد حاولت ذلك مؤخرًا ضد رأيي الأفضل لأنه كان "مجرد كمبيوتر محمول" واستخدم برنامج التثبيت التلقائي قسمًا واحدًا ، وقمت بالنقر فوق الزر.

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

من الناحية المثالية ، وضع / على SSD ، / home على محرك أقراص ثابت ، / var على محرك أقراص ثابت ، يمكن أن يكون / usr على SSD أو HDD بناءً على عدد المرات التي تخطط فيها للترقية. / tmp إلى محرك أقراص ثابت. عادة ما أقوم بعمل قسم آخر لملفات الوسائط المشتركة مثل ملفات MP3 والأفلام مع روابط رمزية لها من منزلي / منزلي. لاحظ أن / sbin جزءًا من الجذر ، وهو / bin و / root. هذا هو الفرق بين / bin و / usr / bin ، هو / usr هي الأشياء التي قد لا تكون متاحة حتى يتم تحميل جميع محركات الأقراص الخاصة بك ، لذلك لا يمكن أن يكون الأمر mount في / usr! وعادة ما احتفظ ببعض الأقسام الإضافية لمراكز linux distros الأخرى ، مثل تلك الموجودة على أحد محركات الأقراص الصلبة الخاصة بي فقط في حالة ما إذا كنت أفسد شيئًا سيئًا حقًا ، فلدي نظام مباشر آخر جاهز للقيام بأعمال الاسترداد.

بالنسبة إلى الخادم الذي قد تحتاج إلى نقل الأشياء إليه ، أضف سعة تخزين ديناميكية ، وتحتاج إلى البقاء مستيقظًا طوال الوقت ، وبالتأكيد استخدم LVM !!!


1
2017-09-20 05:38