النسخ الاحتياطي، لا الإرهاق: ما أطلقناه في Postgresus 2.0 (وما تخلينا عنه)

\ مرت 6 أشهر منذ الإصدار الأول من Postgresus. خلال هذا الوقت، تلقى المشروع 247 عملية دمج، وميزات جديدة، بالإضافة إلى ~2.8 ألف نجمة على GitHub و~42 ألف تنزيل من Docker Hub. نمت أيضًا مجتمع المشروع، وهناك الآن 13 مساهمًا و90 شخصًا في مجموعة تيليجرام ID.

في هذه المقالة سأغطي:

• ما الذي تغير في المشروع خلال ستة أشهر؛
• ما هي الميزات الجديدة التي ظهرت
• ما هي الخطط القادمة.

\

ما هو Postgresus؟

لمن يسمعون عن المشروع لأول مرة: Postgresus هي أداة مفتوحة المصدر لنسخ PostgreSQL الاحتياطي مع واجهة مستخدم. تقوم بتشغيل النسخ الاحتياطي المجدول لقواعد بيانات متعددة، وتحفظها محليًا أو في وحدات تخزين خارجية، وتخطرك عند اكتمال النسخ الاحتياطي أو فشله.

يتم نشر المشروع بأمر واحد في Docker. يمكن تثبيته عبر نص برمجي للشل، أمر Docker، docker-compose.yml والآن عبر Helm لـ Kubernetes. المزيد حول طرق التثبيت.

بجانب الميزة الرئيسية "إنشاء نسخ احتياطية"، يمكن للمشروع:

• تخزين النسخ الاحتياطية محليًا، في S3، CloudFlare R2، Google Drive، Azure Blob Storage و NAS. مزيد من التفاصيل هنا.
• إرسال إشعارات الحالة إلى Slack، Discord، تيليجرام ID، MS Teams، عبر البريد الإلكتروني الاشتراك وإلى webhook قابل للتكوين. مزيد من التفاصيل هنا.
• فصل قواعد البيانات حسب مساحات العمل، ومنح الوصول للمستخدمين الآخرين وحفظ سجلات التدقيق. مزيد من التفاصيل هنا.
• تشفير النسخ الاحتياطية وبيانات الاعتماد. مزيد من التفاصيل هنا.
• العمل مع قواعد البيانات المستضافة ذاتيًا وقواعد البيانات المُدارة في السحابة.

الموقع الإلكتروني - https://postgresus.com/

GitHub - https://github.com/RostislavDugin/postgresus (سأكون ممتنًا لنجمة ⭐️)

تبدو واجهة المشروع كما يلي:

فيديو نظرة عامة: https://www.youtube.com/watch?v=1qsAnijJfJE

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

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

ميزات جديدة ظهرت في الإصدار 2.0

تغير الكثير خلال هذه الأشهر الستة. تم تحسين المشروع في أربعة اتجاهات:

• توسيع الوظائف الأساسية؛
• تحسين تجربة المستخدم؛
• ظهور قدرات جديدة للفرق (مسؤولي قواعد البيانات، DevOps، الفرق، المؤسسات)؛
• تحسين الحماية والتشفير لتلبية متطلبات المؤسسات.

دعونا نستعرض كل واحدة.

1) فحص صحة قاعدة البيانات

بجانب النسخ الاحتياطي، يراقب Postgresus الآن صحة قاعدة البيانات: يظهر وقت التشغيل وينبهك إذا كانت قاعدة البيانات غير متاحة.

يمكن تعطيل فحص الصحة وتكوينه.

إذا كانت قاعدة البيانات غير متاحة - سيرسل النظام إشعارًا بذلك.

2) مصادر جديدة لتخزين النسخ الاحتياطية وإرسال الإشعارات

في البداية، كان بإمكان Postgresus تخزين النسخ الاحتياطية محليًا وفي S3 فقط. تمت إضافة Google Drive، CloudFlare R2، Azure Blob Storage و NAS. تشمل الخطط إضافة FTP وربما SFTP و NFS.

بالنسبة للإشعارات، كان لدى المشروع في البداية تيليجرام ID والبريد الإلكتروني (SMTP). الآن يتم دعم Slack و Discord و MS Teams و webhooks أيضًا. علاوة على ذلك، يتم الآن تكوين webhooks بمرونة للاتصال بمنصات مختلفة:

3) مساحة العمل وإدارة المستخدم

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

• عرض فقط (يمكن عرض سجل النسخ الاحتياطي، تنزيل ملفات النسخ الاحتياطي)؛
• تحرير (يمكن إضافة\حذف\تعديل قواعد البيانات بالإضافة إلى القراءة).

وبالتالي، يمكنك الآن فصل قواعد البيانات:

• قواعد بيانات العميل X؛
• قواعد بيانات الشركة الناشئة Y؛
• قواعد بيانات الفريق Z؛

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

ظهرت أيضًا سجلات التدقيق:

إذا قرر شخص ما حذف جميع قواعد البيانات أو لسبب ما قام بتنزيل جميع النسخ الاحتياطية لجميع قواعد البيانات - سيكون هذا مرئيًا 🙃

4) التشفير والحماية

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

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

لذلك، أصبح تشفير وأمان المشروع بأكمله الأولوية الرئيسية لـ Postgresus. تعمل الحماية الآن على ثلاثة مستويات، وهناك صفحة وثائق مخصصة لهذا.

1) تشفير جميع كلمات المرور والأسرار

يتم تخزين جميع كلمات مرور قاعدة البيانات ورموز Slack وبيانات اعتماد S3 مشفرة في قاعدة بيانات Postgresus. يتم فك التشفير فقط عند الحاجة. يتم تخزين المفتاح السري في ملف منفصل عن قاعدة البيانات، لذلك حتى إذا اخترق شخص ما قاعدة بيانات Postgresus (والتي ليست معرضة خارجيًا على أي حال) - فلن يتمكنوا من قراءة أي شيء. يستخدم التشفير AES-256-GCM.

2) تشفير ملفات النسخ الاحتياطي

يتم الآن أيضًا تشفير ملفات النسخ الاحتياطي (اختياريًا، ولكن التشفير ممكّن افتراضيًا). إذا فقدت ملفًا أو حفظته في S3 العام - فهذا ليس مخيفًا بعد الآن.

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

يتم التشفير في وضع التدفق، ويستخدم AES-256-GCM هنا أيضًا.

3) استخدام مستخدم للقراءة فقط للنسخ الاحتياطي

على الرغم من النقطتين الأوليين، لا توجد طريقة حماية 100٪. لا يزال هناك احتمال ضئيل أن:

• سيتم اختراق الخادم الخاص بك بالكامل، وسيحصلون على المفتاح السري وعنوان IP الشرعي للوصول إلى قاعدة البيانات؛
• سيقوم المتسلل بطريقة ما بفك التشفير كلمات المرور في قاعدة بيانات Postgresus الداخلية ومعرفة كلمة مرور قاعدة البيانات الخاصة بك؛
• أو، الأسوأ من ذلك، لن يكون متسللًا بل شخصًا من الداخل؛
• وسيفسدون قاعدة البيانات الخاصة بك، بعد أن حذفوا النسخ الاحتياطية مسبقًا.

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

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

إليك كيف يقدم Postgresus:

يقدم بإصرار شديد:

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

5) الضغط افتراضيًا، الأكثر مثالية

قدم الإصدار الأول من Postgresus جميع خوارزميات الضغط التي يدعمها PostgreSQL: gzip و lz4 و zstd، مع مستويات ضغط من 1 إلى 9. بصراحة، لم أفهم حقًا لماذا قد يحتاج أي شخص إلى كل هذه الخيارات. لقد اخترت فقط gzip بمستوى 5 كما بدا أنه حل وسط معقول.

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

لذلك الآن افتراضيًا لجميع النسخ الاحتياطية يتم تعيين zstd بمستوى ضغط 5، إذا كان إصدار PostgreSQL 16 وأعلى. إذا كان أقل - لا يزال gzip (بالمناسبة، شكرًا مرة أخرى للمساهمين لدعم PG 12). إليك zstd 5 مقارنة بـ gzip 5 (إنه في الأسفل):

في المتوسط، يتم ضغط النسخ الاحتياطية ~8 مرات بالنسبة لحجم قاعدة البيانات الفعلي.

6) دعم Kubernetes Helm

هذا سريع - أضفنا دعم k8s الأصلي مع تثبيت Helm. يمكن للفرق التي تشغل k8s في السحابة الآن نشر Postgresus بشكل أسهل. ساعد ثلاثة مساهمين في هذه الميزة.

7) الوضع الداكن

أنا لست من محبي الوضع الداكن حقًا. لكن كانت هناك العديد من الطلبات، لذلك أضفت واحدًا (~~شكرًا لـ Claude على المساعدة وعين المصمم~~). بشكل مفاجئ، تبين أنه أفضل من الوضع الفاتح وأصبح الافتراضي. لقد أعدت تصميم الموقع من الفاتح إلى الداكن - كان يبدو جيدًا جدًا.

قبل:

بعد:

8) التخلص من النسخ الاحتياطية التزايدية و PITR (استعادة النقطة الزمنية)

أولاً، بعض السياق:

• النسخ الاحتياطي المنطقي - هو عندما يقوم PostgreSQL نفسه بتصدير بياناته (إلى ملف أو مجموعة من الملفات).
• النسخ الاحتياطي المادي - هو عندما نتصل بالقرص الصلب لـ PostgreSQL ونقوم بعمل نسخة من ملفاته.
• النسخ الاحتياطي التزايدي مع دعم PITR - هو نسخة احتياطية مادية + سجل التغيير (WAL)، منسوخ من القرص أو عبر بروتوكول النسخ المتماثل.

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

لذلك بدأت العمل عليها. لكن ثم واجهت الواقع:

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

للاسترداد - لا يوجد خيار لعدم الاتصال بالقرص مع قاعدة البيانات. لاستعادة من نسخة احتياطية تزايدية، تقوم أداة النسخ الاحتياطي ببساطة باستعادة مجلد pgdata (بشكل أكثر دقة، جزء منه).

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

• معظم السحابات (AWS، Google، Selectel) لن تعمل مع النسخ الاحتياطية التزايدية الخارجية، إذا كانت تتطلب الوصول إلى القرص. من الناحية النظرية، مع بعض الحلول البديلة، عبر النسخ المتماثل - سيعملون. لكن استعادة مثل هذه النسخة الاحتياطية إلى سحابة مُدارة لن تعمل على أي حال.
• توفر جميع السحابات نسخًا احتياطية تزايدية بشكل افتراضي. بشكل عام، هذا هو أحد الأسباب التي تجعلها مدفوعة. وحتى هم عادة لا يسمحون بالاسترداد ثانية بثانية أو إلى لحظة معاملة محددة. وإذا لم تكن في السحابة - فمن غير المرجح أكثر أن يكون مشروعك حرجًا بما يكفي ليتطلب مثل هذه الدقة.

لذلك، إذا كان Postgresus يقوم بعمل نسخة احتياطية من قاعدة بيانات مُدارة - فيكفي القيام بذلك مرة واحدة تقريبًا في الأسبوع. فقط في حالة حدوث طارئ غير متوقع أو إذا كانت السحابة لا تسمح بتخزين النسخ الاحتياطية لفترة كافية. وإلا، اعتمد على النسخ الاحتياطية التزايدية الخاصة بالسحابة.

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

ولكن إذا كنت بنكًا أو مطور قاعدة بيانات مُدارة، فأنت بحاجة حقًا إلى أفضل تكوين للنسخ الاحتياطي لعشرات ومئات التيرابايت من البيانات. هنا لن يتفوق Postgresus أبدًا على النسخ الاحتياطية المادية من WAL-G أو pgBackRest من حيث راحة وحدة التحكم والكفاءة لقواعد البيانات ذات الحجم بالتيرابايت وأكثر. ولكن، في رأيي، هذه هي بالفعل أدوات متخصصة لمثل هذه المهام، صنعها عباقرة ومشرفو PostgreSQL نفسه.

في رأيي، النسخ الاحتياطية التزايدية مطلوبة حقًا في حالتين:

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

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

9) العديد من التحسينات الصغيرة

النقاط أعلاه بعيدة كل البعد عن كل شيء. 80٪ من العمل عادة لا يكون مرئيًا. من رأسي، إليك قائمة قصيرة:

• تحسين التخزين المؤقت وذاكرة الوصول العشوائي. لم يعد Postgresus يحاول تخزين كل ما يرسله pg_dump مؤقتًا أثناء انتظار S3 للحاق به (التنزيل من قاعدة البيانات عادة ما يكون أسرع من التحميل إلى السحابة). استخدام ذاكرة الوصول العشوائي محدود الآن بـ 32 ميجابايت لكل نسخة احتياطية متوازية.
• تحسينات مختلفة في الاستقرار وإصلاحات الأخطاء الصغيرة.
• إضافة SMTP بدون اسم مستخدم وبدون كلمة مرور. لم أكن أعرف حتى أن هذا يحدث...
• إضافة مواضيع لإرسال إشعارات إلى مجموعات تيليجرام ID.
• ظهرت الوثائق!
• دعم PostgreSQL 12.

والكثير غير ذلك.

ما الذي لم ينجح؟

بالطبع، لا ينجح كل شيء ويجب التخلي عن بعض الأشياء. أنا أبني Postgresus في وقت فراغي، الذي بالكاد موجود. لذلك لا يمكنني أن أنتشر كثيرًا أو أعقد تجربة المستخدم بميزات غير ضرورية. الكثير من الميزات سيء أيضًا.

1) مراقبة موارد قاعدة البيانات الكاملة

أردت أن أجعل Postgresus أداة مراقبة PostgreSQL أيضًا. بما في ذلك موارد النظام للخادم الذي يشغل PostgreSQL:

• وحدة المعالجة المركزية
• ذاكرة الوصول العشوائي
• ROM
• سرعة الإدخال/الإخراج والحمل

لقد صنعت حتى الأساس لجمع المقاييس (أي) ونموذج للرسوم البيانية:

اتضح أن PostgreSQL يكشف فقط عن استخدام ذاكرة الوصول العشوائي ومقاييس الإدخال/الإخراج بشكل افتراضي.

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

ثم أدركت أنه يجب تخزين المقاييس في VictoriaMetrics أو على الأقل TimescaleDB، وليس في PostgreSQL الخاص بـ Postgresus، مما سيعقد بناء الصورة.

في النهاية، ستضيف هذه الميزة غير الأساسية:

• تعقيد كبير في الكود، مما يعني صيانة أصعب؛
• المزيد من متطلبات بناء الصورة (مكونات إضافية)؛
• تجربة مستخدم معقدة (كما قلت، الكثير من الميزات سيء)؛
• ~~تحديد غير واضح للموقع: هل نحن أداة نسخ احتياطي، أداة مراقبة، أم نحاول فعل كل شيء؟~~

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

2) وحدة تحكم SQL

أردت أيضًا إضافة وحدة تحكم SQL. بما أن Postgresus متصل بالفعل بقاعدة البيانات، لماذا لا نقوم بتشغيل الاستعلامات مباشرة منه؟ سيكون مريحًا - لا حاجة لفتح PgAdmin أو DataGrip أو DBeaver في كل مرة.

لم أجد أبدًا وقتًا للعمل عليه، فقط خططت. بدأ أحد المساهمين في الميزة و قدم PR. ولكن كما هو متوقع مع الميزات المعقدة، ظهرت العديد من المتطلبات والحالات الحدية:

• الحاجة إلى إضافة دعم بناء جملة SQL؛
• إضافة الإكمال التلقائي والتلميحات؛
• جعل التحميل الكسول بحيث لا تأتي حتى 100 ميجابايت من الصفوف إلى المتصفح؛
• إضافة عدة تصديرات على الأقل إلى CSV و XLSX.

هذا في الأساس مشروع كامل بحد ذاته، وليس مجرد علامة تبويب واحدة.

قررنا إسقاط الميزة وتوفير الجهد. اتضح أن هذا كان القرار الصحيح، لأننا أضفنا أدوارًا للقراءة فقط لا تسمح بـ INSERT، UPDATE و DELETE على أي حال.

الخلاصة

هذه هي الرحلة التي قام بها Postgresus في ستة أشهر. نما من مشروع متخصص إلى أداة على مستوى المؤسسات تساعد كلاً من المطورين الفرديين وفرق مسؤولي قواعد البيانات بأكملها (فوجئت بمعرفة هذا بعد ~2 شهر فقط من الإصدار الأول، بالمناسبة). أنا سعيد حقًا لأن آلاف المشاريع والمستخدمين يعتمدون على Postgresus.

المشروع لا يتوقف هنا. هدفي الآن هو جعل Postgresus أداة النسخ الاحتياطي PostgreSQL الأكثر ملاءمة في العالم. هناك تراكم كبير من الميزات والتحسينات القادمة تدريجيًا.

أولوياتي الرئيسية لا تزال:

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

إذا أعجبك المشروع أو وجدته مفيدًا - سأكون ممتنًا لـ نجمة على GitHub أو مشاركته مع الأصدقاء ❤️

\