كيف تحسب سعة تخزين كاميرات المراقبة؟

✍️ بقلم: فريق تحرير بوابة المستقبل للشبكات — محتوى متخصص ومراجَع  ·  ⏱ 53 دقائق قراءة  ·  📅 15 أكتوبر 2026

كم يومًا ستبقى التسجيلات محفوظة قبل أن يبدأ النظام بحذف الأقدم؟

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

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

Motion Recording. أو دقة أقل مما كان مخططًا. في الحالتين المشكلة واحدة:

سعة التخزين لم تُحسب على أساس طريقة التسجيل الفعلية.

عدد الكاميرات وحده لا يخبرك بحجم التخزين. وكذلك دقة: 4MP. 5MP.

8MP. لا تعطيك رقمًا ثابتًا للتخزين. كاميرتان بالدقة نفسها يمكن أن تنتجا أحجام تسجيل مختلفة جدًا بسبب: Bitrate.

Codec. Frame Rate. نوع المشهد. التسجيل المستمر أو بالحركة.

VBR أو CBR. الإضاءة الليلية. وجود حركة كثيرة في الصورة. والإعدادات التي يفرضها جهاز التسجيل.

لهذا فإن الطريقة الاحترافية لا تبدأ بالسؤال:

كم تيرا أركب؟

بل تبدأ بمجموعة أسئلة: كم كاميرا؟ ما الدقة؟ كم Frame في الثانية؟

ما Bitrate الفعلية؟ أي Codec؟ هل التسجيل 24/7؟ كم يوم احتفاظ نحتاج؟

هل توجد قنوات صوت؟ هل هناك تسجيل إضافي للكاميرات الحرجة؟ هل نحتاج RAID؟ هل سعة الأقراص المكتوبة هي نفسها السعة الفعلية المتاحة للتسجيل؟

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

الخلاصة السريعة:
أهم رقم في حساب تخزين كاميرات المراقبة هو معدل البيانات الفعلي لكل كاميرا، أو Bitrate، وليس عدد الميجابكسل وحده. لحساب التخزين التقريبي، حوّل Bitrate من Mbps إلى حجم يومي، ثم اضربه في عدد الكاميرات وأيام الاحتفاظ. بصورة مبسطة، كاميرا تسجل بمتوسط 4 Mbps تحتاج قرابة 43 جيجابايت يوميًا، أي نحو 1.3 تيرابايت خلال 30 يومًا قبل إضافة أي هامش أو نسخ احتياطي. استخدم H.265 عندما تكون الأجهزة متوافقة، واضبط Frame Rate وجودة الصورة حسب الحاجة الفعلية، ولا تخفضها فقط لتوفير المساحة. احسب أيضًا سعة RAID، والمساحة التي يحتفظ بها النظام لنفسه، وأي تسجيل مزدوج أو صوتي، واترك هامشًا للتغير في Bitrate والمشاهد الليلية. أفضل تصميم هو الذي يحقق مدة الاحتفاظ المطلوبة مع جودة تصلح فعلًا للتحقيق عند الحاجة.

لماذا تعتبر سعة التخزين جزءًا من تصميم نظام المراقبة؟

الهدف من الكاميرا ليس فقط: رؤية الصورة الآن. في كثير من المواقع، القيمة الحقيقية تظهر بعد وقوع حدث. مثل:

حادث مركبة. دخول غير مصرح. فقدان مادة. شكوى عميل.

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

لذلك تصميم CCTV يحتوي على ثلاثة أجزاء مترابطة

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

الفرق بين سعة NVR وعدد القنوات

هذه نقطة أساسية. جهاز NVR قد يدعم: 16 Channel. 32 Channel.

64 Channel. لكن ذلك لا يعني أن التخزين مناسب تلقائيًا لهذا العدد. عدد القنوات يحدد: كم كاميرا يمكن للنظام إدارتها تقريبًا.

أما التخزين فيعتمد على: معدل البيانات لهذه الكاميرات. مثال NVR تدعم:

32 Camera. لكن تحتوي على: هارد واحد 4TB. يمكن تركيب الكاميرات الـ32.

لكن إذا كل كاميرا تسجل بجودة عالية، قد تحتفظ التسجيلات بفترة قصيرة جدًا.

• لذلك
• Channel Capacity
• و
• Storage Capacity

رقمان مختلفان تمامًا.

لماذا عدد الميجابكسل لا يكفي للحساب؟

قد يقال: لدينا 8 كاميرات 4MP. إذن نحتاج X تيرا. لكن هذا غير دقيق.

كاميرا 4MP قد تسجل على: 2 Mbps. أو: 4 Mbps.

أو: 8 Mbps. بحسب: Codec.

FPS. جودة الصورة. المشهد. وبالتالي

حجم التسجيل قد يختلف: مرتين. ثلاث مرات. أو أكثر.

مع أن الدقة نفسها. لهذا يجب أن يكون الحساب مبنيًا على:

Bitrate الفعلية أو التصميمية.

ما هي Bitrate في كاميرات المراقبة؟

Bitrate هي كمية البيانات التي تنتجها الكاميرا خلال الثانية. قد تراها مثلًا: 2 Mbps. 4 Mbps.

6 Mbps. 8 Mbps.

كلما ارتفعت Bitrate غالبًا

زاد: التفاصيل المحفوظة. وحجم التسجيل. لكن

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

الدقة. المشهد. والهدف.

المعادلة الأساسية لحساب التخزين

إذا كانت Bitrate بالـMbps: يمكن استخدام تقريب سريع:

الحجم اليومي بالجيجابايت ≈ Bitrate × 10.8

مثال كاميرا: 4 Mbps. 4 × 10.8 ≈ 43.2 GB يوميًا.

خلال 30 يومًا 43.2 × 30=1,296 GB. أي تقريبًا: 1.3 TB.

وهذا لكاميرا واحدة فقط.

من أين جاء رقم 10.8؟

الحساب الأصلي تقريبًا: 4 Mbps
× 60 ثانية
× 60 دقيقة
× 24 ساعة ثم التحويل من: bits

إلى: bytes. ثم إلى: GB.

لكن للتخطيط السريع يمكن استخدام:

1 Mbps ≈ 10.8 GB/day

إذا كان التسجيل مستمرًا 24 ساعة.

جدول سريع للتخزين اليومي

هذه قيم تخطيطية تقريبية للتسجيل المستمر.

مثال عملي: 8 كاميرات لمدة 30 يومًا

نفترض: 8 Cameras. متوسط كل واحدة: 4 Mbps.

كاميرا واحدة 43.2 GB/day. ثماني كاميرات 345.6 GB/day.

لمدة 30 يومًا 10,368 GB. أي تقريبًا: 10.4 TB.

قبل إضافة هامش. RAID. مساحة النظام.

أو تغير Bitrate. لذلك تركيب: 8TB فقط لن يحقق بالضرورة 30 يومًا.

مثال: 16 كاميرا 5MP

لنفترض Bitrate التصميمية: 5 Mbps لكل Camera. كاميرا واحدة 5 × 10.8=54 GB/day.

16 كاميرا 864 GB/day. 30 يومًا 25,920 GB.

أي نحو: 25.9 TB. إذا أردنا هامشًا قد نتجه إلى:

28–32TB usable storage بحسب النظام.

لا تخلط بين TB المصنعة والسعة الظاهرة داخل النظام

شركة الهارد قد تعلن: 10TB. لكن النظام قد يعرض قيمة أقل.

بسبب اختلاف طريقة الحساب بين: Decimal. Binary. إضافة إلى

File system. RAID metadata. Storage overhead. لذلك

لا تفترض أن: 4 × 10TB تعني 40TB كاملة متاحة للتسجيل.

ما الفرق بين Raw Capacity وUsable Capacity؟

Raw Capacity مجموع أحجام الأقراص المركبة. مثال: 4 أقراص × 10TB=40TB Raw.

Usable Capacity المساحة التي يمكن استخدامها فعليًا بعد: RAID. النظام.

التهيئة. قد تصبح مثلًا: 30TB تقريبًا في بعض ترتيبات RAID.

وهذا الرقم هو الأهم للتسجيل.

مدة الاحتفاظ Retention Period

هي المدة التي تبقى خلالها التسجيلات محفوظة قبل: الكتابة فوقها. عادة أنظمة NVR تعمل بأسلوب: FIFO.

أي: الأقدم يُحذف أولًا عندما تمتلئ المساحة. إذا تحتاج 30 يومًا،

يجب أن يكون التخزين قادرًا على تحمل: 30 يومًا من متوسط البيانات. مع هامش.

لا تختر مدة الاحتفاظ بصورة عشوائية

السؤال يجب أن يكون: متى عادة نكتشف المشكلة؟ مثال متجر قد يراجع الحوادث خلال:

أيام قليلة.

مستودع قد يكتشف فقدان المخزون بعد:

أسبوعين. منشأة معينة قد تحتاج: 30 أو 60 أو 90 يومًا بحسب سياساتها واحتياجاتها.

لذلك Retention يجب أن ترتبط: بالعملية التشغيلية. وليس برقم شائع فقط.

هل 30 يومًا مدة إلزامية؟

لا. ليست هناك مدة واحدة مناسبة لجميع المشاريع. يجب التحقق من: متطلبات العميل.

سياسات المنشأة. وأي متطلبات تنظيمية تنطبق على نوع الموقع. لا تفترض أن كل مشروع يجب أن يحتفظ بالتسجيل:

30 يومًا. قد يحتاج: 7 أيام. أو أكثر.

التسجيل المستمر أم التسجيل بالحركة؟

هناك طريقتان شائعتان: Continuous Recording تسجيل 24/7.

Motion/Event Recording

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

حدث Analytics.

التسجيل بالحركة يمكن أن يقلل التخزين كثيرًا.

لكن لا يمكن حساب النسبة بدقة مسبقًا من دون معرفة: نشاط الموقع.

لماذا لا نقول إن Motion توفر 80% دائمًا؟

لأن المشاهد تختلف. كاميرا داخل: مستودع مغلق ليلًا قد لا تسجل إلا فترات محدودة.

كاميرا على شارع قد تعتبر الصورة في حركة معظم الوقت. أشجار تتحرك. إضاءة تتغير.

سيارات. عمال. قد تجعل: Motion Recording

تعمل لساعات طويلة. لذلك التوفير يعتمد على الموقع.

Motion Detection التقليدية ليست مثل AI Events

Motion التقليدية قد تستجيب لـ: تغير إضاءة. ظل. أشجار.

حشرة أمام العدسة.

الأنظمة الحديثة قد تدعم

Human detection. Vehicle detection. Line crossing. Intrusion.

التسجيل بناء على Analytics يمكن أن يقلل التسجيل غير المهم.

لكن لا تعتمد عليه دون اختبار دقته في البيئة الفعلية.

Pre-record وPost-record يضيفان بيانات

إذا الكاميرا تسجل عند الحركة فقط، قد تكون الإعدادات مثل: 5 ثوانٍ قبل الحدث. 30 ثانية بعد الحدث. هذه الإضافات

مفيدة حتى لا تفقد بداية الواقعة. لكنها تزيد مدة التسجيل الفعلية. لذلك التسجيل بالحركة ليس:

مدة الحدث نفسها فقط.

التسجيل المستمر أكثر أمانًا للتحقيق في بعض المواقع

إذا الحدث مهم ولا تريد الاعتماد على كشف الحركة، التسجيل المستمر يكون أكثر موثوقية من ناحية: عدم فقد لحظات.

خصوصًا الكاميرات الحرجة. مثل: البوابة.

الصندوق. منطقة تحميل. ممر رئيسي. ويمكن استخدام

Continuous في كاميرات حرجة. Motion في كاميرات أقل أهمية.

نموذج هجين للتسجيل

مثال: 4 كاميرات حرجة: 24/7. 12 كاميرا داخلية

Motion-based. هذا يمكن أن يقلل التخزين دون تقليل التوثيق في المناطق الحساسة.

كيف تحسب Motion Recording؟

أفضل طريقة: لا تعتمد على تخمين نظري فقط. شغل النظام عدة أيام.

راقب: عدد ساعات التسجيل الفعلي.

إذا كاميرا تسجل في المتوسط

8 ساعات من 24، فإن نسبة التسجيل: حوالي 33%. عندها

يمكن استخدام النسبة في تقدير السعة.

مثال Motion Recording

كاميرا: 4 Mbps. لو كانت 24/7: 43.2 GB/day.

إذا التسجيل الفعلي 25% من الوقت: حوالي: 10.8 GB/day.

لكن إذا الموقع تغير وأصبح أكثر حركة، قد ترتفع النسبة. لذلك

اترك هامشًا.

H.264 مقابل H.265

Codec هي طريقة ضغط الفيديو. H.264 شائعة ومتوافقة على نطاق واسع. H.265

يمكن أن تحقق كفاءة أعلى في التخزين والباندويث في كثير من الحالات. وهذا يعني صورة مشابهة نسبيًا بـBitrate أقل.

هل H.265 تخفض التخزين للنصف؟

ليس دائمًا. قد تحقق تخفيضًا كبيرًا. لكن النسبة تعتمد على: المشهد.

الجودة. الإعدادات. Hardware. لا تستخدم

"50% دائمًا" كقاعدة. الأفضل الاعتماد على Bitrate النهائية الفعلية.

H.265+ وSmart Codec

بعض الشركات توفر تقنيات مثل: H.265+. Smart Codec. Zipstream.

وغيرها. الفكرة: تقليل Bitrate في المشاهد الثابتة.

يمكن أن تخفض التخزين بشكل ملحوظ.

لكن: الكفاءة. الجودة. التوافق.

تختلف حسب الشركة. راقب النتيجة الفعلية.

لا تختصر التخزين على حساب جودة التحقيق

إذا خفضت Bitrate أكثر من اللازم قد ترى: الصورة جميلة في Live View صغير. لكن عند التكبير

تفاصيل: الوجه. لوحة المركبة. رقم على صندوق.

قد تصبح غير واضحة. التخزين ليس الهدف. الهدف: تسجيل مفيد.

Frame Rate وتأثيرها على التخزين

Frame Rate تقاس بـ: fps. مثل: 10fps.

15fps. 20fps. 25fps. 30fps.

زيادة FPS تعني عدد صور أكثر في الثانية. غالبًا تحتاج: Bitrate أعلى

للحفاظ على الجودة.

هل كل كاميرا تحتاج 25 أو 30fps؟

لا. كاميرا: ممر هادئ. مخزن.

باب. قد تعمل بكفاءة على 12–15fps في كثير من السيناريوهات.

بينما كاميرا تتابع: حركة سيارات. نقد.

عمليات سريعة. قد تحتاج Frame Rate أعلى.

لا تخفض Frame Rate عشوائيًا إلى 5fps

قد توفر تخزينًا. لكن عند حدث سريع: قد تنتقل المركبة أو اليد مسافة كبيرة بين Frame والأخرى. التسجيل يجب أن يناسب

الحدث الذي تريد تحليله.

Resolution وتأثيرها على التخزين

كلما ارتفعت الدقة: زداد عدد Pixels. لكن التخزين لا يتضاعف دائمًا بنفس النسبة

لأن الضغط يتغير. مثال 1080p. 4MP.

5MP. 8MP/4K. كل مستوى يحتاج Bitrate مناسبة.

لذلك استخدم: Bitrate في الحساب النهائي.

جدول تخطيطي تقريبي للـBitrate

هذه ليست قيمًا ثابتة. المشهد والCodec وFPS والجودة تؤثر بقوة.

VBR مقابل CBR

CBR Constant Bitrate. تحاول إبقاء معدل البيانات قريبًا من رقم ثابت. VBR

Variable Bitrate. تزيد أو تخفض البيانات حسب تعقيد المشهد. في CCTV VBR شائعة لأنها توفر مساحة في المشاهد الهادئة.

لكنها تجعل: حجم التسجيل أقل قابلية للتنبؤ بدقة.

كيف نحسب VBR؟

استخدم: Average Bitrate واقعية. أو: Maximum Bitrate

إذا تريد تصميمًا محافظًا جدًا. الأفضل عمليًا بعد تشغيل النظام: راقب Average Bitrate لكل قناة

خلال: نهار. ليل. أيام عمل.

عطلة. ثم عدّل الحساب.

الليل قد يرفع التخزين بدل أن يخفضه

يعتقد البعض أن الليل أقل حركة، إذن البيانات أقل. لكن مع: Low light noise. IR.

Digital gain.

يمكن أن تصبح الصورة مليئة بضوضاء صغيرة.

الـEncoder قد تعتبر هذه التفاصيل: تغيرات مستمرة. فتزيد Bitrate.

Noise Reduction تؤثر على التسجيل

تحسين: 3D DNR. Exposure. Lighting.

قد يقلل الضوضاء الليلية.

ويحسن: Compression efficiency. لذلك الإضاءة وضبط الكاميرا يؤثران على التخزين بشكل غير مباشر.

المطر والأشجار قد ترفع Bitrate

كاميرا خارجية ترى: أشجارًا. مطرًا. غبارًا.

المشهد يتحرك باستمرار.

VBR قد ترفع البيانات. لذلك معدل كاميرا خارجية ليس دائمًا مثل داخلية.

الكاميرات المطلة على الشارع

توجد: سيارات. مشاة. تغيرات مستمرة.

غالبًا تنتج Bitrate أعلى من: ممر داخلي هادئ. حتى لو

الدقة واحدة.

الصوت يزيد التخزين أيضًا

إذا تسجل Audio: هناك Audio bitrate. قد تكون مثل: 64kbps.

128kbps. مقارنة بالفيديو الحجم أصغر. لكن على:

عشرات الكاميرات. وأشهر من التسجيل، قد يصبح ملحوظًا. كذلك

يجب مراعاة المتطلبات القانونية والخصوصية قبل تسجيل الصوت.

لا تفعل Audio لأن الكاميرا تدعمه فقط

تسجيل الصوت أكثر حساسية من: الفيديو. يجب أن يكون له احتياج واضح

وأن يتوافق مع: السياسات والأنظمة المطبقة. إذا لا تحتاجه لا تضفه فقط لأنه متاح.

Main Stream وSub Stream

كثير من الكاميرات توفر: Main Stream. Sub Stream. وربما Stream ثالثة.

Main Stream عادة تستخدم: للتسجيل الرئيسي. Sub Stream

تستخدم: للمشاهدة عن بعد. Mobile. Multi-view.

إذا سجّلت أكثر من Stream

يزداد التخزين.

لا تحسب Main Stream وتنسى Extra Recording

بعض الأنظمة تسجل: Main. ثم نسخة Secondary. أو Analytics stream.

تأكد من إعدادات NVR. لا تفترض أن قناة واحدة=Stream واحدة محفوظة.

Edge Storage على SD Card

بعض الكاميرات تحتوي: microSD. يمكن استخدامها لـ: تسجيل احتياطي.

ANR. Standalone recording. هذا لا يلغي NVR.

لكنه يعطي مستوى إضافيًا من الحماية.

ما فائدة ANR؟

Automatic Network Replenishment أو وظائف مشابهة حسب الشركة تسمح للكاميرا بالتسجيل محليًا أثناء: انقطاع الشبكة. ثم رفع الجزء المفقود إلى NVR بعد عودة الاتصال. مفيدة

في المواقع التي قد يحدث فيها: Link interruption. لكنها تحتاج توافقًا بين الكاميرا وNVR.

SD Card ليست بديلًا مثاليًا عن NVR

لأنها: أصغر. أكثر عرضة للاستهلاك الكتابي. وقد تكون:

داخل الكاميرا نفسها. إذا سرقت الكاميرا قد تفقد التسجيل المحلي. لذلك

تستخدم كطبقة إضافية.

Cloud Recording

بعض الأنظمة تدعم تخزينًا سحابيًا. الميزة التسجيل خارج الموقع. لكن

يحتاج: Upload مستقرة. اشتراكًا. تكلفة شهرية.

وقد توجد قيود Bandwidth. Retention. Privacy.

التخزين المحلي مقابل السحابي

Hybrid Storage

يمكن استخدام: NVR محلية Cloud Clips للأحداث المهمة.

بدل رفع كل التسجيل 24/7. هذا قد يوازن التكلفة.

الإنترنت. والحماية.

لماذا تستخدم أقراص Surveillance HDD؟

أنظمة المراقبة تكتب بيانات: 24/7.

أقراص Surveillance مصممة عادة لتحمل:

Workload مستمر. عدد Streams. اهتزازات معينة في الأنظمة متعددة الأقراص. لذلك

ليست كل Hard Drive مناسبة بنفس الدرجة.

Desktop HDD ليست مصممة دائمًا لنفس الحمل

قرص Desktop قد يكون ممتازًا في: كمبيوتر شخصي. لكنه لا يعمل بالضرورة بنفس الكفاءة في:

NVR تكتب 24 ساعة. اختر Drive مخصصة للتسجيل أو معتمدة من الشركة المصنعة للنظام.

Compatibility List مهمة

بعض NVRs تدعم: أقصى حجم Disk معين. مثال حتى:

10TB لكل Bay. أو: 16TB. 18TB.

إذا اشتريت 22TB قد لا يتعرف عليها الجهاز. راجع

Storage compatibility.

عدد Bays يحدد مرونة التخزين

NVR يمكن أن تحتوي: 1 Bay. عدد Bays الأكبر يسمح: سعة أكبر.

RAID options. توسع أسهل. لا تختار NVR بعدد القنوات فقط.

مثال اختيار NVR

لديك حاجة: 24TB usable. NVR ذات: 2 bays

وحد أقصى: 10TB لكل قرص لن تكفي. حتى لو

تدعم 32 كاميرا. تحتاج عدد Bays أو سعة أقراص أكبر.

RAID ليست نسخة احتياطية

RAID تحمي في بعض الحالات من: تعطل Disk. لكنها لا تحمي من: حذف مقطع.

سرقة NVR. حريق. Malware. أو

تلف النظام بالكامل. لذلك: RAID ≠ Backup.

لماذا تستخدم RAID في أنظمة المراقبة؟

إذا قرص واحد تعطل في نظام بدون RAID، قد: تفقد تسجيلات كثيرة. RAID يمكن أن تسمح باستمرار النظام

أو إعادة بناء البيانات. حسب المستوى. لكنها تقلل: Usable Capacity.

RAID 1

تستخدم: قرصين متطابقين تقريبًا. البيانات تنسخ على الاثنين.

Raw: 20TB إذا: 2 × 10TB.

Usable: حوالي 10TB. الميزة تحمل فشل Disk واحدة عادة.

RAID 5

تحتاج عادة: 3 Disks أو أكثر. تعطي سعة أفضل من RAID1.

مع تحمل فشل قرص واحد. مثال 4 × 10TB.

Raw: 40TB. Usable تقريبًا: 30TB

قبل overhead.

RAID 6

تستخدم Parity إضافية. يمكنها عادة تحمل فشل قرصين. لكنها تضحي

بسعة أكبر. في أنظمة كبيرة قد تكون مناسبة.

RAID 10

تجمع: Mirroring. Striping. تحتاج

عدد أقراص زوجيًا. توفر Performance جيدة وRedundancy. لكن:

نصف السعة الخام تقريبًا تصبح usable.

جدول مبسط لـRAID

هذه تبسيطات عامة، ويجب الرجوع إلى تصميم النظام الفعلي.

RAID 0 ليست مناسبة عندما تحتاج حماية

RAID 0 تجمع الأقراص لزيادة: السعة. الأداء.

لكنها لا تقدم Redundancy.

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

أكبر TB. إذا التسجيل مهم.

Rebuild Time مهم في الأقراص الكبيرة

قرص: 18TB قد يحتاج وقتًا طويلًا لإعادة بناء RAID. خلال Rebuild

النظام يعمل تحت حمل. وإذا تعطل قرص آخر في بعض RAID levels يمكن أن تخسر Array.

لذلك الأقراص الأكبر ليست دائمًا أبسط حل.

Hot Spare

يمكن تخصيص Disk احتياطية داخل النظام. عند فشل قرص تبدأ إعادة البناء تلقائيًا على: Hot Spare.

هذا يقلل وقت انتظار الفني. لكنه يستهلك Bay وسعة.

SMART Monitoring

الأقراص تدعم مؤشرات صحة مثل: SMART. NVR قد تعرض Warnings.

Temperature. Bad sectors. يجب مراقبتها. لا تنتظر

حتى تختفي التسجيلات.

حرارة الأقراص تؤثر على عمرها

NVR فيها: 4 أو 8 أو 16 HDD يمكن أن تنتج: حرارة كبيرة.

يجب أن يكون المكان مهوى. لا تضع NVR داخل صندوق مغلق حار

خصوصًا في بيئات السعودية.

الحرارة والStorage Room

غرفة التسجيل تحتاج: تهوية. تكييفًا عند الحاجة. حماية من:

غبار. ماء. حرارة. وموقعًا آمنًا.

لا تجعل NVR في مستودع معدني شديد الحرارة ثم تتوقع عمرًا طويلًا للأقراص.

لا تضع NVR في مكان يمكن سرقتها بسهولة

إذا النظام يسجل حادثة سرقة ثم يستطيع السارق أخذ: NVR بسهولة،

تضيع القيمة. ضع Recorder في: غرفة مؤمنة.

Rack. موقع محدود الوصول.

من يجب أن يمتلك صلاحية حذف التسجيلات؟

كلما زاد عدد الأشخاص الذين لديهم: Admin access زاد خطر: الحذف.

التعديل. استخدم User roles. Logs.

ولا تعطي كلمة مرور المدير للجميع.

مدة الاحتفاظ يجب أن تكون سياسة مكتوبة

بدل أن يعرف الفني فقط أن: "الجهاز يمسح بعد شهر." وثق Retention target.

مثال: Cameras A: 30 days. Cameras B:

60 days.

حتى يتم التحقق دوريًا من أن النظام ما زال يحققها.

اختلاف مدة الاحتفاظ بين الكاميرات

لا تحتاج كل Camera الفترة نفسها. مثال: بوابات: 60 يومًا.

مكاتب داخلية: مناطق منخفضة الأهمية: إذا النظام يدعم ذلك يمكن تحسين استخدام التخزين.

تسجيل أعلى جودة في الكاميرات الحرجة

قد يكون من الأفضل: 8MP / High bitrate عند بوابة رئيسية. بينما

كاميرا عامة للمحيط: 4MP. بهذا تضع التخزين حيث له قيمة أعلى.

لا تجعل كل كاميرا 4K تلقائيًا

4K جذابة في المواصفات. لكن إذا: المشهد لا يحتاجها. المسافة كبيرة.

العدسة غير مناسبة. الإضاءة ضعيفة. فقد تدفع: Storage أكبر.

Bandwidth أعلى. دون تحسن عملي يناسب التكلفة.

Pixels on Target أهم من رقم 4K وحده

السؤال: هل هناك تفاصيل كافية على: وجه. مركبة.

هدف. وليس فقط كم عدد Pixels للصورة كاملة. إذا العدسة Wide جدًا

حتى 8MP قد لا تعطي: وجهًا واضحًا بعيدًا.

التخزين يجب أن يصمم بعد تصميم الكاميرات

الترتيب الصحيح: أحدد: هدف كل Camera. الموقع.

الدقة. العدسة. FPS. Bitrate.

ثم أحسب Storage. وليس أشتري 20TB أولًا

ثم أخفض جودة كل شيء لتناسبها.

التخزين هو نتيجة للتصميم وليس قيدًا عشوائيًا

إذا المشروع يحتاج: 32TB ليحقق المتطلبات، فالحل المهني ليس:

شراء 8TB ثم تخفيض الصورة إلى أدنى جودة. إما تزيد التخزين.

أو تعيد تصميم: Retention. Recording mode.

Camera priorities. بمنطق واضح.

كيف نقلل التخزين دون الإضرار الكبير بالجودة؟

يمكن العمل على: H.265. Smart Codec. FPS المناسبة.

VBR. Motion/Event Recording. تقليل Bitrate في كاميرات منخفضة الأهمية. Differentiated retention.

لكن كل تغيير يجب أن يراجع: جودة التحقيق.

ترتيب تقليل التخزين بشكل منطقي

قبل خفض: Resolution، جرب: Codec أكثر كفاءة.

ثم: VBR. ثم: FPS مناسبة.

ثم: Event recording حيث يصلح.

إذا ما زلت تحتاج خفضًا

راجع: مدة الاحتفاظ. لا تبدأ مباشرة بتحويل كل 8MP إلى:

720p.

كيف تختبر جودة التسجيل قبل اعتماد الإعدادات؟

لا تنظر إلى: Live View فقط. سجل مشاهد فعلية.

ثم صدّر: Clip. كبر: وجه.

لوحة. تفاصيل. راقب الحركة.

الليل. لأن Recording quality قد تختلف عن Preview.

اختبر النهار والليل

الكاميرا التي تبدو ممتازة: الساعة 2 ظهرًا قد تصبح: Noisy.

Smearing. Ghosting. ليلًا. التخزين والجودة

يجب التحقق منهما في الفترتين.

اختبار الأشخاص المتحركين

اجعل شخصًا: يمشي. يجري. إذا الموقع يحتاج ذلك.

راجع هل تفاصيل الوجه واضحة أثناء الحركة؟ إذا الصورة تصبح Motion blur

فرفع Storage وحده لا يحل المشكلة. قد تحتاج: Shutter. Lighting.

Camera placement.

اختبار المركبات

إذا الهدف: تمييز مركبة. لوحة. اختبر

مركبة حقيقية بالسرعة المتوقعة. لا تعتمد على سيارة متوقفة.

لماذا لا يكفي Bitrate Calculator من الشركة؟

الـCalculator مفيد. لكن يعطي: تقديرًا. المشهد الفعلي

قد يختلف. استخدمه في التصميم الأولي. ثم

تحقق بالبيانات الفعلية بعد التشغيل.

ما الفرق بين Average وMaximum Storage؟

إذا VBR: Average يمكن أن تكون: 4 Mbps. لكن Peaks تصل:

8 Mbps. التخزين طويل المدى يعتمد أكثر على: Average.

أما Bandwidth وسعة الشبكة قد تحتاج فهم الـPeak أيضًا.

لا تنسَ Incoming Bandwidth للـNVR

NVR قد تدعم: 160 Mbps. 256 Mbps. 320 Mbps.

إذا مجموع Bitrates للكاميرات أعلى من:

Incoming bandwidth قد لا يسجل النظام الكل بكفاءة. لذلك التخزين ليس القيد الوحيد.

مثال Incoming Bandwidth

32 كاميرا. كل واحدة: 8 Mbps. الإجمالي

256 Mbps. إذا NVR تدعم 160 Mbps فقط، فحتى لو لديها:

100TB Storage لن يكون التصميم مناسبًا.

Outgoing Bandwidth أيضًا مهمة

إذا عدة مستخدمين: يشاهدون الكاميرات. يصدرون Clips. NVR تحتاج

Outgoing throughput. خصوصًا في غرفة مراقبة.

Playback قدرة مختلفة عن Recording

بعض NVR تستطيع تسجيل: 32 Camera 4K. لكن لا تستطيع عرض: 32 قناة 4K

في الوقت نفسه بنفس Frame Rate. راجع Decoding capability.

هذا لا يغير التخزين مباشرة

لكنه جزء من اختيار NVR الصحيحة.

لا تختَر NVR فقط على رقم "32 Channel 4K"

اقرأ: Incoming bandwidth. HDD bays. Max HDD size.

RAID support. Decoding capability. Backup interfaces. هذه المواصفات

أهم من عنوان التسويق وحده.

مثال تصميم متكامل

المشروع: 20 Camera. 12 Camera داخلية 4MP.

3 Mbps. Continuous. 6 Camera خارجية 5MP.

5 Mbps. Continuous. 2 PTZ 8MP.

8 Mbps. Continuous. الحساب اليومي 12 × 3 × 10.8=388.8 GB.

6 × 5 × 10.8=324 GB. 2 × 8 × 10.8=172.8 GB. الإجمالي 885.6 GB/day.

30 يومًا 26.57 TB. مع هامش 20% نقترب من:

31.9 TB usable. إذا RAID 5 قد تحتاج Raw Capacity أعلى.

مثال باستخدام Motion Recording

نفس المشروع. لكن: 12 كاميرا داخلية تسجل 30% من الوقت.

الداخلية تصبح 388.8 × 0.30=116.64 GB/day. الخارجية PTZ

172.8. الإجمالي 613.44 GB/day. 30 يومًا

18.4 TB تقريبًا. مع هامش قد تخطط: 22TB usable أو أكثر.

بحسب النظام.

مثال 60 يومًا

إذا المشروع السابق: 613 GB/day. 60 يومًا ≈ 36.8 TB.

مع هامش قد تحتاج: 44TB تقريبًا. الفرق بين

30 و60 يومًا كبير جدًا. لذلك Retention لها أثر مباشر على التكلفة.

90 يومًا ليست ثلاثة أضعاف التكلفة دائمًا لكنها قريبة

من ناحية Storage الخام: تقريبًا نعم. إذا: نفس الكاميرات.

نفس Bitrate. نفس Mode. 90 يومًا تحتاج نحو ثلاثة أضعاف:

30 يومًا. لذلك لا تطلب 90 يومًا إذا لا توجد حاجة حقيقية.

Tiered Retention

يمكن استخدام: 60 يومًا للكاميرات الحرجة. 30

للعامة. 14 للكاميرات الأقل أهمية. هذا يقلل

السعة المطلوبة. لكن يجب أن تدعم المنصة: Retention policies مختلفة.

Archiving للأحداث المهمة

حتى لو النظام يحذف بعد: 30 يومًا، يمكن تصدير: Event clips

مهمة وتخزينها: مدة أطول. هذا أفضل من

الاحتفاظ بكل فيديو الموقع لسنوات دون حاجة.

لا تعتمد على Export يدوي فقط إذا هناك Events كثيرة

في المشاريع الكبيرة قد تحتاج: Incident Management. Bookmarking.

Case export. حتى لا تضيع المقاطع المهمة داخل التسجيل الدوري.

Export يجب أن يحافظ على Timestamp

عند تصدير التسجيل تأكد من: التاريخ. الوقت.

Camera ID.

لأن Clip بلا معلومات زمنية

تكون أقل فائدة في التحقيق.

مزامنة الوقت NTP

كل الكاميرات وNVR يجب أن تستخدم: وقتًا صحيحًا. إذا Camera تقول 10:00

وأخرى: 10:07، يصبح التحقيق في حدث متعدد الكاميرات صعبًا. NTP

مهم.

لا تغير Time Zone عشوائيًا

تأكد من: Time zone. DST settings.

السعودية لا تستخدم تغييرًا موسميًا للساعة حاليًا.

اضبط الأنظمة على المنطقة الصحيحة.

الوقت الخطأ لا يؤثر على Storage لكنه يؤثر على قيمة التسجيل

يمكن أن تملك: 90 يومًا من الفيديو. لكن إذا الساعة غير صحيحة: يصعب العثور على الحدث.

جودة النظام ليست TB فقط.

مدة البحث مهمة أيضًا

مئة تيرابايت من التسجيلات غير مفيدة إذا: البحث فيها صعب. استخدم: Events.

Bookmarks. Smart Search. Human/Vehicle filtering. عندما يدعم النظام.

Smart Search يمكن أن يقلل وقت التحقيق

بدل مشاهدة: 6 ساعات فيديو، يمكن البحث عن: حركة في منطقة.

شخص. مركبة. حسب قدرات النظام.

هذا لا يقلل Storage دائمًا

لكنه يزيد قيمة التسجيل.

Face Recognition وAnalytics قد تضيف بيانات إضافية

Metadata نفسها عادة أصغر بكثير من الفيديو. لكن الأنظمة المتقدمة قد تحتاج: Database. Licenses.

Compute.

لا تحسبها كجزء ضخم من Storage دون مراجعة.

التخزين المركزي أم عدة NVRs؟

موقع صغير: NVR واحدة. موقع كبير: قد يستخدم

عدة NVRs. أو VMS + Storage Servers. الاختيار يعتمد على

عدد الكاميرات. المباني. الأمان. Redundancy.

ما فائدة توزيع التسجيل بين عدة NVRs؟

إذا NVR واحدة تعطلت: لا تتوقف كل الكاميرات. كذلك يمكن توزيع:

Bandwidth. Storage. حسب المباني. لكن

الإدارة تصبح أكثر تعقيدًا.

Central VMS

في المشاريع الكبيرة يمكن استخدام: VMS تدير: عدة Recording Servers.

Storage arrays. تسمح بـ: Failover.

Permissions. Monitoring. لكنها أعلى تكلفة وتعقيدًا.

Failover Recording Server

في الأنظمة المتقدمة يمكن أن توجد: Recorder احتياطية.

إذا Server رئيسية تعطلت

تستلم الكاميرات. هذا يحتاج تخطيط Licensing وStorage.

لا تخلط Failover مع Backup

Failover: استمرار التشغيل. Backup: نسخة مستقلة من البيانات.

يمكن أن تمتلك Failover ممتازة لكن لا توجد نسخة خارجية من التسجيلات.

متى تحتاج نسخة احتياطية من التسجيل؟

ليس كل مشروع يحتاج: Backup لكل فيديو. لكن قد تحتاج للأحداث المهمة.

أو مواقع عالية الحساسية. الحل قد يكون Copy للـEvents فقط.

Cloud. Secondary recorder.

التسجيل المزدوج Dual Recording

بعض الكاميرات تستطيع التسجيل إلى: NVR A. NVR B. أو

NVR + SD. يرفع الاعتمادية. لكنه

يضاعف جزءًا من: Bandwidth. Storage.

لا تستخدم Dual Recording بلا حساب للشبكة

إذا كاميرا: 8 Mbps ترسل إلى: Server 1.

Server 2. قد يصبح: 16 Mbps traffic على بعض المسارات

بحسب Architecture. التخزين على كل جهة يحسب مستقلًا.

الموقع البعيد والمراقبة المركزية

مزرعة بعيدة قد تحتوي: NVR محلية. والمكتب الرئيسي يشاهد فقط:

Sub stream.

• هذا أفضل من إرسال
• كل Main stream
• 24/7 عبر الإنترنت

إذا الاتصال محدود.

Remote Viewing لا يعني Remote Recording

يمكن مشاهدة: NVR المحلية عبر الإنترنت. التسجيل يبقى

داخل الموقع. لا تحتاج Upload مساوية لكل Main streams طوال الوقت إلا إذا تسجل مركزيًا في موقع آخر.

إذا تسجل مركزيًا عبر الإنترنت، الحساب يتغير

مثال: 10 Cameras × 4 Mbps. تحتاج: 40 Mbps upload

مستقرة تقريبًا فقط لإرسال التسجيلات. إذا الإنترنت لا تتحمل سيفشل التصميم.

الأفضل أحيانًا Recording محلية + Remote viewing.

جودة الشبكة تؤثر على التسجيل المركزي

Packet loss. Jitter. انقطاع. قد ينتج

فجوات. لذلك Edge storage تزداد أهميتها عند التسجيل عبر WAN.

هل 4TB تكفي لمزرعة؟

لا يمكن الإجابة دون معلومات. نحتاج: عدد الكاميرات. Bitrate.

Codec. Recording mode. Retention. مثال

4 Camera × 2 Mbps. 24/7. يوميًا حوالي:

86.4GB. 4TB نظريًا قد تعطي: نحو 40 يومًا تقريبًا قبل overhead.

لكن 8 Camera × 8 Mbps ستستهلك السعة خلال: أيام قليلة نسبيًا.

هل 8TB تكفي لـ16 كاميرا؟

مرة أخرى: لا يوجد جواب ثابت. عند 2 Mbps 16 Camera:

345.6GB/day. 8TB حوالي: 23 يومًا تقريبًا Raw قبل overhead.

عند 5 Mbps نحو: 864GB/day. قد تنخفض المدة إلى:

حوالي 9 أيام تقريبًا.

إذن لماذا يبيع بعض الموردين "8 كاميرات + 2TB"؟

لأنها Package عامة. قد تكون مناسبة لعميل يريد: عدة أيام.

Motion. Bitrate منخفضة. لكنها لا تثبت أنها تحقق:

30 يومًا. يجب أن تسأل عن Retention الفعلية.

أهم سؤال عند مقارنة عروض CCTV

لا تسأل فقط: كم ميجابكسل؟ كم كاميرا؟ كم سعر؟

اسأل

كم يوم تسجيل فعلي يضمنه التصميم على الإعدادات المتفق عليها؟

ثم اطلب: الحساب. Bitrate المستخدمة. Recording mode.

نموذج مقارنة عرضين

العرض الثاني أسهل في التحقق.

لا تقبل عبارة "حتى 30 يومًا" دون شروط

قد تعني: على Motion. بأقل Bitrate. دون صوت.

وفي موقع هادئ جدًا. اطلب ما هي: Resolution؟

FPS؟ Bitrate؟ Recording mode؟ عدد الكاميرات؟

هامش التخزين مهم

الحساب النظري: 20TB. لا تشترِ 20TB usable تمامًا.

اترك مثلًا: 15–25% هامشًا حسب المشروع.

لماذا؟

تغير Bitrate. زيادة الحركة. تغير الليل. إضافة Camera.

اختلاف الحساب الفعلي.

لا تجعل الهامش بديلاً عن الحساب

شراء: ضعف التخزين ليس احترافًا إذا لا تعرف لماذا. الهدف

حساب منطقي Headroom.

التوسع المستقبلي يجب أن يدخل منذ البداية

إذا المشروع اليوم: 16 Camera. لكن الخطة: لا تصمم

NVR Storage بالكاد تكفي 16. قد تحتاج Bays إضافية. أو

Storage Server.

لا تترك Bays ممتلئة منذ اليوم الأول إذا التوسع قريب

إذا NVR تحتوي: 4 bays وأنت تركب: 4 disks

بالحد الأقصى، لن تستطيع التوسع بسهولة. قد تحتاج استبدال الأقراص

بدل إضافة. خطط Capacity Growth.

الأقراص الكبيرة مقابل عدد أكبر من الأقراص

4 × 18TB. أو: 8 × 8TB. ليست نفس:

التكلفة. الاعتمادية. RAID. التوسع.

الحرارة.

تصميم Storage يحتاج موازنة.

Workload Rating للأقراص

بعض HDD لها: Workload Rating سنوي.

في نظام عشرات الكاميرات

الكتابة المستمرة قد تكون عالية. لذلك اختر فئة مناسبة لـ: عدد القنوات.

حجم البيانات.

الأقراص يجب أن تكون من النوع نفسه في RAID عند الإمكان

خلط: أحجام. سرعات. فئات مختلفة.

قد يقلل الأداء أو يعقّد الإدارة. اتبع توصيات الشركة المصنعة.

لا تستبدل قرصًا فاشلًا بأي Disk متاحة عشوائيًا

راجع: Capacity. Interface. Compatibility.

Workload class. خصوصًا داخل RAID.

مراقبة مدة الاحتفاظ نفسها

بعد التشغيل لا تكتفِ برؤية: "HDD Healthy." افتح

أقدم تسجيل متاح. إذا اليوم: 30 أكتوبر وأقدم Recording:

24 أكتوبر، فأنت تحفظ: 6 أيام فقط. هذا أهم اختبار.

Retention Audit شهرية

يمكن شهريًا تسجيل: Oldest available recording. Free/used capacity. Drive health.

أي Alerts.

إذا مدة الاحتفاظ تنخفض

اعرف السبب قبل أن تصل إلى حادثة تحتاج تسجيلًا أقدم.

لماذا قد تنخفض مدة الاحتفاظ مع الوقت؟

إضافة Cameras. رفع Resolution. رفع FPS. تغير Scene.

زيادة حركة. إضافة Audio. تغير Codec. تعطل Motion rules.

كلها يمكن أن ترفع التخزين.

Firmware Update قد تغير Encoding behavior

بعد Update راجع: Bitrate. Smart codec.

Recording profiles. لا تفترض أن كل الإعدادات بقيت نفسها.

إعدادات الكاميرا قد تعود إلى Default

بعد: Reset. Replacement.

Camera جديدة قد تعمل على:

Higher bitrate. وفجأة تنخفض Retention. لذلك

استخدم: Configuration standards.

أنشئ Camera Profile موحدة

مثال: Profile A – Gate. 5MP. 20fps.

5 Mbps. H.265. Continuous. Profile B – Indoor.

4MP. 15fps. 3 Mbps. Motion.

هذا يسهل الإدارة والحساب.

لا تستخدم Profile واحدة لكل الكاميرات

لأن: البوابة. المخزن. مكتب.

سور خارجي. كلها احتياجات مختلفة.

جدول Profiles نموذجية

الأرقام أمثلة تخطيطية وليست إعدادات ملزمة.

كيف توثق الحساب في المشروع؟

أنشئ Sheet تحتوي على: Camera ID. Location. Resolution.

Codec. FPS. Bitrate. Recording mode.

Recording percentage. Retention days. Daily GB. Total TB.

ثم RAID. Headroom. Final usable requirement.

نموذج جدول حساب

30 يومًا ≈ 23.2TB. مع 20% هامش ≈ 27.8TB usable.

لا تنسَ RAID بعد حساب usable

إذا تحتاج: 28TB usable. وقررت RAID 5 مع 4 أقراص × 10TB:

Raw: 40TB. Usable نظريًا: 30TB تقريبًا.

قد تكون قريبة جدًا من المطلوب بعد Overhead. ربما الأفضل سعة أعلى.

التصميم يجب أن يترك مساحة تشغيلية

إذا Usable: 30TB. والحاجة: 29.5TB.

أنت عمليًا بلا Headroom. ارفع السعة.

أو عدّل الإعدادات.

متى تستخدم NAS للتسجيل؟

بعض الأنظمة تسمح بـ: NAS. iSCSI. Network storage.

يمكن أن تعطي: سعة أكبر. توسعًا. لكنها

تضيف: Network dependency. Management. لا تستخدمها

لمشروع بسيط بلا حاجة.

SAN وStorage Arrays

في مشاريع المراقبة الكبيرة جدًا يمكن استخدام: Enterprise storage. خصوصًا مئات أو آلاف الكاميرات.

لكن هذه Architecture مختلفة تمامًا عن: NVR منزلية.

لا تضع Storage Traffic مع كل Traffic الأخرى بلا تخطيط

إذا Cameras ترسل مئات Mbps إلى: Storage server، يجب أن تتحمل Switches.

Uplinks. NICs. الشبكة نفسها.

سعة التخزين ليست Disk فقط.

كتابة 500 Mbps إلى Storage طوال اليوم

تعني: حمل مستمر. تحتاج Disk array.

Network. Controller. كلها قادرة على Sustained write.

التخزين والـPoE موضوعان منفصلان

PoE تحسب: الطاقة. Storage تحسب: البيانات.

قد يكون لديك PoE Budget ممتازة لكن HDD صغيرة. أو

Storage ضخمة وسويتش لا تشغل الكاميرات. كلا النظامين يجب تصميمهما.

لا تجعل NVR هي نقطة الفشل الوحيدة

إذا المشروع حساس، فكر في: RAID. Edge recording. Failover.

Secondary recorder. بحسب مستوى الأهمية. لا يحتاج كل منزل هذا المستوى.

الأمن السيبراني للتسجيل مهم

NVR تحتوي: بيانات حساسة. لذلك احمِ:

الحسابات. Firmware. Remote access. ولا تعرض

NVR مباشرة للإنترنت بطريقة غير آمنة.

النسخ الاحتياطي لإعدادات NVR

ليس فقط التسجيل. Backup configuration مهمة. إذا الجهاز تعطل

تستطيع إعادة: Camera mappings. Users. Recording schedules.

بسرعة.

لا تخزن نسخة الإعداد داخل NVR فقط

إذا الجهاز نفسه تعطل تفقد: النسخة. احتفظ

بنسخة خارجية آمنة.

Export الحوادث المهمة

إذا وقع Incident لا تنتظر حتى تقترب Retention من نهاية المدة. صدّر

المقطع. وأنشئ نسخة موثقة. واحتفظ

بها وفق سياسة الجهة.

Hashing وEvidence Management

في المشاريع التي تحتاج: Chain of custody قد توجد آليات تحقق من: سلامة الملف.

هذا يتجاوز الاستخدام المنزلي العادي.

لكن في المنشآت الحساسة يمكن أن يكون مهمًا.

لا تعدل التسجيل الأصلي عند استخدامه للتحقيق

إذا تحتاج نسخة: Compressed. Blurred. Annotated.

احتفظ بالملف الأصلي. وأنشئ نسخة للعمل.

الوقت المطلوب لتصدير تسجيل طويل

إذا طلب العميل: 24 ساعة من 16 كاميرا،

حجم الملفات قد يكون ضخمًا.

التخطيط للـExport مهم.

قد تحتاج: USB 3. Network copy. Storage destination.

لا تنسَ مساحة جهاز التصدير

قد يكون NVR يحتوي التسجيل. لكن USB المستخدمة: 64GB. لا تكفي

لـ500GB Export. جهز وسائط مناسبة.

الأقراص الخارجية ليست أرشيفًا أبديًا

إذا تحتفظ بـEvidence لسنوات تحتاج: سياسة. عدة نسخ.

فحص. لا تعتمد على HDD واحدة في درج.

Data Retention Policy تساعد على عدم التخزين بلا نهاية

التخزين غير المحدود: يزيد التكلفة. المخاطر. الإدارة.

احتفظ بما تحتاجه للمدة المطلوبة. واحذف

وفق السياسة والأنظمة المنطبقة.

الخصوصية جزء من تخطيط التسجيل

كلما زادت: مدة الاحتفاظ. جودة الصورة. نقاط التغطية.

زادت كمية البيانات الشخصية المحتملة.

لذلك يجب أن يكون التسجيل مرتبطًا: بغرض مشروع. وصلاحيات محددة.

لا تجعل مدة الاحتفاظ أطول فقط لأن الأقراص رخيصة

السؤال ليس: هل أستطيع الاحتفاظ سنة؟ بل هل أحتاج؟

هل يسمح النظام والسياسة؟ من سيصل إليها؟

وما مخاطر البيانات؟

تصميم التخزين للمزرعة أو الاستراحة

في المزرعة قد توجد: كاميرات بوابات. حظائر. مستودعات.

طرق.

أفضل تقسيم يمكن أن يكون:

بوابة رئيسية: جودة أعلى + Retention أطول. مناطق عامة: إعداد متوسط.

مناطق منخفضة الحركة: Motion recording.

مثال مزرعة

12 Camera: 4MP. 3 Mbps. 24/7.

يوميًا 12 × 3 × 10.8 ≈ 388.8GB. 30 يومًا

≈ 11.7TB. مع 20% ≈ 14TB usable. إذا أردت

60 يومًا تقترب من: 28TB usable.

تصميم التخزين للمستودعات

المستودع قد يحتاج: Loading docks. Aisles. Cash/dispatch area.

Gates. مناطق التحميل حركة عالية. تحتاج

Bitrate أعلى أحيانًا. بينما ممر هادئ يمكن أن يستخدم إعدادًا مختلفًا.

تصميم التخزين للمنزل

عادة: عدد أقل. Retention قد تكون: 7–30 يومًا

بحسب الاحتياج. Motion recording يمكن أن تكون فعالة. لا تحتاج

RAID Enterprise غالبًا.

تصميم التخزين للمنشآت الحرجة

قد تحتاج: Redundant recorders. RAID. Edge storage.

Longer retention. Monitoring. Alerts. وتوثيقًا أقوى.

لا تستخدم نظام منزل لمشروع صناعي كبير

NVR بسيطة قد تدعم: 64 قناة نظريًا. لكن Storage architecture.

Cooling. RAID. Throughput. قد لا تناسب

المشروع.

مراقبة فشل الأقراص

فعّل: Email alerts. SNMP. System alarms.

إن كانت المنصة تدعم. لا تعتمد على شخص يفتح صفحة Storage مرة كل ستة أشهر.

Disk Failure يجب أن يكون لها Runbook

إذا Disk تعطلت: من يلاحظ؟ من يطلب البديل؟

هل توجد Spare؟

هل RAID تعمل؟ كم وقت Rebuild؟ الإجراءات يجب أن تكون معلومة في المشاريع الكبيرة.

لا تستبدل عدة أقراص في RAID دفعة واحدة بلا فهم

يمكن أن تسبب: Data loss. اتبع Procedure الشركة المصنعة.

إذا لست مختصًا استخدم فنيًا.

Backup Battery للـRAID Controller

في بعض Storage systems المتقدمة، Controllers قد تستخدم: Cache protection.

هذه تفاصيل Enterprise.

لكنها مهمة في الأنظمة ذات الكتابة العالية.

UPS مهمة لحماية NVR والأقراص

انقطاع الكهرباء المفاجئ يمكن أن: يوقف التسجيل. ويؤثر على: File system.

RAID rebuild. UPS مناسبة تساعد على: استمرار التشغيل.

Graceful shutdown.

لكن UPS لا تزيد مدة التخزين

هي تحمي: استمرارية التسجيل. لا تغير TB المطلوبة.

• لا تخلط
• Power redundancy
• مع

Storage capacity.

الكهرباء المستقرة تحمي الأقراص

التوقفات المتكررة وإعادة التشغيل القسرية ليست بيئة جيدة لـ: HDD arrays.

لذلك تصميم الطاقة جزء من موثوقية التسجيل.

لا تضع التخزين في نفس المكان المعرض للمياه

Rack تحت: مواسير. وحدة تكييف تقطر. خطر.

اختر موقعًا مناسبًا.

مراقبة الرطوبة والغبار

الأقراص ليست مصممة للعمل داخل: غبار كثيف. حرارة شديدة. الغرفة الجيدة

تطيل عمر: NVR. Disks. Switches.

ماذا لو امتلأت NVR قبل المتوقع؟

ابدأ بالتحقق من: عدد الكاميرات. Bitrate. FPS.

Codec. Recording mode. Audio. ثم

هل تم إضافة Channels؟ لا تبدأ بحذف التسجيل يدويًا.

ماذا لو مدة الاحتفاظ أطول بكثير من المطلوب؟

قد يعني: Bitrate منخفضة. Motion كثيرة. أو

Storage أكبر من اللازم.

لا تقلل الجودة تلقائيًا.

إذا النظام يحقق: جودة جيدة وRetention أطول، قد يكون هذا:

هامش مفيد.

ماذا لو إحدى الكاميرات تستهلك ثلاثة أضعاف غيرها؟

راجع: Scene motion. Noise. Codec.

FPS. Bitrate cap. Camera settings. قد تكون

الكاميرا طبيعية لأن مشهدها أكثر حركة. أو تحتاج ضبطًا.

Monitoring per-camera bitrate

في الأنظمة الجيدة يمكن مشاهدة: Current bitrate. Average.

يساعد على كشف: Outliers. مثال

15 كاميرا حول: 3 Mbps. واحدة: 18 Mbps.

تستحق الفحص.

لا تستخدم Bitrate منخفضة جدًا فقط لتحقيق عدد أيام معين

إذا مطلوب: 30 يومًا ولا توجد Storage كافية، الحل ليس:

خفض كل قناة حتى تصبح الوجوه غير قابلة للتعرف. اعرض على العميل الخيارات: زيادة Storage.

تقليل Retention. استخدام Motion. خفض FPS بشكل مدروس. القرار

يجب أن يكون واضحًا.

مستويات مختلفة للجودة حل أفضل أحيانًا

مثال: Gate: 8 Mbps. Warehouse:

4 Mbps. Office: 2 Mbps. بدل

4 Mbps للجميع. هذا يطابق أهمية كل منطقة.

Recording Schedule

يمكن ضبط: 24/7. Motion. Events.

حسب: الأيام. الساعات. مثال

مكتب يعمل: 8–5. بعد الدوام: Motion فقط.

لكن لا تنشئ Schedule معقدة يصعب إدارتها.

Schedule المعقدة قد تسبب فجوات غير مقصودة

إذا أخطأت في: جدول الجمعة. Holiday. AM/PM.

قد لا تسجل ساعات. لذلك اختبر: Timeline

بعد الإعداد.

لا تفترض أن اللون الأخضر في Schedule يعني ما تظنه

كل شركة تستخدم: ألوانًا. Modes. بشكل مختلف.

افتح Recorded Timeline وتأكد فعليًا.

اختبار Retention قبل التسليم

بعد تشغيل النظام لعدة أسابيع: افتح أقدم Recording. قارن

بالهدف. إذا الهدف: 30 يومًا. والمتاح:

يجب تعديل: Storage أو Settings.

لا تسلم المشروع قبل وجود بيانات كافية إن أمكن

إذا المشروع جديد اليوم لا يمكنك إثبات: 30 يومًا. لكن

يمكن: حساب التصميم. ثم تنفيذ Audit بعد:

أسبوعين. شهر. للتأكد.

نموذج تقرير بعد 30 يومًا

التخزين يجب أن يدخل ضمن الصيانة الدورية

صيانة CCTV لا تعني: تنظيف العدسة فقط. يجب فحص: Disk health.

Retention. Recording gaps. Time sync. Export test.

Playback.

اختبار Playback شهريًا مفيد

اختر: كاميرا عشوائية. وقتًا عشوائيًا. شغل

التسجيل. لا تعتمد على Icon يقول: Recording.

Recording Gaps قد تحدث رغم أن Disk سليمة

الأسباب: Network interruptions. Camera reboot. NVR restart.

Schedule. License. لذلك تحقق من Timeline.

Heatmap للفجوات

في نظام كبير يمكن إنشاء تقارير: Missing recording. لكل Camera.

يساعد على معرفة: هل المشكلة محلية أم عامة.

لا تعتبر 99% Recording uptime كافية دائمًا

1% فقدان يومي: 14.4 دقيقة. إذا الحدث وقع خلالها لا يهم أن النظام كان يعمل:

99%. المواقع الحرجة تحتاج مستوى أعلى.

Redundancy يجب أن تتناسب مع تكلفة فقدان التسجيل

منزل: ربما NVR واحدة تكفي. مستودع عالي القيمة: قد يحتاج

RAID + SD + UPS. منشأة حساسة: قد تحتاج Failover + secondary storage.

لا تشتري أعلى مستوى لكل موقع

المطلوب: Risk-based design. اسأل ما تكلفة:

فقد يوم؟ فقد ساعة؟ فقد Camera واحدة؟ ثم

صمم.

تكلفة التخزين ليست فقط HDD

تشمل: NVR/Server. Disks. RAID controller.

Rack. Cooling. UPS. Backup.

Maintenance. لذلك لا تقارن مشروعين بسعر الأقراص فقط.

نطاقات تخطيطية عامة للأقراص

الأسعار تختلف كثيرًا حسب: السعة. العلامة. الفئة.

السوق. لذلك الأفضل عند التخطيط مقارنة:

تكلفة لكل TB usable وليس سعر القرص فقط.

Cost per Usable TB

مثال: 4 × 10TB RAID5. Raw: 40TB.

Usable: ≈30TB.

إذا تكلفة الأقراص كلها

4,000 ريال، تكلفة Storage hardware لكل usable TB: ≈133 ريال قبل NVR والتبريد وبقية العناصر.

هذا مجرد مثال حسابي.

لا تنسَ تكلفة التوسع

إذا اليوم تشتري NVR 2-bay ثم بعد سنة تحتاج: 40TB.

قد تستبدل الجهاز كاملًا.

NVR أكبر من البداية قد تكون أوفر إذا التوسع مؤكد.

لكن لا تشتري Data Center لمشروع 4 Cameras

التوازن مهم. منزل صغير يحتاج: حلًا بسيطًا.

مجمع كبير يحتاج: Scalable storage.

كيف تقارن بين NVRs من ناحية التخزين؟

راجع: عدد HDD bays. Max HDD capacity. RAID support.

Hot swap. Incoming bandwidth. H.265 support. Smart codec.

External storage support.

Failover. Health monitoring.

Hot Swap

يعني إمكانية استبدال Disk في بعض الأنظمة دون إطفاء النظام. مهم

في المشاريع التي لا تريد توقف التسجيل. لكن يجب تنفيذ الاستبدال وفق إجراءات النظام.

لا تسحب Disk من NVR عشوائيًا

حتى لو يوجد: Hot Swap. يجب التأكد أي Disk فشلت.

وضع RAID. واتباع Procedure.

Recording Server تحتاج نظام تشغيل مناسب

في VMS الكبيرة Storage server قد تعمل على: Windows Server. Linux.

Appliance. يجب إدارة: Updates. Antivirus exclusions.

Disk policies. حسب Vendor.

لا تستخدم Consumer NAS بلا اعتماد في مشروع مهم

قد تعمل. لكن إذا Vendor لا تدعمها قد تواجه: مشكلات.

استخدم Storage معتمدة للنظام.

Bandwidth Calculator وStorage Calculator يجب أن يعملا معًا

نفس Bitrate التي تحدد: Storage تحدد أيضًا: Network bandwidth.

إذا مجموع: 200 Mbps إلى Recorder، يجب أن تتحمل:

Switch. Uplink. NIC. باستمرار.

مثال شبكة تسجيل

40 Camera × 5 Mbps. الإجمالي 200 Mbps. على 1GbE

من ناحية الرقم النظري يوجد هامش. لكن يجب إضافة: Viewing.

Overhead. Other traffic. وربما استخدام Uplinks أعلى في الأنظمة الكبيرة.

لا تضع كاميرات على Wi-Fi إذا التسجيل حرج بلا سبب

Wireless قد يكون مناسبًا لبعض الحالات. لكن PoE Ethernet غالبًا أكثر استقرارًا للـCCTV الثابتة.

كل انقطاع Wireless قد ينتج: Recording gap.

إن كانت Camera على 5G أو Wireless Bridge

تأكد من: Local SD. ANR. لأن

WAN قد تنقطع. هذا مهم في المواقع البعيدة.

تخزين الكاميرات على الطرق الطويلة في المزارع

قد تستخدم: Remote cabinets. Wireless bridges. إذا Link تنقطع

Edge recording تساعد. لكن احسب: SD endurance.

Retention local.

SD Endurance

microSD العادية قد تتآكل بسرعة مع: Continuous recording. استخدم High-endurance cards

عندما تكون مخصصة للتسجيل المستمر.

لا تعتمد على SD غير معروفة السعة الحقيقية

البطاقات المقلدة منتشرة في بعض الأسواق. اختبر Capacity. Health.

واستخدم مصادر موثوقة.

Storage Encryption

بعض الأنظمة تدعم: Encryption. مفيدة لحماية البيانات.

لكنها قد تؤثر على: Recovery. Performance. ويجب إدارة

Keys. إذا فقدت المفتاح قد تفقد التسجيل.

كلمة مرور NVR لا تحمي Disk إذا نُزعت دائمًا

يعتمد ذلك على النظام.

إذا التسجيلات غير مشفرة

قد يستطيع مختص قراءة Disk خارج الجهاز. لذلك المواقع الحساسة قد تحتاج: Encrypted storage.

نسخ التسجيل خارج الموقع

يمكن أن يتم: Cloud. Secondary site. أو

Export للأحداث. هذا يحمي من: سرقة Recorder. حريق.

لكن يرفع: Bandwidth. التكلفة.

لا تبنِ Off-site recording على اتصال غير مناسب

إذا لديك: 100 Mbps upload لكن التسجيل يحتاج: 150 Mbps،

لن يستقر. احسب قبل التنفيذ.

Retention السحابية قد تكون أقصر لأسباب تكلفة

يمكن أن يكون: 30 يومًا محليًا. 7 أيام Cloud Events. هذا نموذج منطقي

في بعض المشاريع. ليس لازمًا أن تتطابق الطبقتان.

ماذا تفعل عند توسعة النظام؟

قبل إضافة Camera: احسب: Bitrate. Storage.

NVR incoming bandwidth. PoE. License. لا تضف

ثم تنتظر المشاكل.

Expansion Checklist

• هل يوجد Channel؟
• هل يوجد PoE Port؟
• هل يوجد Network capacity؟
• هل توجد Storage؟
• هل Retention ستتأثر؟
• هل License متوفرة؟
• هل UPS تتحمل؟

مثال إضافة 4 Cameras

كل واحدة: 6 Mbps. التخزين اليومي 4 × 6 × 10.8

≈ 259.2GB/day. 30 يومًا ≈ 7.8TB.

إضافة أربع Cameras فقط

قد تحتاج: قرابة 8TB إضافية usable. لذلك التوسعة ليست بسيطة دائمًا.

لا تنسَ أن Upgrade Resolution تساوي تقريبًا Camera جديدة من ناحية التخزين أحيانًا

تحويل:

• 16 كاميرا
• من 2 Mbps
• إلى 4 Mbps

يضاعف: البيانات. كأنك أضفت 16 قناة إضافية من ناحية Storage.

تغيير FPS قد يكون له أثر مشابه

من: 10fps إلى: 25fps

قد يرفع Bitrate المطلوبة. لذلك أي تغيير Profile يجب أن يمر على:

Storage review.

من يجب أن يوافق على تغيير إعدادات الكاميرا؟

في مشروع منظم: ليس أي فني. لأن رفع Bitrate Camera واحدة

قد يبدو بسيطًا. لكن تكراره على 50 Camera يؤثر على:

Storage. Network.

Change Management

سجل: ما الإعداد القديم؟ الجديد؟ السبب؟

أثره على Storage. بعد التغيير راجع:

Retention.

لا تعمل Factory Reset بلا Backup للإعدادات

قد تعود: Resolution. Bitrate. Schedules.

إلى Default. النتيجة Storage تختلف.

قائمة فحص قبل حساب السعة

• عدد الكاميرات معروف.
• موديلات الكاميرات محددة.
• دقة كل مجموعة معروفة.
• Frame Rate معروفة.
• Codec محددة.
• Bitrate التصميمية معروفة.
• VBR/CBR معروفة.
• التسجيل مستمر أم أحداث محدد.
• نسبة Motion متوقعة عند استخدامها.
• الصوت داخل الحساب عند الحاجة.
• Retention لكل مجموعة محددة.
• التوسع المستقبلي معروف.

قائمة فحص اختيار NVR

• عدد القنوات يكفي.
• Incoming bandwidth تكفي.
• عدد HDD bays مناسب.
• Max disk size مناسبة.
• H.265 مدعومة.
• RAID المطلوبة مدعومة.
• Hot spare مدعومة عند الحاجة.
• Storage expansion ممكنة.
• Health monitoring متوفرة.
• Backup configuration ممكنة.
• Playback/decoding تكفي غرفة المراقبة.
• Compatibility مع الكاميرات مؤكدة.

قائمة فحص الأقراص

• Surveillance-grade أو معتمدة.
• السعة متوافقة مع NVR.
• عدد الأقراص مناسب للـRAID.
• جميع الأقراص سليمة.
• Firmware/SMART طبيعي.
• الحرارة ضمن الحدود.
• Bay labels واضحة.
• Spare متوفرة عند الحاجة.
• Warranty موثقة.

قائمة فحص بعد التشغيل

• كل Camera تسجل.
• Main stream المطلوبة محفوظة.
• Audio تعمل فقط حيث مطلوبة.
• Recording schedule صحيحة.
• أقدم Recording تحقق.
• Retention قريبة من التصميم.
• Bitrate الفعلية راجعت.
• Cameras ذات الاستهلاك العالي حددت.
• Disk health سليمة.
• NVR temperature طبيعية.
• لا توجد Recording gaps.
• الوقت متزامن.

قائمة فحص بعد 30 يومًا

• أقدم تسجيل لكل مجموعة راجع.
• مدة الاحتفاظ الفعلية موثقة.
• Total storage utilization راجعت.
• Average bitrate حدثت.
• Nighttime bitrate راجعت.
• Motion percentage راجعت.
• الأقراص سليمة.
• RAID Healthy.
• Export test نفذ.
• UPS اختبرت.
• Alerts تعمل.
• Capacity expansion forecast حدث.

الأخطاء الأكثر شيوعًا في حساب التخزين

الخطأ الأول: الحساب بعدد الكاميرات فقط.

الخطأ الثاني: استخدام Resolution دون Bitrate.

الخطأ الثالث: نسيان التسجيل المستمر 24/7.

الخطأ الرابع: افتراض أن Motion توفر نسبة ثابتة.

الخطأ الخامس: استخدام Raw Capacity بدل Usable.

الخطأ السادس: نسيان RAID overhead.

الخطأ السابع: خفض جودة الصورة فقط لتحقيق عدد أيام.

الخطأ الثامن: استخدام Desktop HDD غير مناسبة للحمل.

الخطأ التاسع: تجاهل حرارة غرفة التسجيل.

الخطأ العاشر: عدم اختبار أقدم Recording بعد التشغيل.

الخطأ الحادي عشر: نسيان Incoming bandwidth للـNVR.

الخطأ الثاني عشر: إضافة Cameras دون إعادة حساب Retention.

أخطاء إضافية ترفع تكلفة المشروع

تركيب 4K في كل مكان بلا حاجة. استخدام 25fps لجميع الكاميرات تلقائيًا. عدم استخدام H.265 عندما تكون الأجهزة متوافقة. ترك Bitrate على أعلى قيمة لكل Camera.

تسجيل Audio غير مطلوب.

تسجيل Streams إضافية بلا حاجة.

شراء NVR بعدد Bays قليل.

الاعتماد على "حتى 30 يومًا" من المورد دون حساب. عدم ترك Headroom. وعدم فصل الكاميرات الحرجة عن العامة في سياسات التسجيل.

سيناريو: 16 كاميرا و8TB فقط

المتوسط: 4 Mbps. التخزين اليومي 16 × 4 × 10.8

≈ 691GB. 8TB تقريبًا: 11 يومًا Raw

قبل overhead. إذا العميل يريد 30 يومًا، النظام غير كافٍ.

سيناريو: 8 كاميرات 4K لكن Motion فقط

إذا الموقع هادئ قد تعطي: 30 يومًا بسعة أقل بكثير من Continuous.

لكن يجب تشغيل النظام ومراجعة: Actual recording percentage.

لا تعتمد على التخمين.

سيناريو: التخزين كان 30 يومًا ثم أصبح 18

تمت إضافة: 6 Cameras. ولم يعد أحد يحسب السعة.

الحل إما: زيادة Storage. أو

إعادة ضبط Policies. وليس حذف ملفات يدويًا.

سيناريو: كاميرا خارجية تستهلك أكثر من الجميع

المشهد: أشجار. حركة مستمرة. ضوضاء ليلية.

VBR ترفع Bitrate. الحل فحص:

DNR. Exposure. Smart codec. وليس

خفض الجودة مباشرة.

سيناريو: NVR لا ترى HDD الجديدة

القرص: 22TB. NVR القديمة تدعم حتى:

10TB لكل Bay. المشكلة Compatibility. لا تعني

أن Disk تالفة.

سيناريو: RAID5 لكنها ما زالت لا تحقق 30 يومًا

4 × 10TB. Raw: 40TB. Usable:

≈30TB. المشروع يحتاج: 35TB usable. RAID سليمة.

لكن السعة غير كافية.

سيناريو: 30 يومًا متوفرة لكن التحقيق صعب

كل Camera لها: وقت مختلف. البحث عن حادثة يحتاج ساعات.

المشكلة Time sync. لا Storage.

سيناريو: التسجيل يتوقف عند انقطاع الشبكة

Camera بعيدة عبر: Wireless bridge. لا توجد SD. كل انقطاع

يخلق Gap.

Edge recording يمكن أن تساعد.

سيناريو: NVR سُرقت

كل التسجيلات كانت داخلها فقط. هنا RAID لم تفد. تحتاج

Off-site copy أو Cloud events إذا المخاطر تبرر.

سيناريو: العميل يريد سنة كاملة من التسجيل

قبل قبول الطلب احسب: تكلفة Storage. الخصوصية.

سياسة البيانات.

• وقد يكون
• Archiving للأحداث المهمة
• أكثر منطقية

من حفظ كل Camera 365 يومًا.

سيناريو: متجر يريد مراجعة 60 يومًا

يمكن أن تكون: Cameras الصندوق: 60 يومًا. كاميرات الممرات:

Cameras الخارجية العامة:

14 أو 30. حسب الاحتياج. هذا يقلل السعة مقارنة بتطبيق 60 يومًا على الجميع.

سيناريو: مزرعة فيها إنترنت ضعيف

لا تستخدم: Cloud-only recording إذا Upload غير مستقرة. الأفضل

Local NVR. Remote viewing عبر: Sub stream.

وCloud للأحداث المهمة إذا احتاج.

سيناريو: مصنع يحتوي 120 كاميرا

هنا لا يكفي التفكير في: "كم TB؟" تحتاج VMS.

Recording servers. Storage arrays. RAID. Bandwidth.

Failover. Monitoring.

هذا مشروع بنية تحتية متكامل.

الأسئلة الشائعة

كيف أحسب تخزين كاميرات المراقبة؟

اجمع معدل Bitrate لكل الكاميرات، وحوله إلى حجم يومي، ثم اضربه في عدد أيام الاحتفاظ وأضف هامشًا مناسبًا.

كم تحتاج كاميرا 4 Mbps يوميًا؟

تقريبًا 43.2 جيجابايت عند التسجيل المستمر 24 ساعة.

كم تحتاج خلال 30 يومًا؟

حوالي 1.3 تيرابايت تقريبًا لكل كاميرا 4 Mbps قبل الهامش والـOverhead.

هل 4MP تعني حجم تسجيل ثابتًا؟

لا. التخزين يتأثر بالـBitrate وFPS والCodec والمشهد وطريقة التسجيل.

هل 4K تحتاج أربعة أضعاف 1080p؟

ليس دائمًا، لأن الضغط والإعدادات تختلف. استخدم Bitrate الفعلية للحساب.

ما أهم رقم في الحساب؟

متوسط Bitrate التصميمية أو الفعلية لكل كاميرا.

هل H.265 توفر مساحة؟

نعم غالبًا مقارنة بـH.264 عند إعدادات متقاربة، لكن مقدار التوفير يختلف.

هل H.265+ أفضل؟

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

هل التسجيل بالحركة يقلل التخزين؟

نعم، أحيانًا كثيرًا، لكن مقدار التوفير يعتمد على عدد ساعات الحركة الفعلية.

هل يمكن حساب Motion بنسبة 20% دائمًا؟

لا. موقع مزدحم قد يسجل معظم اليوم، بينما موقع هادئ قد يسجل دقائق فقط.

هل AI Motion أفضل؟

يمكن أن تقلل التنبيهات والحركات غير المهمة إذا كانت مضبوطة جيدًا، لكنها تحتاج اختبارًا.

هل التسجيل المستمر أفضل؟

من ناحية عدم فقد الأحداث، نعم غالبًا، لكنه يحتاج Storage أكبر.

ما أفضل حل؟

يمكن استخدام تسجيل مستمر للكاميرات الحرجة وMotion للكاميرات الأقل أهمية.

كم يوم تسجيل أحتاج؟

يعتمد على احتياج المشروع والسياسات والمتطلبات المنظمة، وليس هناك رقم واحد للجميع.

هل 30 يومًا رقم إلزامي؟

ليس بالضرورة. تحقق من متطلبات الموقع والجهة.

هل NVR 32 Channel تكفي لـ32 كاميرا؟

من ناحية القنوات ربما، لكن يجب أيضًا مراجعة Incoming bandwidth والتخزين والـHDD bays.

ما هي Incoming Bandwidth؟

إجمالي كمية بيانات الكاميرات التي تستطيع NVR استقبالها في الثانية.

هل التخزين الكبير يعوض Incoming Bandwidth ضعيفة؟

لا. يجب أن تكون NVR قادرة على استقبال Streams أصلًا.

ما هي Usable Capacity؟

المساحة التي تستطيع استخدامها فعليًا بعد RAID والتهيئة والـOverhead.

لماذا 10TB لا تظهر 10TB كاملة؟

بسبب اختلاف وحدات الحساب والتهيئة ومساحة النظام.

ما الفرق بين Raw وUsable؟

Raw هي مجموع أحجام الأقراص، أما Usable فهي المساحة المتاحة فعليًا للتسجيل.

هل RAID تزيد مساحة التخزين؟

ليست بالضرورة. RAID تستخدم جزءًا من الأقراص لتحقيق Redundancy حسب المستوى.

هل RAID Backup؟

لا. RAID تحمي من بعض حالات فشل الأقراص، لكنها ليست نسخة احتياطية مستقلة.

ما أفضل RAID للمراقبة؟

يعتمد على حجم النظام ومستوى الاعتمادية والسعة المطلوبة. RAID5 و6 و10 تستخدم في سيناريوهات مختلفة.

هل RAID5 تفقد سعة Disk واحدة؟

تقريبًا نعم في الحساب المبسط لمجموعة متساوية الأقراص.

هل RAID6 أفضل من RAID5؟

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

هل أحتاج RAID للمنزل؟

ليس دائمًا. يعتمد على أهمية التسجيل والميزانية.

هل أقراص الكمبيوتر العادية مناسبة لـNVR؟

يمكن أن تعمل، لكن أقراص Surveillance مصممة عادة لأحمال الكتابة المستمرة وأنظمة المراقبة.

هل SSD أفضل من HDD للتسجيل؟

SSD أسرع وأقل ضجيجًا، لكنها أغلى لكل TB غالبًا، وHDD ما زالت شائعة جدًا للتسجيلات الكبيرة.

هل يمكن استخدام NAS؟

نعم إذا النظام يدعمها وتم تصميم الشبكة والتخزين بصورة مناسبة.

هل يمكن التخزين على Cloud فقط؟

تقنيًا نعم في أنظمة معينة، لكن يعتمد بقوة على الإنترنت والتكلفة والسياسة.

هل Cloud تحتاج Upload كبيرة؟

نعم إذا ترفع Streams كاملة بصورة مستمرة.

هل Remote Viewing تستهلك نفس Bandwidth التسجيل؟

ليس إذا التسجيل محليًا. المشاهدة عن بعد يمكن أن تستخدم Sub stream أقل.

ما هي Sub Stream؟

Stream أخف تستخدم غالبًا للمشاهدة عن بعد أو العرض المتعدد.

هل يجب تسجيل Sub Stream؟

ليس عادة إلا إذا هناك سبب واضح.

هل الصوت يزيد التخزين؟

نعم، لكن عادة بدرجة أقل بكثير من الفيديو.

هل أسجل الصوت؟

فقط إذا هناك حاجة واضحة ومسموح بذلك وفق السياسات والأنظمة.

هل الليل يستهلك تخزينًا أقل؟

ليس دائمًا. Noise وIR والحركة يمكن أن تزيد Bitrate.

لماذا Camera خارجية تستخدم Storage أكثر؟

قد يكون بسبب حركة المشهد أو الضوضاء أو المطر أو الأشجار أو Bitrate أعلى.

هل Frame Rate تؤثر؟

نعم. زيادة FPS غالبًا تحتاج Bitrate أعلى للحفاظ على جودة مماثلة.

هل 30fps ضرورية لكل Camera؟

لا. بعض المواقع تعمل جيدًا على 12–15fps حسب الهدف.

هل أخفض FPS لتوفير المساحة؟

يمكن، لكن يجب التأكد أن الحركة المطلوبة ما زالت واضحة.

هل أخفض Resolution أولًا؟

ليس بالضرورة. يمكن تجربة Codec وVBR وFPS وRecording mode قبل خفض الدقة.

كيف أعرف أن الجودة كافية؟

صدّر تسجيلًا فعليًا لليل والنهار وحاول قراءة التفاصيل التي تحتاجها مثل الوجه أو المركبة.

هل Live View تكفي؟

لا. يجب فحص التسجيل المحفوظ نفسه.

ما أهمية NTP؟

توحيد وقت الكاميرات وNVR حتى يمكن ربط الأحداث بين القنوات.

ماذا لو الوقت غير صحيح؟

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

هل microSD مفيدة؟

نعم كـEdge recording أو Backup أثناء انقطاع الشبكة.

هل SD بديل عن NVR؟

عادة لا، بل طبقة إضافية.

ما هي ANR؟

وظيفة تسمح لبعض الأنظمة بجلب التسجيل الذي حفظته الكاميرا محليًا أثناء انقطاع الاتصال.

هل 8TB تكفي لـ16 Camera؟

يعتمد على Bitrate وطريقة التسجيل. قد تعطي أيامًا قليلة أو أسابيع حسب الإعدادات.

كيف أعرف مدة التسجيل الحالية؟

افتح أقدم Recording موجودة في Timeline وقارن تاريخها بتاريخ اليوم.

لماذا Retention تقل مع الوقت؟

إضافة Cameras أو رفع Bitrate أو FPS أو تغير المشهد أو تشغيل الصوت.

كم Headroom أضيف؟

لا يوجد رقم ثابت، لكن 15–25% نطاق تخطيطي مناسب في كثير من المشاريع حسب مستوى التوسع والتغير.

هل يجب حساب التوسع المستقبلي؟

نعم، خصوصًا إذا هناك خطة لإضافة Cameras خلال فترة قصيرة.

ما أهم خطأ عند شراء NVR؟

اختيارها بعدد Channels فقط دون حساب Bandwidth وStorage وHDD bays.

ما أهم خطأ عند شراء HDD؟

شراء سعة كبيرة غير مدعومة من NVR أو نوع غير مناسب للتسجيل المستمر.

هل أكبر Disk دائمًا أفضل؟

لا. قد تؤثر على RAID rebuild والتكلفة والتوافق والتوسع.

ماذا أفعل إذا Disk تعطلت؟

اتبع إجراءات النظام، واستبدلها بقرص متوافق، وراقب RAID rebuild إذا كانت موجودة.

هل UPS مهمة للتسجيل؟

نعم لتقليل توقف التسجيل وحماية الأنظمة من الانقطاع المفاجئ.

هل UPS تزيد عدد أيام التسجيل؟

لا، هي تحمي الاستمرارية فقط.

هل يمكن أن أحتفظ ببعض Cameras 60 يومًا وبعضها 30؟

نعم إذا النظام يدعم Retention policies منفصلة.

هل يمكن أرشفة أحداث معينة لسنوات؟

نعم عبر Export أو Archive مستقل وفق سياسة الجهة.

ماذا يجب أن أطلب من المورد في العرض؟

عدد القنوات، Bitrate الافتراضية، Recording mode، مدة الاحتفاظ المحسوبة، Raw وUsable storage، نوع الأقراص وRAID إن وجدت.

هل عبارة "حتى 30 يومًا" كافية؟

لا. يجب معرفة الظروف والإعدادات التي تحقق الرقم.

ما أفضل طريقة للتأكد من صحة التصميم؟

الحساب أولًا، ثم تشغيل النظام ومراجعة Bitrate الفعلية ومدة الاحتفاظ بعد فترة كافية.

قائمة الفحص النهائية لحساب التخزين

• عدد الكاميرات النهائي معروف.
• دقة كل Camera موثقة.
• Bitrate التصميمية معروفة.
• Codec محددة.
• FPS محددة.
• Continuous/Motion محددة.
• نسبة التسجيل بالحركة مقدرة عند الحاجة.
• الصوت محسوب إذا مستخدم.
• Retention لكل مجموعة محددة.
• Daily GB محسوبة.
• إجمالي TB محسوبة.
• Headroom مضافة.
• RAID أثرها محسوب.
• Usable Capacity وليس Raw فقط محسوبة.
• Max HDD size متوافقة مع NVR.
• عدد Bays يسمح بالسعة المطلوبة.
• Incoming bandwidth مناسبة.
• التوسع المستقبلي محسوب.
• HDD من فئة مناسبة للتسجيل.
• UPS موجودة عند الحاجة.
• غرفة التسجيل مناسبة حراريًا.
• Disk health ستتم مراقبتها.
• أقدم Recording ستراجع بعد التشغيل.
• Export test ستنفذ.
• Time sync صحيحة.
• Edge recording موجودة في المواقع الحرجة عند الحاجة.
• سياسة حفظ المقاطع المهمة موثقة.

الخلاصة

حساب تخزين كاميرات المراقبة لا يبدأ من:

كم عدد الكاميرات؟

ولا من:

كم ميجابكسل؟

السؤال الأساسي هو:

كم بيانات تنتج كل Camera خلال الثانية؟

ومن هنا تبدأ المعادلة. إذا كانت Camera تسجل: 4 Mbps على مدار 24 ساعة،

فهي تنتج تقريبًا: 43GB يوميًا. خلال: 30 يومًا

نقترب من: 1.3TB. لكاميرا واحدة. إذا لديك:

16 Camera، يمكن أن تتجاوز الحاجة: 20TB بسهولة. وإذا كانت Bitrate أعلى، قد تصل إلى:

30 أو 40TB أو أكثر. بعد ذلك ضع في الحساب: طريقة التسجيل. التسجيل المستمر يستهلك أكثر.

Motion يمكن أن توفر كثيرًا إذا كانت البيئة مناسبة. لكن لا تستخدم نسبة افتراضية بلا اختبار. ثم راجع: Codec.

H.265 وSmart Codec يمكن أن تعطي كفاءة أفضل، لكن لا تجعل تقليل الملفات أهم من الحفاظ على: تفاصيل قابلة للاستخدام. ولا تستخدم: FPS عالية

في كل Camera تلقائيًا. كما لا تخفضها إلى درجة تفقد معها الحركة. صمم كل مجموعة حسب الوظيفة. Gate ليست مثل:

ممر داخلي. PTZ ليست مثل: Camera مراقبة عامة. بعد ذلك حدد:

Retention. لا تقل: "نبغى أكبر عدد ممكن." اسأل:

متى نكتشف الحوادث؟ كم يومًا نحتاج فعليًا؟ هل كل Camera تحتاج المدة نفسها؟ قد تجد أن:

البوابات تحتاج 60 يومًا. وباقي الموقع 30. وهذا يمكن أن يوفر كمية كبيرة من التخزين. ثم احسب:

Usable Storage. لا Raw فقط. إذا ركبت: 4 × 10TB

داخل RAID5، فأنت لا تحصل على: 40TB كاملة للتسجيل. راجع:

RAID. الـOverhead. ومتطلبات NVR. ولا تنسَ:

Incoming bandwidth. فـNVR التي لا تستطيع استقبال Bitrate الكاميرات لن تنجح مهما كانت HDD كبيرة. بعد التشغيل، لا تعتمد على الحساب إلى الأبد. راقب:

Actual bitrate. Disk health. Temperature. Recording gaps.

وأهم شيء:

أقدم تسجيل متاح.

إذا التصميم يقول: 30 يومًا لكن النظام يحتفظ: 18 يومًا،

فهناك فرق يجب إصلاحه. وقد يكون السبب: إضافة كاميرات. رفع الجودة.

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

للاستفسار والمراسلة: 0531266622