تجربة صغيرة حول النسخ الاحتياطي والتخزين

مرحبا بالجميع!

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

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

ميزات المحلية "التحجيم"

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

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

لدينا حل على الكتلة ، لماذا تحتاج النسخ الاحتياطي؟!

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

ومع ذلك ، يتحقق فقدان البيانات ليس فقط بسبب فشل المعدات في موقع واحد ، ولسبب من الأسباب لم يرغب المطور في فهم ذلك لبعض الوقت. نتيجة لذلك ، تم إصدار الإصدار الأول من البرنامج على المجتمع DBMS ، التي لم تسمح ميكانيكا النسخ الاحتياطي بتلبية متطلبات RTO / RPO أو SLA للمقاول.
بشكل عام ، أسمع هذه العبارة عن كتلة في كثير من الأحيان.

أولا ، ثم هذا!

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

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

تفريغ كل شيء لدينا؟

غالبًا ما أجد حلولاً على قواعد بيانات إدارة قواعد البيانات مثل MySQL و PostgreSQL. وغالبًا ما صادفت موقفًا حيث يتم استخدام تفريغ عادي لقاعدة البيانات في / tmp كطريقة نسخ احتياطي ، ثم إلى وسيط آخر. في الوقت نفسه ، تعد الأنظمة التي تستخدم فيها قواعد بيانات إدارة قواعد البيانات (DBMS) ضرورية للغاية للتوقف في حالة فقد البيانات ، ويتم تحميلها بشكل كبير. أنا صامت بالفعل عن مجلدات.

لسبب ما ، يقرأ عدد قليل من الأشخاص الوثائق الخاصة بهذه المنتجات ولا يعرفون أن هناك طرقًا وحلولًا بديلة لإنشاء نُسخ احتياطية من قواعد بيانات إدارة قواعد البيانات هذه. MySQL Enterprise Backup لـ MySQL و pg_basebackup ( pg_start_backup ، pg_stop_backup ) على التوالي في PostgreSQL ، على التوالي. أو يعرف ، لكنه طار من رأسه. على الرغم من أن هذه الحلول ليست أكثر تعقيدًا وأسرع بكثير. أسرع النسخ الاحتياطي ، واستعادة أسرع ، أسرع اختبار.

من فضلك لا تطلق النار على عازف البيانو.
إنه يبذل قصارى جهده.
أوسكار فينغال أوفلاهرتي ويلز وايلد