القصة تتكرر بشكل شبه ثابت: إما واحد يشتري NVR بثمانية bays محشو بأقراص ما راح تمتلي أبداً، أو واحد يوفر على نفسه ويشتري جهاز بـ 2 bay فقط، وبعد أحد عشر يوم يكتشف إن المساحة خلصت والتسجيل بدأ يمسح فوق نفسه بصمت — بالضبط في اللحظة اللي يحتاجون فيها الفوتيج. المشكلتين لهما نفس السبب: محد سوّى حساب البت ريت (bitrate) قبل ما يوقّع على عرض السعر. الحساب يأخذ عشر دقايق وآلة حاسبة. خلونا نصلحها.

ليش "خذ NVR أكبر عشان نضمن" فكرة فاشلة

المبالغة في الحجم مو الخيار الآمن اللي يتصوره الناس. الـ bays الإضافية تكلف فلوس من البداية، والأقراص الإضافية تستهلك كهرباء وحرارة أكثر على مدى سنوات من التشغيل المستمر 24/7، والمصفوفة الأكبر تعني وقت rebuild أطول لو انصفح أحد الأقراص. لكن التقليل في الحجم أسوأ: تكتشف إن التخزين ما يكفي في نفس اليوم اللي تحتاج فيه فوتيج من قبل ثلاث أسابيع، وتلقاه راح — انمسح بسبب loop recording. ولا واحدة من المشكلتين تظهر في أول يوم؛ الجهاز يشتغل تمام لما يكون جديد التركيب في الحالتين. المشكلة تطلع فقط لما تحتاج مدة احتفاظ ما عندك، أو لما تكون صرفت ميزانية على سعة محد يستخدمها. والحل واحد في الاتجاهين: احسب الحجم من الأرقام الفعلية، مو من فكرة "خلنا نأخذ الأكبر عشان الاحتياط".

المعادلة الأساسية: بت ريت × عدد الكاميرات × ساعات × أيام

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

سعة التخزين (بايت) = (البت ريت بالـ Kbps × 1000 ÷ 8) × 3600 × عدد ساعات التسجيل يومياً × عدد الكاميرات × أيام الاحتفاظ ÷ 1,000,000,000

وهذا مثال محسوب مباشرة من نفس المعادلة: كاميرتين، كل وحدة تبث بحد أقصى 1024 Kbps، تسجيل مستمر (24 ساعة) لمدة 7 أيام — النتيجة تقريباً 154.8 GB. كبّر الأرقام والنمط واضح: ضاعف عدد الكاميرات تضاعف التخزين، وضاعف أيام الاحتفاظ يتضاعف التخزين مرة ثانية. لو عندك 16 كاميرا بدل كاميرتين، وتبي 30 يوم بدل 7، ما راح تكون تحسب لـ NAS صغير — راح تكون تحسب لعدة أقراص بسعة تيرابايتات متعددة في RAID.

المتغير اللي يوقع الناس في الغلط مو عدد الكاميرات — هذا سهل تحسبه صح. المشكلة في البت ريت. البت ريت مو رقم ثابت تقراه من علبة الكاميرا؛ يعتمد على الدقة (resolution)، معدل الفريمات، الكوديك المستخدم، وكمية الحركة والتفاصيل الموجودة فعلياً في المشهد. كاميرا موجهة على ممر مستودع فاضي بالليل تنتج بيانات أقل بكثير من نفس الكاميرا موجهة على رصيف تحميل مزدحم في وضح النهار، لأن المُرمِّزات (encoders) الحديثة تصرف بتات فقط على اللي يتغير بين الفريمات. لهذا السبب كاميرتين "متطابقتين" بدقة 4MP على نفس الـ NVR ممكن تنتجان أحجام ملفات مختلفة تماماً حسب مكان تركيبهما.

كيف يغيّر H.264 مقابل H.265/H.265+ فاتورة التخزين عندك

اختيار الكوديك هو أقوى أداة بيدك لتقليل تكلفة التخزين بدون التضحية بمدة الاحتفاظ. H.265 (المعروف بـ HEVC) يقلل البت ريت بنسبة تقريباً 25 إلى 50 بالمئة مقارنة بـ H.264، لنفس الدقة والجودة، حسب طبيعة المشهد. هذا فرق مو هامشي — على نظام يحتاج مصفوفة 8TB مع H.264، نفس النظام بـ H.265 ممكن يعطيك نفس الـ 30 يوم احتفاظ على 4-6TB فقط. لو الـ NVR والكاميرات عندك تدعم H.265 أو نسخة الشركة المصنعة من "H.265+"/"smart codec" (اللي تضيف تحكم تكيّفي بالبت ريت حسب المشهد)، فعّلها. عملياً ما فيه سبب تشتري معدات جديدة بـ H.264 اليوم إلا إذا كنت مجبور بسبب توافق مع جهاز تسجيل قديم أو كاميرا قديمة لسه شغالة عندك. تأكد إن الطرفين — الكاميرا والـ NVR — يدعمان الكوديك فعلاً قبل ما تفترض ذلك؛ عدم توافق الفيرموير سبب شائع يخلي الفنيين يرجعون لـ H.264 وهم ما يدرون إنهم كانوا يقدرون يتفادونه.

خلّ الجدول اليدوي جانب: استخدم أداة الحساب الرسمية من الشركة المصنعة

حساب المعادلة يدوياً كويس لتقدير سريع، أو لتشرح لعميل ليش عرض السعر بهالشكل. لكن لأمر شراء فعلي، لا تعتمد على جدولك الخاص كقول أخير. Axis مثلاً توجّه الفنيين لأداتها الرسمية AXIS Site Designer تحديداً لأن الحساب اليدوي غالباً يفوّت التفاصيل اللي فعلاً تغيّر الرقم: الدقة الدقيقة، معدل الفريمات، إعداد الضغط، جدول التسجيل (مستمر أو بتحفيز حركة أو مجدول)، وتعقيد المشهد. أداة التصميم من Axis نفسها تحسب تفاصيل الصورة والحركة في المشهد بالضبط لأن ممر ثابت وصالة تجزئة مزدحمة بنفس الدقة ما ينتجان نفس حجم الملف، رغم إن معادلتك اليدوية بتعاملهم بنفس الطريقة. أغلب الشركات المصنعة الكبرى للـ NVR والكاميرات عندها حاسبة مشابهة — استخدم اللي تطابق البراند اللي تشتريه فعلاً، وأدخل قائمة الكاميرات الحقيقية وهدف الاحتفاظ الفعلي، واعتبر المعادلة اليدوية مجرد فحص عقلاني لناتج الأداة، مو العكس.

كم يوم احتفاظ تحتاج فعلاً؟

هذا الرقم هو اللي يحدد كل شي بعده، وهو نفس الرقم اللي الناس يخمنونه بدل ما يبحثون عنه. لو أنت ضمن نطاق PCI DSS — يعني تتعامل مع بيانات بطاقات دفع في أي مكان بموقعك — فمتطلبات الأمان المادي في المعيار تحدد حد أدنى 90 يوم للاحتفاظ ببيانات مراقبة الفيديو وسجلات الدخول. هذا مو اقتراح؛ لو صار عليك تدقيق ونظام الـ CCTV عندك يرجع بس 30 يوم، هذي ملاحظة مخالفة (finding) موثقة. لو PCI DSS ما ينطبق عليك، النمط العام في صناعة CCTV التجاري يتراوح بين 30 و90 يوم، وهذا يعطيك وقت كافي لمراجعة الفوتيج بعد نزاع أو سرقة أو بلاغ حادثة قبل ما تنمسح. رأيي الشخصي: إلا إذا فيه متطلب امتثال إلزامي يدفعك لـ 90 يوم، فـ 30 يوم تسجيل مستمر خيار افتراضي معقول لمكتب صغير أو محل تجزئة، مع كون 60-90 يوم الخيار الأكثر أماناً لأي مكان يتعامل مع نقد أو بضاعة عالية القيمة أو مدفوعات بطاقات. لا تحدد الاحتفاظ عند 7 أو 14 يوم بس لأن هذا اللي يناسب الأقراص اللي عندك أصلاً — هذا تفصيل للمتطلب على مقاس الجهاز بدل العكس، وهو بالضبط الغلط اللي هالمقالة كاملة تحاول تفاديه.

قائمة تحقق سريعة لحساب السعة

• اعمل قائمة بكل كاميرا مع الدقة الفعلية المضبوطة عندها، ومعدل الفريمات، والكوديك — مو الرقم الأقصى المكتوب في ورقة المواصفات.
• اسحب البت ريت الحقيقي لكل كاميرا من صفحة إعداداتها، أو استخدم البت ريت الأقصى/المتوسط المعلن من الشركة المصنعة لكل دقة.
• حدد وضع التسجيل لكل كاميرا: مستمر 24 ساعة، بتحفيز حركة، أو ساعات مجدولة. هذا يغيّر "عدد الساعات باليوم" في المعادلة بشكل كبير.
• حدد هدف الاحتفاظ بناءً على متطلب الامتثال (90 يوم لو PCI DSS ينطبق) أو على مستوى تحمّل المخاطر (30-90 يوم في غير ذلك).
• شغّل الأرقام عبر أداة التصميم/الحساب الرسمية من الشركة المصنعة باستخدام قائمة كاميراتك الفعلية، مو قالب عام.
• راجع النتيجة بالمعادلة اليدوية — بت ريت × 3600 ÷ 8 × عدد الكاميرات × ساعات × أيام ÷ 1,000,000,000 — كفحص عقلاني على ناتج الأداة.
• تحوّل إلى H.265/H.265+ في أي مكان يدعمه كل من الكاميرا والـ NVR، وأعد الحساب بعد التحويل — عادة الانخفاض بالمتطلب يكون كبير كفاية يغيّر عدد الأقراص اللي تحتاجها.
• أضف هامش أمان، مو زيادة عشوائية: احسب مساحة لقرص إضافي واحد لأجل RAID redundancy، وربما 10-15% احتياط لطفرات البت ريت وقت المشاهد كثيرة الحركة — مو "خلنا نأخذ الموديل اللي فوقه".

قبل ما توافق على أي عرض سعر لنظام CCTV، اطلب حساب السعة اللي وراء عدد الأقراص المقترح — مو بس رقم السعة الإجمالية. لو الفني ما قدر يوريك الحساب، هذي إشارة إنك تسوي الحساب بنفسك قبل ما توقّع.

المصادر

• CCTV Storage Calculator | DIY Formula & Storage Saving Tips (Reolink)
• Axis Storage Calculator | Storage Calculators
• Bitrate control for IP video - White papers | Axis Communications
• Axis Design Tool User's Guide | Axis Communications
• H.264 vs H.265: File Size, Bitrate, and When to Use Each
• PCI DSS Compliance: 12 Requirements (v4.0) | CrowdStrike
• How Long do Security Cameras Keep Footage? | Pro-Vigil

مصدر الصورة: hisperati — BY