فصل مزود النسخ الاحتياطي لـ S3 عن مزود S3 الأساسي

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

الأسباب الرئيسية:

  • غالبًا ما تختلف متطلبات دلو S3 الذي يخزن الأصول الثابتة عن تلك التي تخزن النسخ الاحتياطي. على سبيل المثال، يعد أداء الشبكة القوي مهمًا للدلو الذي يخزن الأصول الثابتة، ولكن ليس كثيرًا للدلو الاحتياطي (بخلاف كونه موثوقًا). قد يكون الأمان مصدر قلق أكبر للدلو الاحتياطي.

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

  • يسهل تغيير المزودين لحل المشكلات مع مزودين محددين. على سبيل المثال، تعمل Scaleway S3 بشكل مثالي كدلو S3 أساسي بالنسبة لي، ومع ذلك، هناك مشكلات مع النسخ الاحتياطي لأنهم يدعمون فقط 1000 جزء من تحميلات الأجزاء المتعددة، بينما يستخدم SDK الخاص بـ AWS S3 10000 كحد أقصى. لقد قمت بحل هذه المشكلة باستخدام pups لاستبدال الحد الأقصى للأجزاء في جوهرة S3، ولكنه حل مؤقت للغاية وأحتاج إلى التحقق مما إذا كان المسار للملف قد تغير في كل تحديث/إعادة بناء. لكي أحل هذه المشكلة، سأحتاج إلى ترحيل الدلو الأساسي للتبديل إلى مزود مختلف متوافق للنسخ الاحتياطي.

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

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

على أي حال، مجرد اقتراح - شكرًا!

إعجابَين (2)