Quando um gestor de TI especifica storage para um servidor de VMS, o processo típico é: calcular a capacidade necessária para o número de câmeras e o período de retenção desejado, adicionar RAID5 por segurança, comprar os discos e o controller. O orçamento passa pelo CFO como "custo de infraestrutura de storage" e o projeto avança.
O problema é que esse processo captura apenas o custo inicial e ignora três componentes que sistematicamente distorcem o TCO real: o overhead de capacidade do RAID, a vida útil dos discos e o custo de manutenção em cenário de falha. Cada um desses componentes tem um número específico — e a soma muda a conclusão sobre qual arquitetura é mais eficiente para VMS.
O que RAID5 realmente custa em VMS
1. Overhead de capacidade: 25–33% que não serve para o negócio
RAID5 usa 1 disco de N como paridade distribuída. Com 4 discos de 4TB, você tem 12TB utilizáveis — 4TB (25%) estão ocupados com paridade que não armazena nenhum frame de vídeo.
Esse overhead não é opcional em RAID5 — ele é o mecanismo de proteção. E tem impacto direto na retenção: se o target era 30 dias com 16TB, com RAID5 você fica com 22–23 dias no mesmo hardware. Para atingir os 30 dias, você adiciona mais um disco (e mais overhead) ou compra discos maiores.
| Configuração | Discos | Capacidade total | Capacidade útil | Overhead |
|---|---|---|---|---|
| RAID5 | 4 × 4TB | 16TB | 12TB | 4TB (25%) |
| RAID5 | 6 × 4TB | 24TB | 20TB | 4TB (17%) |
| Distribuição de frames | 4 × 4TB | 16TB | 16TB | 0TB (0%) |
| Distribuição de frames | 6 × 4TB | 24TB | 24TB | 0TB (0%) |
2. Controller RAID: custo de hardware invisível no orçamento
RAID5 em servidor de produção exige controller dedicado para performance adequada — não o RAID de software do Windows, que causa carga significativa no CPU do servidor. Um controller RAID hardware de qualidade para ambiente de VMS custa entre R$ 3.000 e R$ 8.000 por servidor, dependendo do número de portas e da capacidade de cache.
Em projetos com 3 a 10 servidores de recording, esse item raramente aparece explicitamente no orçamento — é absorvido no custo do servidor ou esquecido, sendo especificado apenas quando o integrador lembra de incluí-lo. A distribuição de frames não requer controller dedicado: usa as portas SATA/SAS nativas do servidor com discos commodity.
3. Rebuild após falha: 6 a 24 horas de risco elevado
Quando um disco falha em RAID5, o sistema entra em modo degradado e inicia o rebuild — processo de reconstrução dos dados do disco perdido a partir da paridade. O rebuild de um disco de 4TB em operação normal leva 6 a 24 horas.
Durante esse período:
- O sistema continua operando em modo degradado — leituras exigem cálculo de paridade em tempo real, aumentando carga do controller e latência de acesso
- Risco de double failure é real — o stress adicional sobre os discos remanescentes durante o rebuild aumenta a probabilidade de uma segunda falha. Se isso acontecer em RAID5, a perda é total — todos os dados são irrecuperáveis
- Performance de gravação cai — em servidores com muitas câmeras, a queda de performance durante rebuild pode causar perda de frames ou gaps de gravação
O custo oculto: fragmentação e vida útil dos discos
Este é o componente de TCO mais raramente discutido e sistematicamente mais subestimado.
Em um servidor de VMS com muitas câmeras gravando simultaneamente, os dados chegam ao disco de forma aleatória — câmera 1 grava um frame, câmera 2 grava outro, câmera 1 grava mais um, câmera 7 grava o próximo. O sistema de arquivos distribui esses blocos de dado pelo espaço disponível no disco à medida que chegam, enquanto deleta simultaneamente os blocos mais antigos para liberar espaço.
O resultado é fragmentação progressiva: o disco acumula fragmentos de arquivos espalhados em posições não contíguas. O head de leitura/escrita precisa se mover fisicamente entre diferentes trilhas para acessar dados de uma mesma câmera — aumentando o seek time e acelerando o desgaste mecânico.
Em sistemas com distribuição de frames por disco, o padrão de escrita é radicalmente diferente. Cada disco recebe frames em sequência — frame 1, frame 5, frame 9, frame 13... — sempre no próximo espaço disponível, de forma linear. O disco não fragmenta porque os dados chegam ordenados. Cada disco permanece fisicamente organizado, com seek rate baixo e desgaste mínimo.
| Fator | RAID / VMS tradicional | Distribuição de frames |
|---|---|---|
| Padrão de escrita | Aleatório (múltiplas câmeras concorrentes) | Sequencial por disco |
| Fragmentação | Progressiva — piora com o tempo | Zero — estruturalmente impossível |
| Seek rate do head | Alto e crescente | Baixo e estável |
| Performance ao longo do tempo | Degrada — sistema fica mais lento | Estável durante toda a vida útil |
| Vida útil estimada | 3–4 anos em operação 24/7 | 5–7 anos em operação 24/7 |
A diferença de 2 a 3 anos de vida útil por disco, multiplicada pelo número de discos por servidor e pelo número de servidores, transforma-se em uma diferença relevante de custo de reposição e de intervenção técnica ao longo de um contrato de 5 anos.
TCO comparativo em 5 anos — servidor típico de VMS
Considerando um servidor de recording com 4 discos de 4TB, 40 câmeras, operação 24/7:
| Componente de custo | RAID5 | Distribuição de frames |
|---|---|---|
| Discos (4 × 4TB) | R$ 2.400 | R$ 2.400 |
| Controller RAID hardware | R$ 4.000–8.000 | R$ 0 |
| Capacidade útil efetiva | 12TB | 16TB |
| Substituição de discos em 5 anos (vida útil 3–4 anos) | 1 ciclo completo (R$ 2.400) | 0–1 ciclo (R$ 0–2.400) |
| Técnico: rebuild + reconfiguração por falha | R$ 800–2.000 por evento | R$ 0 (automático) |
| Risco de double failure | Perda total — custo indeterminado | N/A |
Apenas o controller RAID mais o primeiro ciclo de substituição de discos representam R$ 7.000 a R$ 12.000 de diferença por servidor em 5 anos — sem contar o custo de indisponibilidade e de manutenção técnica. Em um projeto com 5 servidores, essa diferença chega a R$ 35.000–60.000.
O que muda na retenção
A diferença de capacidade útil tem efeito direto sobre a retenção possível com o mesmo hardware. Com 16TB em vez de 12TB no mesmo servidor, a retenção aumenta 33% sem adicionar um único disco.
Para operações que precisam de 30 dias de retenção por compliance: com RAID5 em 4 discos de 4TB, podem precisar de 5 ou 6 discos para atingir a meta. Com distribuição de frames, os mesmos 4 discos chegam lá com margem.
Quando RAID ainda faz sentido em VMS
Há cenários onde RAID em VMS tem justificativa:
- Requisito de compliance de zero perda de frames — setores onde evidência degradada não é aceita e o requisito é preservação total de cada frame. Raro, mas existe em contextos forenses específicos.
- Storage compartilhado (SAN) com múltiplos servidores — em arquiteturas de storage centralizado onde o RAID é gerenciado pela SAN, a lógica de TCO muda.
- Servidor legado já com controller instalado — se o hardware já está pago, o custo marginal de usar RAID é menor.
Fora desses casos, a distribuição de frames entrega melhor TCO, maior retenção e operação mais estável ao longo do tempo para o caso de uso específico de VMS.
Próximo passo
A arquitetura de storage — junto com a decisão entre CFTV legado e VMS inteligente moderno — é onde o custo de longo prazo de um sistema de monitoramento é definido. A comparação detalhada entre as duas abordagens de VMS está em CFTV tradicional vs VMS inteligente. E para entender o que o sistema atual já tem ou não tem, os 7 sinais de obsolescência de VMS cobrem o diagnóstico técnico completo.