ملخص
- قيمة Falconstor Software تُقيم بأفضل شكل من خلال سجل الاسترداد: ما إذا كانت فهارس النسخ الاحتياطي، ووسائط الشريط الافتراضية، وحالة النسخ المتماثل، والنسخ غير القابلة للتغيير، وإجراءات المشغل يمكن أن تنتج استردادًا مقبولًا تحت ضغط الفشل أو برامج الفدية أو ضغط الترحيل.
- ملاءمة StorSafe تكون أقوى حيث تحتاج المؤسسات ومزودو الخدمات المدارة وفرق IBM Power إلى الحفاظ على عمليات النسخ الاحتياطي المألوفة مع تقليل تكلفة التخزين وإضافة الاحتفاظ السحابي أو نقل أعباء العمل، لكن المنتج لا يلغي الحاجة إلى تدريبات الاسترداد وانضباط الفهرس وتخطيط الشبكة وحدود الدعم وحوكمة التكلفة.
سجل الاسترداد هو المنتج الحقيقي
برامج النسخ الاحتياطي تخلق الراحة فقط حتى يبدأ الاسترداد. يمكن أن تنتهي مهمة مجدولة، ويمكن أن يزيل هدف التخزين تكرار البيانات، ويمكن أن تظهر نسخة خارج الموقع في وحدة تحكم، ويمكن أن يبلغ سحابة تخزين عن كائنات سليمة. لا شيء من تلك الحقائق وحدها يثبت أن الشركة يمكنها إعادة تشغيل النظام الذي تعتمد عليه. في اللحظة المهمة، يحتاج الفريق إلى سجل استرداد: مجموعة من إدخالات الفهرس، والوسائط الافتراضية، ونقاط تفتيش النسخ المتماثل، وبيانات الاعتماد، ومسارات الشبكة، وخطوات الاسترداد، وملاحظات التحقق، والقبول التجاري التي تظهر أن عبء عمل معين يمكن إعادته إلى حالة قابلة للاستخدام.
هذا هو الإطار الذي يجب من خلاله الحكم على Falconstor Software. لا تبيع الشركة التطبيق الأساسي، أو قاعدة البيانات، أو منصة السحابة، أو برنامج الاستجابة للحوادث بالكامل. إنها تبيع برامج وخدمات تعمل على تحسين حماية البيانات، وتجعل تدفقات النسخ الاحتياطي الشبيهة بالشريط افتراضية، وتزيل تكرار صور النسخ الاحتياطي، وتنسخ البيانات المحمية، وتضع نسخ الاحتفاظ على تخزين الكائنات، وتساعد الفرق على ربط الأنظمة المحلية بالبيئات السحابية أو المدارة. السؤال ليس ما إذا كان Falconstor يمكنه استقبال بيانات النسخ الاحتياطي. السؤال هو ما إذا كان مكانه في السلسلة يحافظ على الحقيقة الكافية للعميل لإثبات الاسترداد.
هذا التمييز مهم لأن Falconstor يعمل في بيئات حيث نظام النسخ الاحتياطي غالبًا ما يكون قديمًا وإجرائيًا وصعب التغيير سياسيًا. IBM i وAIX وLinux على IBM Power وعمليات الشريط طويلة الأمد وعادات BRMS وروابط Fibre Channel أو iSCSI وتخزين الكائنات السحابية ومزودي الخدمات المدارة وتمارين التعافي من الكوارث لا تتصرف مثل نشر برنامج كخدمة في حقل جديد. عملية النسخ الاحتياطي ليست مجرد تكنولوجيا. إنها طقوس إنتاج متكررة يملكها مسؤولون يعرفون استثناءات النظام وجدول نهاية الشهر ونافذة الشبكة وقاعدة الاحتفاظ واصطلاح تسمية الشريط والمسؤول التنفيذي الذي سيسأل عما إذا كانت أحدث نسخة نظيفة.
فرصة Falconstor هي تحديث هذه الطقوس دون إجبار كل عميل على إعادة كتابتها. يتم تقديم StorSafe كبرنامج يمكن تشغيله في بيئات سحابية أو مادية أو افتراضية؛ والعمل مع برامج النسخ الاحتياطي الحالية؛ ومحاكاة مكتبات الأشرطة؛ وتقليل بيانات النسخ الاحتياطي المتكررة من خلال إزالة التكرار؛ ودعم الأرشفة طويلة الأجل لتخزين الكائنات؛ ومساعدة فرق IBM Power على استخدام أهداف سحابية للنسخ الاحتياطي والتعافي من الكوارث والترحيل. يضيف StorSight إدارة مركزية عبر مثيلات StorSafe. يوسع Habanero نفس المنطق إلى خدمة حماية خارج الموقع مُدارة لعملاء IBM Power الذين يحتاجون إلى نسخ خارج الموقع آمنة دون نشر وتشغيل كل البنية التحتية الأساسية بأنفسهم.
الجاذبية واضحة. قد لا يرغب بنك أو مصنع أو مشغل رعاية صحية أو مزود خدمة مُدارة أو مؤسسة إقليمية تدير أعباء عمل IBM Power في استبدال العمود الفقري التشغيلي الذي حماية أنظمتها لسنوات. قد لا يزال يحتاج إلى مرونة أفضل ضد برامج الفدية، وتكلفة تخزين أقل، وطريق إلى IBM Power Virtual Server، واحتفاظ خارج الموقع أسرع، أو طريقة للتوقف عن معاملة الشريط المادي كالإجابة الوحيدة. عرض Falconstor هو أنه يمكنه الجلوس خلف العملية، واستقبال البيانات بشكل مألوف، وتقليصها، ونسخها، ونقلها، وجعلها قابلة للإدارة عبر الأهداف المحلية والسحابية.
الخطر واضح أيضًا. سلسلة الاسترداد قوية فقط بقدر أقوى افتراض غير مختبر فيها. إزالة التكرار يمكن أن توفر السعة ولكنها تجعل سلامة المستودع وتوفر الفهرس أمرًا حاسمًا. الشريط الافتراضي يمكن أن يحافظ على ألفة العملية ولكنه يمكن أيضًا أن يحافظ على العادات القديمة التي لم تُختبر بشكل كافٍ. الاحتفاظ السحابي يمكن أن يقلل عبء الأجهزة ولكنه يقدم قرارات الشبكة وتخزين الكائنات والخروج والهوية والمنطقة. الثبات يمكن أن يحمي نسخة من التغيير ولكنه لا يستطيع أن يقرر ما إذا كانت النسخة ملوثة بالفعل أو غير كاملة أو مفهرسة بشكل سيئ أو تفتقد اعتمادًا.
الخدمة المُدارة يمكن أن تقلل عبء الموظفين ولكنها تنقل الثقة إلى شروط الخدمة والشفافية التشغيلية وجودة التصعيد واستمرارية البائع.
لذلك لا ينبغي تقييم Falconstor كبائع نسخ احتياطي عام. يجب تقييمه كشركة يتم إدخال برامجها في الميل الأخير بين النسخة المخزنة والاسترداد المقبول. الأدلة المهمة هي تشغيلية: كيف تدخل صور النسخ الاحتياطي إلى النظام، وكيف تبقى الفهارس قابلة للاستخدام، وكيف يتم الإشراف على اكتمال النسخ المتماثل، وكيف يتم جعل النسخ خارج الموقع غير قابلة للتغيير أو محمية بطريقة أخرى، وكيف يثبت المسؤولون مسارات الاسترداد، وكيف تتجنب عمليات الترحيل التوقف، وكيف تتصرف التكاليف عند حساب التخزين المُزال التكرار وتخزين كائنات السحابة ونقل الشبكة والدعم ووقت الموظفين معًا.
ما الذي يقوم Falconstor بأتمتته فعليًا
الأتمتة الأساسية لـ Falconstor ليست "القيام بالنسخ الاحتياطي" بشكل مجرد. في العديد من بيئات العملاء، تطبيق النسخ الاحتياطي موجود بالفعل. قد يكون جدولة المهام وعملية حفظ قاعدة بيانات وروتين BRMS وسياسة الشريط وقاعدة الاحتفاظ وأمر الاستعادة مضمنة بالفعل في سنوات من العمليات. تبدأ أتمتة Falconstor حيث تحتاج تدفقات النسخ الاحتياطي هذه إلى هدف أفضل ومسار أكثر أمانًا لقابلية الاسترداد.
المهمة الأولى هي الاستيعاب. يمكن لـ StorSafe أن يقدم نفسه كمكتبة أشرطة افتراضية أو يستقبل بيانات النسخ الاحتياطي من التطبيقات والأنظمة الحالية. بالنسبة لمستخدمي IBM Power، هذا مهم لأن العديد من العمليات التشغيلية بُنيت حول دلالات الشريط. الهدف من VTL ليس الحنين إلى الماضي. إنه تقليل المخاطر. إذا كان مسؤول النسخ الاحتياطي يمكنه الاحتفاظ بعملية حفظ معروفة، وتوجيهها إلى هدف برمجي، وتجنب إعادة تدريب كل مشغل في وقت واحد، فإن عبء التحديث يكون أقل. هذا قوي تجاريًا، خاصة في الفرق الصغيرة والمتوسطة حيث قد يحمل مسؤول أو اثنان من ذوي الخبرة معظم معرفة الاستعادة.
المهمة الثانية هي تقليل البيانات. تدفقات النسخ الاحتياطي غالبًا ما تكون متكررة للغاية. تحتوي النسخ اليومية على الكثير من نفس نظام التشغيل والتطبيق وقاعدة البيانات والسجل ومحتوى الملف. تدعي Falconstor قدرة كبيرة على إزالة التكرار، مع وصف المواد الرسمية المتكررة لتقليل البيانات بنسبة تصل إلى 95 بالمائة في ظل ظروف مناسبة. القراءة المفيدة لهذا الادعاء ليست أن كل ممتلكات ستحققه. إنها أن إزالة التكرار مركزي في الحالة الاقتصادية لـ Falconstor. إذا كان العميل يمكنه تقليل الحجم المنقول إلى التخزين الثانوي أو تخزين كائنات السحابة، فقد يقلل من تكلفة السعة، والطلب على النطاق الترددي، وضغط نافذة النسخ الاحتياطي، ونفقات الاحتفاظ طويلة الأجل.
المهمة الثالثة هي الحركة. النسخة المحمية التي تبقى بجانب نظام الإنتاج معرضة لفشل الموقع ويمكن أن تكون معرضة لوصول المهاجم. تؤكد مواد Falconstor على النسخ المتماثل والحماية خارج الموقع والأرشفة السحابية واعتماد السحابة الهجينة. في بيئات IBM Power، يعني ذلك غالبًا نقل بيانات النسخ الاحتياطي المُزالة التكرار نحو IBM Cloud Object Storage أو PowerVS أو موقع آخر مدعوم سحابيًا أو إعداد خدمة مُدارة. هذا هو المكان الذي يصبح فيه سجل الاسترداد أكثر تعقيدًا. لم يعد كافيًا معرفة أن مهمة النسخ الاحتياطي انتهت.
يجب أن يعرف الفريق أي نسخة تم نقلها، وما إذا كان النسخ المتماثل قد اكتمل، وما إذا كان الهدف قابلاً للوصول، وما إذا كانت سياسة الاحتفاظ قد طُبقت، وما إذا كان مسار الاستعادة قد تم السير فيه عائدًا من البيئة الهدف.
المهمة الرابعة هي الإدارة. يهدف StorSight إلى توحيد الرؤية عبر مثيلات StorSafe، بما في ذلك الإدارة وإعداد التقارير والتحليلات والتنبؤ والتنبيه وعناصر التحكم بنمط الإيجار. هذا مهم لأن أهداف الحماية المتعددة يمكن أن تصبح غير مرئية تشغيليًا. يمكن أن يخلق موقع VTL واحد في موقع أساسي وآخر في PowerVS ومستودع تخزين كائنات وخدمة مُدارة من قبل مزود خدمة مدارة والعديد من تطبيقات النسخ الاحتياطي ممتلكات مجزأة. لا يثبت سطح الإدارة الواحد قابلية الاسترداد، لكنه يمكن أن يقلل من تكلفة الإشراف على معرفة مكان وجود حالة النسخ الاحتياطي والاحتفاظ.
المهمة الخامسة هي تعزيز الاحتفاظ. تضع Falconstor التخزين غير القابل للتغيير والشريط الافتراضي بنمط WORM والتشفير وتكامل تخزين كائنات السحابة كجزء من التعافي من برامج الفدية. أفضل تفسير هو محدد: يمكن لهذه الضوابط أن تساعد في الحفاظ على نقطة استرداد من العبث أو الحذف لاحقًا. هي لا تحدد بذاتها جاهزية الغرفة النظيفة أو تسلسل إعادة البناء أو استرداد الهوية أو اتساق التطبيق أو ما إذا كان المسؤولون سيعرفون أي نقطة زمنية نظيفة. الحالة المستردة هي أثر تجاري، وليس أثر تخزين فقط.
المهمة السادسة هي الترحيل. تمنح علاقة IBM مع Falconstor ومواد المنتج دورًا مركزيًا للترحيل. العميل الذي ينقل أعباء عمل IBM i أو AIX أو Linux إلى PowerVS أو سياق سحابي مدعوم آخر قد يحتاج إلى حمل كميات كبيرة من البيانات المحمية ووسائط النسخ الاحتياطي التاريخية دون تحويل النقل إلى مشروع استشارات مخصص. يمكن للشريط الافتراضي والنسخ المتماثل المُزال التكرار أن يجعل هذا المسار أكثر تنظيمًا. لكن الترحيل هو أصعب نوع من اختبار الاسترداد لأن البيئة الهدف تختلف عن المصدر. يتطلب الترحيل الناجح ليس فقط نقل البيانات ولكن قابلية التشغيل ووصول الشبكة واتساق التطبيق والهوية وجداول الدفعات والاعتماديات الطرفية والمراقبة وتخطيط التراجع.
تحدد هذه المهام الست القيمة العملية لـ Falconstor. إنها أقل بديلاً لانضباط النسخ الاحتياطي الكامل وأكثر كطبقة تحديث لسلاسل الاسترداد القديمة والهجينة. كلما عرف العميل بالفعل عمليات الحفظ الخاصة به واعتماديات الاستعادة والتزامات الامتثال، كلما زاد استخدام Falconstor كنقطة رافعة. وكلما قل معرفة العميل بهذه الأشياء، زاد خطر أن يصبح Falconstor نظامًا آخر يُبلغ باللون الأخضر بينما يظل سجل الاسترداد الفعلي غير مكتمل.
لماذا يجعل IBM Power الزاوية أكثر حدة
قصة السوق الحالية لـ Falconstor مرتبطة بشدة بـ IBM Power. ركزت الشركة على IBM Power وPowerVS وIBM Cloud Object Storage ومزودي الخدمات المدارة والتسليم عبر القنوات في رسائلها الأخيرة للمنتجات والمستثمرين. تصف وثائق IBM الخاصة بالشريك والسحابة أيضًا Falconstor VTL كحل نسخ احتياطي محسّن وإزالة تكرار لسياق Power Virtual Server، مع محاكاة مكتبة الأشرطة وأرشفة S3 السحابية وإزالة التكرار العالمية والنسخ المتماثل وقدرات أرشيف الحاويات.
هذا التركيز ليس عرضيًا. ممتلكات IBM Power غالبًا ما تكون حرجة للمهمة وطويلة العمر ومحافظة تشغيليًا. قد تدير أعباء العمل المصرفية الأساسية والتأمين والتوزيع والتصنيع والتجزئة والخدمات اللوجستية أو الرعاية الصحية. كثير منهم لا يحاولون أن يصبحوا سحابيين أصليين بالمعنى العصري. إنهم يحاولون الحفاظ على موثوقية الأنظمة التي تعمل بالفعل مع منح أنفسهم حماية خارج الموقع أفضل وتعافيًا من الكوارث أكثر مرونة وطريقًا إلى سعة سحابية عندما يتطلب تحديث الأجهزة أو تغيير مركز البيانات أو خطة استمرارية الأعمال ذلك.
هذا هو بالضبط المكان الذي يصبح فيه عدسة سجل الاسترداد مفيدة. في تطبيق سحابي بسيط، قد يتم تأطير تحديث النسخ الاحتياطي حول اللقطات أو قواعد البيانات المُدارة أو النسخ المتماثل المدمج للخدمة. في بيئة IBM Power، الواقع التشغيلي مختلف. قد يتضمن عبء العمل عمليات حفظ IBM i وروتينات BRMS وأنظمة ملفات AIX ونقاط اتساق خاصة بالتطبيق وتوقعات احتفاظ شبيهة بالشريط ومسؤولين أمضوا سنوات في استخدام إجراء استعادة معين. يمكن أن يكون استبدال الطريقة بأكملها أكثر خطورة من تحسين الهدف وراءها.
ادعاء Falconstor المتعلق بـ IBM ليس فقط حول التوافق التكنولوجي. إنه حول استمرارية العملية. يمكن تقديم StorSafe كهدف شريط افتراضي بحيث تبقى عمليات النسخ الاحتياطي والاستعادة الحالية مألوفة. هذا مهم عندما تكون سعة الموظفين محدودة وعندما لا تستطيع المؤسسة تحمل فترة إعادة تدريب مطولة. كما أنه مهم لمزودي الخدمات المدارة الذين يحتاجون إلى أنماط قابلة للتكرار عبر ممتلكات عملاء متعددة بدلاً من الهندسة الفردية لكل عميل.
يمكن أن تصبح نفس استمرارية العملية نقطة ضعف إذا كانت تحمي الانضباط السيئ. إذا لم يختبر الفريق إجراءات الاستعادة بانتظام، فإن تقديم VTL أكثر كفاءة لا يسد هذه الفجوة. إذا كان مشغلو النسخ الاحتياطي لا يستطيعون تحديد الخدمة التجارية التي تعتمد على مجموعة الأشرطة أو حفظ قاعدة البيانات أو تكوين التطبيق أو إدخال DNS أو موفر الهوية، فإن إزالة التكرار لن تنشئ هذه الخريطة. إذا افترض دليل استعادة التشغيل وجود مكتبة أشرطة محلية ولكن هدف الاستعادة الجديد هو بيئة PowerVS مستضافة سحابيًا، يجب على الفريق التحقق من أن الخطوات القديمة لا تزال تنتج نظامًا قابلاً للاستخدام.
لهذا السبب فإن سجل الاسترداد المقبول هو اختبار أفضل من تغطية النسخ الاحتياطي. تسأل تغطية النسخ الاحتياطي عما إذا كانت الأنظمة الصحيحة مضمنة. يسأل سجل الاسترداد عما إذا كانت خدمة مسماة يمكن استعادتها من نقطة مسماة، في مكان مسمى، مع بيانات اعتماد معروفة، واعتماديات معروفة، ووقت منقضي مُقاس، وقبول تجاري موثق. يمكن لـ Falconstor أن يساعد في خلق الظروف التقنية لهذا السجل. لا يمكنه استبدال مسؤولية العميل في الحفاظ عليه.
IBM Power أيضًا يزيد من حدة اقتصاديات الوحدة. تعتمد قيمة مشروع تحديث النسخ الاحتياطي على التكلفة التي تم تجنبها لتحديث الأجهزة والتعامل مع الأشرطة ونمو التخزين والتوقف وعمل ترحيل السحابة وفشل الامتثال وفوضى التعافي من برامج الفدية. إذا قلل StorSafe من كمية بيانات النسخ الاحتياطي المخزنة أو المنقولة، ودعم عمليات الحفظ الحالية، وفتح مسارًا مدعومًا إلى PowerVS، فقد تكون الاقتصاديات مقنعة. إذا كانت البيئة صغيرة أو مقاومة للتغيير أو مختبرة بشكل خفيف أو قادرة على استخدام آليات نسخ احتياطي أبسط، فقد يكون من الصعب تبرير نفس الترخيص والتكاليف التشغيلية.
تشير الرسائل المالية لـ Falconstor لعامي 2025 و2026 إلى شركة تتحول نحو الإيرادات المتكررة واعتماد مزودي الخدمات المدارة ونمو الإيرادات السنوية المتكررة للسحابة الهجينة. هذا مهم لأن العملاء الذين يقيمون البنية التحتية للاسترداد يقيمون أيضًا استمرارية البائع. منصة الاسترداد ليست أداة يمكن التخلص منها. تصبح جزءًا من أدلة التدقيق وتصعيد الدعم والذاكرة العضلية التشغيلية وتخطيط التجديد. قد يؤدي تحرك Falconstor نحو النماذج المتكررة والتي يقودها مزودو الخدمات المدارة إلى تحسين القدرة على التنبؤ للشركة، ولكنه يعني أيضًا أن العملاء بحاجة إلى فهم مخاطر التجديد ونطاق الخدمة وتوفر الخبرة على المدى الطويل.
العمل المتكرر وراء الاستعادة النظيفة
العمل الذي يحدد قيمة Falconstor متكرر وغير جذاب. يبدأ قبل وقوع الحادث. يجب على المسؤولين تحديد ما هو محمي، وعدد مرات حفظه، وتطبيق النسخ الاحتياطي الذي يملك المهمة، وأين توجد الوسائط الافتراضية، وكيف يتم تحديد حجم مستودعات إزالة التكرار، والروابط التي تحمل حركة النسخ المتماثل، ودلاء تخزين الكائنات أو أجهزة التخزين التي تحتوي البيانات، وعناصر التحكم في الاحتفاظ التي تنطبق، ومن يمكنه تغيير السياسة. هذه القرارات هي عمل إنتاج. إنها ليست ملاحظات نشر لمرة واحدة.
كل دورة نسخ احتياطي تنشئ بعد ذلك سلسلة من السجلات. يجب على النظام الأساسي إنشاء حفظ متسق. يجب أن يكتمل تطبيق النسخ الاحتياطي. يجب على StorSafe أو هدف ذي صلة استيعاب البيانات. يجب أن تنتهي إزالة التكرار في الوضع المقصود. يجب أن يظل الفهرس متماسكًا. يجب أن يكتمل النسخ المتماثل أو الأرشفة. يجب مراجعة التنبيهات. يجب فحص اتجاهات السعة. يجب التحقيق في أي مهمة فائتة قبل أن يحول الفشل التالي ذلك الفقدان إلى فقدان بيانات. هذا هو التصنيع اليومي لقابلية الاسترداد.
يمكن لبرنامج Falconstor أتمتة أجزاء من تلك السلسلة، ولكنه يضيف أيضًا حالته الخاصة. هناك مستودع وفهرس وبيانات تكوين واتصال شبكة وخدمات إدارة وإصدارات نظام تشغيل مدعومة وتسجيل ترخيص وتوافق تخزين وسياسة دعم. تجعل مواد النشر الرسمية لـ IBM Power هذا صريحًا بتسمية الحاجة إلى تحديد الحجم والوصول إلى IBM Cloud وبيانات اعتماد تخزين الكائنات وتثبيت StorSight وتصميم الشبكة ومعرفة iSCSI أو Fibre Channel وتخطيط الأمان. هذه ليست افتراضات تافهة. إنها حدود المهارة.
تكلفة الإشراف تقع في الفجوات بين المنتجات. قد يملك مسؤولو النسخ الاحتياطي جدولة المهام. قد يملك مسؤولو التخزين سعة المستودع. قد تملك فرق الشبكة Direct Link أو VPN أو VLANs أو مسارات النسخ المتماثل. قد تملك فرق السحابة تخزين الكائنات وبيانات الاعتماد والمفاتيح والمناطق والفوترة. قد تملك فرق الأمان الثبات والوصول المميز وعزل برامج الفدية ومتطلبات التدقيق. قد يملك مالكو التطبيقات اختبار القبول. يمكن لـ Falconstor تقليل الاحتكاك في الوسط، ولكن لا يزال هناك من ينسق السجل عبر هؤلاء المالكين.
هذا التنسيق مهم بشكل خاص لبرامج الفدية. تؤكد الإرشادات العامة من سلطات الأمن على النسخ الاحتياطية غير المتصلة أو المحمية بطريقة أخرى والاختبار المنتظم لتوفر وسلامة النسخ الاحتياطي. الدرس بسيط: النسخ الاحتياطي الذي لا يمكن الوثوق به تحت الهجوم ليس خطة استرداد. ميزات الثبات والنسخ خارج الموقع في Falconstor ذات صلة لأن مشغلي برامج الفدية غالبًا ما يبحثون عن أنظمة النسخ الاحتياطي ويحذفون أو يشفرون النسخ القابلة للوصول ويجبرون الضحية على قرار تحت ضغط الوقت. يمكن للنسخة غير القابلة للتغيير بنمط WORM أن تحسن موقف المدافع.
لكن التعافي من برامج الفدية لا يزال يتطلب اختيار نقطة زمنية نظيفة وإعادة بناء البنية التحتية الموثوقة والتحقق من بيانات التطبيق وإعادة توصيل الاعتماديات وتجنب إعادة العدوى.
ينطبق نفس النمط على الترحيل. يمكن لنهج الشريط الافتراضي لـ Falconstor نقل وسائط النسخ الاحتياطي القديمة أو أعباء العمل المحمية نحو البنية التحتية السحابية دون الحاجة إلى إعادة تصميم كاملة لعملية النسخ الاحتياطي. ولكن يجب أن يظهر السجل المقبول أن عبء العمل المنقول يبدأ، وأن المستخدمين يمكنهم الوصول إليه، وأن عمليات الدُفعات تعمل، وأن الاحتفاظ بالامتثال يظل سليمًا، وأن الوسائط القديمة لا تزال قابلة للقراءة عند الحاجة، وأن التراجع ممكن إذا فشل التحول. الخطر هو معاملة نقل البيانات كنجاح الترحيل. نقل البيانات هو المادة الخام. الخدمة العاملة هي النتيجة.
بالنسبة لمزودي الخدمات المدارة، يتغير العمل المتكرر ولكنه لا يختفي. يمكن لمزود الخدمة المُدارة توحيد النشر والمراقبة والاحتفاظ خارج الموقع وإعداد التقارير للعملاء. يمكن أن يكون ذلك جذابًا للفرق الصغيرة التي لا تستطيع حمل خبرة IBM Power والاسترداد العميقة داخليًا. يناسب تأطير الخدمة المُدارة في Habanero هذه الحاجة من خلال الوعد بحماية خارج الموقع بتسعير يمكن التنبؤ به وعمليات مُدارة.
لكن العميل لا يزال بحاجة إلى معرفة ما تغطيه الخدمة، وما هي سيناريوهات الاسترداد المضمنة، وما هو إيقاع اختبار الاستعادة المتاح، وكيف يتم التصعيد بسرعة، وكيف يتم التعامل مع بيانات الاعتماد من جانب العميل واعتماديات التطبيق، وما هي الأدلة المنتجة للمدققين أو المسؤولين التنفيذيين.
أقوى نشر لـ Falconstor، إذن، هو حيث يصبح المنتج جزءًا من حلقة تشغيل منضبطة. يستقبل تدفقات النسخ الاحتياطي دون زعزعة الإجراءات المعمول بها. يقلل تكلفة التخزين والنقل بما يكفي لتغيير اقتصاديات الاحتفاظ. ينسخ ويحمي النسخ بطريقة يمكن للمشغلين فهمها. يكشف عن حالة كافية لتقليل النقاط العمياء. يتم تضمينه في تدريبات الاستعادة. له حدود دعم واضحة. يتم اختباره تحت سيناريوهات تحاكي الفشل الفعلي، وليس فقط تحت عروض نظيفة.
حقيقة الفهرس، وليس فقط عدد النسخ
أسهل خطأ في النسخ الاحتياطي هو حساب النسخ وتجاهل الحقيقة. قد يكون لدى الشركة نسخ محلية ونسخ خارج الموقع ونسخ سحابية ونسخ غير قابلة للتغيير ونسخ أرشيف شهرية. ومع ذلك، عندما تبدأ الاستعادة، تكون الأسئلة المهمة أضيق. أي نسخة تحتوي على البيانات المطلوبة؟ أي إدخال فهرس يصفها؟ أي إصدار تطبيق يمكنه قراءتها؟ أي مفاتيح تفتحها؟ أي فهرس مستودع يمكنه إعادة بنائها؟ أي شريط افتراضي يتوافق مع الخدمة التجارية؟ أي مسار شبكة يمكنه إعادتها ضمن هدف الاسترداد؟ أي مشغل تدرب على التسلسل؟
حدود منتج Falconstor تجعل حقيقة الفهرس مركزية. غالبًا ما يعمل StorSafe جنبًا إلى جنب مع تطبيقات النسخ الاحتياطي الحالية للمؤسسات بدلاً من استبدال كل سجل أعلى. هذا يعني أنه يمكن أن يكون هناك فهارس متعددة أو مفاهيم جرد: فهرس تطبيق النسخ الاحتياطي، وعرض الشريط الافتراضي، ومعلومات مستودع وإدارة StorSafe الخاصة، وبيانات تخزين الكائنات الوصفية، وأي طبقة تقارير من مزود الخدمة المُدارة أو العميل. يجب أن يوفق سجل الاسترداد بين هذه الآراء.
إذا انحرفت الآراء، يمكن أن يصبح الاسترداد تمرين بحث. قد يعتقد تطبيق النسخ الاحتياطي أن شريطًا افتراضيًا موجود. قد يكون الشريط الافتراضي مختزلًا لأن البيانات انتقلت إلى تخزين الكائنات. قد تكون نسخة تخزين الكائنات في منطقة أو دلو محكوم ببيانات اعتماد منفصلة. قد يحتاج فهرس إزالة التكرار إلى حالة تخزين معينة. قد يكون مسار السحابة قد تغير. قد يكون الموظف الذي فهم الخريطة الأصلية قد غادر. لا يعني أي من هذا أن Falconstor ضعيف. يعني أن المنتج يعيش في جزء البنية التحتية حيث انضباط البيانات الوصفية هو الفرق بين الاسترداد والتأخير.
مواد الدعم والشهادات الخاصة بـ Falconstor تعزز هذا الواقع التشغيلي. تحافظ الشركة على مصفوفات شهادات لمجموعات الأجهزة والبرامج وتلاحظ أن إصدارات الموقع الفعلية قد تختلف عن المجموعات المختبرة. تميز مواد الدعم أيضًا بين الدعم الفني وعمل النشر واستكشاف أخطاء الشبكة وتكوين التخزين وترقيات الإصدارات الرئيسية. هذه الحدود طبيعية في برامج المؤسسات، لكنها مهمة اقتصاديًا. العميل الذي يفترض أن البائع سيمتلك كل مشكلة بيئية قد يخطئ في تقدير تكلفة النشر. العميل الذي يعامل الشهادة ومحاذاة الإصدار والخدمات المهنية كجزء من نظام الاسترداد سيكون أكثر استعدادًا.
لذلك يجب أن يتضمن سجل الاسترداد المقبول سياق البائع والإصدار. يجب أن يذكر إصدار StorSafe قيد الاستخدام، وتطبيقات النسخ الاحتياطي وأنظمة التشغيل المعتمدة، وأجهزة التخزين أو أهداف تخزين الكائنات المستخدمة، ومنطقة السحابة التي تحتوي البيانات خارج الموقع، وعناصر التحكم في الاحتفاظ الممكنة، وخطة الدعم المطبقة، والخدمات المهنية المستخدمة، واختبارات الاستعادة المكتملة. بدون هذا السجل، تمتلك المؤسسة مجموعة من المكونات الواعدة بدلاً من وضع استرداد قابل للإثبات.
هذا هو أيضًا المكان الذي يهم فيه ملف الشركة الصغير لـ Falconstor. للشركة تاريخ طويل في تخزين المؤسسات، لكنها ليست مزود سحابة فائق الحجم أو بائع حزمة نسخ احتياطي عملاق. تظهر الإصدارات المالية الأخيرة شركة تركز على نمو الإيرادات المتكررة والانضباط التشغيلي من قاعدة إيرادات متواضعة. يمكن أن يكون ذلك قوة للعملاء المركزين: اهتمام متخصص، وخبرة IBM Power، ومواءمة مزودي الخدمات المدارة، ومنتج مصمم لألم تشغيلي محدد. يمكن أن يكون أيضًا خطرًا: يحتاج العملاء إلى الثقة في سعة الدعم واستمرارية خريطة طريق المنتج وتغطية الشريك وتوفر المنفذين المهرة على مدى عمر ممتلكات النسخ الاحتياطي.
استمرارية البائع ليست قضية شراء مجردة في الاسترداد. إذا أصبح مستودع إزالة التكرار أو تنسيق VTL أو نظام الإدارة أو نموذج الاحتفاظ السحابي مضمنًا في ممارسة الامتثال والتعافي من الكوارث، فإن الخروج من المنصة يمكن أن يكون شاقًا. الترحيل بعيدًا عن هدف النسخ الاحتياطي هو بحد ذاته مشروع شبيه بالاسترداد.
لذلك يجب على العملاء أن يسألوا ليس فقط "هل يمكن لـ Falconstor تقليل تكلفة التخزين؟" ولكن أيضًا "هل يمكننا استرداد أو ترحيل بياناتنا المحمية إذا تغيرت علاقتنا مع Falconstor، أو تغير مزود الخدمة المُدارة لدينا، أو تغيرت استراتيجيتنا السحابية؟" قد تكون الإجابة مقبولة، ولكن يجب توثيقها قبل أن يصبح النظام المسار العملي الوحيد لوسائط النسخ الاحتياطي القديمة.
برامج الفدية تغير معنى النسخ الاحتياطي
غيرت برامج الفدية النسخ الاحتياطي من ممارسة استمرارية روتينية إلى عنصر تحكم عدائي. قد لا يتوقف المهاجم عند تشفير بيانات الإنتاج. قد يبحث المهاجم عن وحدات تحكم النسخ الاحتياطي وبيانات اعتماد المسؤول ودلاء التخزين وأهداف النسخ المتماثل وسياسات الاحتفاظ. أفضل هدف نسخ احتياطي ليس فقط فعالًا. يجب أن يكون من الصعب العبث به، وقابلًا للمراقبة تحت الضغط، ومرتبطًا بعملية استعادة مختبرة.
تأتي أهمية Falconstor في مواجهة برامج الفدية من عدة قدرات: الاحتفاظ خارج الموقع، وتكامل التخزين غير القابل للتغيير، والأشرطة الافتراضية بنمط WORM، والتشفير، والنسخ المتماثل، والقدرة على حفظ النسخ المحمية خارج البيئة الأساسية. هذه ميزات ذات معنى. إذا اخترق مهاجم مضيف الإنتاج وتخزين النسخ الاحتياطي القابل للوصول، يمكن أن تكون النسخة المحمية خارج الموقع الفرق بين التفاوض وإعادة البناء. إذا كان قفل الاحتفاظ يمنع حتى المستخدم المميز من تغيير نسخة خلال فترة الاحتفاظ، يحصل المدافع على مرساة أقوى.
لكن برامج الفدية تكشف أيضًا حدود اللغة المتمحورة حول التخزين. قد تكون النسخة المحمية غير قابلة للتغيير ومع ذلك تكون نسخة من البيانات المشفرة بالفعل. قد يكون النسخ الاحتياطي نظيفًا ولكن يفتقر إلى خادم الهوية اللازم للوصول. قد تستعيد قاعدة البيانات ولكن تظل غير متسقة مع ملفات التطبيق أو قوائم انتظار الرسائل. قد تكون النسخة السحابية موجودة ولكن تستغرق وقتًا طويلاً للاسترداد لأنه لم يتم التخطيط للنطاق الترددي أو تكلفة الخروج أو قدرة الحوسبة الهدف. قد يكون الشريط الافتراضي متاحًا ولكن غير قابل للقراءة بواسطة إصدار برنامج النسخ الاحتياطي المتوقع إذا انحرف الفهرس أو التوافق.
لهذا السبب يجب أن يتضمن سجل الاسترداد أدلة قرار، وليس فقط أدلة فنية. أي نقطة تم اختيارها نظيفة؟ ما هو افتراض وقت بقاء البرامج الضارة المستخدم؟ هل تم تضمين الهوية وDNS والشهادات وجدولة المهام ومشاركات الملفات والمراقبة؟ هل تم إجراء الاستعادة في بيئة معزولة قبل إعادة الاتصال؟ هل قبل مالكو التطبيق البيانات؟ هل فهمت الفرق القانونية والامتثال والتنفيذية نافذة فقدان البيانات المتوقعة؟ يمكن لـ Falconstor المساهمة في هذا السجل، خاصة حول حفظ وسائط النسخ الاحتياطي ونقلها، لكنه لا يستطيع اتخاذ القرار التجاري بمفرده.
تُظهر لغة Habanero والغرفة النظيفة السحابية أن Falconstor يتجه نحو مشكلة الثقة الأوسع في الاسترداد. خدمة خارج الموقع مُدارة لـ IBM Power تعالج فجوة حقيقية للعملاء الذين لا يحاولون نقل أعباء عملهم الأساسية بالكامل إلى السحابة ولكنهم يحتاجون إلى نسخ خارج الموقع آمنة وممتثلة ومرنة. العرض منطقي تجاريًا لأن العديد من فرق IBM Power لديها موظفون محدودون ومتطلبات استمرارية عالية. يمكن للتسعير يمكن التنبؤ به والعمليات المُدارة أن تقلل من الحاجز أمام القيام بالحماية خارج الموقع بشكل صحيح.
الحذر هو أن الحماية الخارجية المُدارة يجب أن تُحكم عليها من خلال أدلة الاستعادة. يجب على العملاء أن يسألوا عن عدد مرات اختبار الاسترداد، وما إذا كانت اختبارات الاستعادة مضمنة أو مفروضة بشكل منفصل، وكيف يبدو هدف الاسترداد، وما هي التزامات مستوى الخدمة المطبقة، وكيف يتم التعامل مع متطلبات التخزين السيادية، وكيف تتم إدارة المفاتيح وبيانات اعتماد العميل، وكيف يعمل تصعيد الحوادث، وما هي الأدلة المقدمة بعد الاختبار. الخدمة التي تخزن نسخًا خارج الموقع قيمة. الخدمة التي تنتج سجل استرداد قابل للتكرار أكثر قيمة.
اقتصاديات التخزين حقيقية ولكنها مشروطة
تبدأ الحالة الاقتصادية لـ Falconstor بتقليل البيانات. بيانات النسخ الاحتياطي متكررة، وتقليل البيانات المتكررة يمكن أن يخفض تكلفة السعة والنطاق الترددي والاحتفاظ السحابي. تصف المواد الرسمية باستمرار تخفيضات كبيرة محتملة، بما في ذلك ما يصل إلى 95 بالمائة في ظل ظروف مواتية، وغالبًا ما تربط الشركة هذه التخفيضات بانخفاض تكاليف التخزين والنقل. تصف المواد المتعلقة بـ IBM أيضًا استخدام تخزين الكائنات كمستودع إزالة تكرار أو طبقة أرشفة، مما يمكن أن يغير نموذج التكلفة مقارنة بأجهزة النسخ الاحتياطي المخصصة أو عمليات الشريط المادي.
الاقتصاديات معقولة، لكنها مشروطة. تعتمد إزالة التكرار على نوع عبء العمل وتكرار النسخ الاحتياطي ومعدل التغيير والضغط والتشفير قبل الاستيعاب وأنماط الاحتفاظ وما إذا كانت البيانات المماثلة تُرى من قبل نفس المستودع. قاعدة بيانات تتغير بشكل كبير، أو تطبيق يضغط أو يشفر قبل النسخ الاحتياطي، أو نموذج احتفاظ يعزل البيانات في العديد من المجالات الصغيرة قد ينتج تخفيضًا أقل من عنوان البائع. يجب على العملاء نمذجة بياناتهم الفعلية بدلاً من شراء متوسط الادعاء.
تشمل اقتصاديات السحابة أيضًا أكثر من تخزين لكل غيغابايت. هناك اتصال الشبكة وفئة تخزين الكائنات وتكرار الاسترجاع وعمليات API والخروج والنسخ المتماثل والحركة عبر المناطق واستعادة الحوسبة والدعم وأدوات الأمان ووقت الموظفين. قد تكون نسخة النسخ الاحتياطي رخيصة التخزين ولكنها مكلفة أو بطيئة الاسترداد على نطاق واسع. قد يتطلب حادث برامج الفدية سحب كميات كبيرة بسرعة واختبار نقاط متعددة وإبقاء حوسبة إضافية حية أثناء إعادة بناء الأنظمة. لذلك يجب أن يتضمن سجل الاسترداد سيناريو استرداد مكلف، وليس فقط فاتورة تخزين.
قيمة الترحيل لـ Falconstor مشروطة بالمثل. إذا كانت المؤسسة تواجه نهاية خدمة الأجهزة أو عبء مكتبة الأشرطة أو خروج مركز البيانات أو ترحيل PowerVS أو تحول مزود خدمة مُدارة، يمكن لـ StorSafe جعل وسائط النسخ الاحتياطي القديمة والعمليات الحالية مفيدة في بنية جديدة. تجنب إعادة الترطيب أو تجنب منطقة هبوط كبيرة أو الحفاظ على تدفقات عمل النسخ الاحتياطي المألوفة يمكن أن ينتج وفورات حقيقية. ولكن إذا كان العميل قد وحد بالفعل على منصة نسخ احتياطي حديثة أخرى مع استرداد سحابي مباشر، أو إذا كانت ممتلكات Power صغيرة ومستقرة، فقد تكون القيمة الإضافية أضيق.
الترخيص واستمرارية البائع ينتميان إلى نفس الحساب. قد يتوافق تحرك Falconstor نحو الإيرادات المتكررة وقنوات مزودي الخدمات المدارة مع طلب العملاء على الاستهلاك بنمط الخدمة. قد يحول أيضًا البنية التحتية للاسترداد إلى نفقة تشغيل متكررة تحتاج إلى حوكمة تجديد. يجب أن يعرف العميل ما إذا كان التسعير مرتبطًا بالسعة أو التيرابايت المحمية أو مستوى الخدمة أو التخزين السحابي أو حزمة مزود الخدمة المُدارة أو مستوى الدعم أو الخدمات المهنية. يجب أن يعرف أيضًا كيف يمكن تصدير البيانات، وكم من الوقت تظل الوسائط الافتراضية القديمة قابلة للقراءة، وماذا يحدث إذا انتهى الترخيص أثناء حادث.
حساب الموظفين قد يكون الأهم. غالبًا ما تفشل مشاريع تحديث النسخ الاحتياطي ليس لأن هدف التخزين سيئ ولكن لأن المؤسسة تقلل من تقدير العمل البشري: الجرد والتنظيف وتحديد الحجم وتصميم الشبكة والتحكم في الوصول وسياسة الاحتفاظ واختبار الاستعادة ورسم خرائط التطبيق والتوثيق والتسليم التشغيلي. يمكن لـ Falconstor تقليل عبء التخزين وتغيير العملية، لكنه لا يلغي هذه المهام. في فريق صغير، شراء هدف أكثر كفاءة دون تمويل تدريبات الاستعادة والتوثيق قد ببساطة يخلق نقطة عمياء أكثر تقدمًا.
البدائل ليست كلها متشابهة
تنافس Falconstor مع عدة أنواع من البدائل، وكل منها يغير سجل الاسترداد بشكل مختلف. البديل الأول هو جهاز نسخ احتياطي للأجهزة أو هدف إزالة تكرار تقليدي. قد يكون ذلك مألوفًا وسريعًا محليًا وناضجًا تشغيليًا، ولكنه يمكن أن يكون مكلفًا في التحديث وأقل مرونة في البيئات السحابية وأقل ملاءمة للنشر المعرف بالبرمجيات عبر المواقع المحلية وسياقات PowerVS. نهج Falconstor القائم على البرمجيات هو الأقوى عندما يكون احتجاز الأجهزة أو نهاية عمر الجهاز جزءًا من المشكلة.
البديل الثاني هو حزمة نسخ احتياطي واسعة للمؤسسات. قد يقدم البائعون في هذه الفئة تكاملًا عميقًا للتطبيقات، وتنسيقًا، ومستودعات غير قابلة للتغيير، واسترداد سحابي، وأنظمة دعم كبيرة. بالنسبة للعملاء الموحدين بالفعل على مثل هذه الحزمة، يجب على Falconstor تبرير دوره كهدف أو جسر أو متخصص في IBM Power. الحجة ليست أن كل مؤسسة تحتاج إلى طبقة أخرى. إنها أن بعض الممتلكات تحتاج إلى مسار تحديث على شكل VTL وتغطية IBM Power قد لا تحلها الحزمة العامة بأناقة.
البديل الثالث هو النسخ الاحتياطي السحابي الأصلي والنسخ المتماثل. في ممتلكات سحابية أصلية بحتة، قد توفر المنصة لقطات ونسخًا احتياطية لقاعدة بيانات مُدارة وإصدار الكائنات ونسخًا متماثلاً عبر المناطق واستردادًا كبنية تحتية كرمز. يمكن أن يكون ذلك أبسط من إدراج طبقة VTL. لكن العديد من عملاء Falconstor ليسوا سحابيين أصليين بحتين. إنهم هجينون أو أغنياء بالقديم أو متمركزون حول Power. قد لا تفهم الخدمات السحابية الأصلية واقعهم التشغيلي، خاصة عندما تكون نقطة البداية هي ممارسة حفظ/استعادة IBM i أو الأشرطة التاريخية أو تصميم استرداد هجين محلي وPowerVS.
البديل الرابع هو الشريط المادي. يظل الشريط مناسبًا للاحتفاظ الطويل وانضباط الفجوة الهوائية واحتياجات امتثال أو تكلفة معينة. يمكن أن يكون قويًا عند إدارته بشكل جيد. يمكن أن يكون أيضًا بطيئًا ويدويًا وعرضة للأخطاء وصعب التكامل مع الاسترداد السحابي السريع. يمكن لنهج الشريط الافتراضي لـ Falconstor الحفاظ على دلالات الشريط مع إزالة بعض عبء الوسائط والميكانيكي. ومع ذلك، سيبقي بعض العملاء الشريط المادي كطبقة إضافية، خاصة حيث يكون الاحتفاظ غير المتصل على المدى الطويل مطلوبًا.
البديل الخامس هو مزود خدمة مُدارة أو مزود استمرارية الأعمال الذي يلخص اختيار المنتج. يحرك Habanero Falconstor في هذا الاتجاه، ولكن قد يشتري العملاء أيضًا الاسترداد كخدمة من مقدمي الخدمات باستخدام أدوات أخرى. المقارنة الرئيسية هي الأدلة. أي مزود ينتج سجلات استرداد أفضل؟ أي واحد يمكنه إظهار استرداد مُختبر في بيئة تشغيل العميل؟ أي واحد يتعامل مع IBM Power واحتياجات التدقيق والاحتفاظ والأمان وشفافية التكلفة؟ أسماء المنتجات أقل أهمية من دليل الاسترداد.
أفضل ملاءمة لـ Falconstor ليست عالمية. إنها الأقوى للمؤسسات التي لديها عمليات نسخ احتياطي حالية تستحق الحفظ، وبيانات نسخ احتياطي متكررة كبيرة، وممتلكات IBM Power أو أنظمة تشغيل مختلطة، وحاجة للاحتفاظ السحابي أو خارج الموقع، وضغط ترحيل، وانضباط تشغيلي كافٍ لاختبار الاستعادة. إنها أضعف حيث تكون الممتلكات محمية بالفعل بشكل نظيف بواسطة منصة حديثة، أو حيث يكون الاسترداد السحابي الأصلي أبسط، أو حيث لن يحافظ الموظفون على السجل، أو حيث يتوقع العميل أن برنامج التخزين سيحل استمرارية التطبيق بمفرده.
ما يجب أن يطلبه العملاء قبل الثقة به
يجب أن يبدأ التقييم الجاد لـ Falconstor بسيناريو استرداد، وليس بقائمة ميزات. اختر عبء عمل مهمًا واحدًا. حدد نقطة الاسترداد المطلوبة ووقت الاسترداد المطلوب. حدد عملية النسخ الاحتياطي المصدر وهدف StorSafe ومستودع إزالة التكرار ونسخة خارج الموقع أو تخزين الكائنات ووحدة التحكم الإدارية ومسار الشبكة والأشخاص وبيانات الاعتماد واعتماديات التطبيق واختبار القبول. ثم نفذ أو على الأقل صمم الاستعادة. المنتج إما يساعد في إنتاج هذا السجل أو لا.
يجب أن يتضمن التقييم أيضًا تدريبًا على الفهرس. هل يمكن للفريق تحديد الوسائط الافتراضية الدقيقة أو مجموعة النسخ الاحتياطي المطلوبة لتاريخ محدد؟ هل يمكنه الاسترداد إذا كان الموقع الأساسي غير متاح؟ هل يمكنه الاستعادة من شريط افتراضي مختزل أو مُرحل سحابيًا؟ هل لا يزال تطبيق النسخ الاحتياطي يفهم الوسائط؟ هل يمكن لمسؤول جديد متابعة السجل دون معرفة قبلية؟ إذا كانت الإجابة غير واضحة، فإن المشروع ليس جاهزًا للاعتماد الإنتاجي، بغض النظر عن وفورات إزالة التكرار.
يجب اختبار افتراضات الشبكة والسحابة. حركة النسخ المتماثل، واتصال تخزين الكائنات، واختيارات Direct Link أو VPN، وعزل VLAN، والوصول إلى خدمات الترخيص، وبيانات اعتماد السحابة، وعرض النطاق الترددي للاستعادة كلها مهمة. يمكن أن يكون النسخ الاحتياطي ممتازًا ومع ذلك يفشل في هدف الاسترداد إذا كان مسار العودة بطيئًا جدًا أو محظورًا ببيانات اعتماد يعرفها شخص واحد فقط. وثائق نشر Falconstor مفصلة بما يكفي لإظهار أن هذه الاعتماديات حقيقية. يجب على العملاء معاملة هذه التفاصيل كقائمة تخطيط، وليس كأوراق.
يجب أن تكون افتراضات الأمان صريحة. من يمكنه حذف أو انتهاء صلاحية أو تغيير الوسائط الافتراضية؟ أي النسخ غير قابلة للتغيير؟ لمدة كم؟ هل المفاتيح مُدارة بواسطة Falconstor أو العميل أو مزود السحابة أو مزود الخدمة المُدارة؟ هل يمكن لمسؤول تحت سيطرة المهاجم تعطيل الحماية المستقبلية؟ هل واجهات الإدارة معزولة ومراقبة؟ هل النسخ خارج الموقع قابلة للوصول من هويات الإنتاج المخترقة؟ هل يتم إجراء اختبارات الاستعادة في بيئة معزولة قبل إعادة الاتصال؟ هذه الأسئلة تحدد ما إذا كانت الحماية من برامج الفدية أكثر من مجرد عبارة تسويقية.
يجب أن يتم تسعير الدعم والخدمات كجزء من النظام. كتيب دعم Falconstor يميز بشكل طبيعي بين الدعم الفني وعمل النشر أو البيئة. إذا كان مشروع الاسترداد يحتاج إلى تقسيم SAN أو شبكات IP أو تكوين تخزين كائنات سحابية أو عمل Linux أو ضبط تطبيق النسخ الاحتياطي أو مساعدة ترقية الإصدار الرئيسي، يجب أن يعرف العميل من يملك هذا العمل. ترخيص رخيص مع خدمات مهنية غير ممولة يمكن أن يصبح مكلفًا أثناء استعادة فاشلة.
يجب أن تطلب الشركة أيضًا أدلة على التكلفة. نموذج تخزين الأساس وتكلفة ترخيص Falconstor أو تكلفة الخدمة وتخزين الكائنات والشبكة والاسترجاع السحابي والدعم والخدمات المهنية ووقت الموظفين واختبار الاستعادة وعمل الترحيل. ثم قارن النموذج مع البدائل الواقعية. بالنسبة لبعض ممتلكات IBM Power الهجينة، قد يقلل Falconstor ما يكفي من التخزين والأجهزة وألم الترحيل لتبرير التغيير. بالنسبة للآخرين، قد تعتمد الاقتصاديات بشكل كبير على أفضل حالة لتقليل البيانات أو الإشراف غير المحسوب.
أخيرًا، يجب أن يسأل التقييم ما الذي سيغير القرار. إذا أظهرت اختبارات الاستعادة انحراف الفهرس، أو إذا كانت وفورات إزالة التكرار أقل بكثير من التوقع، أو إذا كانت تكاليف استرجاع السحابة تجعل استرداد الحادث الكامل غير عملي، أو إذا كان تقارير مزود الخدمة المُدارة معتمًا جدًا، أو إذا لم يتم اعتماد إصدارات نظام التشغيل أو تطبيق النسخ الاحتياطي الهامة، أو إذا كانت حدود الدعم غير واضحة، أو إذا ارتفعت مخاوف استمرارية البائع، يجب على العميل التباطؤ. إذا، بدلاً من ذلك، يتيح Falconstor سجل استرداد نظيف مع تكلفة تخزين أقل وعمليات مألوفة واسترداد خارج الموقع مُختبر وشروط دعم مقبولة، فإن المنتج يستحق مكانه.
الحكم
Falconstor Software هي الأكثر إثارة للاهتمام لأنها لا تطلب من كل عميل التخلي عن عالم الاسترداد القديم. تحاول جعل هذا العالم أكثر كفاءة وأكثر قدرة على السحابة وأكثر مرونة. هذه استراتيجية ذات مصداقية في بيئات IBM Power والمؤسسات الهجينة حيث يمكن أن تكون تكلفة التغيير الجذري أعلى من تكلفة تحسين طبقة الهدف وراء العمليات المعمول بها.
قصة التكنولوجيا للشركة لها جوهر: الشريط الافتراضي، إزالة التكرار، النسخ المتماثل، استخدام تخزين الكائنات، إدارة StorSight، شهادة IBM Power والتوفر عبر قنوات IBM، دعم الترحيل السحابي، وضع النسخ غير القابلة للتغيير، وخدمة خارج الموقع مُدارة جديدة في Habanero. قصتها التجارية متماسكة أيضًا: الإيرادات المتكررة، اعتماد مزود الخدمة المُدارة، التركيز على نظام IBM البيئي، والعروض القائمة على الخدمة للعملاء الذين يحتاجون إلى المرونة دون بناء كل مكون بأنفسهم.
لكن المعيار الصحيح لا يرحم. لا يتم إثبات Falconstor من خلال مهمة نسخ احتياطي مكتملة، أو ادعاء كبير بإزالة التكرار، أو قائمة IBM، أو اقتباس شريك، أو لوحة معلومات. يتم إثباته من خلال ما إذا كان العميل يمكنه إنتاج سجل استرداد مقبول لأعباء العمل المهمة. يجب أن يظهر السجل أن حقيقة النسخ الاحتياطي نجت من الفوضى العادية للعمليات: إصدارات البرامج، الفهارس، المفهرس، بيانات الاعتماد، مسارات الشبكة، التخزين السحابي، الاحتفاظ، حدود الدعم، تغييرات الموظفين، الشك في برامج الفدية، وضغط الترحيل.
هذا المعيار يجعل Falconstor مفيدًا ولكنه ليس سحريًا. يمكن أن يخفض تكلفة وتعقيد الحفاظ على البيانات القابلة للاسترداد. يمكن أن يساعد الفرق في الحفاظ على عمليات النسخ الاحتياطي المألوفة مع تحديث الأهداف. يمكن أن يجعل الاحتفاظ السحابي وخارج الموقع أكثر عملية. يمكن أن يعطي عملاء IBM Power جسرًا بين الأنظمة المحلية وPowerVS. يمكن أن يساعد مزودي الخدمات المدارة في حزمة خدمة قابلة للتكرار. ومع ذلك، كل واحدة من هذه الفوائد تعتمد على التكوين المنضبط والاختبار المتكرر والاقتصاديات الصادقة.
الاستنتاج العملي ضيق وقوي: Falconstor هو خيار جاد للمؤسسات ومقدمي الخدمات الذين يحتاجون إلى تحويل بيانات النسخ الاحتياطي المحمية إلى حالة قابلة للاسترداد مقبولة عبر البنية التحتية القديمة والهجينة. إنه ليس بديلاً عن حوكمة الاسترداد. يجب أن يبدأ المشترون بسجل الاسترداد الذي يحتاجونه، واختبار Falconstor مقابل ذلك السجل، وعندها فقط يقررون ما إذا كانت وفورات التخزين ومسار الترحيل ووضع برامج الفدية ونموذج الخدمة المتكرر يبرران الالتزام.