Como dimensionar Storage para CFTV: fórmula por bitrate, retenção, capacidade líquida, RAID, Recording Database, Archive Database, rede e testes de aceite.
Confira!
Storage para CFTV deve ser dimensionado por dois requisitos independentes: espaço líquido suficiente para reter as gravações e desempenho sustentado para receber, consultar e preservar os vídeos durante a operação normal e degradada. A conta começa pelo bitrate efetivo de cada stream, pelo tempo de gravação, pelos dias de retenção e pelos dados adicionais. Depois entram a proteção RAID, as reservas, o sistema de arquivos, o desempenho de leitura/escrita, o arquivamento e as condições de falha.
Para sistemas corporativos com VMS como Milestone XProtect ou Genetec Security Center, a capacidade bruta informada nos discos não é a capacidade disponível para gravação. Também não é suficiente multiplicar megapixels por câmeras: resolução, FPS, codec, complexidade da cena, áudio, eventos, perfis de gravação e operações concorrentes alteram profundamente a demanda. O projeto deve apresentar uma memória de cálculo auditável e validar os resultados com a arquitetura realmente fornecida.
Como calcular o armazenamento necessário para CFTV
Para gravação contínua, usando bitrate médio efetivo em megabits por segundo, uma aproximação inicial em unidades decimais é:
Volume de vídeo (TB) ≈ Nº de câmeras × bitrate médio por câmera (Mbit/s) × 86.400 × dias de gravação ÷ 8.000.000.
Em forma compacta, cada 1 Mbit/s gravado continuamente durante 24 horas corresponde a aproximadamente 10,8 GB decimais por dia. Em trinta dias, isso significa 0,324 TB por Mbit/s de fluxo contínuo. O fator é matemático; não representa o consumo que todas as câmeras terão. O projeto precisa obter bitrate representativo do stream efetivamente armazenado.
Imagine 100 câmeras com 4 Mbit/s médios cada, durante 24 horas por dia por 30 dias. O fluxo agregado é de 400 Mbit/s, ou cerca de 50 MB/s antes dos overheads. O volume de vídeo puro é aproximadamente 129,6 TB decimais. Isso ainda não inclui áudio, metadados, índices, reservas do storage, capacidades reais de volume, preservação de evidências ou expansão. O resultado é um ponto de partida para dimensionar a plataforma, não o número final de discos a comprar.
Em um segundo cenário, 60 câmeras com 2,5 Mbit/s constantes, gravadas durante 30 dias, representam 48,6 TB decimais de vídeo. Se metade das câmeras realmente grava por eventos com ocupação efetiva de 40% do tempo, o total muda; porém, não é tecnicamente correto aplicar 40% à instalação inteira sem medir os perfis de cada grupo. Também é possível que a gravação por eventos mantenha pré-buffer e pós-buffer, acrescentando conteúdo fora do momento de movimento detectado.
| Cenário ilustrativo | Fluxo médio agregado | Volume bruto de vídeo em 30 dias |
|---|---|---|
| 30 câmeras × 2 Mbit/s, 24×7 | 60 Mbit/s | 19,44 TB |
| 60 câmeras × 2,5 Mbit/s, 24×7 | 150 Mbit/s | 48,60 TB |
| 100 câmeras × 4 Mbit/s, 24×7 | 400 Mbit/s | 129,60 TB |
| 200 câmeras × 4 Mbit/s, 24×7 | 800 Mbit/s | 259,20 TB |
A tabela utiliza valores médios constantes para ilustrar a matemática. Nenhum desses números deve substituir testes ou simulações de bitrate baseados nas cenas e nos equipamentos realmente selecionados. Para interpretar o comportamento dos codificadores e a relação com FPS e resolução, consulte bitrate em sistemas de videomonitoramento IP.
A memória de cálculo deve começar por cada tipo de câmera
Em um projeto corporativo, raramente todas as câmeras apresentam a mesma resolução, enquadramento ou atividade. Dome fixas em corredores, bullets de perímetro, PTZ e câmeras multidirecionais podem gerar demandas muito diferentes. Agrupe os equipamentos por perfil de stream, não apenas por unidade física: uma câmera multidirecional pode disponibilizar vários canais de vídeo e registrar cada um separadamente no VMS.
Os streams gravados, a capacidade líquida e o tráfego da rede precisam ser dimensionados em conjunto. O projeto de CFTV estabelece os requisitos que permitem comparar soluções de storage sem omitir disponibilidade ou retenção.
Para cada grupo, a engenharia registra quantidade, codec, resolução, FPS, bitrate nominal e de pico, modalidade contínua ou por evento, horas operacionais e retenção requerida. Cenas com movimento, folhagens, chuva ou baixa luz podem elevar o bitrate em VBR, pois o encoder precisa descrever maior complexidade. Por outro lado, redução de ruído, compressão adaptativa e períodos pouco movimentados alteram a média. A memória deve explicitar a origem das premissas e sua variabilidade.
O cálculo deve usar o stream efetivamente gravado, que nem sempre coincide com aquele visto no aplicativo da câmera ou no mosaico da central. Uma instalação configurada para monitorar em substream e gravar em stream principal precisa considerar o perfil mais exigente no storage; um erro de seleção de stream pode resultar em retenção aparentemente maior à custa de evidências com menor definição. A conferência deve abranger resolução gravada, taxa de quadros, compressão e perfil dos eventos.
Também há demandas que não são simples fluxo de vídeo. Áudio, analytics, metadados, anotações, índices, proteção de evidências e bancos de configuração consomem recursos, ainda que sua contribuição em TB seja frequentemente menor que a das imagens. Como cada produto possui arquitetura própria, percentuais genéricos de overhead não devem ser apresentados como regra universal. Use recomendações do fabricante e ensaios representativos.
Uma planilha auditável pode conter colunas para local, identificação da câmera, perfil, quantidade de streams, bitrate medido, fator de atividade, retenção, volume por grupo, responsável pela premissa e versão da configuração. Isso permite revisar a conta quando uma lente, codec ou exigência operacional mudar, sem refazer o dimensionamento a partir de suposições não documentadas.
Gravação contínua, por movimento e por evento não são equivalentes
Uma câmera configurada para gravação contínua gera dados durante todo o período de funcionamento. Uma câmera configurada para movimento ou evento armazena apenas intervalos definidos pelas regras, dependendo do pré-buffer, do pós-buffer e da política do VMS. A estimativa de economia deve considerar o tempo de gravação efetivo e não simplesmente a quantidade de disparos por dia.
A ocupação de gravação muda conforme a operação. Um acesso que registra pouco movimento à noite pode ficar ocupado quase o dia inteiro em horário comercial. Uma câmera de perímetro exposta à vegetação e à chuva pode disparar eventos mesmo quando não há intrusão real. A análise de risco precisa considerar se a economia de espaço justifica o risco de não registrar algum trecho relevante.
Em sistemas que implementam pré-buffer na memória ou no disco, o efeito sobre o storage pode ser diferente. A documentação de arquitetura do Milestone XProtect distingue o pré-buffer em memória, que evita gravação permanente antes do evento, do pré-buffer em disco, que mantém escrita mesmo de material posteriormente descartado. Duas soluções com a mesma taxa de retenção podem, portanto, gerar cargas de escrita distintas.
A estimativa precisa separar volume guardado e trabalho realizado pelo storage. Um sistema pode arquivar apenas 30% do tempo e ainda manter atividade significativa de escrita no disco devido ao método de buffering. O mesmo ocorre quando o arquivamento transfere grande quantidade de gravações entre volumes: o total retido continua igual, mas há carga adicional de leitura e escrita.
O projeto deve registrar condições de operação normal e de eventos excepcionais. Em unidades com milhares de visitantes, o percentual de movimento de um mês tranquilo pode não representar períodos de maior atividade. Retenção e desempenho não podem ser prometidos com base apenas em teste curto ou em uma estimativa de ocupação otimista.
Recording Server, Recording Database e Archive Database
O Recording Server é o componente responsável por receber e armazenar streams, conforme a arquitetura do VMS. O armazenamento ativo é frequentemente descrito, no XProtect, como Recording Database; o Archive Database recebe dados transferidos segundo políticas de arquivamento. O componente de gerenciamento, os bancos de configuração e os clientes possuem funções e recursos próprios. Esses conceitos não devem ser fundidos em um único item de orçamento chamado “servidor de gravação”.
A documentação de arquitetura da Milestone explica que a Recording Database recebe escritas de muitos dispositivos em paralelo. Na presença de um Archive Database, os registros são transferidos segundo o agendamento, e o VMS pode recuperá-los de forma transparente ao usuário. O arquivamento pode ser organizado em camadas com tecnologias de custo e desempenho diferentes, desde que o planejamento considere todas as operações.
Uma gravação ativa de dezenas ou centenas de câmeras não se comporta como uma cópia única de um arquivo grande. Além dos streams, existem atualizações de índices e outras operações menores. O sistema pode exigir grande número de transações de armazenamento, mesmo com throughput agregado modesto. Por isso, IOPS e latência precisam ser analisados em conjunto com a taxa de dados e as recomendações do software.
Se o projeto prevê migração de gravações para archive, o cálculo precisa considerar as janelas em que um volume ainda retém dados além do período nominal até a próxima execução do arquivamento. O exemplo da Milestone é esclarecedor: uma base configurada com sete dias e processo diário pode conter gravações com quase oito dias antes da transferência. Dimensionar estritamente sete dias pode desconsiderar esse intervalo operacional.
A política também define o que acontece quando um volume atinge seu limite de capacidade. Dependendo do VMS, dados antigos podem ser removidos ou movidos, afetando o prazo real de retenção. O contrato deve exigir uma configuração capaz de manter o mínimo contratado nas condições de maior carga, sem depender da exclusão antecipada de imagens.
Como selecionar HDD, SSD e tecnologias de armazenamento
O dispositivo físico precisa atender a capacidade e ao perfil de acesso. HDDs de alta capacidade podem ser econômicos em arquivos grandes, mas seu tempo de acesso mecânico limita certas cargas de gravação concorrente. SSDs possuem vantagens em latência e IOPS, embora custo, endurance de escrita, desempenho sustentado e políticas de proteção devam ser avaliados para uso contínuo. Escolher uma tecnologia apenas pela capacidade ou pelo preço por TB pode gerar uma solução inadequada.
A Milestone, em suas recomendações para armazenamento, destaca que a gravação envolve múltiplos arquivos em tempo real e apresenta exigências distintas entre Recording Database e Archive Database. Essa característica pode justificar separar uma camada de ingestão de uma camada voltada à retenção por prazo maior. O projeto, entretanto, não deve impor SSDs ou determinada rotação de HDD sem analisar o workload e a arquitetura homologada.
Quando utilizar SSD, a especificação deve verificar DWPD ou TBW, reservas para desgaste, proteção contra perda de energia conforme aplicação, firmware e condições de garantia. A endurance de uma unidade destinada a aplicações leves não pode ser presumida adequada a escritas contínuas. Em plataformas híbridas, a efetividade de cache, política de destaging e comportamento após falha de energia precisam ser comprovados.
Também se avalia conexão e organização: discos internos, DAS, NAS ou SAN. Um NAS pode facilitar centralização e compartilhamento, mas acrescenta dependências de rede, controladora e protocolos. Uma SAN pode atender arquiteturas maiores e requisitos específicos, porém exige avaliação de multipath, switch, controladora e operação. DAS reduz certas dependências de rede, mas pode limitar centralização. Nenhuma dessas siglas representa garantia automática de disponibilidade.
| Arquitetura | Condição em que faz sentido avaliar | Risco a testar |
|---|---|---|
| DAS / discos locais | Gravação concentrada em servidor ou appliance | Recuperação de servidor e capacidade de expansão |
| NAS | Compartilhamento de arquivo com rede apropriada | Latência, throughput, protocolo e falha de rede |
| SAN | Ambientes com requisitos de bloco e alta escala | Caminhos, controladoras e multipath |
| Camadas Recording + Archive | Retenção prolongada e ingestão intensa | Carga de transferência e janelas de arquivamento |
| SSD em gravação ativa | Carga concorrente e latência exigente | Endurance, custo e comportamento sustentado |
A escolha precisa seguir a compatibilidade do VMS e do servidor. Não se deve afirmar que qualquer appliance oferece desempenho igual por utilizar discos da mesma capacidade. Controladoras, firmware, número de dispositivos, organização dos volumes e comportamento do software devem constar da proposta e ser confirmados em testes.
RAID 1, RAID 5, RAID 6 e RAID 10: proteção e capacidade líquida
RAID permite organizar discos para desempenho e tolerância a determinados modos de falha. RAID não substitui backup, replicação ou failover, nem protege contra exclusão lógica, corrupção, ataque ou perda de todo o equipamento. A escolha depende do equilíbrio entre capacidade útil, tolerância a falhas, tempo de rebuild e desempenho sob carga. Uma especificação que apenas informa “RAID” não descreve o risco aceito.
Em arranjos usuais de discos iguais, RAID 5 emprega capacidade equivalente a uma unidade para paridade e tolera uma falha de disco; RAID 6 emprega o equivalente a duas e tolera até duas falhas. RAID 10 combina espelhamento e distribuição e utiliza aproximadamente metade da capacidade, com tolerância condicionada aos pares que falharem. A configuração e o comportamento precisam ser confirmados conforme fabricante e controladora.
Com oito HDDs de 16 TB nominais, a capacidade bruta anunciada é 128 TB. O RAID 5 teria teoricamente 112 TB e o RAID 6, 96 TB antes de formatação, reservas, índices e outros consumos. Se a memória de vídeo prevê 90 TB, não se pode afirmar que “cabe em 96 TB” sem avaliar espaço livre mínimo, crescimento, metadados e o comportamento do VMS próximo do limite.
| Exemplo: oito discos de 16 TB | Capacidade teórica antes de overheads | Tolerância de falha de disco |
|---|---|---|
| Sem RAID | 128 TB | Nenhuma |
| RAID 5 | 112 TB | Uma unidade |
| RAID 6 | 96 TB | Até duas unidades |
| RAID 10 | 64 TB | Depende dos pares afetados |
O custo do RAID precisa ser confrontado com a exigência de preservação de imagens. Discos de alta capacidade podem tornar prolongada a reconstrução de paridade; durante o rebuild, a gravação continua competindo por recursos. Uma escolha aparentemente econômica pode apresentar risco operacional elevado, especialmente quando não há margem de desempenho degradado. A comparação aplicada está no artigo RAID 5 vs RAID 6 para CFTV.
Hot spare, política de substituição, identificação de slots e suporte para componentes compatíveis devem entrar no memorial. Uma unidade de reserva pode reduzir tempo antes do rebuild, mas não garante que toda a capacidade de gravação será preservada durante a recuperação. O teste de falha precisa verificar tanto integridade de dados quanto ingestão dos streams.
Retenção não é capacidade bruta: reservas, limites e arquivos protegidos
Um projeto pode exigir trinta, sessenta ou noventa dias de gravação, mas o storage só entrega a retenção contratada se o volume líquido for suficiente durante todo o período de operação. Devem ser considerados volume de vídeo, áudio, metadados, índices, overheads do sistema de arquivos, margens operacionais, crescimento e espaços reservados para incidentes. O percentual de reserva não deve ser inventado como regra universal: cada plataforma possui requisitos e a política precisa ser explicitada.
A documentação de Storage and Archiving da Milestone 2026 R1 alerta que bases podem mover ou excluir os registros mais antigos ao atingir determinados limites de espaço livre. São comportamentos específicos do produto, não valores mínimos para todo sistema CFTV. A engenharia deve identificar os limites da edição e versão contratadas e manter distância operacional desses gatilhos.
A documentação de armazenamento da Genetec Security Center 5.14 recomenda avaliar requisitos por função Archiver ou Auxiliary Archiver e considerar vídeos protegidos contra eliminação automática, além de modos de gravação e metadados. Isso demonstra que a capacidade retida não depende apenas da quantidade física dos discos e do bitrate das câmeras.
Gravações protegidas para investigação podem permanecer além do ciclo comum de sobrescrita. Se o planejamento não previr sua ocupação, o sistema pode reduzir o período efetivo de retenção das demais imagens. O projeto deve distinguir espaço para operação cotidiana de volume preservado por exigência contratual, judicial ou administrativa, respeitando a finalidade e os controles de privacidade.
A configuração precisa ser auditável. A tabela de volumes deve mostrar capacidade bruta, nível RAID, capacidade do volume, reservas, espaço dedicado a gravação ativa, archive e retenção protegida, incluindo as premissas usadas. Uma planilha que termina na capacidade de catálogo do fabricante não constitui memória de dimensionamento concluída.
O desempenho também depende da rede e das consultas simultâneas
O fluxo agregado de câmeras percorre switches, uplinks, interfaces de servidor e camadas de armazenamento. Uma conta pode indicar apenas 300 Mbit/s de ingestão, mas deixar de considerar tráfego de usuários visualizando câmeras ao vivo, reprodução de vídeos, exportação e transferências de arquivos. A taxa exigida deve ser estimada por direção e por interface, incluindo períodos de maior uso simultâneo.
A rede deve ser avaliada pela capacidade realmente utilizável e pelas exigências de disponibilidade, não somente pelo valor nominal de uma porta. Uma interface de 1 Gb/s pode aparentar folga em condições normais e, ainda assim, concentrar tráfego de câmeras e clientes de maneira inadequada. Segmentação, roteamento, QoS quando pertinente, redundância, caminhos e políticas de firewall precisam ser coerentes com o projeto.
O storage enfrenta operações simultâneas diferentes: gravação dos streams, atualização de índices, consulta de registros, exportações e arquivamento. O fabricante pode indicar IOPS de referência, mas uma única métrica não traduz a carga. IOPS, throughput, latência, distribuição de operações e tamanho dos blocos precisam ser observados no cenário do VMS. A documentação de desempenho da base de mídia do XProtect explica por que a carga de gravação de muitos dispositivos não se reduz a um único fluxo sequencial.
Uma solução que mantém os vídeos ao vivo sem problemas pode apresentar travamento na pesquisa quando vários operadores realizam busca forense. Isso exige teste representativo, inclusive com o storage próximo da ocupação prevista e com grupos relevantes de câmeras. A ingestão deve continuar enquanto as consultas são realizadas, salvo degradações explicitamente aceitas pelo contratante.
O projeto de rede lógica e redes corporativas complementa o dimensionamento: transporte, gravação, administração e operação devem ser coordenados para reduzir gargalos e falhas comuns. A arquitetura precisa demonstrar em qual segmento cada tipo de tráfego aparece e qual recurso atende ao pior cenário contratado.
Disponibilidade, failover e o que ocorre durante a perda de storage
A presença de RAID não significa continuidade garantida da gravação. O servidor pode ficar indisponível, o sistema de arquivos pode falhar, a rede pode perder conectividade ou uma função do VMS pode parar mesmo com todos os discos saudáveis. Para cada classe de falha, a equipe deve indicar comportamento esperado e tempo máximo aceitável sem registro. Esses requisitos orientam a necessidade de failover, gravação local, replicação ou outras estratégias.
A disponibilidade da gravação exige coordenação de servidores, controladoras, rede e mecanismos de recuperação. O desenho de segurança integrada define os eventos que não podem deixar de ser registrados e os procedimentos de contingência.
No XProtect, os mecanismos de failover e a reação à indisponibilidade de storage dependem do produto e da configuração. A documentação de gerenciamento de Storage and Archiving distingue parada de gravação por perda do armazenamento e possíveis ações quando há Recording Server de failover. A existência do recurso no catálogo não significa que foi instalado e testado.
Uma matriz de disponibilidade deve abranger perda de um disco, controladora, Recording Server, interface de rede, switch, energia e local físico. É necessário reconhecer dependências comuns: dois servidores podem usar o mesmo storage, duas interfaces podem depender do mesmo switch, e uma controladora redundante pode compartilhar alimentação ou chassis. A análise não precisa exigir duplicação universal, mas deve expor o risco residual.
Quando houver gravação de borda, verifique duração de buffer e como o VMS recupera os segmentos depois de restabelecida a comunicação. Sem esse teste, o sistema pode apresentar uma falsa promessa de continuidade. O procedimento precisa contemplar sincronização de horários, integridade de arquivos e consequências de eventuais duplicações ou lacunas.
A escolha de RAID e failover deve decorrer do impacto da perda de imagens para cada área. Câmeras do perímetro, ambientes regulados e acessos críticos podem justificar prioridade diferente de áreas secundárias. Essas decisões precisam constar do projeto de CFTV, e não apenas de uma proposta de servidor.
SSD, HDD e configuração do sistema operacional do servidor
A instalação do sistema operacional e do software de gravação em volumes próprios pode reduzir interferências sobre a base de vídeo e simplificar manutenção. A Milestone recomenda discos físicos separados para sistema operacional e gravações, explicando que separar apenas partições lógicas não elimina interferência nem o risco de falha de uma mesma unidade física. Esse é um requisito de arquitetura a avaliar com o produto homologado.
Configurações de formatação, tamanho da unidade de alocação, controladora, cache e políticas de escrita influenciam o desempenho. Para determinadas instalações do XProtect em Windows, a documentação do fabricante recomenda NTFS e unidade de alocação de 64 KiB ou superior. Essa recomendação não deve ser generalizada para qualquer NAS, SAN ou sistema operacional sem verificação do fabricante e da arquitetura utilizada.
O projeto também precisa registrar processo de atualização, backup de configurações, gerenciamento de credenciais e acesso remoto autorizado. Um incidente no sistema operacional pode impedir a gravação mesmo que os volumes de vídeo estejam íntegros. A operação requer documentação para restauração de serviços e controle de mudanças de firmware, drivers e versões do VMS.
Em plataformas virtualizadas, o storage e os recursos computacionais precisam ser reservados e observados no workload real. A virtualização não elimina as exigências de throughput, latência, CPU e rede. A solução só deve ser aceita quando o fornecedor demonstrar compatibilidade, monitoramento e recuperação das máquinas virtuais e dos volumes, sem introduzir pontos únicos de falha incompatíveis com a disponibilidade.
A separação física de volumes e responsabilidades facilita diagnóstico. A equipe deve conseguir distinguir falha de disco, saturação do volume, processo de arquivamento, processamento do servidor e incidente de rede. Quanto mais interfaces existirem, maior a necessidade de desenhos, alarmes e procedimentos que permitam localizar rapidamente a causa.
Exemplo de dimensionamento com gravação e arquivamento em camadas
Considere, apenas para ilustração, oitenta câmeras com bitrate médio de 3 Mbit/s, gravando continuamente durante trinta dias. O fluxo agregado é 240 Mbit/s e o volume total de vídeo puro é 77,76 TB decimais. Uma arquitetura hipotética pode reter a gravação ativa por sete dias e transferir o restante para Archive Database, mas a necessidade de espaço da camada ativa não pode ser calculada como exatamente sete dias se houver janela de transferência.
Sete dias de fluxo representam 18,144 TB. Se o arquivamento ocorrer uma vez por dia, pode ser necessário suportar até oito dias de dados no volume ativo antes da transferência, além das margens pertinentes: 20,736 TB de vídeo puro. O volume de arquivo receberia dados remanescentes até o horizonte de trinta dias conforme as regras e o calendário de movimentação. Não se deve somar indiscriminadamente trinta dias de gravação ativa e trinta dias de archive se o material é movido, não duplicado.
| Etapa do exemplo | Volume de vídeo puro, antes dos overheads |
|---|---|
| 80 câmeras × 3 Mbit/s, por dia | 2,592 TB |
| 7 dias de gravação ativa | 18,144 TB |
| Até 8 dias antes de uma transferência diária | 20,736 TB |
| 30 dias de retenção total | 77,760 TB |
O desenho detalhado exige considerar o modo de transferência de cada produto, sobreposição temporária, possíveis reprocessamentos, retenção protegida, exportações e throughput adicional de arquivamento. Uma gravação de evento com pré-buffer em disco pode gerar escrita superior à quantidade de arquivos finais retidos, alterando principalmente o desempenho. O exemplo demonstra por que não existe uma única conta que substitua a análise da arquitetura.
O cálculo de investimento também deve considerar expansão de câmeras, mudanças de codec, aumento da taxa de quadros e novos serviços de analytics. Uma capacidade que atende ao primeiro ano pode não atender ao crescimento contratado. A memória de cálculo precisa apresentar cenários atual e futuro, com condicionantes e gatilhos para expansão.
Como elaborar a especificação técnica para contratação do storage
A especificação deve declarar resultados a entregar, não apenas marcas e quantidade de discos. É necessário informar número de câmeras por perfil, streams, bitrate de referência e condições de medição, período de retenção, modo de gravação, arquitetura do VMS e exigência de disponibilidade. O fornecedor deve demonstrar como o hardware proposto atende a esses requisitos.
A lista de componentes pode abranger servidores, processadores, memória, sistema operacional, interfaces de rede, controladoras, discos, volumes, licenças do VMS, proteção elétrica, switches, suportes e condições ambientais. Também deve indicar compatibilidade, assistência técnica, substituição de discos e suporte de versões. A obrigação de integrar componentes de fabricantes distintos precisa ter responsável nomeado.
| Requisito contratual | Documento / evidência necessária | Critério de verificação |
|---|---|---|
| Quantidade e perfil de câmeras | Matriz de streams e bitrates | Revisão de premissas |
| Retenção de gravações | Memória de capacidade líquida | Verificação de volumes e políticas |
| Gravação simultânea | Perfil de ingestão e concorrência | Ensaio de carga |
| RAID e tolerância | Desenho de arranjos e falhas | Teste controlado |
| Arquivamento | Diagrama de tiers e agendamentos | Teste de transferência e recuperação |
| Operação do VMS | Licenças e compatibilidade | Teste integrado e logs |
| Aceitação | Plano de Inspeção e Testes (PIT) | Relatório técnico com pendências |
Os critérios precisam ser estabelecidos antes da aquisição. Se a proposta exclui sistema operacional, serviços de instalação, configuração de RAID ou comissionamento, essa exclusão não pode ficar implícita. A análise de equivalência técnica deve observar capacidade utilizável e desempenho, não somente o número de gavetas ou o tamanho bruto anunciado.
O Projeto de CFTV IP e Videomonitoramento coordena gravação, rede, câmeras, VMS e requisitos de segurança. A especificação do storage deve ser parte dessa engenharia, pois mudanças em resolução, bitrate e retenção afetam os demais componentes.
Comissionamento: comprovar gravação, consulta, falha e retenção
O primeiro ensaio valida a configuração, os volumes disponíveis e o vínculo entre cada câmera e o storage previsto. O segundo verifica ingestão em carga representativa, sem perda de períodos contratualmente relevantes. O terceiro adiciona consultas e exportações concorrentes, observando filas, latência, alarmes e capacidade de pesquisa. A plataforma não deve ser aprovada apenas porque consegue exibir imagens ao vivo.
Testes de armazenamento precisam ser planejados com segurança. A simulação de perda de disco, controladora ou rede deve preservar dados e seguir procedimentos autorizados. Um rebuild pode durar significativamente mais que a janela de ensaio, exigindo abordagem por etapas ou evidências homologadas. O importante é estabelecer critérios mensuráveis e não apresentar um teste curto como garantia de desempenho permanente.
O aceite deve verificar retenção programada e comportamento dos limites de espaço; quando o prazo contratual é extenso, a validação pode combinar teste controlado e verificação de configuração e capacidade, em vez de depender exclusivamente de esperar meses. A operação deve saber quando alertas de disco, ocupação, perda de gravação ou falha de archive demandam ação.
Todos os resultados precisam registrar cenário, configuração, duração, instrumentos, carga, valores observados, responsáveis e pendências. As evidências devem permitir auditoria posterior e comparação quando ocorrer expansão ou troca de componentes. Um sistema entregue sem inventário de discos, mapas de volumes e procedimentos de contingência pode ser difícil de manter mesmo que funcione na primeira semana.
O Comissionamento de Equipamentos transforma requisitos de especificação em testes. Em sistemas críticos, o comissionamento precisa envolver rede, VMS, servidores, energia e operação para demonstrar a continuidade que foi contratada.
Erros recorrentes e roteiro de revisão da memória de cálculo
O primeiro erro é dimensionar somente por megapixels e quantidade de câmeras. O segundo é usar capacidade bruta como se todo o volume estivesse disponível depois do RAID. O terceiro é supor que bitrate constante é condição normal de todas as cenas. O quarto é ignorar acesso ao arquivo, arquivamento e rebuild como cargas adicionais. Esses erros podem coexistir e produzir resultados de retenção muito inferiores aos anunciados.
Também ocorrem estimativas de atividade sem base, aplicação de fatores de compressão publicados para cenas diferentes, falta de margem operacional e ausência de procedimentos de recuperação. Quando o VMS depende de um storage compartilhado, uma falha de rede ou controladora pode afetar vários Recording Servers; essa dependência precisa estar documentada e aceita.
Antes de liberar o projeto, a equipe deve percorrer uma verificação sequencial:
- Confirmar matriz de câmeras, streams, codec, FPS, bitrate e condições reais de gravação.
- Calcular volume de vídeo por grupo, período e cenário, separando dados efetivamente medidos de hipóteses.
- Verificar áudio, metadados, evidências protegidas e políticas de pré-buffer, retenção e arquivo.
- Dimensionar volumes, reservas e espaço líquido após RAID e formatação, usando requisitos do fabricante.
- Conferir recursos de servidores, rede, throughput, latência e acessos simultâneos em operação normal e degradada.
- Estabelecer matriz de falhas, continuidade, suporte, sobressalentes, operação e critérios de aceite.
- Registrar aprovações, limitações, versão do VMS, documentação de entrega e gatilhos de expansão.
O roteiro não elimina a necessidade de engenharia. Ele organiza a verificação para que inconsistências sejam identificadas antes da contratação, quando o custo de ajuste é menor. Uma alteração simples em FPS ou política de eventos pode mudar tanto o espaço quanto a necessidade de desempenho, devendo ser propagada à memória e ao projeto.
Considerações finais
Dimensionar Storage para CFTV significa conciliar volume retido, carga sustentada de gravação, consulta de imagens, disponibilidade e capacidade de manutenção. O cálculo por bitrate fornece uma base objetiva, mas não substitui a análise de VMS, RAID, arquivamento, rede, controladoras e cenários de falha. A infraestrutura deve preservar os streams previstos e disponibilizar gravações durante o período contratado, inclusive sob condições operacionais representativas.
Um projeto tecnicamente consistente distingue capacidade bruta e líquida, gravação ativa e arquivos, proteção de discos e recuperação de serviços. As premissas precisam ser rastreáveis e os resultados, demonstráveis. Esse é o critério que permite ao proprietário contratar uma solução comparável, receber o sistema com evidências e planejar sua expansão sem comprometer registros importantes.
A qualidade da entrega depende de ensaios documentados de gravação, consulta, proteção de discos e recuperação. Os testes demonstram se os componentes atendem à carga contratada e evidenciam pendências para o recebimento.
Referências técnicas
[1] MILESTONE SYSTEMS. XProtect Storage Architecture and Recommendations. Storage architecture. Disponível em: https://doc.milestonesys.com/xprotect/xprotect-storage-architecture-and-recommendations/v/en/storage-architecture.
[2] MILESTONE SYSTEMS. XProtect Management Client 2026 R1. Storage and archiving. Disponível em: https://doc.milestonesys.com/xprotect/xprotect-management-client/2026r1/en/storage-and-archiving.html.
[3] MILESTONE SYSTEMS. XProtect Storage Architecture and Recommendations. Media database performance and recommendations. Disponível em: https://doc.milestonesys.com/xprotect/xprotect-storage-architecture-and-recommendations/v/en/media-database-performance-and-recommendations.
[4] MILESTONE SYSTEMS. XProtect Storage Architecture and Recommendations. Microsoft Windows recommendations. Disponível em: https://doc.milestonesys.com/xprotect/xprotect-storage-architecture-and-recommendations/v/en/microsoft-windows-recommendations.
[5] MILESTONE SYSTEMS. XProtect Storage Architecture and Recommendations. Storage technologies. Disponível em: https://doc.milestonesys.com/xprotect/xprotect-storage-architecture-and-recommendations/v/en/storage-technologies.
[6] GENETEC. Security Center 5.14. Armazenamento de arquivos. Disponível em: https://techdocs.genetec.com/r/pt-BR/Guia-do-administrador-do-Security-Center-5.14/Armazenamento-de-arquivos.
[7] SEAGATE. RAID Manager — RAID Levels. Disponível em: https://www.seagate.com/manuals/software/raid-manager/raid-levels/.
[8] AXIS COMMUNICATIONS. Axis Zipstream technology — White paper. Disponível em: https://whitepapers.axis.com/en-us/axis-zipstream-technology.
Perguntas frequentes
Some os bitrates médios efetivamente gravados, multiplique por 86.400 segundos por dia e pelos dias de retenção; divida por oito para converter bits em bytes e considere overheads, RAID e reservas.
Aproximadamente 10,8 GB decimais por dia de gravação contínua, antes de outras informações e overheads.
Aproximadamente 129,6 TB decimais de vídeo puro, antes das reservas e da proteção RAID.
Bruta é a soma dos discos; líquida é o volume efetivamente disponível após RAID, formatação, reservas e demais consumos.
Não necessariamente. Depende da frequência real de eventos, pré-buffer, pós-buffer, cena e política do VMS.
É a camada de armazenamento ativo em que o VMS grava dados provenientes dos dispositivos.
É a camada que pode receber dados transferidos da gravação ativa por políticas de arquivamento e retenção.
Depende da tolerância a falhas, do desempenho durante rebuild, da capacidade útil e dos riscos aceitos.
Não. DAS, NAS ou SAN podem ser adequados conforme workload, arquitetura, suporte do VMS e disponibilidade.
É apenas uma referência inicial. Valores devem ser ajustados por cena, codec, FPS e configuração efetiva.
Não. Protegem contra falhas diferentes, e a solução precisa especificar os comportamentos de cada mecanismo.
Por ensaios de ingestão, consulta, exportação, operação degradada, alarmes, retenção, documentação e recuperação dos serviços.
Materiais técnicos complementares
Soluções relacionadas
Serviços relacionados
- Projeto de CFTV IP e Videomonitoramento
- Projeto de Rede Lógica e Redes Corporativas
- Projeto de Segurança Eletrônica Integrada
- Comissionamento de Equipamentos
