TrueNAS: 360 TB pra usar 70 — por que eu abandonei
Comprei dois storages HP de 12 discos cada e montei TrueNAS com ZFS pra testar mais de 240 TB na minha operação de vídeo. Entre o TB de marketing, os discos de paridade e o overhead do ZFS, a área útil caiu pra uns 70 TB por conjunto. E como eu não posso perder vídeo de cliente, eu preciso de três cópias — o que vira 360 TB comprados pra usar 70. Aqui eu conto o teste inteiro, o que quebrou no caminho, e pra quem o TrueNAS continua fazendo muito sentido.
🎧 PREFERE OUVIR? · 24 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 24 minutos no canal @josimarjmv em 28 de junho de 2026, a pedido de quem acompanha o canal, do jeito que eu sempre gravo: duas câmeras, sem corte no meio. Assista e leia junto — aqui embaixo eu refiz as contas com calma, corrigi um número que eu falei de cabeça e fui atrás da documentação do OpenZFS e dos dados públicos de falha de disco da Backblaze pra sustentar com fonte o que eu vivi na prática.
o TrueNAS funciona — ele é que não fecha a conta do meu negócio. Eu preciso de alta disponibilidade, backup, performance e redundância ao mesmo tempo, com vídeo de cliente entrando o tempo todo. Três coisas me tiraram de lá: (1) a área útil — de 12 discos de 12 TB sobra bem menos do que você imagina, porque a perda vem em três camadas empilhadas; (2) as três cópias — sem elas eu perco arquivo de cliente, e com elas a conta vira 360 TB comprados pra usar 70; (3) a replicação por snapshot, que não é ativo-ativo e deixa uma janela que a minha operação não tolera. Fora isso ainda tem o resilver, que derruba a performance do conjunto por dias quando um disco mecânico grande queima. Pra backup, produtora, agência e acervo local, o TrueNAS é excelente — e eu digo abaixo exatamente como eu montaria.
A carteirada primeiro: eu monto, eu desmonto e eu pago a conta do rack
Antes de eu falar de storage de 100, 200, 300 TB, você precisa saber de onde eu falo, pra não perder o seu tempo aqui com papagaio digital. Eu sou CEO de uma empresa de tecnologia e engenheiro de infraestrutura. Eu cuido de infraestrutura no Brasil e nos Estados Unidos, eu entro por SSH, eu escrevo código e — como todo mundo hoje — também sou vibe coder com as IDEs da vida. E eu monto servidor com a minha mão: desmonto, monto e organizo. Eu sei como a engenharia dessas coisas funciona por dentro, não por leitura.
A minha empresa é empresa de vídeo: a gente tem plataforma de vídeo. Isso define tudo o que vem a seguir. Eu preciso de alta disponibilidade, backup, performance e redundância, tudo ao mesmo tempo e em tempo real. Não existe "daqui a duas horas o arquivo aparece no outro lado". Quando o cliente sobe um vídeo, aquele vídeo tem que estar seguro e servível agora.
Antes do TrueNAS eu já tinha passado por outra experiência parecida: a gente testou armazenamento distribuído com S3 e matou aquele cluster. Esse é um capítulo à parte e eu já contei ele em outro lugar. O que interessa aqui é que eu não cheguei no TrueNAS por moda — eu cheguei procurando, de novo, uma saída open source que coubesse no meu bolso.
Por que eu fui parar no TrueNAS: eu sou open source first e sou bootstrap
Eu sou open source first, e isso não é ideologia: é modelo de negócio. A minha empresa é bootstrap, trabalha com dinheiro próprio. Eu não sou startup que recebe aporte e torra dinheiro como se não houvesse amanhã. Eu trabalho no osso. Então quando aparece uma alternativa que eu posso testar sem assinar um contrato de cinco anos, eu testo.
E foi assim que a coisa começou: chegou um profissional na empresa dizendo que usava TrueNAS em outro lugar, que era muito bom. Eu sou curioso. Vamos testar. E funcionou — eu quero deixar isso claro desde já, porque o título deste texto não é "TrueNAS é ruim". A gente montou, rodou, tinha os terabytes lá. Ele funciona.
A pergunta que eu fiz antes de comprar qualquer coisa foi outra: isso aqui é proprietário? Porque se fosse, eu estava fora na hora.
Eu não compro hardware com software proprietário — e isso não é briga com fabricante
Existe muito NAS proprietário no mercado, de marca grande, pra hospedagem e pra storage. Eu não compro. E não é que eu esteja falando mal de ninguém: eu estou falando do meu modelo de negócio. Quando você compra hardware amarrado num software proprietário, você fica vinculado à tecnologia daquela empresa, seja ela qual for. Eu preciso ter controle: controle operacional, controle de performance, controle de tudo. Se eu não tenho, pra mim não serve.
Pra hospedar a vida do cliente, isso não é preciosismo. É a mesma lógica que me fez sair da nuvem e ir pro on-premise e que me faz rodar as minhas VMs em Proxmox aqui dentro: o dia em que o fornecedor mudar a regra, eu quero ter pra onde ir. Eu tenho um iPhone no bolso, então pode me chamar de contraditório à vontade — mas pra guardar arquivo de cliente eu não abro mão disso. Eu não usaria coisa proprietária nem em casa, se fosse montar um servidor de vídeo meu.
No caso do TrueNAS a resposta foi a que eu queria: existe a versão community, open source, que você instala, desinstala e reinstala em qualquer hardware. Ou seja: eu compro um servidor de storage com 12, 20, 40 discos e, se não der certo, eu uso aquele servidor pra outra coisa. Esse foi o argumento que fechou o teste. O risco do experimento era baixo.
O tiering que a minha operação exige: do NVMe à fita
Pra você entender por que eu estava atrás desses storages, precisa entender como a coisa é organizada quando você trabalha nesse nível. A gente tem tiers de storage, camadas por temperatura do dado:
| Tier | O que fica ali | Preço e tempo de resgate |
|---|---|---|
| NVMe enterprise (quente) | Vídeo com muita procura agora | Caríssimo · imediato |
| SSD enterprise | Acervo ativo, procura média | Caro · imediato |
| HD mecânico enterprise | Arquivo sem tanta demanda de leitura | Médio · imediato, mas lento |
| Fita (glacial) | O que você guarda e não mexe mais | Baratíssimo · 2 a 3 dias pra restaurar |
O NVMe é o topo: quando um vídeo começa a ter muita procura, o sistema identifica sozinho e manda copiar aquele arquivo pros NVMe, distribuir no CDN, replicar no POP de Miami, no Brasil, e na Europa quando o tráfego de lá aperta. Isso é automático, com deploy contínuo e observabilidade em cima. É a mesma engrenagem que decide onde o seu play vai bater — e que explica, por exemplo, por que uma transmissão grande acumula segundos de atraso.
E o último tier surpreende quem não é da área: os grandes data centers ainda escrevem em fita. A gente está em 2026 e o cara pega a fita, grava e guarda. É por isso que restaurar backup de arquivo morto leva dois, três dias: alguém tem que pegar a fita de volta e fazer o retrieve. E é porque é barato: 100 TB de fita é baratíssimo, e não precisa ficar nada ligado consumindo energia. Fica aqui a dica que eu daria pra você que está lendo: se você tem acervo que não pode sumir, alugue ou pegue emprestado um gravador de fita, grave em duas cópias e guarde. Não vai sair dali. Você não paga assinatura pra ninguém.
Disco comum em data center: eu já quebrei a cara com isso
Uma pausa pra uma lição que eu paguei pra aprender, porque ela vale pra qualquer um que esteja montando storage agora. Quando eu falo "SSD padrão", eu falo de disco comum, o de loja. Em data center a gente usa enterprise, e tem motivo.
O disco comum não é feito pra rodar em alta rotação 24 horas por dia. O enterprise é: aguenta temperatura, aguenta carga contínua. Eu, sendo teimoso e querendo economizar, peguei HD e SSD comuns e botei no data center pra testar. A durabilidade foi de pouquíssimos meses. No fim eu gastei mais colocando disco comum do que gastaria comprando enterprise de uma vez. Então: eu sou baixo custo, eu tinha que testar — e o resultado do teste é esse. Não economize aí.
O primeiro erro: reaproveitar disco de tamanho diferente
Comprei dois servidores HP, cada um com espaço pra 12 discos. E a primeira coisa que eu fiz foi a coisa errada: eu tinha uns HDs parados aqui, um de 8 TB, outro de 10, outro de 18, e pensei em reaproveitar.
Não dá. Na hora de montar a pool, o ZFS nivela tudo por baixo. Se você tem os discos todos de 18 TB e de repente enfia um de 6, ele vai contabilizar todos como 6. Ou você cria outra pool separada só pros pequenos — o que é mais complexidade pra administrar — ou você compra tudo igual. Eu fiquei contrariado, mas engoli: comprei 12 discos iguais de um lado e 12 iguais do outro. Por quê dois conjuntos? Porque você precisa de redundância, e de um terceiro pra backup. Isso é o mínimo. Já já eu explico por que é mínimo mesmo.
Aproveitando pra te dar um número que eu conferi depois de gravar: a documentação do OpenZFS (zpoolconcepts), que eu li em 29/09/2026, recomenda "entre 3 e 9" dispositivos por grupo RAIDZ pra ajudar na performance. Eu montei com 12 num grupo só. Funciona, mas se eu fosse montar hoje eu quebraria em dois grupos menores dentro do mesmo servidor.
ZFS é fantástico — e é por isso que eu testei mesmo assim
Deixa eu ser justo com a tecnologia antes de reclamar dela. Você já ouviu falar de ext3, ext4? Pois é, o ZFS é outro patamar. Coisa fantástica de verdade.
Um exemplo do que ele faz e que eu acho genial: você tem um espelho no boot. Queimou um dos discos. Você pode arrancar o disco na lata e a máquina dá boot normal, sem problema nenhum. Depois você espeta o disco novo e ele sozinho vai reconstruindo o conteúdo pro novo. Ele usa bastante memória e entrega uma performance inicial muito boa. Não é bom em todos os cenários — nenhum sistema de arquivos é — mas eu sou fã. O problema que eu vou descrever agora não é do ZFS: é da conta que a minha operação faz em cima dele.
A conta que me tirou de lá: a perda vem em três camadas
Vamos fazer a conta com calma, porque é aqui que o negócio desanda pro meu caso. Você compra 12 discos de 12 TB, acha que tem 144 TB e não tem. A perda acontece em três estágios seguidos:
Estágio 1 — o TB do rótulo. Aqui eu preciso te corrigir uma coisa que eu falei de cabeça na gravação. Eu disse que você perde "18%, 20%" entre o disco de 12 TB e o que aparece no sistema. Refazendo a conta com calma, não é isso: o fabricante conta terabyte decimal e o sistema mostra em binário, então 12 TB viram uns 10,9 — a diferença é de uns 9%, não 18%. Eu prefiro te dar o número certo e ficar com cara de quem errou no vídeo do que deixar você planejar compra em cima de um número torto. O ponto continua de pé: o disco que você compra não é o disco que você usa.
Estágio 2 — a paridade. Com 12 discos, você tem que deixar 2 ou 3 pra paridade do grupo: é o RAIDZ2 ou o RAIDZ3. A documentação do OpenZFS, conferida por mim em 29/09/2026, é direta: "um grupo raidz pode ter paridade simples, dupla ou tripla, o que significa que o grupo pode suportar uma, duas ou três falhas, respectivamente, sem perder nenhum dado". Traduzindo pro bolso: no Z3 você compra 12 discos e guarda arquivo em 9. Esses 3 não somem — eles são exatamente o que impede a sua pool de virar pó quando um disco queimar às duas da manhã.
Estágio 3 — o overhead do próprio ZFS, que no meu conjunto ficou em torno de 3,8%. Não vou entrar em mais detalhe técnico aqui senão isto vira uma aula chata e você não leva nada pra casa — se você quer dominar esse assunto, vai ter que estudar de verdade.
Somando os três estágios, a área útil do meu conjunto ficou em torno de 70 TB. Esse é o número que eu carrego de cabeça e eu não vou fingir precisão que eu não tenho sobre a configuração final. A ordem de grandeza é essa, e é ela que decide a compra.
Três cópias: por que 360 TB pra usar 70 não fecha
Aí vem a parte que mata o caso de uso. Eu não posso perder vídeo de cliente. Não é uma preferência, é o negócio. Isso me obriga a ter três cópias: a que está em produção, a redundância e o backup.
Faça a multiplicação comigo: se cada conjunto me dá ~70 TB úteis e eu preciso de três, eu vou ter uns 360 TB comprados, energizados e ocupando rack, pra usar 70 na prática. Disco enterprise, note bem, não disco de loja. Pro meu negócio, isso não fecha. E não adianta me dizer "então usa uma pool só, sem paridade" — você perde a essência do negócio, que é não perder o arquivo. Foi uma ideia que passou pela nossa cabeça e a gente descartou.
Repare que a minha conclusão é sobre o meu caso, não sobre a ferramenta. É a mesma disciplina de olhar o custo real de cada peça que me fez passar a faca num cluster de Elasticsearch de 6 TB quando a conta parou de justificar o que ele entregava. Infraestrutura é isso: conta, não gosto pessoal.
O resilver: por que você nunca pode perder uma pool de 100 TB
Tem outro custo escondido que não aparece em planilha nenhuma e que eu quero que você entenda, porque é ele que separa quem já operou de quem só leu. Se você monta uma pool de 100 TB sem paridade nenhuma e perde ela de uma vez, quanto tempo você acha que leva pra ressincronizar 100 TB?
Pausa a leitura, abre a sua IA preferida e pergunta: quanto tempo leva pra sincronizar 100 TB em rede local, com disco mecânico? Olha o número que ela te devolver. Você vai entender por que não dá pra contar com isso. Não é tarde, não é noite: é semana, e dependendo do volume vira mês.
Por isso você precisa de disco de paridade suficiente pro conjunto conseguir se reconstruir sozinho. Queimou um disco? O ZFS tira ele do grupo e começa o resilver: reconstrói o conteúdo daquele disco no disco novo e rebalanceia. Genial — só que enquanto isso a performance vai lá embaixo, porque ele está lendo de todos os outros discos e escrevendo pesado no que entrou. Um disco mecânico de 10 TB não se reconstrói rápido de jeito nenhum.
Aí você me pergunta: e como eu continuo recebendo arquivo nessa pool enquanto ela se recupera? Você não continua. Você joga o tráfego pro par e para de escrever ali. E agora imagine a cena completa: disco queimado, resilver rodando, performance no chão, e você dependendo de uma cópia só pra servir leitura. Se essa também der pau no meio do caminho, acabou. É essa a hora em que a sua terceira cópia deixa de ser paranoia e vira a única coisa entre você e uma ligação muito difícil pro cliente.
A maldade que ninguém te conta: não compre tudo do mesmo lote
Essa aqui é a dica que eu mais gosto de dar, porque ela custa zero e salva o seu fim de semana. Quando você for montar o seu conjunto: não compre todos os discos na mesma data, da mesma marca, do mesmo modelo e do mesmo lote.
Por quê? Porque disco tem vida útil. Se você espeta doze discos da mesma fábrica, do mesmo lote, ligados no mesmo dia, sob a mesma carga e na mesma temperatura, eles tendem a chegar no fim da vida por volta da mesma hora. Queimou dois ou três juntos, você está no pau da goiaba. E isso nunca acontece numa quarta-feira de manhã com você na mesa: acontece no sábado, ou nas suas férias, com as calças na mão.
Isso a gente aprendeu sofrendo na pele, ao longo dos anos — é experiência de quem opera, não teoria. E fui conferir se o dado público apoia a intuição: a Backblaze, que publica estatística de falha da frota dela — 345.662 discos no fim do 1º trimestre de 2026, com taxa anualizada de falha de 1,24% no trimestre e 1,39% no acumulado de vida, segundo o relatório publicado em 09/07/2026, que eu li em 29/09/2026 — escreve na própria análise que "discos individuais dentro do conjunto de um fabricante, e mesmo dentro de um único modelo, podem variar bastante". Ou seja: a média é baixa, mas a variação entre unidades é real, e você não quer que a sua amostra inteira venha da mesma caixa.
A trinca que eu recomendo pra quem for montar: RAIDZ2 no mínimo, um disco de spare (reserva parado, esperando) e lotes diferentes. O spare é o que salva quando o disco queima no sábado: a pool faz o resilver sozinha, no disco de reserva, sem esperar você acordar. Isso está previsto na ferramenta — a documentação do OpenZFS descreve que "o ZFS permite que dispositivos sejam associados a pools como 'hot spares'. Esses dispositivos não são ativamente usados na pool". Eles ficam ali, quietos, custando o preço de um disco parado. É o dinheiro mais bem gasto do seu rack.
A replicação não é ativo-ativo: é snapshot, e essa janela me derrubou
Aqui está o segundo motivo técnico que fechou a porta pro meu caso. Quando você joga um arquivo no TrueNAS primário, ele não espelha na hora pro secundário. Ele faz snapshot — uma foto do estado — e move a diferença pro outro lado. Você configura o intervalo: de um em um minuto, por exemplo. Não é imediato. Não é como um S3, que aceita e já resolve a distribuição por baixo.
Isso está na natureza da ferramenta e não é defeito de implementação. A documentação do zfs send do OpenZFS, que eu li em 29/09/2026, descreve exatamente isso: o comando "cria uma representação em fluxo do snapshot", e no modo incremental "gera um fluxo incremental do primeiro snapshot (a origem incremental) para o segundo snapshot (o destino incremental)". Snapshot a snapshot. Por definição, sempre existe uma janela.
Pra backup essa janela é irrelevante. Pra mim, em que o cliente manda o vídeo e aquele vídeo precisa estar replicado e servível já, ela é justamente o que não cabe. Não dá pro meu cliente mandar vídeo pra um TrueNAS e esse vídeo sincronizar no outro e no backup no tempo que a minha operação exige. Simples assim.
SSH, Netcat e a placa de 10 Gb — mas o gargalo é a escrita do outro lado
E tem a parte do transporte, que é onde muita gente calcula errado. Pra mandar o snapshot pro outro servidor você tem basicamente dois caminhos:
- SSH: criptografado, seguro, e gasta CPU pra caramba.
- Netcat: extremamente inseguro, sem tratamento nenhum — e por isso extremamente rápido. Em rede local dedicada entre o par, é maravilhoso.
Antes disso, a rede: pra um conjunto desse tamanho, com 12 discos de 10 TB, você precisa de placa de 10 Gb. Com 1 Gb você nem começa a brincadeira, porque fica preso em ~100 MB/s e a sincronização nunca termina.
Resolvido o link, vem a pegadinha. O Netcat usa o topo do que a rede permite — e aí você olha o gráfico e acha que está voando. Não está. Olha os números reais de um HD mecânico comum:
| Onde você mede | O que você vê | Por que engana |
|---|---|---|
| Placa de rede | 10 Gb disponíveis | Não é a rede que limita — é o disco |
| Leitura na origem | ~150 a 180 MB/s | Dura só o começo da cópia |
| Escrita no destino | ~50 a 70 MB/s | É aqui que tudo estabiliza |
| Performance geral | Cai junto | Estourar a escrita derruba o conjunto inteiro |
Você lê a 150, mas rapidinho estabiliza em 50 — porque na outra ponta a escrita só aceita 50. E quando você estoura a escrita de um disco, a performance do conjunto inteiro vai junto. Agora empilha tudo: disco queimado, resilver rodando, e você ainda tentando empurrar cópia pro par. Não dá. Você tem que jogar o tráfego pra outro lugar, e "outro lugar" é mais um par de servidores que alguém tem que comprar.
Pra quem o TrueNAS faz sentido — e como eu montaria
Depois de tudo isso, a pergunta certa não é "TrueNAS é bom?". É "TrueNAS serve pra quê?". E a resposta é: serve, e serve bem, pra um monte de gente que não é eu.
- Backup: tranquilo. É provavelmente o melhor uso dele.
- Produtora, agência de vídeo, acervo local: quem tem volume absurdo de material produzido, gravação grande, acervo de foto e vídeo. Faz bastante sentido.
- Backup principal com pool pequena: uma dezena de terabytes, onde uma semaninha de sincronização inicial ainda cabe na vida real. Passou disso, você já precisa de um segundo conjunto.
- Servidor de casa / acervo pessoal: perfeito — e sem amarra de fabricante.
Se for o seu caso, monte assim: RAIDZ2 no mínimo, disco de spare configurado, discos comprados em marcas ou lotes diferentes, e discos enterprise se aquilo for ficar ligado o tempo todo. O que não dá é colocar isso em tempo real pra cliente, porque aí você precisa duplicar e triplicar tudo o que eu descrevi aqui — e é exatamente aí que a conta estoura.
E teste o fallback, não só o backup
Tem uma última coisa, e ela é a que mais derruba gente boa. Você monta, tudo funcionando, lindo. Aí a placa-mãe queima. E agora?
Você recupera as suas pools? Você recupera o seu operacional? O boot sobe com a mesma montagem, o fstab certo? O buraco é mais embaixo, e você só descobre isso no dia. Por isso: teste o fallback antes. Monta a pool, desliga tudo, desconecta tudo, troca a placa-mãe, move os discos pra outro servidor, desmonta a pool e monta de novo sem perder dado. Sim, você vai precisar de equipamento pra testar. É o preço de saber o que você está fazendo.
Não ter esse plano é o tipo de coisa que derruba empresa — e o exemplo recente que eu mais uso é o caso do Abacate Pay e a lição de testar restore de backup. Eles foram muito honestos e muito transparentes sobre o que aconteceu, e isso merece crédito. Mas o estrago veio de falta de provisionamento de infraestrutura, e é exatamente esse o assunto aqui. Backup que ninguém restaurou não é backup: é esperança.
Nota de cronologia (importante)
Eu gravei em 28/06/2026 e estou escrevendo isto em 29/09/2026. O teste com TrueNAS é anterior à gravação, então os modelos de disco, os preços e até algumas capacidades do produto podem ter mudado desde então — inclusive a versão community, que evolui. Eu corrigi aqui um número que eu falei de cabeça no vídeo (a diferença entre o TB de marketing e o TB do sistema é de uns 9%, não os 18% a 20% que eu citei). Os números de desempenho de disco (~150 MB/s de leitura, ~50 MB/s de escrita) são ordens de grandeza de HD mecânico comum na minha experiência, não medição de bancada com modelo e firmware declarados. E a área útil de ~70 TB é o número do meu conjunto, com a configuração que eu rodei — o seu vai depender do RAIDZ que você escolher e de quantos discos você puser no grupo. Se você for decidir compra em cima disto, faça a conta com os discos que você vai comprar de fato.
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
Por que 240 TB de disco comprado viram só 70 TB de área útil?
Eu posso misturar discos de tamanhos diferentes no mesmo grupo?
Por que eu não posso simplesmente montar uma pool grande sem paridade?
Por que a performance despenca quando um disco queima?
Por que não comprar todos os discos da mesma marca, modelo e lote?
A replicação do TrueNAS é em tempo real?
Qual é o gargalo real quando eu sincronizo dois servidores?
Então o TrueNAS é ruim? Para quem ele funciona?
Esse é o nível de conversa que quase ninguém tem no país: disco, paridade, resilver, lote de fabricação, gargalo de escrita, teste de fallback. E eu tenho absoluta certeza de que, na era da inteligência artificial, infraestrutura é o segmento onde vale a pena investir o seu tempo — seja você dono de empresa que gasta muito com nuvem e quer entender o risco e o custo disso, seja você técnico, ou dev querendo virar consultor de infraestrutura. É justamente isso que eu vou ensinar na Imersão de Infraestrutura: storage como base de tudo, uso de memória, kernel, alta disponibilidade, compra de servidor, data center, bloco de IP próprio e homologação, pipeline, IA com pipeline, observabilidade, Docker e virtualização — até onde vale alugar servidor ou VPS e a partir de onde vale comprar o seu e colocar num data center. Conteúdo, formato, data, valor e condição ficam na página de cada imersão, que é onde essa informação está certa. Espero que isto faça sentido pra você. Um abraço, e sabe onde eu quero te ver.
Baseado na gravação do canal @josimarjmv publicada em 28/06/2026 (24min13), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
São da minha vivência e foram ditos na gravação: ser CEO de empresa de tecnologia e engenheiro de infraestrutura que cuida de infra no Brasil e nos Estados Unidos e monta servidor com a própria mão; ter empresa de vídeo que exige alta disponibilidade, backup, performance e redundância em tempo real; ter testado antes armazenamento distribuído com S3 e desativado aquele cluster; ser open source first e bootstrap, trabalhando com dinheiro próprio; não comprar hardware com software proprietário por causa do vínculo com a tecnologia do fabricante e da perda de controle; o TrueNAS ter versão community instalável em qualquer hardware, o que permitia reaproveitar o servidor se o teste falhasse; ter comprado dois servidores HP de 12 discos cada; os tiers de storage NVMe enterprise, SSD enterprise, HD mecânico enterprise e fita, com restore de fita em dois a três dias e a dica de gravar em duas fitas e guardar; ter testado disco comum em data center e durar pouquíssimos meses, saindo mais caro que enterprise; a tentativa de reaproveitar discos de 8, 10 e 18 TB e a descoberta de que o grupo nivela pelo menor disco; a paridade RAIDZ2 ou RAIDZ3 consumindo dois ou três discos; o overhead de cerca de 3,8% do sistema de arquivos; a área útil de cerca de 70 TB no conjunto montado; a necessidade de três cópias por não poder perder vídeo de cliente, chegando a cerca de 360 TB comprados para 70 úteis; a impossibilidade de perder uma pool de 100 TB pelo tempo de ressincronização; a queda de performance durante o resilver e a necessidade de desviar o tráfego; a recomendação de não comprar discos da mesma marca, modelo, data e lote, e de usar disco de spare; a replicação por snapshot, não ativo-ativo; o transporte por SSH com consumo de CPU ou por Netcat em rede local; a exigência de placa de 10 Gb; as faixas de ~150 a 180 MB/s de leitura e ~50 a 70 MB/s de escrita em HD mecânico como gargalo da cópia; o recorte de para quem o TrueNAS faz sentido; a necessidade de testar o fallback trocando placa-mãe e remontando a pool; a menção ao caso do Abacate Pay como exemplo de falta de provisionamento, com reconhecimento da transparência deles; e os temas da imersão presencial de infraestrutura. É apuração minha, feita em 29/09/2026, e não estava na gravação: a correção da diferença entre o TB decimal do rótulo e o TB binário do sistema, que é de cerca de 9% e não os 18% a 20% que eu citei de cabeça; a frase da documentação do OpenZFS sobre RAIDZ de que um grupo raidz com paridade simples, dupla ou tripla suporta uma, duas ou três falhas sem perda de dados; a recomendação de "entre 3 e 9" dispositivos por grupo e a descrição de hot spares como dispositivos associados à pool mas não usados ativamente, ambas do manual zpoolconcepts do OpenZFS; a descrição do zfs send no manual do OpenZFS como criação de um fluxo a partir de um snapshot, com modo incremental entre dois snapshots; e os números do relatório Drive Stats da Backblaze para o 1º trimestre de 2026, publicado em 09/07/2026 — 345.662 discos monitorados, taxa anualizada de falha de 1,24% no trimestre e 1,39% no acumulado de vida, e a observação de que discos de um mesmo fabricante, e mesmo de um mesmo modelo, podem variar bastante entre si. Sobre as minhas imersões eu não repito preço, data nem condição: essa informação é final e fica na página de cada imersão.