> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # تخزين تسجيلات كاميرات المراقبة: كم قرصاً تحتاج فعلاً؟ - URL: https://arabroot.io/articles/تخزين-تسجيلات-كاميرات-المراقبة-وحساب-الاقراص/ - Published: 2026-10-28T10:14:34.000Z - Updated: 2026-10-28T11:39:46.000Z - Description: كيف تحسب مساحة تسجيلات كاميرات المراقبة وعدد الأيام من معدل البت الحقيقي، وما الإعدادات التي تضاعف عمر القرص نفسه. - Author: فريق عرب رووت - Tags: الأدلة التقنية, مجالات متخصصة, هوم لاب, الاستضافة الذاتية لنفرض أن لديك شركة ناشئة تبيع قطع غيار السيارات عبر الإنترنت، ولها مستودع صغير ومكتب، وقررت أن تركب ثماني كاميرات مراقبة بدقة 1080p على المداخل وممرات الرفوف ومنطقة التحميل. وجاء عرض المورد بجهاز تسجيل NVR فيه قرص واحد 4TB، ومكتوب بجانبه «يحفظ التسجيلات شهراً كاملاً». وبعد ثلاثة أسابيع من التركيب اختفت شحنة من منطقة التحميل، فطلب مدير المستودع تسجيل يوم الشحن، فوجد أن أقدم تسجيل على الجهاز عمره أحد عشر يوماً فقط. فلا أحد حذف شيئاً، ولا يوجد عطل في الجهاز، وإنما الرقم «شهر كامل» لم يكن مبنياً على أي حساب. وهذه القصة تتكرر بأشكال كثيرة، والسبب أن المساحة التي تأخذها تسجيلات الكاميرات لا تحددها الدقة ولا عدد الكاميرات وحدهما، وإنما معدل البت Bitrate الذي تخرجه كل كاميرا فعلاً، وهو يتغير مع المشهد والإعدادات بفروق تصل إلى عشرة أضعاف. لذلك سوف نحسب في هذا المقال المساحة كما يجب أن تحسب: من أرقام قسناها بأنفسنا على مقاطع كاميرات حقيقية، ثم نجرب ماذا يحدث عندما يمتلئ القرص فعلاً، ثم نبني خطة احتفاظ Retention تجعل نفس القرص يحفظ شهراً من الأحداث المهمة. وإذا كانت مصطلحات مثل NVR وRTSP ومعدل البت جديدة عليك، فابدأ بمقال [أنواع كاميرات المراقبة وكيف تختار بينها](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%83%D8%A7%D9%85%D9%8A%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%A8%D9%8A%D9%86%D9%87%D8%A7/). وسوف نناقش في هذا المقال ما يلي: - معادلة المساحة الكاملة، ولماذا يخطئ الحساب من ورقة المواصفات. - تجربة تقيس معدل البت الحقيقي على ثلاثة مشاهد: هادئ ومزدحم وفيه ضجيج يشبه الليل، مع أثر المعدل الثابت CBR والمتغير VBR والضغط H.265 والدقة وعدد الإطارات. - لماذا يحفظ قرص 4TB أقل من 4TB، بالأرقام الحقيقية من نظام الملفات ext4. - طرق الاحتفاظ بالتسجيلات: المستمر، وعند الحركة، وعند الأحداث، ولماذا لا يسكن المشهد الخارجي أبداً. - تجربة نملأ فيها قرص المسجل عمداً، ثم نضيف قاعدة احتفاظ ونرى الفرق. - نوع القرص وحمل الكتابة Workload، والشبكة، وأين تضع الأقراص: منفصلة أم RAID. - كم يوماً تحتاج أصلاً، ثم خطة احتفاظ كاملة للشركة، وقائمة تحقق تستخدمها مع أي عرض. ## المعادلة: من معدل البت إلى عدد الأيام الحساب نفسه بسيط ولا يحتاج أي أداة: معدل البت بالبت في الثانية، ضرب 86,400 ثانية في اليوم، ثم تقسم على 8 لتحول البت إلى بايت، فتحصل على البايتات التي تكتبها الكاميرا في اليوم، ثم تضرب في عدد الكاميرات، ثم تقسم المساحة المتاحة فعلاً على الناتج فتحصل على عدد الأيام. والصورة التالية تطبق المعادلة على كاميرات الشركة بالأرقام التي سوف نقيسها في التجربة: ![أربع بطاقات مرقمة من اليمين: معدل البت 3994 كيلوبت قسناه من بث الكاميرا ضرب 86400 قسمة 8 يعطي 43.1 جيجابايت لكل كاميرا في اليوم، ثم ضرب ثماني كاميرات يعطي 345 جيجابايت في اليوم، ثم القرص الحقيقي 4 تيرابايت تساوي 3.64 تيبي بايت وبعد بيانات نظام الملفات ext4 بنسبة 1.6% وحجز 5% للمدير يبقى 3.74 تيرابايت للتسجيل، ثم عدد الأيام 3.74 تيرابايت قسمة 345 جيجابايت يساوي 10.8 يوماً وليس شهراً كما في العرض](https://arabroot.io/content/images/2026/10/recording-storage-01-formula.webp) نفس الحساب الذي لم يقم به أحد في عرض السعر، بالأرقام الحقيقية والعرض لم يكذب في الدقة ولا في حجم القرص، وإنما افترض معدل بت أقل بكثير من الذي تخرجه الكاميرات بإعداداتها الافتراضية، أو حسب على أساس أن الكاميرات تسجل عند الحركة فقط، ثم ركبها الفني على التسجيل المستمر. وفي كل الحالات الخطأ نفسه: الرقم الوحيد الذي يهم في المعادلة هو معدل البت الحقيقي، وهذا الرقم لا تجده في ورقة المواصفات، فالورقة تقول ما تستطيعه الكاميرا، لا ما تخرجه في مكانها. لذلك قبل أي شيء آخر عليك أن تعرف كيف تقيس هذا الرقم، وما الذي يغيره. ### المعدل الثابت CBR والمعدل المتغير VBR كل كاميرا شبكية تعطيك في صفحة إعدادات الفيديو خياراً بين طريقتين للتحكم في معدل البت، وهذا الخيار وحده قد يغير المساحة بنسبة كبيرة: - **المعدل الثابت CBR:** اختصار Constant Bitrate، تحدد فيه رقماً مثل 4096 كيلوبت، فتحاول الكاميرا أن تخرج هذا المعدل طوال الوقت، فإذا كان المشهد ساكناً صرفت البتات على تفاصيل لا تحتاجها، وإذا كان مزدحماً خفضت الجودة حتى لا تتجاوزه. وميزته الوحيدة أن المساحة معروفة مسبقاً بدقة، وعيبه أنك تدفع ثمن أسوأ مشهد في كل ثانية. - **المعدل المتغير VBR:** اختصار Variable Bitrate، تحدد فيه مستوى جودة وحداً أعلى للمعدل، فتخرج الكاميرا بتات قليلة عندما يسكن المشهد، وبتات أكثر عندما يتحرك، حتى الحد الأعلى. وهو ما ننصح به لأغلب الكاميرات، بشرط أن تحسب المساحة على المعدل الذي تقيسه في أكثر ساعات اليوم ازدحاماً، وليس على متوسط ساعة هادئة. ## تجربة: معدل البت الحقيقي على ثلاثة مشاهد الكلام السابق يبقى نظرياً حتى ترى الأرقام، لذلك أخذنا مقطعين حقيقيين منشورين في الملكية العامة: [تسجيل كاميرا مراقبة ثابتة على موقف سيارات](https://commons.wikimedia.org/wiki/File:BLK-HDPTZ12%5FSecurity%5FCamera%5FParking%5FLot%5FSurveillance%5FVideo.webm?ref=arabroot.io) فيه سيارات قليلة تتحرك وأشجار وغيوم، وسميناه المشهد الهادئ، و[تصويراً بفاصل زمني لموقف مزدحم](https://commons.wikimedia.org/wiki/File:Tower%5FFall%5Fparking%5Farea%5Ftimelapse%5F%2836948468311%29.webm?ref=arabroot.io) من هيئة المتنزهات الوطنية الأمريكية، فيه سيارات وأشخاص يتحركون في كل إطار، وسميناه المشهد المزدحم. ثم صنعنا مشهداً ثالثاً بإضافة ضجيج متغير إلى المشهد الهادئ، يشبه ما يحدث في حساس الكاميرا ليلاً عندما ترفع الكاميرا الحساسية، ونذكر بوضوح أن هذا الضجيج مضاف وليس تصويراً ليلياً حقيقياً. وفي كل الحالات ضغطنا الفيديو كما تضغطه الكاميرات: بدقة 1920×1080 و15 إطاراً في الثانية، دون إطارات من نوع B، وإطار مفتاحي I-Frame كل ثانيتين، ثم قسنا معدل البت بأداة ffprobe. والسكربت `matrix.sh` كما يلي: ```bash # Measure the bitrate a camera setting really produces, on three scenes: # quiet = 60 s of a fixed parking-lot CCTV camera, busy = 30 s timelapse of a crowded car park, # noisy = the quiet scene with added temporal grain (a stand-in for sensor noise at night). # Every encode: x264/x265 without B-frames, key frame every 2 s, like a camera. Output: kbps and GB/day. cd /work src() { case $1 in quiet) echo "-t 60 -i /samples/parking.webm" ;; busy) echo "-t 30 -i /samples/towerfall.webm" ;; noisy) echo "-t 60 -i /samples/parking.webm" ;; esac; } vf() { case $1 in noisy) echo "$2,noise=alls=10:allf=t" ;; *) echo "$2" ;; esac; } run() { # scene label filter fps codec-args scene=$1; label=$2; f=$3; fps=$4; shift 4 ffmpeg -v error -y $(src $scene) -an -vf "$(vf $scene "scale=$f,fps=$fps")" -bf 0 -g $((fps*2)) -keyint_min $((fps*2)) -sc_threshold 0 "$@" out.mp4 b=$(ffprobe -v error -show_entries format=bit_rate -of csv=p=0 out.mp4) awk -v s=$scene -v l="$label" -v b=$b 'BEGIN { printf "%-6s %-34s %6d kbps %6.1f GB/day\n", s, l, b/1000, b*86400/8/1e9 }' } for scene in quiet busy noisy; do run $scene "1080p 15fps H.264 VBR (CRF 23)" 1920:1080 15 -c:v libx264 -preset veryfast -crf 23 -maxrate 6M -bufsize 12M run $scene "1080p 15fps H.264 CBR 4 Mbps" 1920:1080 15 -c:v libx264 -preset veryfast -b:v 4M -minrate 4M -maxrate 4M -bufsize 4M -x264-params nal-hrd=cbr run $scene "1080p 15fps H.265 VBR (CRF 28)" 1920:1080 15 -c:v libx265 -preset fast -crf 28 -x265-params bframes=0:log-level=error done ``` ونشغله داخل Image الخاصة ب MediaMTX لأنها تحمل ffmpeg 8.1.2 مع المكتبتين libx264 وlibx265، والمقطعان في مجلد `media`: ```bash mkdir -p work docker run --rm --name scv-matrix -v "$PWD:/lab" -v "$PWD/work:/work" -v "$PWD/media:/samples:ro" \ --entrypoint sh bluenviron/mediamtx:1.21.1-ffmpeg /lab/matrix.sh ``` والمخرج سوف يكون كما يلي: ```text quiet 1080p 15fps H.264 VBR (CRF 23) 2366 kbps 25.6 GB/day quiet 1080p 15fps H.264 CBR 4 Mbps 3994 kbps 43.1 GB/day quiet 1080p 15fps H.265 VBR (CRF 28) 1400 kbps 15.1 GB/day busy 1080p 15fps H.264 VBR (CRF 23) 6052 kbps 65.4 GB/day busy 1080p 15fps H.264 CBR 4 Mbps 3996 kbps 43.2 GB/day busy 1080p 15fps H.265 VBR (CRF 28) 6726 kbps 72.6 GB/day noisy 1080p 15fps H.264 VBR (CRF 23) 6060 kbps 65.5 GB/day noisy 1080p 15fps H.264 CBR 4 Mbps 3996 kbps 43.2 GB/day noisy 1080p 15fps H.265 VBR (CRF 28) 9543 kbps 103.1 GB/day ``` في المخرج أعلاه لاحظ التالي: - المعدل الثابت CBR أعطى نفس الرقم تقريباً في المشاهد الثلاثة، 43.1 جيجابايت في اليوم لكل كاميرا، وهذا هو الرقم الذي استخدمناه في حساب الشركة، لأن أغلب الكاميرات تأتي بإعداد CBR قريب من 4 ميجابت لدقة 1080p. - المعدل المتغير VBR في المشهد الهادئ أعطى 2366 كيلوبت فقط، أي 25.6 جيجابايت في اليوم، وهذا توفير 41% من نفس القرص دون أن تفقد شيئاً من الجودة، لأن CBR كان يصرف البتات على مشهد لا يتغير. - نفس إعداد VBR في المشهد المزدحم وفي مشهد الضجيج وصل إلى الحد الأعلى الذي وضعناه وهو 6 ميجابت، أي 65.4 جيجابايت في اليوم، وهذا أكثر من CBR نفسه. لذلك الكاميرا التي تنظر إلى شارع مزدحم، أو تعمل ليلاً بضجيج عال، قد تأخذ في VBR أكثر مما تتوقع، والحد الأعلى Max Bitrate هو الذي يحميك هنا. - CBR في المشهد المزدحم بقي عند 4 ميجابت، ولكن ثمن ذلك أن الجودة نزلت في اللحظات التي تحتاجها فعلاً، أي عندما يتحرك كل شيء في الصورة. - أرقام H.265 تحتاج قراءة حذرة، لأن مستوى CRF 28 في H.265 لا يعني نفس الجودة التي يعنيها CRF 23 في H.264، فالمقارنة الصحيحة تحتاج قياس الجودة، وهذا ما فعلناه في الخطوة التالية. ### هل يوفر H.265 نصف المساحة فعلاً؟ كثير من العروض تقول إن H.265 يوفر نصف المساحة، والطريقة الوحيدة لاختبار هذه الجملة أن تجعل الجودة متساوية ثم تقارن الحجم. لذلك حفظنا كل مشهد مرة واحدة كفيديو خام غير مضغوط ليكون المرجع، ثم ضغطناه ب H.264 بمستوى CRF 23، وب H.265 بثلاثة مستويات، وقسنا لكل نسخة مقياس التشابه SSIM مع المرجع، حيث 1 تعني تطابقاً تاماً. وهذا الجزء من السكربت `matrix2.sh`: ```bash for scene in quiet busy; do ffmpeg -v error -y $(src $scene) -an -vf scale=1920:1080,fps=15 -c:v rawvideo -pix_fmt yuv420p -f nut ref.nut ffmpeg -v error -y -i ref.nut -c:v libx264 -preset veryfast -bf 0 -crf 23 -g 30 -sc_threshold 0 o.mp4 ss=$(ffmpeg -i o.mp4 -i ref.nut -lavfi ssim -f null - 2>&1 | grep -o 'All:[0-9.]*') line $scene "H.264 CRF 23" $(kb o.mp4) "SSIM $ss" for c in 24 26 28; do ffmpeg -v error -y -i ref.nut -c:v libx265 -preset fast -crf $c -x265-params bframes=0:keyint=30:scenecut=0:log-level=error o.mp4 ss=$(ffmpeg -i o.mp4 -i ref.nut -lavfi ssim -f null - 2>&1 | grep -o 'All:[0-9.]*') line $scene "H.265 CRF $c" $(kb o.mp4) "SSIM $ss" done done ``` والمخرج سوف يكون كما يلي: ```text quiet H.264 CRF 23 2366 kbps 25.6 GB/day SSIM All:0.991738 quiet H.265 CRF 24 2484 kbps 26.8 GB/day SSIM All:0.991988 quiet H.265 CRF 26 1876 kbps 20.3 GB/day SSIM All:0.990193 quiet H.265 CRF 28 1400 kbps 15.1 GB/day SSIM All:0.987993 busy H.264 CRF 23 6740 kbps 72.8 GB/day SSIM All:0.988271 busy H.265 CRF 24 10124 kbps 109.3 GB/day SSIM All:0.988293 busy H.265 CRF 26 8243 kbps 89.0 GB/day SSIM All:0.984940 busy H.265 CRF 28 6726 kbps 72.6 GB/day SSIM All:0.980673 ``` والنتيجة مختلفة عما يقوله التسويق، وفي المخرج أعلاه لاحظ التالي: - في المشهد الهادئ، نسخة H.265 التي تساوي H.264 في الجودة تقريباً هي CRF 24 بمقياس 0.9920 مقابل 0.9917، وحجمها أكبر قليلاً لا أصغر، ونسخة CRF 26 وفرت 21% مقابل جودة أقل قليلاً. - في المشهد المزدحم، H.265 بنفس الجودة احتاج 10,124 كيلوبت مقابل 6,740 في H.264، أي أنه أكبر بنحو النصف، ولم يتساو الحجم إلا عند CRF 28 بجودة أقل بوضوح. - هذا لا يعني أن H.265 سيئ، وإنما يعني أن الوعد بنصف المساحة يعتمد على المرمز Encoder وإعداداته، فقد استخدمنا مرمزات برمجية بإعدادات سريعة ودون إطارات B كما تفعل الكاميرات، ومقياس SSIM نفسه يعاقب بعض تحسينات x265 التي تستهدف العين لا الرياضيات. وشريحة الضغط في كاميرتك مرمز آخر تماماً بنتائج أخرى. - الدرس العملي: لا تحسب المساحة بنسبة توفير مكتوبة في كتيب، وإنما فعل H.265 في كاميرا واحدة يوماً كاملاً، ثم اقرأ حجم تسجيلاتها الحقيقي، وتذكر أن بعض المتصفحات والبرامج لا تعرض H.265 أصلاً، كما ذكر [مقال أنواع الكاميرات](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%83%D8%A7%D9%85%D9%8A%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%A8%D9%8A%D9%86%D9%87%D8%A7/#resolution-bitrate). ### الدقة وعدد الإطارات: أيهما يوفر أكثر؟ الخطوة الأخيرة في القياس أن نثبت الجودة لكل إطار ونغير الدقة وعدد الإطارات، فاستخدمنا مكمماً ثابتاً QP 28، وهو يجعل كل إطار يضغط بنفس الدرجة كما يفعل مرمز الكاميرا تقريباً، وهذا هو الجزء الأول من `matrix2.sh`: ```bash for scene in quiet busy; do for cfg in "1920:1080 5" "1920:1080 10" "1920:1080 15" "1920:1080 25" "1280:720 15" "640:360 10"; do set -- $cfg ffmpeg -v error -y $(src $scene) -an -vf "scale=$1,fps=$2" -c:v libx264 -preset veryfast -bf 0 -qp 28 -g $(($2*2)) -sc_threshold 0 o.mp4 line $scene "${1%%:*}w ${2}fps H.264 QP 28" $(kb o.mp4) "" done done ``` والمخرج سوف يكون كما يلي: ```text quiet 1920w 5fps H.264 QP 28 962 kbps 10.4 GB/day quiet 1920w 10fps H.264 QP 28 1013 kbps 10.9 GB/day quiet 1920w 15fps H.264 QP 28 1031 kbps 11.1 GB/day quiet 1920w 25fps H.264 QP 28 1061 kbps 11.5 GB/day quiet 1280w 15fps H.264 QP 28 488 kbps 5.3 GB/day quiet 640w 10fps H.264 QP 28 158 kbps 1.7 GB/day busy 1920w 5fps H.264 QP 28 4286 kbps 46.3 GB/day busy 1920w 10fps H.264 QP 28 6361 kbps 68.7 GB/day busy 1920w 15fps H.264 QP 28 6026 kbps 65.1 GB/day busy 1920w 25fps H.264 QP 28 10925 kbps 118.0 GB/day busy 1280w 15fps H.264 QP 28 5364 kbps 57.9 GB/day busy 640w 10fps H.264 QP 28 1327 kbps 14.3 GB/day ``` في المخرج أعلاه لاحظ التالي: - في المشهد الهادئ لم يغير عدد الإطارات شيئاً تقريباً، فمن 5 إلى 25 إطاراً زاد المعدل 10% فقط، والسبب أن الإطارات المفتاحية ثابتة العدد، كل ثانيتين، وهي التي تأخذ أغلب البايتات، بينما الإطارات P بين صورتين متشابهتين صغيرة جداً. - في المشهد المزدحم تضاعف المعدل أكثر من مرتين بين 5 و25 إطاراً، لأن كل إطار مختلف عن الذي قبله، فالإطارات P كبيرة. ولاحظ أن 10 و15 إطاراً أعطتا أرقاماً متقاربة، لأن المقطع تصوير بفاصل زمني، وحذف إطار منه يجعل الإطار التالي أبعد عنه، فلا تتوقع أن تكون النسبة خطية. - تخفيض الدقة من 1080p إلى 720p نصف المعدل في المشهد الهادئ، وخفضه بنحو 11% فقط في المشهد المزدحم، فالدقة ليست وحدها التي تحدد الحجم، وإنما كمية التغير في الصورة. - بث بدقة 640×360 و10 إطارات، وهو قريب من البث الفرعي Sub Stream في الكاميرات، أخذ 1.7 جيجابايت في اليوم للمشهد الهادئ، أي جزءاً صغيراً من البث الرئيسي، وهذا يفيدك عندما يكفيك تسجيل منخفض الدقة لبعض الأيام. والصورة التالية تجمع أهم الأرقام في مكان واحد: ![رسمان بأعمدة أفقية. الأول لنفس المشهد الهادئ مع تغيير الإعداد: 1080p بمعدل ثابت CBR 4M يعطي 3994 كيلوبت و43.1 جيجابايت في اليوم، وبمعدل متغير VBR 2366 و25.6، وبضغط H.265 بجودة أقل قليلاً 1876 و20.3، وبجودة ثابتة QP 28 1031 و11.1، و720p 488 و5.3، و360p 158 و1.7. والثاني لنفس إعداد VBR مع تغيير المشهد: الهادئ 2366 و25.6، والمزدحم 6052 و65.4 لأنه وصل إلى الحد الأعلى 6M، والهادئ مع ضجيج يشبه الليل 6060 و65.4](https://arabroot.io/content/images/2026/10/recording-storage-02-measured.webp) المشهد يغير المساحة أكثر من أي إعداد، والمعدل الثابت يعطيك رقماً معروفاً مقابل ثمن في الجودة أو في القرص والخلاصة من هذه التجربة أن تقيس كل كاميرا في مكانها، فالكاميرا على مدخل المستودع الهادئ والكاميرا على منطقة التحميل المزدحمة بنفس الإعدادات تختلفان في المساحة بثلاثة أضعاف، والكاميرا نفسها في الليل قد تأخذ أكثر من النهار بسبب الضجيج. ومع Frigate تجد معدل كل كاميرا الحقيقي في واجهة النظام وفي أحجام ملفاتها، كما فعلنا في [قسم التسجيلات والمساحة الحقيقية](https://arabroot.io/articles/frigate-%D8%AA%D8%B3%D8%AC%D9%8A%D9%84-%D9%83%D8%A7%D9%85%D9%8A%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83/#lab-recordings) عندما قسنا 2.41 ميجابت لكاميرا واحدة من تسجيلاتها. ### قس كاميرتك في دقيقة كل الأرقام السابقة من مقاطع منشورة، أما كاميراتك فتقيسها بنفسك بنفس الطريقة التي يسجل بها أي مسجل: تسجل دقيقة من البث دون إعادة ضغط، ثم تحول حجم الملف إلى معدل بت وجيجابايتات في اليوم. والسكربت التالي `measure-camera.sh` يفعل ذلك، ويأخذ عنوان RTSP للكاميرا: ```bash # Measure one camera's real bitrate: record 60 s of its stream without re-encoding, then turn the # file size into kbps and GB per day. Run it at a busy hour and again at night. URL=${1:-rtsp://scv-cam:8554/main} ffmpeg -v error -y -rtsp_transport tcp -i "$URL" -t 60 -c copy /tmp/sample.mp4 ffprobe -v error -show_entries format=duration,size -of csv=p=0 /tmp/sample.mp4 | awk -F, '{ kbps = $2*8/$1/1000; printf "duration %.1f s, size %.1f MB, %.0f kbps, %.1f GB/day ", $1, $2/1e6, kbps, kbps*1000*86400/8/1e9 }' ``` وجربناه على البث الرئيسي ثم البث الفرعي للكاميرا الوهمية التي سوف نستخدمها في تجربة امتلاء القرص بعد قليل: ```bash docker run --rm --name scv-meas --network scv-net -v "$PWD:/lab" --entrypoint sh bluenviron/mediamtx:1.21.1-ffmpeg /lab/measure-camera.sh rtsp://scv-cam:8554/main docker run --rm --name scv-meas --network scv-net -v "$PWD:/lab" --entrypoint sh bluenviron/mediamtx:1.21.1-ffmpeg /lab/measure-camera.sh rtsp://scv-cam:8554/sub ``` والمخرج سوف يكون كما يلي، بعد حذف رسائل التحذير التي تظهر في أول ثانية: ```text duration 59.2 s, size 29.8 MB, 4027 kbps, 43.5 GB/day duration 59.5 s, size 3.8 MB, 513 kbps, 5.5 GB/day ``` في المخرج أعلاه لاحظ التالي: - البث الرئيسي بمعدل CBR 4 ميجابت أعطى 4027 كيلوبت، أي 43.5 جيجابايت في اليوم، وهو نفس الرقم تقريباً الذي حصلنا عليه في جدول القياس، وهذا ما تتوقعه من CBR: الرقم الذي تضبطه هو الرقم الذي تكتبه. - البث الفرعي بدقة 640×360 أعطى 5.5 جيجابايت في اليوم، أي قرابة ثمن البث الرئيسي. - رسائل التحذير في أول ثانية مثل `reference picture missing` سببها أن التسجيل بدأ في منتصف مجموعة صور قبل وصول إطار مفتاحي، وهي لا تؤثر في الحساب، ولكنها تذكرك أن أول جزء من أي تسجيل لا يعرض حتى يصل الإطار المفتاحي الأول. - شغل الأمر في أكثر ساعة ازدحاماً، ثم شغله ليلاً، وخذ الأكبر من الرقمين لكل كاميرا، والسبب أن كاميرا VBR في الليل قد تتجاوز رقم النهار كما رأينا في مشهد الضجيج. ## لماذا يحفظ قرص 4TB أقل من 4TB؟ الجزء الثاني من المعادلة هو المساحة المتاحة، وهنا مفاجأتان صغيرتان تأكلان من القرص قبل أن يكتب عليه أي تسجيل: - **التيرابايت والتيبي بايت:** الشركات تكتب السعة بالنظام العشري، فالقرص 4TB يعني 4,000,000,000,000 بايت، أما نظام التشغيل فيعرضها غالباً بالنظام الثنائي، حيث التيبي بايت TiB يساوي 1024 أس 4 بايت، فيظهر القرص 3.64 TiB، وكثير من الأدوات تكتبها 3.6T دون أن تذكر أنها TiB. - **نظام الملفات File System:** يحجز جزءاً لبياناته الخاصة، مثل جداول الملفات وسجل التغييرات Journal، ونظام ext4 على Linux يحجز افتراضياً 5% من القرص للمدير root، و[توثيق mke2fs](https://man7.org/linux/man-pages/man8/mke2fs.8.html?ref=arabroot.io) يذكر أن هذا الحجز يقلل التجزئة ويسمح لخدمات النظام بالعمل بعد أن يمتلئ القرص على بقية البرامج. ولكي نرى الرقم الحقيقي دون أن نشتري قرصاً، أنشأنا ملفاً متفرقاً Sparse File بحجم 4,000,000,000,000 بايت بالضبط، أي قرص 4TB كما تبيعه الشركات، داخل الذاكرة، ثم صغناه ext4 بالإعدادات الافتراضية وقرأنا أرقامه: ```bash docker run --rm --name scv-fs --tmpfs /work:size=2500m debian:trixie-slim sh -c ' apt-get -qq update >/dev/null && apt-get -qq install -y e2fsprogs >/dev/null 2>&1 mke2fs -V 2>&1 | head -1 truncate -s 4000000000000 /work/disk.img mkfs.ext4 -q -F /work/disk.img tune2fs -l /work/disk.img | grep -E "^Block count|^Reserved block count|^Free blocks|^Block size" du -h /work/disk.img' ``` والمخرج سوف يكون كما يلي: ```text mke2fs 1.47.2 (1-Jan-2025) Block count: 976562500 Reserved block count: 48828125 Free blocks: 960948293 Block size: 4096 54M /work/disk.img ``` في المخرج أعلاه لاحظ التالي: - القرص فيه 976,562,500 كتلة Block حجم كل منها 4096 بايت، أي 4.00 تيرابايت بالضبط كما على الملصق. - الكتل الحرة بعد الصيغة 960,948,293، أي أن نظام الملفات أخذ قرابة 1.6% لبياناته، وهذا قرابة 64 جيجابايت. - الكتل المحجوزة للمدير 48,828,125، أي 5% بالضبط، وهذا قرابة 200 جيجابايت لا يستطيع برنامج التسجيل أن يكتب فيها إذا كان يعمل بمستخدم عادي. - المتبقي للتسجيل (960,948,293 ناقص 48,828,125) ضرب 4096 يساوي قرابة 3.74 تيرابايت، وهو الرقم الذي استخدمناه في الحساب، أي أن 6.6% من القرص ذهبت قبل أول ثانية تسجيل. - الملف المتفرق لم يأخذ من الذاكرة إلا 54 ميجابايت، لأن الصيغة كتبت البيانات الأساسية فقط، وهذا ما يجعل التجربة ممكنة دون قرص حقيقي. وإذا كان القرص مخصصاً للتسجيلات وحدها، ونظام التشغيل على قرص آخر، فتستطيع أن تخفض هذا الحجز إلى 1% بالأمر `tune2fs -m 1` كما يشرح [توثيق tune2fs](https://man7.org/linux/man-pages/man8/tune2fs.8.html?ref=arabroot.io)، فتسترد قرابة 160 جيجابايت، ولا تجعله صفراً على قرص النظام نفسه، والسبب أن هذا الحجز هو ما يبقي النظام يعمل يوم يمتلئ القرص. والصورة التالية لقرص مراقبة من النوع الذي يأتي مع كثير من المسجلات، ولاحظ أن الملصق يكتب السعة 4.0TB بالنظام العشري: ![قرص صلب 3.5 بوصة من نوع WD Purple بسعة 4.0TB، على ملصقه الأرجواني عبارة Surveillance Hard Drive وعبارة 24x7 Reliability ورمز QR ورقم الموديل WD40PURX](https://arabroot.io/content/images/2026/10/recording-storage-03-surveillance-disk.webp) قرص مخصص للمراقبة، والسعة على الملصق بالنظام العشري. الصورة: Solomon203، بترخيص CC BY-SA 3.0، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:WD40PURX-64GVNY0%5F20140130.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP). ## طرق الاحتفاظ بالتسجيلات Retention بعد أن عرفنا المعدل الحقيقي والمساحة الحقيقية، يبقى القرار الذي يحدد فعلاً كم يوماً يحفظ القرص: ماذا تسجل، وكم تحتفظ به. وهناك ثلاث طرق أساسية، وكل برنامج تسجيل جيد يسمح بخلطها: - **التسجيل المستمر Continuous Recording:** كل ثانية من كل كاميرا، وهو الأكثر أماناً لأنه لا يعتمد على أي كشف قد يخطئ، والأكثر استهلاكاً للمساحة، لذلك يحتفظ به عادة أياماً قليلة. - **التسجيل عند الحركة Motion Recording:** يحفظ فقط الأجزاء التي تغيرت فيها الصورة، وفيه مشكلة سوف نراها بالأرقام بعد قليل: المشهد الخارجي لا يسكن أبداً تقريباً. - **التسجيل عند الأحداث Event Recording:** يحفظ فقط الأجزاء التي فيها شيء يهمك، مثل شخص أو سيارة، بحسب كاشف أجسام يعمل على الفيديو، وهذا يحتاج نظاماً يفهم ما في الصورة، مثل Frigate. و[توثيق التسجيل في Frigate](https://docs.frigate.video/configuration/record?ref=arabroot.io) يعرض ثلاثة أشكال شائعة تخلط هذه الطرق: الأكثر حذراً، وفيه التسجيل المستمر ثلاثة أيام، وأجزاء الحركة سبعة أيام، والتنبيهات والاكتشافات ثلاثين يوماً، ثم شكل أوفر لا يحفظ إلا الحركة ثلاثة أيام والأحداث ثلاثين يوماً، ثم الحد الأدنى الذي لا يحفظ إلا التنبيهات ثلاثين يوماً. والإعداد الأول منها مكتوب في التوثيق كما يلي: ```yaml record: enabled: True continuous: days: 3 motion: days: 7 alerts: retain: days: 30 mode: all detections: retain: days: 30 mode: all ``` والفكرة التي يجب أن تفهمها في هذا الإعداد أن كل جزء من الفيديو يحتفظ به أطول مدة تنطبق عليه، فالدقيقة التي فيها تنبيه بشخص تبقى ثلاثين يوماً، والدقيقة الهادئة تماماً تحذف بعد ثلاثة أيام، وبهذا يصبح عدد الأيام شيئاً تختاره لكل نوع من الفيديو، ولا تفرضه عليك سعة القرص. ### كيف يكتب المسجل الملفات؟ المسجل لا يكتب التسجيل في ملف واحد كبير لكل كاميرا، وإنما في مقاطع قصيرة متتالية، والسبب أن الملف الواحد الضخم يصعب حذف أوله دون إعادة كتابته، ويضيع كله إذا تلف فهرسه، ويصعب القفز فيه إلى دقيقة معينة. ففي Frigate مثلاً يذكر [توثيق التسجيل](https://docs.frigate.video/configuration/record?ref=arabroot.io) أن المقاطع تكتب بطول 10 ثوان في مجلدات بالشكل `YYYY-MM-DD/HH//MM.SS.mp4` بتوقيت UTC، وكل مقطع له سجل في قاعدة بيانات صغيرة فيها مدته وحجمه وهل فيه حركة أو أجسام، وهذه القاعدة هي التي تقرر عند الحذف أي مقطع يبقى وأي مقطع يذهب. ولهذا التصميم ثلاثة آثار عملية: - **الحذف رخيص:** حذف يوم قديم يعني حذف مجلد من الملفات الصغيرة، دون لمس أي ملف آخر، ولذلك تستطيع قاعدة الاحتفاظ أن تعمل كل بضع دقائق دون أن تثقل القرص. - **العطل يضيع مقطعاً واحداً:** إذا انقطعت الكهرباء أو امتلأ القرص، يضيع المقطع المفتوح فقط، كما سنرى في التجربة، وليس تسجيل اليوم كله. - **ما قبل الحدث وما بعده:** عندما يقع حدث، يحتاج المسجل ثواني قبله حتى ترى الشخص وهو يقترب، وليس بعد أن أصبح أمام الكاميرا، ويسمي Frigate ذلك Pre-capture وPost-capture، والقيمة الافتراضية بحسب التوثيق 5 ثوان لكل منهما، والحد الأعلى لما قبل الحدث 60 ثانية. ولاحظ أن التوثيق يذكر أن المقاطع التي تبقى من هذه النافذة تتبع أيضاً وضع الاحتفاظ، فإذا كان الوضع `motion` فقد ترى أقل من النافذة المضبوطة إذا لم تكن في بعض أجزائها حركة. وطول المقطع نفسه قرار له ثمن، فالمقاطع القصيرة جداً تعني آلاف الملفات في اليوم لكل كاميرا، والطويلة تعني أن العطل يضيع جزءاً أكبر، والمقسم لا يقطع إلا عند إطار مفتاحي، لذلك إذا كان الإطار المفتاحي كل عشر ثوان فلن تحصل على مقاطع بطول أقل من ذلك مهما ضبطت. ### تجربة: كم دقيقة في اليوم «فيها حركة»؟ قبل أن تعتمد على التسجيل عند الحركة، اسأل هذا السؤال: كم من اليوم يسكن المشهد فعلاً؟ ولكي نجيب بالأرقام، ضغطنا 150 ثانية من الكاميرا الثابتة على الموقف بمعدل VBR، ثم جمعنا حجم الإطارات من نوع P في كل ثانية، والسبب أن هذه الإطارات تحمل الفرق بين الصور فقط، فإذا سكن المشهد صغرت، وإذا تحرك شيء كبرت. السكربت `activity.sh`: ```bash # How much of the day has activity? Encode 150 s of the fixed camera with VBR (CRF 23, cap 6 Mbps), # then add up the bytes of every second: P-frames are large only when something moves. cd /tmp ffmpeg -v error -y -t 150 -i /samples/parking.webm -an -vf scale=1920:1080,fps=15 -c:v libx264 -preset veryfast \ -bf 0 -crf 23 -maxrate 6M -bufsize 12M -g 30 -keyint_min 30 -sc_threshold 0 vbr.mp4 ffprobe -v error -select_streams v:0 -show_entries packet=pts_time,size,flags -of csv=p=0 vbr.mp4 | awk -F, '$3 !~ /K/ { s=int($1); b[s]+=$2 } END { for (i in b) print i, b[i]*8/1000 }' | sort -n > persec.txt sort -k2 -n persec.txt | awk '{ v[NR]=$2 } END { med=v[int(NR/2)]; print "seconds:", NR, " median P-frame kbit/s:", med; n=0; for (i=1;i<=NR;i++) if (v[i] > 2*med) n++; printf "seconds above 2x median (activity): %d = %.0f%%\n", n, n*100/NR }' awk '{ printf "%s ", int($2) } END { print "" }' persec.txt ``` والمخرج سوف يكون كما يلي، وقد اختصرنا السطر الأخير إلى أول ثلاثين ثانية من 150: ```text seconds: 150 median P-frame kbit/s: 1183 seconds above 2x median (activity): 1 = 1% 878 1257 969 1117 1288 1130 966 1168 1385 1182 1167 1246 1339 1288 871 945 950 1693 1161 1279 1139 1641 1233 1427 1206 1784 1251 1247 1089 1425 ... ``` في المخرج أعلاه لاحظ التالي: - الإطارات P في هذا المشهد «الهادئ» لا تنزل عن قرابة 700 كيلوبت في الثانية في أي ثانية، ووسيطها 1183 كيلوبت، أي أن الكاميرا ترى تغيراً طوال الوقت. - ثانية واحدة فقط من 150 تجاوزت ضعف الوسيط، أي أن «الحركة الكبيرة» لم تكن في هذه الدقائق إلا لحظة، ومع ذلك فالبيانات لم تسكن في أي لحظة. - السبب أوراق الأشجار والغيوم وحركة السيارات البعيدة وتغير الضوء، وكل ذلك يراه كشف الحركة البسيط حركة، لذلك التسجيل عند الحركة في كاميرا خارجية كهذه سوف يسجل أغلب اليوم، ولن يوفر ما تتوقعه، إلا إذا ضبطت حساسيته ورسمت أقنعة Masks على الأشجار والسماء. - والتسجيل عند الأحداث هو الذي يحل هذه المشكلة، لأن الكاشف يسأل «هل في الصورة شخص أو سيارة تتحرك؟» وليس «هل تغيرت البكسلات؟»، وهذا موضوع مقال مخطط في [مرحلة الكاميرات](https://arabroot.io/start/#stage-cameras) عن كشف الأشخاص والسيارات بدقة. ## نجرب العطل: ماذا يحدث عندما يمتلئ القرص؟ أغلب المسجلات الجاهزة تكتب فوق الأقدم تلقائياً Overwrite، ولكن عندما تبني المسجل بنفسك على سيرفر، أو تخطئ في إعداد البرنامج، قد لا توجد أي قاعدة تحذف القديم، والسؤال: ماذا يحدث يوم يمتلئ القرص؟ لنرى ذلك بأعيننا، شغلنا كاميرا وهمية بخادم [MediaMTX](https://github.com/bluenviron/mediamtx?ref=arabroot.io) تنشر بث 1080p بمعدل CBR 4 ميجابت عبر RTSP، ثم سجلناه بأداة ffmpeg في ملفات مدة كل منها 30 ثانية كما يفعل أي مسجل، عبر [مقسم الملفات segment](https://ffmpeg.org/ffmpeg-formats.html?ref=arabroot.io#segment)، على قرص صغير جداً حجمه 64 ميجابايت حتى يمتلئ في دقائق بدل أيام. والسكربت `record-full.sh`: ```bash # Record the camera's main stream in 30-second files, like an NVR, onto a 64 MB disk (tmpfs) # with no retention rule, and watch what happens when the disk fills up. cd /rec date -u +"start %H:%M:%S UTC" ffmpeg -v warning -rtsp_transport tcp -i rtsp://scv-cam:8554/main -c copy -f segment -segment_time 30 \ -reset_timestamps 1 -strftime 1 "cam1-%H%M%S.mp4" 2>&1 | tail -4 date -u +"ffmpeg stopped %H:%M:%S UTC" ls -l /rec | awk 'NR>1 {print $5, $9}' df -h /rec | tail -1 last=$(ls -1 /rec | tail -1) echo "--- can the last file be read?"; ffprobe -v error -show_entries format=duration -of csv=p=0 "/rec/$last" 2>&1 | head -2 ``` ```bash docker run --rm --name scv-rec2 --network scv-net --tmpfs /rec:size=64m -v "$PWD:/lab" \ --entrypoint sh bluenviron/mediamtx:1.21.1-ffmpeg /lab/record-full.sh ``` والمخرج سوف يكون كما يلي: ```text start 09:54:47 UTC [out#0/segment @ 0x7fda3e1a87c0] Task finished with error code: -28 (No space left on device) [out#0/segment @ 0x7fda3e1a87c0] Terminating thread with return code -28 (No space left on device) [segment @ 0x7fda3e29f600] Failure occurred when ending segment 'cam1-095733.mp4' [out#0/segment @ 0x7fda3e1a87c0] Error writing trailer: No space left on device ffmpeg stopped 09:57:48 UTC 12000791 cam1-095451.mp4 11795921 cam1-095522.mp4 10478580 cam1-095602.mp4 14239128 cam1-095636.mp4 10898028 cam1-095710.mp4 7688192 cam1-095733.mp4 tmpfs 64.0M 64.0M 0 100% /rec --- can the last file be read? [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fdd8d523380] moov atom not found /rec/cam1-095733.mp4: Invalid data found when processing input ``` في المخرج أعلاه لاحظ التالي: - بعد ثلاث دقائق امتلأ القرص 100%، فتوقف ffmpeg تماماً بالخطأ `No space left on device`، أي أن المسجل لم يتوقف عن حفظ الجديد فقط، وإنما توقف عن العمل كله، ولن يسجل أي شيء بعد ذلك حتى يتدخل أحد. ومع قرص حقيقي يحدث نفس الشيء بعد أحد عشر يوماً، وغالباً في ليلة لا يراقب فيها أحد. - الملف الأخير لا يفتح، والرسالة `moov atom not found` تعني أن فهرس ملف MP4، الذي يكتب في نهايته عند إغلاقه، لم يكتب لأنه لا توجد مساحة، فضاعت آخر عشرين ثانية تقريباً، وهي غالباً اللحظات التي تريدها. - أحجام الملفات بين 10 و14 ميجابايت لكل ملف، والحدود ليست كل 30 ثانية بالضبط، لأن المقسم لا يقطع إلا عند إطار مفتاحي، وهذا سبب إضافي لأن تبقى الإطارات المفتاحية متقاربة بشكل معقول. ثم أعدنا التجربة على نفس القرص بأبسط قاعدة احتفاظ موجودة في كل مسجل: إذا زاد الاستخدام على 75% احذف أقدم ملف. السكربت `record-retention.sh`: ```bash # The same 64 MB disk, now with the simplest retention rule an NVR has: when the disk is above 75%, # delete the oldest file. Runs for 4 minutes, then prints what was deleted and what is left. cd /rec ffmpeg -v warning -rtsp_transport tcp -i rtsp://scv-cam:8554/main -c copy -f segment -segment_time 30 \ -reset_timestamps 1 -strftime 1 "cam1-%H%M%S.mp4" 2>/tmp/ffmpeg.log & end=$(( $(date +%s) + 240 )) while [ $(date +%s) -lt $end ]; do used=$(df /rec | awk 'NR==2 {print int($3*100/$2)}') if [ "$used" -gt 75 ]; then oldest=$(ls -1 cam1-*.mp4 | head -1) echo "$(date -u +%H:%M:%S) disk ${used}% -> delete $oldest" rm -f "$oldest" fi sleep 2 done kill %1; wait echo "--- left on disk:"; ls -l /rec | awk 'NR>1 {print $5, $9}' df -h /rec | tail -1 echo "--- ffmpeg errors:"; grep -ci "no space" /tmp/ffmpeg.log ``` والمخرج سوف يكون كما يلي: ```text 10:03:35 disk 77% -> delete cam1-100152.mp4 10:04:08 disk 77% -> delete cam1-100222.mp4 10:04:38 disk 77% -> delete cam1-100252.mp4 10:05:06 disk 76% -> delete cam1-100322.mp4 10:05:37 disk 76% -> delete cam1-100352.mp4 --- left on disk: 15058972 cam1-100422.mp4 14250273 cam1-100452.mp4 13763305 cam1-100522.mp4 tmpfs 64.0M 41.1M 22.9M 64% /rec --- ffmpeg errors: 0 ``` والصورة التالية تضع التجربتين جنباً إلى جنب: ![في الأعلى ستة ملفات تسجيل بأحجام بين 7.7 و14.2 ميجابايت، آخرها بإطار أحمر متقطع، ثم منطقة حمراء مكتوب فيها القرص ممتلئ 100%، وتحتها رسالة الخطأ Error writing trailer No space left on device وشرح أن ffmpeg توقف والملف الأخير بلا فهرس. وفي الأسفل ثمانية ملفات على خط زمني لأربع دقائق، الخمسة الأقدم رمادية مكتوب عليها حذف الأقدم، والثلاثة الأحدث خضراء باقية على القرص، والقرص بقي بين 64% و77% وصفر أخطاء](https://arabroot.io/content/images/2026/10/recording-storage-04-retention.webp) بلا احتفاظ يتوقف التسجيل كله، ومع قاعدة بسيطة يبقى أحدث ما يتسع له القرص دائماً في المخرج أعلاه لاحظ أن القرص لم يتجاوز 77%، وأن ffmpeg لم يكتب أي خطأ مساحة، وأن القرص يحمل دائماً آخر دقيقة ونصف تقريباً، وهذا بالضبط سلوك المسجل الجيد: يبقى يسجل للأبد، ويحفظ أحدث ما يتسع له القرص. ولاحظ أيضاً أن القاعدة تعمل على النسبة وليس على عدد الأيام، وهذا ما يفعله Frigate أيضاً بطبقة أمان إضافية فوق إعدادات الأيام، فتوثيق التسجيل يذكر أنه عندما يبقى أقل من قرابة ساعة من مساحة التسجيل، يقدرها من معدل البت الحالي وليس بنسبة ثابتة، يحذف أقدم التسجيلات أولاً بغض النظر عن إعدادات الاحتفاظ، وينصح إذا تكرر ذلك بأن تخفض الأيام في الإعداد. والفرق مهم: الحذف الطارئ ينقذ التسجيل، ولكنه يحذف دون أن ينظر هل في الملف حدث مهم أم لا، لذلك اجعل الأيام في الإعداد أقل مما يتسع له القرص بهامش واضح، حتى لا تصل إلى هذه المرحلة أبداً. ## أي قرص تشتري؟ أقراص المراقبة وحمل الكتابة Workload المسجل يكتب على القرص طوال اليوم وطوال السنة، وهذا عمل مختلف عن حاسوب مكتبي يكتب قليلاً ويقرأ كثيراً، لذلك تبيع الشركات أقراصاً مخصصة للمراقبة، مثل WD Purple من Western Digital وSkyHawk من Seagate، والرقم الذي يهمك في ورقة مواصفاتها ليس السعة فقط، وإنما حمل العمل السنوي Workload Rate. و[صفحة WD Purple](https://www.westerndigital.com/products/outlet/internal-drives/wd-purple-sata-hdd?ref=arabroot.io) تقول إنها مصممة للعمل 24 ساعة طوال الأسبوع بحمل عمل يصل إلى 180 تيرابايت في السنة ودعم حتى 64 كاميرا، وأن الأحجام من 8 إلى 14 تيرابايت تصل إلى 360 تيرابايت، وتعرف حمل العمل بأنه البيانات التي تنقل إلى القرص ومنه، محسوبة على سنة بالمعادلة: التيرابايت المنقولة ضرب 8760 ساعة قسمة ساعات التشغيل المسجلة. والآن نحسب حمل الشركة: ثماني كاميرات بمعدل CBR 4 ميجابت تكتب 32 ميجابت في الثانية، وفي السنة 31,536,000 ثانية، فالمجموع 32 ضرب 31,536,000 قسمة 8 يساوي قرابة 126 تيرابايت في السنة كتابة فقط، قبل أي مشاهدة أو بحث في التسجيلات. وهذا ما زال تحت 180، ولكن مسجلاً بست عشرة كاميرا بنفس الإعدادات على قرص واحد يكتب قرابة 252 تيرابايت، أي فوق الحد المكتوب، ومع VBR بالمعدل الذي قسناه في المشهد الهادئ تنزل الكتابة إلى قرابة 75 تيرابايت للكاميرات الثماني. وفي الصفحة نفسها تجد أن تقنية التسجيل في القرص CMR، وهذا سؤال آخر تسأله قبل الشراء، لأن تقنية SMR التي تكتب المسارات متداخلة تبطئ كثيراً مع الكتابة المستمرة. وقد يتساءل البعض: لماذا لا أستخدم قرص SSD؟ والإجابة أن SSD ممتاز لنظام التشغيل وقاعدة بيانات المسجل والصور المصغرة، ولكنه مكلف جداً للتسجيلات نفسها بأحجام عشرات التيرابايتات، ولأقراص SSD أيضاً حد للكتابة يكتب بالتيرابايتات TBW، فإذا وضعت عليه التسجيل المستمر فاحسب الكتابة السنوية كما حسبناها أعلاه وقارنها بالرقم في ورقته. ### والشبكة تحمل نفس الأرقام معدل البت الذي يملأ القرص هو نفسه الذي يمر على الشبكة قبل أن يصل إليه، لذلك احسب الشبكة بنفس المعادلة. فالكاميرات الثماني بمعدل CBR 4 ميجابت تعني 32 ميجابت في الثانية تصل إلى المسجل باستمرار، وإذا كان المسجل يأخذ البث الفرعي أيضاً للعرض والتحليل فأضف قرابة نصف ميجابت لكل كاميرا. وهذا رقم صغير على منفذ Gigabit في Switch حديث، ولكنه يصبح مهماً في ثلاث حالات: عندما تمر الكاميرات عبر رابط واحد بين Switch في المستودع وآخر في المكتب، فكل الكاميرات تتقاسم هذا الرابط مع أجهزة الموظفين، وعندما تكون بعض الكاميرات لاسلكية Wi-Fi فتأخذ من سعة الشبكة التي تستخدمها الهواتف، وعندما يشاهد أحد التسجيلات من خارج المكان، فسرعة الرفع Upload في اشتراك الإنترنت قد لا تتحمل بثاً رئيسياً واحداً بجودة كاملة، وهذا سبب أن تطبيقات المشاهدة تستخدم البث الفرعي عن بعد. وقد شرحنا حدود اتصال المنزل والمكتب في [تشغيل خادمك من إنترنت المنزل](https://arabroot.io/articles/%D8%AA%D8%B4%D8%BA%D9%8A%D9%84-%D8%AE%D8%A7%D8%AF%D9%85%D9%83-%D9%85%D9%86-%D8%A5%D9%86%D8%AA%D8%B1%D9%86%D8%AA-%D8%A7%D9%84%D9%85%D9%86%D8%B2%D9%84/). ### قرص واحد أم عدة أقراص؟ وأين RAID من ذلك؟ عندما يكبر النظام وتحتاج أكثر من قرص، يأتي السؤال: هل تضع الأقراص منفصلة، أم في مصفوفة RAID؟ والصورة التالية تبين أربعة خيارات لأربعة أقراص سعة كل منها 8 تيرابايت: ![أربع بطاقات لأربعة أقراص 8 تيرابايت: أقراص منفصلة JBOD بمساحة 32 تيرابايت ولا تتحمل أي عطل، وعطل قرص يضيع تسجيلاته فقط، ثم مرآة RAID 1 على زوجين بمساحة 16 تيرابايت وتتحمل عطل قرص من كل زوج وهي الأبسط، ثم RAID 5 أو RAIDZ1 بمساحة 24 تيرابايت وتتحمل عطل قرص واحد وعطل ثان أثناء البناء يضيع الكل، ثم RAID 6 أو RAIDZ2 بمساحة 16 تيرابايت وتتحمل عطل أي قرصين وهي الأنسب لعدة أقراص كبيرة](https://arabroot.io/content/images/2026/10/recording-storage-05-raid.webp) في المراقبة السؤال: هل تتحمل أن تضيع أيام كاميرات قرص واحد إذا تعطل؟ في الصورة أعلاه لاحظ أن الأقراص المنفصلة ليست اختياراً سيئاً للمراقبة كما في الملفات المهمة، فإذا وزعت الكاميرات على الأقراص وتعطل قرص، فقدت تسجيلات تلك الكاميرات من الأيام الماضية فقط، وبقيت الأخرى تسجل، وكثير من المسجلات الجاهزة تعمل بهذه الطريقة. أما إذا كان فقدان أي يوم من أي كاميرا غير مقبول، كما في المستودع الذي يحتاج أن يثبت ما حدث لشحنة، فالمرآة أو التكافؤ المزدوج أفضل، مع العلم أن إعادة بناء مصفوفة من أقراص كبيرة قد تأخذ ساعات طويلة تحت حمل الكتابة المستمر، وأن عطلاً ثانياً أثناء إعادة البناء في RAID 5 يضيع كل شيء. وقد شرحنا كيف يحمي ZFS البيانات من التلف وكيف تختار تخطيط الأقراص في [ZFS للمبتدئين](https://arabroot.io/articles/zfs-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D9%83%D9%8A%D9%81-%D9%8A%D8%AD%D9%85%D9%8A-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA%D9%83-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%84%D9%81-%D8%A7%D9%84%D8%B5%D8%A7%D9%85%D8%AA/)، والفرق بين التخزين المتصل بالشبكة والتخزين المباشر في [الفرق بين NAS وSAN](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-nas-%D9%88-san-%D9%88%D9%85%D8%AA%D9%89-%D9%8A%D9%83%D9%81%D9%8A%D9%83-das/). وتذكر أن RAID ليس نسخة احتياطية، فالمصفوفة تحميك من عطل قرص، ولا تحميك من حذف خاطئ أو برنامج فدية أو حريق في غرفة الأجهزة. والتسجيل المستمر لا يحتاج نسخة احتياطية عادة، لأنه يتجدد كل يوم، أما المقطع الذي تحتاجه دليلاً لحادثة فصدره من المسجل فوراً، واحفظه خارجه بقاعدة 3-2-1 التي شرحناها في [النسخ الاحتياطي بقاعدة 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)، والسبب أن قاعدة الاحتفاظ لا تعرف أن هذا المقطع مهم، وسوف تحذفه في موعده. ## كم يوماً تحتاج أصلاً؟ قبل أن تبني الخطة، اسأل السؤال الذي لا يسأله أغلب الناس: متى تكتشف عادة أن شيئاً حدث؟ فعدد الأيام الصحيح ليس رقماً جميلاً مثل «شهر»، وإنما المدة بين وقوع الحادثة وبين أن يطلب أحد التسجيل، مضافاً إليها هامش. وفي المستودع مثلاً، الشحنة المفقودة لا يكتشفها أحد يوم خروجها، وإنما عندما يشتكي العميل بعد أيام من موعد التسليم، أو عند الجرد الشهري، والخدش في سيارة في الموقف يكتشفه صاحبها في المساء نفسه، والسرقة من الرف قد لا تظهر إلا في الجرد. لذلك اجمع مع فريقك قائمة قصيرة بأنواع الحوادث التي تهمك، وبجانب كل منها المدة التي تكتشف فيها عادة، ثم خذ أطول مدة منها وأضف إليها أسبوعاً، وهذا هو عدد أيام الأحداث الذي تحتاجه. وفي المقابل لا تحتفظ بالتسجيلات أطول مما تحتاج، لأن كل يوم إضافي ليس مساحة على القرص فقط، وإنما فيديو لموظفين وعملاء وزوار محفوظ عندك، وأنت مسؤول عن حمايته وعن من يطلع عليه، وكلما طالت المدة زاد ما يمكن أن يتسرب إذا اخترق المسجل يوماً ما. والقاعدة العملية أن يكون لكل نوع من التسجيلات مدة مكتوبة بسبب واضح، وأن يحذف المسجل ما بعدها تلقائياً، وأن يحفظ المقطع الذي تحتاجه دليلاً بالتصدير كما ذكرنا، لا بإطالة مدة كل شيء. والأنظمة نفسها قد تحدد مدة دنيا يجب أن تحفظ خلالها التسجيلات في بعض الأماكن، أو مدة قصوى لا تتجاوزها، وهذا ما سنفصله من النصوص الرسمية في مقال الخصوصية والأنظمة القادم. ## خطة الاحتفاظ للشركة: نفس القرص، وشهر من الأحداث الآن نعود إلى المستودع، ونبني خطة بالأرقام التي قسناها، والصورة التالية تقارن ثلاث خطط على نفس القرص 4TB الذي يتسع فعلاً ل 3.74 تيرابايت: ![ثلاثة أعمدة أفقية مقابل خط أحمر متقطع لسعة القرص المتاحة 3.74 تيرابايت: الأول ما في العرض CBR 4M مستمر 30 يوماً يمتلئ القرص بعد 10.8 يوماً والمطلوب 10.34 تيرابايت، والثاني VBR مستمر 30 يوماً يمتلئ بعد 18.3 يوماً والمطلوب 6.14 تيرابايت، والثالث VBR مستمر 7 أيام 1.43 تيرابايت وأحداث 30 يوماً 0.61 تيرابايت وفارغ 45% هامش للنمو والأعطال. وفي الأسفل لوحة عن حمل الكتابة: 126 تيرابايت في السنة مع CBR و75 مع VBR مقابل 180 في صفحة WD Purple](https://arabroot.io/content/images/2026/10/recording-storage-06-plan.webp) القرص نفسه، والفرق في الإعدادات وقرار الاحتفاظ وفيما يلي خطوات الخطة الثالثة: 1. **VBR بدل CBR** في كل الكاميرات، بحد أعلى 6 ميجابت، وقياس معدل كل كاميرا بعد أسبوع من التشغيل الحقيقي، ليلاً ونهاراً، وليس من التجربة وحدها. وفي حسابنا استخدمنا 25.6 جيجابايت في اليوم من المشهد الهادئ، والكاميرا على منطقة التحميل سوف تأخذ أكثر. 2. **تسجيل مستمر سبعة أيام:** 25.6 ضرب 8 كاميرات ضرب 7 أيام يساوي قرابة 1.43 تيرابايت، وهذا يغطي أي حادثة يكتشفها أحد خلال أسبوع. 3. **الأحداث ثلاثين يوماً:** بافتراض أن الأشخاص والسيارات موجودون في الصورة 10% من الوقت، وهذا افتراض لا قياس، فالمساحة 25.6 ضرب 8 ضرب 30 ضرب 0.1 يساوي قرابة 0.61 تيرابايت، وبعد أسبوعين من التشغيل تعرف النسبة الحقيقية من برنامج التسجيل وتعيد الحساب. 4. **هامش لا يقل عن 30%:** المجموع 2.05 تيرابايت من 3.74، أي 55%، والباقي هامش لكاميرا إضافية، ولليالي التي يرتفع فيها المعدل بسبب الضجيج، ولأيام الذروة، حتى لا يصل القرص إلى الحذف الطارئ. 5. **تصدير الأدلة:** أي مقطع يحتاجه أحد لشكوى أو تحقيق يصدر فوراً ويحفظ خارج المسجل، ولا يترك لقاعدة الاحتفاظ. وبهذه الخطة يحفظ نفس القرص الذي عرضه المورد شهراً من كل ما فيه شخص أو سيارة، وأسبوعاً من كل شيء، مع هامش واضح، وكل رقم فيها تستطيع أن تراجعه من التسجيلات نفسها بعد أسبوع. وتذكر أن مدة الاحتفاظ ليست قراراً تقنياً فقط، فهناك أنظمة تحدد كم يجب أن تحفظ التسجيلات وكم لا يجوز أن تتجاوز، وهذا موضوع مقال الخصوصية والأنظمة المخطط في نفس المرحلة. ## أخطاء شائعة - حساب المساحة من الدقة أو من جدول في كتيب، دون قياس معدل البت الحقيقي لكل كاميرا في مكانها. - ترك الكاميرات على CBR بالمعدل الافتراضي، فتدفع ثمن أسوأ مشهد في كل ثانية من اليوم. - الاعتماد على وعد H.265 بنصف المساحة دون تجربة، ثم اكتشاف أن المسجل أو المتصفح لا يعرضه. - حساب السعة على الرقم المكتوب على القرص، ونسيان الفرق بين TB وTiB وحجز نظام الملفات. - التسجيل عند الحركة في كاميرا خارجية فيها أشجار وسماء، والظن أنه يوفر المساحة. - بناء مسجل على سيرفر دون قاعدة احتفاظ أو مراقبة للقرص، فيتوقف التسجيل كله يوم يمتلئ. - وضع التسجيلات على قرص نظام التشغيل، فيتوقف النظام كله عندما يمتلئ. - تجاهل حمل الكتابة السنوي عند إضافة كاميرات على نفس القرص. ## قائمة تحقق قبل أن توافق على أي عرض | البند | كيف تتحقق منه | القيمة المعقولة | | -------------------- | --------------------------------------------- | ------------------------------------- | | معدل البت لكل كاميرا | من حجم تسجيلات يوم كامل، ليلاً ونهاراً | VBR بحد أعلى معروف | | المساحة المتاحة | السعة بعد الصيغة والحجز، وليس الملصق | قرابة 93% من الملصق مع ext4 الافتراضي | | عدد الأيام | المساحة المتاحة قسمة مجموع الكاميرات في اليوم | مع هامش 30% على الأقل | | طريقة الاحتفاظ | مستمر للأيام القريبة، وأحداث للمدة الأطول | مثل 7 أيام و30 يوماً | | سلوك القرص الممتلئ | اسأل المورد، أو جربه كما في التجربة | حذف الأقدم دون توقف التسجيل | | نوع القرص | ورقة المواصفات: Surveillance وCMR | حمل عمل أعلى من الكتابة السنوية | | الكتابة السنوية | مجموع معدلات البت ضرب ثواني السنة | أقل من حمل العمل المكتوب بهامش | | الحماية من عطل القرص | منفصلة أو مرآة أو تكافؤ مزدوج | بحسب تحمل فقدان أيام كاميرا | | تصدير الأدلة | من يصدر وأين يحفظ | خارج المسجل، بقاعدة 3-2-1 | ### حذف التجربة ```bash docker rm -f scv-cam docker network rm scv-net rm -rf work ``` ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - المساحة تساوي معدل البت ضرب الوقت، ومعدل البت الحقيقي يأتي من التسجيلات لا من ورقة المواصفات، وفي تجربتنا اختلف نفس الإعداد بين مشهد هادئ ومزدحم بأكثر من ضعفين ونصف. - CBR بمعدل 4 ميجابت يعني 43.1 جيجابايت في اليوم لكل كاميرا مهما كان المشهد، وVBR في المشهد الهادئ وفر 41% منها، ولكنه في المشهد المزدحم والليلي يصل إلى حده الأعلى. - H.265 لم يوفر في تجربتنا ما يعد به التسويق بنفس الجودة، فقس كاميرتك قبل أن تعتمد على النسبة. - قرص 4TB بصيغة ext4 الافتراضية يتسع لقرابة 3.74 تيرابايت، و5% منه محجوزة للمدير. - المشهد الخارجي لا يسكن أبداً، فالتسجيل عند الحركة لا يوفر فيه كثيراً، والتسجيل عند الأحداث هو الذي يحفظ الشهر. - القرص الممتلئ دون قاعدة احتفاظ يوقف التسجيل كله ويضيع آخر ملف، وقاعدة حذف الأقدم تبقي المسجل يعمل دائماً. - احسب الكتابة السنوية واختر قرص مراقبة بحمل عمل أعلى منها، وقرر بين الأقراص المنفصلة وRAID بحسب ما تتحمل أن تفقده، وصدر الأدلة خارج المسجل. وفي المقالات القادمة من [مرحلة الكاميرات](https://arabroot.io/start/#stage-cameras) بإذن الله نتكلم عن الخصوصية والأنظمة ومدد الاحتفاظ، ثم تأمين الكاميرات. وأقرب المقالات إلى هذا الموضوع على الموقع: [![](https://arabroot.io/content/images/2026/10/camera-types-cover-cover.webp)دليلأنواع كاميرات المراقبة وكيف تختار بينهاما الفرق بين أنواع كاميرات المراقبة، وما الذي تحتاجه في الكاميرا حتى تسجلها على جهازك، وكم قرصاً تحتاج للتسجيلات.](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%83%D8%A7%D9%85%D9%8A%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%A8%D9%8A%D9%86%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/frigate-cover-cover.webp)دليلFrigate: تسجيل كاميرات المراقبة على سيرفرك مع كشف الأجسامكيف تثبت Frigate على سيرفرك، وتسجل به كاميرات المراقبة محلياً، ويكشف لك الأشخاص والسيارات دون أن يخرج الفيديو من بيتك.](https://arabroot.io/articles/frigate-%D8%AA%D8%B3%D8%AC%D9%8A%D9%84-%D9%83%D8%A7%D9%85%D9%8A%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83/)[![](https://arabroot.io/content/images/2026/10/zfs-basics-cover-cover.webp)دليلZFS للمبتدئين: كيف يحمي بياناتك من التلف الصامتكيف يكتشف ZFS التلف الصامت ويصلحه، وكيف ترتب الأقراص في Pool يتحمل العطل وتستعيد ملفاتك من Snapshots.](https://arabroot.io/articles/zfs-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D9%83%D9%8A%D9%81-%D9%8A%D8%AD%D9%85%D9%8A-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA%D9%83-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%84%D9%81-%D8%A7%D9%84%D8%B5%D8%A7%D9%85%D8%AA/)[![](https://arabroot.io/content/images/2026/10/nas-das-san-cover-cover.webp)دليلالفرق بين NAS وSAN، ومتى يكفيك قرص متصل مباشرةكيف تصل الأجهزة إلى الأقراص عبر الشبكة بالملفات أو بالكتل، ولماذا قد يسلمك RAID ملفاً تالفاً دون أي خطأ.](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-nas-%D9%88-san-%D9%88%D9%85%D8%AA%D9%89-%D9%8A%D9%83%D9%81%D9%8A%D9%83-das/)[![](https://arabroot.io/content/images/2026/10/backup-321-cover-cover.webp)دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)[![](https://arabroot.io/content/images/2026/10/homelab-hardware-cover-cover.webp)دليلعتاد الهوم لاب: Mini PC أم NAS أم سيرفر مستعمل؟كيف تختار جهاز الهوم لاب بأرقام الشركة المصنعة وليس بالسعر وحده، وكم يكلفك من الكهرباء في السنة بالتعرفة السعودية.](https://arabroot.io/articles/%D8%B9%D8%AA%D8%A7%D8%AF-%D8%A7%D9%84%D9%87%D9%88%D9%85-%D9%84%D8%A7%D8%A8-mini-pc-%D8%A7%D9%85-nas-%D8%A7%D9%85-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-%D9%85%D8%B3%D8%AA%D8%B9%D9%85%D9%84/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، وتنفيذ التجارب على ffmpeg 8.1.2 وMediaMTX 1.21.1 وe2fsprogs 1.47.2 وDocker Engine 29.8.0 بمقطعين حقيقيين في الملكية العامة.