Kalkulator dysku CCTV
Oszacuj pojemność archiwum CCTV z liczby kamer, średniego bitrate, czasu nagrywania, retencji i rezerwy.
Oblicz pojemność dysku CCTV
Od danych do świadomej decyzji
- Wymagania
- Narzut i rezerwa
- Wynik
- Weryfikacja sprzętu
Który bitrate kamery wpisać do obliczenia?
Pojemność zależy od średniego strumienia zapisywanego przez rejestrator
Kamera może mieć ustawiony bitrate docelowy, maksymalny albo zmienny. Do obliczenia retencji potrzebna jest średnia liczba bitów rzeczywiście zapisywana w typowych i trudnych warunkach. Sam limit maksymalny daje wariant ostrożny, ale może znacznie zawyżyć rozmiar przy spokojnej scenie.
Najlepszym punktem startowym jest pomiar z rejestratora wykonany przez kilka reprezentatywnych dni. Powinien obejmować dzień, noc, ruch, deszcz, zmianę oświetlenia i działanie podczerwieni. Jedna spokojna godzina w biurze nie opisze kamery skierowanej na ulicę.
Jeśli system dopiero powstaje, użyj tabeli producenta dla wybranego kodeka, rozdzielczości i fps, a następnie policz wariant typowy oraz maksymalny. Po uruchomieniu zastąp założenie rzeczywistą średnią.
Każdy dodatkowy strumień może trafić na dysk
Rejestrator może zapisywać główny strumień wysokiej jakości, substream do podglądu albo oba. Kalkulator zakłada jeden łączny bitrate na kamerę. Jeśli archiwizujesz dwie wersje, zsumuj ich wartości.
Dźwięk, metadane analityczne, miniatury i indeks bazy także zajmują miejsce. Audio 64 kb/s wydaje się małe przy obrazie 4 Mb/s, lecz pomnożone przez wiele kamer i 30 dni staje się mierzalnym składnikiem.
Sprawdź, czy eksport zdarzeń, kopia zapasowa lub drugi serwer nie przechowuje osobnej kopii. Ten sam materiał zapisany w dwóch lokalizacjach wymaga dwóch niezależnych bilansów pojemności.
Przykład: osiem kamer po 4 Mb/s przez 30 dni
Łączny strumień wynosi 32 Mb/s
Osiem kamer pomnożonych przez 4 Mb/s daje 32 Mb/s. Po podzieleniu przez osiem zamieniamy bity na bajty i otrzymujemy 4 MB danych na sekundę w jednostkach dziesiętnych.
W ciągu godziny zapis wynosi 4 MB/s × 3600 = 14 400 MB, czyli 14,4 GB. W ciągu pełnej doby powstaje 345,6 GB, a przez 30 dni 10 368 GB.
Po przeliczeniu 1000 GB = 1 TB otrzymujemy 10,368 TB, czyli około 10,37 TB przed rezerwą. Rachunek zakłada ciągły zapis przez 24 godziny na dobę.
Rezerwa 20% podnosi cel do 12,44 TB
Kalkulator mnoży pojemność bazową przez 1,20. Dla 10,368 TB daje to 12,4416 TB, wyświetlane jako 12,44 TB. Rezerwa wynosi około 2,07 TB.
To pojemność użyteczna dostępna dla nagrań, a nie suma etykiet dysków. Jeżeli macierz RAID traci część przestrzeni na parzystość lub kopię lustrzaną, surowa pojemność fizycznych nośników musi być większa.
Nie zaokrąglaj 12,44 TB do jednego dysku 12 TB. Już nominalnie brakuje 0,44 TB, a po formatowaniu i utworzeniu systemu plików dostępna wartość będzie wyglądać inaczej. Dobierz konfigurację, która przekracza wymaganie użyteczne.
| Okres lub etap | Pojemność |
|---|---|
| 1 godzina | 14,4 GB |
| 1 doba | 345,6 GB |
| 30 dni bez rezerwy | 10,368 TB |
| rezerwa 20% | 2,0736 TB |
| cel użyteczny | 12,4416 TB |
Dlaczego system może pokazywać mniej terabajtów niż etykieta dysku?
Producenci dysków używają TB dziesiętnych, a część systemów pokazuje TiB
Jeden terabajt dziesiętny to 1 000 000 000 000 bajtów. Jeden tebibajt to 2⁴⁰ bajtów, czyli 1 099 511 627 776 bajtów. To różne jednostki, choć interfejs może opisać obie skrótem TB.
Pojemność 12,4416 TB dziesiętnego odpowiada około 11,32 TiB. Różnica nie oznacza, że producent ukrył przestrzeń; wynika głównie ze sposobu dzielenia tej samej liczby bajtów.
Dodatkową część zajmuje system plików, baza nagrań, partycje i przestrzeń zarezerwowana przez rejestrator. Dlatego porównuj wymagane bajty z udokumentowaną pojemnością użyteczną konkretnego systemu.
Rezerwa ma pokryć zmienność, a nie błędne jednostki
Margines 20% pomaga przy wyższym bitrate, dodatkowych metadanych i zmianach konfiguracji. Nie powinien służyć do przypadkowego ukrywania różnicy między pojemnością surową a użyteczną macierzy.
Najpierw policz dane, potem straty RAID i systemu, a na końcu sprawdź, czy pozostaje zaplanowana rezerwa. Jeśli wszystko wrzucisz do jednego niejasnego procentu, trudno później ustalić przyczynę krótszej retencji.
W systemie o wymaganej retencji prawnej lub kontraktowej warto przyjąć scenariusz maksymalny i regularnie mierzyć liczbę rzeczywiście dostępnych dni. Sam projektowy procent nie jest dowodem spełnienia wymagania.
Co najbardziej zmienia rzeczywisty rozmiar nagrań?
VBR reaguje na ruch, szum i scenę nocną
Przy VBR kamera przydziela więcej bitów trudnym fragmentom. Liście poruszane wiatrem, deszcz, tłum, ruch uliczny i śnieg zwiększają ilość zmieniających się szczegółów. Statyczny korytarz może zużywać znacznie mniej.
W nocy szum matrycy i owady oświetlone promiennikiem IR potrafią podnieść bitrate. Kamera testowana w dzień może więc nie ujawnić najbardziej wymagającego okresu.
Kodek H.265 może zmniejszyć średni strumień względem H.264 przy podobnej jakości, ale efekt zależy od implementacji, sceny i ustawień. Zmiana kodeka wymaga też zgodności rejestratora, stacji klienckich i eksportu dowodowego.
Zapis zdarzeniowy nie jest prostym skróceniem do kilku godzin
Pole godzin dziennie może modelować harmonogram, na przykład zapis tylko przez 12 godzin. Przy detekcji ruchu liczba godzin aktywnego nagrania zmienia się z dnia na dzień i między kamerami.
Bufor przed zdarzeniem i po zdarzeniu wydłuża każdy klip. Fałszywe alarmy od cieni, deszczu lub roślin mogą zamienić planowane 4 godziny zapisu w prawie pełną dobę.
Aby oszacować zapis zdarzeniowy, zmierz rzeczywisty udział czasu aktywnego w reprezentatywnym okresie i dodaj wariant szczytowy. Dla krytycznej retencji nie zakładaj optymistycznego odsetka wyłącznie na podstawie pustej sceny testowej.
Zmiana rozdzielczości, fps lub GOP wpływa na bitrate i użyteczność obrazu
Mniejsza liczba klatek i niższa rozdzielczość mogą ograniczyć dane, ale również utrudnić analizę szybkiego zdarzenia lub identyfikację szczegółu. Oszczędność dysku nie powinna naruszać celu systemu.
Długi GOP poprawia kompresję, lecz wpływa na przewijanie, odporność na utratę danych i dokładność eksportu od konkretnej klatki. Parametry trzeba dobrać razem z wymaganiami dowodowymi i wydajnością rejestratora.
Najpierw ustal wymagany poziom szczegółu, kąt kamery i czas retencji. Dopiero potem optymalizuj kodek i bitrate na scenie testowej; nie zaczynaj od najmniejszej liczby, która mieści się na posiadanym dysku.
Jak przejść od wymaganych TB do działającego archiwum?
RAID zmienia pojemność użyteczną i odporność na awarię
W lustrze RAID 1 połowa surowej pojemności przechowuje kopię. W RAID 5 odpowiednik jednego dysku jest przeznaczony na parzystość, a w RAID 6 dwóch, zanim uwzględni się system plików i nierówne rozmiary nośników.
RAID nie jest kopią zapasową. Chroni dostępność przy określonej liczbie awarii dysków, ale nie przed usunięciem nagrań, błędem konfiguracji, pożarem, kradzieżą rejestratora czy zaszyfrowaniem systemu.
Odbudowa dużej macierzy trwa i mocno obciąża dyski. Projekt powinien sprawdzić, czy podczas rebuild system nadal przyjmuje łączny strumień 32 Mb/s i obsługuje odczyty użytkowników.
Wydajność zapisu i limit liczby kamer są równie ważne jak pojemność
Rejestrator może mieć limit łącznego bitrate wejściowego, liczby kanałów, rozdzielczości dekodowania i równoczesnego odtwarzania. Dysk o odpowiedniej liczbie TB nie znosi tych ograniczeń.
Nośniki przeznaczone do monitoringu są projektowane do ciągłego zapisu wielu strumieni, ale trzeba sprawdzić listę zgodności producenta NVR. Firmware, interfejs SATA, temperatura i zasilanie wpływają na niezawodność.
Alarm SMART lub błąd jednego dysku powinien generować powiadomienie. Bez monitoringu macierz może działać zdegradowana do czasu kolejnej awarii, kiedy retencja i dostępność zostaną utracone.
Retencję potwierdza data najstarszego nagrania
Po uruchomieniu obserwuj dzienny przyrost danych i najstarszy dostępny materiał. Gdy system się wypełni i zacznie nadpisywać, różnica między bieżącym czasem a najstarszym nagraniem pokazuje rzeczywistą retencję.
Test wykonaj w typowych oraz trudnych okresach, na przykład po tygodniu intensywnego ruchu i nocnej pogodzie. Jeśli retencja spada poniżej celu, wskaż przyczynę: wyższy bitrate, więcej godzin, dodatkowe strumienie czy mniejsza pojemność użyteczna.
Udokumentuj ustawienia kamer, wersje firmware, liczbę dysków i politykę nadpisywania. Bez tego późniejsza zmiana jakości może skrócić archiwum niezauważenie.
- przelicz wymaganą pojemność użyteczną
- dobierz RAID i pojemność surową
- sprawdź limit zapisu NVR
- uruchom alarmy stanu dysków
- zmierz najstarsze dostępne nagranie po zapełnieniu systemu
Najczęstsze pytania
Czy dysk 12 TB wystarczy dla wyniku 12,44 TB?
Nie. Już nominalna pojemność jest mniejsza od celu, a system plików i konfiguracja rejestratora dodatkowo zmniejszają przestrzeń dostępną na nagrania.
Dlaczego system pokazuje mniej niż suma etykiet dysków?
Może używać TiB zamiast TB, zajmować miejsce na system i metadane albo przeznaczać część nośników na kopię lub parzystość RAID.
Jak uwzględnić nagrywanie po detekcji ruchu?
Zmierz rzeczywisty udział aktywnego zapisu wraz z buforem przed i po zdarzeniu. Policz też wariant szczytowy, bo pogoda i fałszywe alarmy zwiększają liczbę klipów.
Czy H.265 zawsze zmniejszy pojemność o połowę?
Nie. Zysk zależy od sceny, ustawień i implementacji. Porównaj rzeczywisty obraz oraz średni bitrate na tej samej kamerze.
Czy RAID jest kopią zapasową nagrań?
Nie. Zwiększa dostępność przy awarii dysku, ale nie chroni przed skasowaniem, sabotażem, awarią rejestratora ani utratą całej lokalizacji.
Jak sprawdzić rzeczywistą retencję?
Po zapełnieniu archiwum porównaj bieżący czas z datą najstarszego dostępnego nagrania i powtarzaj kontrolę przy trudnych scenach oraz po zmianach ustawień.
Źródła i dalsza lektura
- FFmpeg Project. (n.d.). FFmpeg codecs documentation.
- ONVIF. (n.d.). ONVIF specifications for IP-based physical security products.