- O ReFS boot traz maior resiliência, escalabilidade até 35 PB e melhor desempenho ao volume de sistema em comparação com NTFS.
- O suporte de arranque ReFS exige firmware UEFI com Secure Boot configurado e não funciona em ambientes de BIOS legado ou VMs de Geração 1.
- A atualização para certificados Microsoft Secure Boot CA 2023 é fundamental para manter a cadeia de confiança e a compatibilidade futura do arranque.
- Fabricantes como Lenovo e ASUS já fornecem firmware e procedimentos para atualizar UEFI e chaves de Secure Boot, facilitando adoção em ambientes empresariais.
O suporte de arranque com ReFS está a transformar a forma como os administradores planeiam e protegem o disco do sistema nos servidores Windows. Depois de anos em que o NTFS dominou o volume de arranque, a Microsoft começou finalmente a permitir que o próprio sistema operativo seja iniciado diretamente a partir de um volume formatado em ReFS, começando pelas compilações Insider do Windows Server vNext. Esta mudança abre a porta a um arranque mais resiliente, mais escalável e com melhor desempenho em cenários modernos de virtualização e armazenamento intensivo.
Ao longo deste artigo vamos detalhar o que é o ReFS, por que motivo o suporte de arranque com este sistema de ficheiros é tão relevante, como o testar nas versões Insider e que relação tudo isto tem com UEFI, Secure Boot, certificados da Microsoft e firmware atualizado. Também vamos tocar em implicações práticas para fabricantes como Lenovo e ASUS, já que a transição para novos certificados de Secure Boot (CA 2023) está diretamente ligada à segurança do processo de arranque e à compatibilidade com o ReFS em ambientes empresariais.
O que é o ReFS e por que interessa para o arranque do Windows
O ReFS (Resilient File System) é o sistema de ficheiros de próxima geração da Microsoft, desenhado desde a base para maximizar integridade de dados, escalabilidade e resiliência em cargas de trabalho modernas. Apareceu pela primeira vez em 2012, como alternativa ao NTFS, e desde então tem recebido melhorias em várias versões do Windows: Windows Server 2012, 2016, 2019, 2022 e iterações sucessivas do Windows 10 e Windows 11.
Enquanto o NTFS continua a ser extremamente difundido, a arquitetura do ReFS foi pensada para enfrentar problemas típicos de ambientes de grande escala, como corrupção silenciosa de dados, volumes gigantescos e operações intensas de I/O. A filosofia do ReFS é “integridade em primeiro lugar”, apoiando-se em técnicas como copy-on-write (cópia em escrita) e checksums para metadados, o que reduz a probabilidade de corrupção após falhas de energia ou desligamentos abruptos.
Até recentemente, o ReFS era utilizado sobretudo em volumes de dados: clusters de armazenamento, volumes para máquinas virtuais, backups e arquivos de longa duração. O grande salto agora é permitir que o próprio volume de sistema – a famosa unidade C: que contém o Windows – seja formatado em ReFS e usado como disco de arranque, algo que muitos administradores aguardavam há quase 14 anos.
Esta evolução é particularmente relevante para empresas que dependem de workloads críticos, grandes repositórios de VHD/VHDX e ambientes de virtualização com volumes enormes. Ao trazer o ReFS diretamente para o disco de arranque, é possível alinhar a estratégia de resiliência do sistema operativo com a estratégia de resiliência do armazenamento de dados, sem misturar tecnologias com características diferentes.
Principais vantagens do arranque com ReFS em vez de NTFS
Uma das maiores vantagens do arranque com ReFS é a resiliência acrescida do próprio disco do sistema operativo. O ReFS foi concebido para detetar corrupção de dados o mais cedo possível, graças à verificação de integridade baseada em metadados, e consegue resolver muitos problemas de sistema de ficheiros enquanto o volume continua online, evitando ter de recorrer ao tradicional chkdsk que, em alguns casos, implica downtime prolongado.
O design copy-on-write do ReFS reduz de forma significativa a hipótese de corrupção causada por falhas inesperadas, como um crash do servidor ou uma queda de energia. Em vez de sobrescrever dados em bloco, o ReFS escreve novas versões em locais separados e apenas depois atualiza os apontadores, o que torna o sistema mais tolerante a interrupções no meio da escrita.
Outro benefício brutal é a escalabilidade: o ReFS suporta volumes até 35 petabytes (35.000 TB), um valor extremamente superior aos limites práticos habituais do NTFS, que rondam os 256 TB. Para empresas que planeiam crescer de forma agressiva, ou que já lidam com enormes bibliotecas de máquinas virtuais e repositórios de backup, isto significa não bater em tetos de capacidade tão cedo.
No campo do desempenho, o ReFS também traz truques importantes, com destaque para o block cloning e o aprovisionamento disperso (sparse provisioning). O block cloning permite duplicar grandes ficheiros, como VHD/VHDX de tamanho fixo, sem copiar fisicamente todos os dados, apenas ajustando referências de metadados. O resultado prático é que operações de criação, expansão e clonagem de grandes ficheiros são muito mais rápidas, consumindo menos I/O real.
Para administradores que trabalham com Hyper-V, PowerProtect Data Manager e outras soluções de backup e virtualização, estas otimizações do ReFS podem poupar horas em tarefas de manutenção e janelas de backup. Copiar enormes volumes de informação, criar discos virtuais para novos servidores ou ajustar tamanhos de VHDX passa a ser uma operação bem mais eficiente, o que, na prática, encurta janelas de manutenção e reduz pressão no armazenamento.
Por que workloads modernos precisam de ReFS no volume de sistema
As cargas de trabalho atuais – máquinas virtuais densas, containers, bases de dados volumosas e analytics – exigem muito mais do volume de arranque do que antigamente. Já não estamos a falar apenas de carregar o kernel do sistema e meia dúzia de drivers; hoje, o disco do sistema armazena ficheiros de página, caches intensivos, instantâneos e uma série de componentes críticos para I/O.
Neste contexto, o NTFS começa a mostrar limitações, tanto em termos de escalabilidade como de mecanismos nativos de proteção de integridade. Embora seja robusto, o NTFS não foi criado com o mesmo foco em integridade automática e reparo online que o ReFS oferece, sobretudo quando o volume atinge centenas de terabytes.
Ao permitir o arranque directamente de um volume ReFS, a Microsoft garante que os mesmos mecanismos avançados de resiliência usados para grandes repositórios de dados também protegem os ficheiros mais sensíveis do sistema operativo. Isto inclui os binários do Windows, drivers de baixo nível e componentes críticos de inicialização que, se corrompidos, podem deixar um servidor totalmente inoperante.
Na prática, a adoção do ReFS no arranque traduz-se em menos downtime inesperado, menor necessidade de ferramentas de reparação offline e maior previsibilidade em ambientes de produção. Para organizações que trabalham com contratos de SLA rigorosos, cada minuto de indisponibilidade conta, e um sistema de ficheiros mais resiliente no disco do sistema é um aliado direto na redução de riscos.
Como testar o arranque ReFS no Windows Server Insider
Atualmente, o suporte de arranque com ReFS está disponível para utilizadores inscritos no programa Windows Server Insider, nas compilações vNext mais recentes. Se quer experimentar esta funcionalidade antes de ela chegar às versões finais do produto, é necessário garantir que o servidor corre uma build suficientemente recente.
De acordo com a Microsoft, o suporte de arranque ReFS foi incluído em compilações lançadas a partir de 11 de fevereiro de 2026, com número mínimo de build 29531.1000.260206-1841. Se estiver numa compilação anterior, o instalador ainda não vai permitir formatar a unidade de sistema em ReFS durante a instalação.
O processo básico para testar o arranque ReFS no Windows Server Insider segue alguns passos principais, fáceis de acompanhar para quem já instala servidores com frequência. Em primeiro lugar, é preciso aderir ao programa Windows Server Insiders, descarregar a ISO correspondente à build mais recente e preparar o meio de instalação (USB ou ISO para máquina virtual).
Durante a instalação do Windows Server vNext Insider, na etapa de seleção e formatação de discos, deve escolher o volume do sistema (habitualmente C:) e formatá‑lo explicitamente como ReFS. A interface de setup passa a mostrar a opção ReFS como sistema de ficheiros suportado para o volume de sistema, o que antes não acontecia.
Depois de concluir a instalação, o servidor arranca naturalmente e, já no sistema, é fundamental confirmar que a unidade C: está realmente em ReFS. Isso pode ser feito quer pelas propriedades do disco no Explorador, quer via linha de comandos, por exemplo, executando o comando fsutil fsinfo volumeInfo C: para listar detalhes do sistema de ficheiros do volume.
Requisitos de firmware: UEFI e limitações de BIOS legado
Um ponto crítico para o arranque com ReFS é que ele depende de firmware UEFI e não é suportado em modos de arranque com BIOS legado. Isto significa que servidores e máquinas virtuais configuradas como “Generation 1” – que emulam BIOS antigo – não podem arrancar diretamente de um volume ReFS.
Na prática, se estiver a planear testar ReFS boot em ambiente virtual, é necessário criar VMs do tipo Generation 2, que usam UEFI e suportam funcionalidades modernas como Secure Boot. Para hardware físico, é indispensável verificar nas opções de firmware se o modo de arranque está definido para UEFI e não para Legacy ou CSM (Compatibility Support Module).
A própria Microsoft destaca que o ReFS boot não oferece suporte para arranque em VMs de Geração 1. Isto não impede que use ReFS em volumes de dados nessas VMs, mas o volume de sistema continua a ter de ser NTFS se o firmware exposto for do tipo BIOS clássico.
Para evitar dores de cabeça, é recomendável validar a compatibilidade de UEFI, ativar o modo de arranque adequado e, se for o caso, reprovisionar as máquinas virtuais como Generation 2 antes de começar os testes de arranque com ReFS. Uma vez garantidas as condições de firmware, o processo de instalação baseado em ReFS costuma ser tão simples quanto uma instalação NTFS tradicional.
Resiliência adicional com ReFS boot e cenários empresariais
Quando falamos de resiliência, o ReFS boot não é apenas um detalhe técnico, mas sim um componente chave na estratégia de continuidade de negócio. A combinação de deteção precoce de corrupção, reparação online e design focado na integridade aumenta bastante a robustez do volume de sistema.
Em ambientes empresariais, onde servidores Windows suportam aplicações críticas, bases de dados, serviços de diretório e infraestruturas de backup como o PowerProtect Data Manager, qualquer corrupção no volume C: pode ter impacto em cadeia. O ReFS minimiza esse risco, tornando menos provável que um problema de I/O ou um crash súbito leve ao colapso total do sistema de ficheiros.
Outro ponto importante é que, com volumes que podem ir até 35 PB, é possível consolidar de forma mais agressiva dados de VMs, ficheiros de configuração e outros componentes essenciais num mesmo volume, sem medo de bater no limite logo à partida. Isto simplifica alguns projetos de desenho de armazenamento para grandes datacenters.
Ao acelerar operações como clonar VHD/VHDX e copiar grandes ficheiros, o ReFS também encurta as janelas de backup, restauro e provisão de novos servidores. Menos tempo a executar operações intensivas significa menos impacto no desempenho percebido pelos utilizadores finais e mais previsibilidade em janelas de manutenção.
Para equipas de TI com responsabilidades sobre SLAs rigorosos, o ReFS no volume de arranque torna-se um aliado direto para reduzir incidentes, bem como para acelerar a recuperação quando algo corre mal. A combinação de resiliência, escalabilidade e performance acaba por ser difícil de ignorar em projetos novos de infraestrutura.
Secure Boot, UEFI e a cadeia de confiança no arranque
O suporte de arranque com ReFS caminha lado a lado com outro pilar fundamental da plataforma moderna: o Secure Boot baseado em UEFI. Enquanto o ReFS protege a integridade do sistema de ficheiros, o Secure Boot garante que só código confiável é carregado nas primeiras fases do arranque.
O Secure Boot é uma funcionalidade de segurança que impede que firmware, drivers e sistemas operativos não autorizados sejam carregados durante o processo de boot. Está previsto na especificação UEFI e foi adotado pela Microsoft a partir do Windows 8 e Windows Server 2012, tornando-se desde então um requisito de segurança central no ecossistema Windows.
Quando a máquina é ligada, o firmware UEFI verifica as assinaturas digitais do software de pré‑arranque – incluindo o Windows Boot Manager – contra uma base de dados de autoridades certificadoras guardada no próprio firmware. Se a assinatura for válida, o firmware entrega o controlo ao gestor de arranque, que por sua vez valida componentes seguintes, carrega o sistema para memória e inicia o Windows.
Ao bloquear bootkits, rootkits e outro malware de baixo nível antes que o sistema operativo seja carregado, o Secure Boot funciona literalmente como a primeira linha de defesa. Isto é especialmente relevante em servidores que lidam com dados sensíveis ou que operam em ambientes altamente regulados, onde a integridade da cadeia de arranque precisa de ser comprovável.
Para que o Secure Boot funcione, existe uma hierarquia de chaves e bases de dados mantida no firmware UEFI, composta pela Platform Key (PK), Key Exchange Key (KEK), Allowed Signature database (DB) e Forbidden Signature database (DBX). A PK define o “dono” da plataforma (normalmente o fabricante do hardware), a KEK autoriza atualizações às bases de dados de confiança, a DB lista assinaturas permitidas e a DBX regista assinaturas revogadas ou maliciosas.
Atualização dos certificados de Secure Boot: CA 2011 para CA 2023
Desde a introdução do Secure Boot no Windows, a maioria dos dispositivos utilizou o conjunto de certificados Microsoft CA 2011 no KEK e na base de dados de assinaturas (DB). Estes certificados, no entanto, têm prazo de validade, e a partir de 2026 começam a expirar, o que levanta várias questões operacionais e de segurança.
Quando os certificados CA 2011 expirarem, os sistemas podem até continuar a arrancar inicialmente, mas deixarão de receber atualizações de segurança relacionadas com Secure Boot. Além disso, atualizações futuras do Windows Boot Manager podem falhar a verificação de Secure Boot, e meios de recuperação, WinPE e instalação criados com base em certificados antigos podem deixar de arrancar em firmware atualizado.
Isto significa que, para manter a integridade da cadeia de confiança no arranque, é essencial transitar para os certificados de Secure Boot de 2023 da Microsoft (CA 2023). Sem essa atualização, os sistemas podem tornar-se não conformes com baselines de segurança empresariais e requisitos regulatórios que exigem firmware, bootloaders e sistemas sempre validados por certificados atualizados.
Fabricantes como a Lenovo já passaram a incluir firmware UEFI atualizado, com os novos certificados de Secure Boot de 2023, facilitando a transição sem necessidade de desligar o Secure Boot ou realizar registo manual de chaves. Isto reduz o risco operacional e permite que a proteção de Secure Boot permaneça ativa durante todo o processo de migração.
Ao mesmo tempo, estas mudanças contribuem para mitigar vulnerabilidades específicas, como a CVE-2023-24932 (vulnerabilidade BlackLotus), associada ao Windows Boot Manager e potencialmente explorável para contornar o Secure Boot. Com certificados atualizados e firmware corrigido, a superfície de ataque é reduzida e a cadeia de arranque torna‑se mais difícil de comprometer.
Passos gerais para manter o Secure Boot atualizado em servidores Windows
Para administradores que já têm o Secure Boot ativado nos seus servidores Windows, o passo mais importante é garantir que os certificados Microsoft de 2023 estão instalados antes de os certificados antigos expirarem. Caso contrário, podem surgir falhas de compatibilidade com novas versões do Windows Boot Manager e com meios de instalação recentes.
A atualização pode ocorrer de diferentes formas, mas na maioria dos cenários basta aplicar atualizações de firmware/BIOS fornecidas pelo fabricante do hardware e instalar as últimas atualizações do Windows que incluem um Boot Manager compatível com CA 2023. Muitos fabricantes automatizam grande parte deste processo para reduzir o risco de erro humano.
Em ambientes Lenovo, por exemplo, existe orientação específica para atualizar o Windows Boot Manager, os certificados de arranque e para criar imagens WinPE bootáveis que já respeitam a nova cadeia de confiança. O objetivo é garantir que todos os servidores continuam a arrancar normalmente e recebem atualizações regulares de Secure Boot, sem necessidade de desativar proteções.
Se o seu sistema tiver Secure Boot ativo, é recomendado verificar a documentação do fabricante para confirmar que a firmware UEFI foi atualizada com os certificados de 2023. Em alguns casos, pode ser necessário validar manualmente que as entradas na KEK e na DB incluem elementos como “Microsoft Corporation KEK 2K CA 2023”, “Windows UEFI CA 2023” e “Microsoft UEFI CA 2023”.
O ponto-chave é que, mantendo a cadeia de certificados em dia, garante-se que o arranque em ReFS, o Boot Manager e o próprio Secure Boot trabalham em conjunto, oferecendo tanto integridade de dados como proteção contra código não autorizado desde o primeiro segundo de execução.
Exemplo prático: atualização manual de UEFI e chaves de Secure Boot (ASUS)
Alguns cenários exigem uma abordagem mais manual, sobretudo quando o equipamento não recebe atualizações automáticas via Windows Update ou quando estamos a falar de placas-mãe dedicadas, notebooks específicos ou dispositivos AIoT. A ASUS, por exemplo, descreve procedimentos detalhados para atualizar a BIOS/UEFI e gerir as chaves de Secure Boot manualmente.
Para placas-mãe (desktops e servidores DIY), o processo típico envolve descarregar a versão mais recente da UEFI BIOS a partir do site oficial da ASUS e aplicá-la seguindo as instruções do fabricante. Após a atualização, é normalmente recomendado aceder novamente ao setup da BIOS, ir a Advanced\Boot > Secure Boot, mudar o modo de Standard para Custom e aceder a Key Management.
Nesse menu, é possível utilizar opções como “Clear Secure Boot Keys” para limpar todas as chaves PK, KEK, DB e DBX atuais e, em seguida, “Install Default Secure Boot Keys” para reinstalar as chaves padrão do fabricante que já incluem os certificados Microsoft CA 2023. O importante é verificar que o número de chaves não é zero e que a origem (Key Source) está marcada como Default.
Há também orientação específica para validar o estado das chaves, selecionando itens como KEK Management ou DB Management e usando a opção de mostrar detalhes sem apagar as chaves. Nessa listagem devem aparecer entradas como “Microsoft Corporation KEK 2K CA 2023”, “Microsoft UEFI CA 2023” e “Windows UEFI CA 2023”.
Em notebooks ASUS, o fluxo é semelhante, mas com termos ligeiramente diferentes, como “Reset To Setup Mode” para limpar chaves e “Restore Factory Keys” para restaurar as chaves de fábrica com os novos certificados. Para dispositivos AIoT, por sua vez, o fabricante recomenda garantir que o Secure Boot Mode está em Standard e aceitar a instalação de chaves de fábrica na gestão avançada de chaves (Expert Key Management).
Um detalhe importante para quem usa BitLocker ou encriptação de dispositivo é que certas atualizações de BIOS podem pedir a chave de recuperação após o reboot. Por isso, muitos fabricantes, incluindo a ASUS, sugerem desativar temporariamente a encriptação antes de atualizar o firmware e reativá‑la depois, para evitar surpresas e garantir que o acesso ao sistema é restaurado sem complicações.
Impacto em ambientes Windows Server e clientes
O conjunto de mudanças envolvendo ReFS boot e Secure Boot com certificados atualizados afeta uma gama ampla de produtos Microsoft, desde servidores antigos até sistemas mais recentes. Entre os sistemas envolvidos em diferentes cenários de suporte e transição encontram-se Windows Server 2012, 2012 R2, 2016, 2019, 2022, além de várias versões do Windows 10 e Windows 11, incluindo edições Home, Pro, Enterprise, Education e IoT.
Para organizações com ambientes híbridos, onde convivem Windows Server antigos e novos, esta diversidade de versões significa que o planeamento da migração para ReFS boot e da atualização do Secure Boot precisa de ser cuidadoso. Alguns sistemas podem não suportar ReFS como volume de arranque, mas ainda assim precisam dos certificados CA 2023 para manter a cadeia de arranque segura e compatível com novos meios de instalação e recuperação.
Do ponto de vista prático, é comum que empresas com grandes parques de servidores adotem uma estratégia em ondas: primeiro garantem que todo o firmware e certificados Secure Boot estão em dia, depois iniciam projetos pilotos de ReFS boot em ambientes de teste e, só então, migram gradualmente workloads de produção. Este tipo de abordagem reduz o risco e permite identificar incompatibilidades específicas de hardware antes que afetem serviços críticos.
Ferramentas de proteção de dados e gestão de backups, como o PowerProtect Data Manager, também precisam de ser avaliadas nesse contexto, garantindo que suportam volumes ReFS, que as operações de snapshot e restauro funcionam corretamente e que o fluxo de arranque continua certificado pelo Secure Boot. Uma boa prática é manter documentação interna atualizada, registando que servidores usam ReFS no arranque e quais ainda estão em NTFS.
No fim, a convergência entre ReFS, UEFI, Secure Boot e certificados de 2023 cria uma base mais sólida para servidores Windows modernos, tanto em centros de dados locais como em ambientes híbridos ligados à cloud. Quem planear esta transição com antecedência tende a colher ganhos de resiliência, desempenho e segurança sem sobressaltos.
No contexto atual, em que as infraestruturas Windows caminham para volumes de dados cada vez maiores, requisitos de segurança mais apertados e operações de virtualização intensivas, combinar um volume de arranque em ReFS com firmware UEFI atualizado e Secure Boot configurado com certificados Microsoft CA 2023 oferece uma espécie de “combo” ideal: mais proteção contra corrupção, mais performance em I/O pesado e uma cadeia de confiança robusta desde o primeiro segundo do boot.