USN Journal no Windows 11: como o NTFS registra alterações

setembro 2, 2026 admin Sistema Operacional, Windows 11 0

USN Journal no Windows 11 mostrando o comando fsutil usn e o registro de alterações em arquivos do NTFS.
O USN Journal permite acompanhar alterações registradas pelo NTFS e pode ser consultado no Windows 11 com o comando fsutil usn.
75 / 100
Desenvolvido por Rank Math SEO
Pontuação de SEO

Você cria um arquivo.

Renomeia uma pasta.

Um programa modifica centenas de arquivos.

Uma atualização substitui componentes.

Milhares de arquivos são criados e excluídos durante uma instalação.

Como programas e componentes do Windows conseguem descobrir que alguma coisa mudou sem precisar analisar continuamente todos os arquivos existentes no SSD?

Parte dessa resposta está escondida dentro do sistema de arquivos NTFS.

O nome do mecanismo é:

USN Change Journal.

Também podemos encontrá-lo chamado simplesmente de:

USN Journal

ou:

Change Journal.

Ele funciona como um diário de alterações mantido pelo NTFS em cada volume no qual está disponível.

Quando arquivos, diretórios e outros objetos NTFS sofrem determinadas alterações, o sistema de arquivos pode acrescentar registros nesse diário.

Esses registros permitem que programas descubram mudanças de maneira muito mais eficiente do que percorrer milhões de arquivos comparando datas e outras informações repetidamente.

E existe um detalhe interessante:

o próprio Windows possui ferramentas capazes de consultar informações desse mecanismo.

Uma delas é:

fsutil usn

Por exemplo:

fsutil usn queryjournal C:

Esse comando permite consultar informações sobre o USN Change Journal do volume C:.

Mas antes de executar comandos, precisamos entender o que o USN realmente é, o que ele registra e, principalmente, o que ele não registra.

Primeiro: o que é NTFS?

Para entender o USN Journal, precisamos começar pelo sistema de arquivos.

Um SSD ou HD não organiza sozinho conceitos como:

C:\Usuarios
C:\Windows
C:\Program Files

O dispositivo de armazenamento fornece blocos nos quais informações podem ser armazenadas.

É o sistema de arquivos que cria a estrutura lógica utilizada pelo sistema operacional para organizar:

  • arquivos;
  • diretórios;
  • nomes;
  • atributos;
  • permissões;
  • metadados;
  • localização dos dados;
  • diversas outras informações.

No Windows, um dos principais sistemas de arquivos é:

NTFS — New Technology File System.

É comum encontrarmos a unidade do sistema:

C:

formatada em NTFS.

Podemos verificar isso facilmente.

Abra o PowerShell e execute:

Get-Volume

Entre as informações apresentadas existe:

FileSystem

Em uma instalação comum do Windows, poderemos encontrar algo semelhante a:

DriveLetter : C
FileSystem  : NTFS

Isso será importante porque o USN Change Journal está intimamente ligado ao funcionamento do sistema de arquivos.

O problema de descobrir o que mudou

Imagine um computador contendo:

1.000 arquivos

Descobrir mudanças nesse conjunto não parece particularmente difícil.

Agora imagine:

100.000 arquivos

Depois:

1.000.000 arquivos

Ou vários milhões.

Um programa interessado em descobrir alterações poderia, teoricamente, percorrer todos eles periodicamente e comparar informações.

Algo conceitualmente semelhante a:

Arquivo 1 mudou?
Arquivo 2 mudou?
Arquivo 3 mudou?
Arquivo 4 mudou?
...
Arquivo 2.000.000 mudou?

Depois de algum tempo:

Vamos verificar tudo novamente.

Esse método seria extremamente ineficiente.

É justamente aqui que um diário de alterações se torna interessante.

Em vez de perguntar repetidamente:

“Qual dos milhões de arquivos mudou?”

o programa pode utilizar informações mantidas pelo sistema de arquivos para descobrir alterações ocorridas desde determinado ponto.

A lógica muda para algo conceitualmente parecido com:

Estado conhecido
      ↓
USN
      ↓
novas alterações
      ↓
programa processa apenas
o que precisa investigar

Isso pode economizar uma enorme quantidade de trabalho.

O que significa USN?

USN significa:

Update Sequence Number.

Em português, podemos traduzir aproximadamente como:

Número de Sequência de Atualização.

Os registros do Change Journal são organizados utilizando números de sequência.

Novos registros aparecem posteriormente no fluxo e recebem valores que permitem determinar sua posição relativa.

Podemos imaginar uma representação simplificada:

USN 1000 → alteração A
USN 1100 → alteração B
USN 1200 → alteração C
USN 1300 → alteração D
USN 1400 → alteração E

Um programa pode guardar uma referência do ponto até onde processou.

Por exemplo:

Último USN processado:
1200

Depois, em vez de analisar novamente tudo desde o começo, ele procura os registros posteriores ao ponto conhecido.

Conceitualmente:

1200
 ↓
1300
1400
1500
1600

Essa lógica ajuda a compreender por que o mecanismo é tão eficiente.

O USN Journal existe para cada arquivo?

Não.

Essa distinção é importante.

O Change Journal pertence ao:

volume.

Por exemplo, podemos ter:

C:

com seu diário.

Outro volume:

D:

pode possuir outro diário.

Portanto, não existe simplesmente:

um USN Journal global
para todo o computador

A arquitetura é associada aos volumes.

Imagine:

SSD

C: NTFS
   ↓
USN Change Journal C:

D: NTFS
   ↓
USN Change Journal D:

Os dois volumes possuem contextos separados.

O que o USN Journal registra?

Quando objetos NTFS são:

  • adicionados;
  • excluídos;
  • modificados;

o NTFS pode criar registros no Change Journal.

Cada registro contém informações que permitem identificar o objeto e o tipo ou motivo da alteração.

Existem vários motivos possíveis.

Alguns exemplos conceituais incluem:

dados sobrescritos
dados acrescentados
dados truncados
arquivo criado
arquivo excluído
renomeação
alteração de informações básicas
alteração de segurança
fechamento

Esses motivos aparecem tecnicamente através de sinalizadores conhecidos como:

USN_REASON

Portanto, o diário não guarda simplesmente:

Arquivo mudou.

Ele consegue fornecer informações mais específicas sobre a natureza da mudança.

Um exemplo simples

Imagine:

C:\Documentos\relatorio.txt

O usuário abre o arquivo.

Depois altera seu conteúdo.

Salva.

Fecha.

O NTFS pode gerar informações relacionadas às alterações ocorridas durante esse processo.

Uma representação didática seria:

relatorio.txt
      ↓
conteúdo modificado
      ↓
registro USN
      ↓
motivo da alteração

Isso permite que um programa interessado saiba que aquele objeto sofreu uma mudança.

O USN Journal guarda o conteúdo antigo do arquivo?

Não.

Esse é provavelmente o ponto mais importante de todo o artigo.

Imagine que:

relatorio.txt

continha:

Versão A

Depois você substituiu o conteúdo por:

Versão B

O USN Change Journal pode registrar que ocorreu uma alteração.

Mas isso não significa que ele tenha armazenado:

Versão A

para que você possa recuperá-la posteriormente.

Portanto:

USN Journal
≠
backup

Também não devemos tratá-lo como:

USN Journal
≠
Histórico de Arquivos

nem:

USN Journal
≠
controle de versões

O objetivo é outro.

O USN Journal consegue desfazer uma alteração?

Não.

O diário registra informações sobre mudanças, mas não possui dados suficientes para reconstruir o estado anterior de um arquivo.

Essa diferença evita uma interpretação perigosa:

“Se o USN registra que um arquivo foi modificado, consigo recuperar o conteúdo anterior pelo USN.”

Não necessariamente.

O diário sabe que aconteceu uma mudança.

Ele não mantém uma cópia integral do conteúdo anterior necessária para desfazê-la.

USN Journal também não é a Lixeira

Outro erro seria confundir o mecanismo com:

Lixeira do Windows

Quando um arquivo é enviado para a Lixeira, existe outro processo envolvido.

O USN Journal pode registrar alterações relacionadas ao objeto, mas não funciona como local de armazenamento dos arquivos excluídos.

Portanto:

Arquivo excluído
       ↓
registro de mudança

não significa:

Arquivo excluído
       ↓
cópia completa guardada
dentro do USN Journal

São coisas completamente diferentes.

Ele também não é um sistema de auditoria completo

Outro cuidado importante.

O USN Journal não deve ser interpretado automaticamente como:

“um registro perfeito de tudo que todos os usuários fizeram no computador.”

Esse não é seu objetivo.

Ele registra alterações no sistema de arquivos.

Além disso, registros antigos podem ser removidos conforme o diário precisa administrar seu tamanho.

Portanto, não devemos tratá-lo como uma trilha histórica permanente e infinita.

O histórico do USN é infinito?

Não.

Se cada mudança feita durante anos fosse preservada indefinidamente, o diário poderia crescer continuamente.

O NTFS precisa administrar esse espaço.

Registros antigos podem ser descartados.

Podemos imaginar:

Registros antigos
100
200
300
400
500

Registros novos
600
700
800
900
1000

Conforme o diário avança, registros mais antigos podem deixar de estar disponíveis.

Portanto:

USN Journal é persistente, mas não significa histórico eterno.

Essa distinção é essencial.

O que significa “persistente” nesse contexto?

Significa que o mecanismo não funciona simplesmente como uma pequena lista temporária mantida apenas enquanto determinado programa está aberto.

O diário faz parte da infraestrutura do volume.

Isso permite que aplicações utilizem os registros para acompanhar mudanças mesmo em situações nas quais seria pouco eficiente depender somente de notificações instantâneas.

Mas novamente:

persistente

não significa:

permanente para sempre

Por que registros antigos podem desaparecer?

Porque o Change Journal possui parâmetros relacionados ao gerenciamento de seu tamanho.

Entre as informações associadas ao diário existem conceitos como:

Maximum Size
Allocation Delta
First USN
Next USN

Esses valores ajudam a entender o estado atual do diário.

Mais adiante vamos consultar essas informações diretamente no Windows.

Como saber se existe um USN Journal no C:?

Abra o Prompt de Comando como administrador.

Execute:

fsutil usn queryjournal C:

O Windows poderá apresentar várias informações técnicas.

Dependendo da versão e configuração, podemos encontrar campos relacionados a:

Usn Journal ID
First Usn
Next Usn
Lowest Valid Usn
Max Usn
Maximum Size
Allocation Delta

Os valores podem aparecer em hexadecimal.

Não se preocupe.

Vamos interpretar cada um deles.

O que é o USN Journal ID?

Cada Change Journal possui um identificador.

Esse identificador é importante porque aplicações não deveriam assumir que um diário consultado hoje é necessariamente exatamente a mesma instância utilizada anteriormente.

Imagine que um programa tenha salvo:

Journal ID: A
Último USN: 50000

Depois o diário é excluído e recriado.

Agora existe:

Journal ID: B

O programa não deveria simplesmente continuar assumindo:

USN > 50000

como se nada tivesse acontecido.

O identificador ajuda a verificar a continuidade do diário.

Por que isso importa?

Imagine um programa que acompanha alterações.

Ele sabe:

Último ponto processado:
USN 9000

Depois o diário é recriado.

Se o programa não verificar o identificador, pode interpretar incorretamente os dados.

Portanto, aplicações que trabalham seriamente com Change Journal precisam considerar tanto:

Journal ID

quanto:

USN

É uma proteção importante contra interpretações erradas.

O que é First USN?

De maneira simplificada, representa a região inicial de registros atualmente disponível para leitura no diário.

Isso nos leva a uma conclusão importante.

Se registros antigos forem removidos:

USN antigo

pode ficar abaixo do ponto que ainda está disponível.

Um programa que deixou de consultar o diário por muito tempo pode descobrir que as informações necessárias já não existem.

Nesse caso, ele pode precisar executar uma nova análise mais ampla do volume.

O que é Next USN?

Podemos pensar no:

Next USN

como a posição associada à continuidade do fluxo de registros.

Conforme novas alterações são registradas, os valores avançam.

Isso permite que aplicações saibam aproximadamente até onde o diário chegou.

Uma representação didática:

First USN
   ↓
[ registros disponíveis ]
                        ↓
                     Next USN

Não devemos interpretar esses valores como simples números de quantidade de arquivos.

Eles representam posições/sequências dentro do mecanismo.

USN não é número de versão do arquivo

Outro erro possível:

arquivo.txt
USN 100

e depois:

arquivo.txt
USN 200

não significa necessariamente:

versão 1
versão 2

como acontece em um sistema tradicional de controle de versões.

O USN identifica a posição relacionada aos registros de alteração.

Ele não transforma automaticamente cada arquivo em um documento versionado.

Um arquivo possui somente um registro USN?

Não devemos pensar dessa forma.

Um mesmo arquivo pode participar de vários registros ao longo do tempo conforme diferentes alterações acontecem.

Imagine:

arquivo criado
      ↓
modificado
      ↓
renomeado
      ↓
modificado novamente
      ↓
excluído

O diário pode conter registros associados a diferentes etapas desse processo.

Por isso a ideia correta é:

diário de alterações

e não:

ficha única do arquivo

Várias gravações podem não produzir registros independentes da maneira que você imagina

Aqui o funcionamento fica ainda mais interessante.

O NTFS trabalha com sinalizadores de motivo.

Durante determinadas sequências de operações sobre um arquivo aberto, alterações do mesmo tipo podem ser consolidadas na forma como os motivos aparecem nos registros.

Isso significa que não devemos interpretar o USN Journal como:

cada tecla digitada
=
um registro

ou:

cada byte gravado
=
um registro

Não funciona assim.

O diário registra mudanças relevantes segundo a lógica do sistema de arquivos.

O sinalizador CLOSE é particularmente interessante

Quando operações sobre determinado arquivo são concluídas e ele é fechado, registros podem envolver o motivo:

USN_REASON_CLOSE

Isso pode ajudar aplicações interessadas em processar alterações após a conclusão de uma sequência de modificações.

Mas novamente:

o USN não fornece uma reprodução completa, passo a passo, de tudo que aconteceu dentro do arquivo.

O diário fornece um histórico parcial

Essa expressão é importante.

Podemos imaginar:

arquivo.docx

criado
 ↓
alterado
 ↓
renomeado
 ↓
alterado
 ↓
fechado

O USN Journal fornece informações sobre eventos relacionados ao objeto.

Mas não devemos esperar:

conteúdo antes
conteúdo depois
usuário digitou isto
programa mudou aquilo

O nível de informação é diferente.

Por que programas preferem consultar o USN em vez de verificar timestamps?

Imagine um programa acompanhando:

2.000.000 de arquivos

Sem um mecanismo eficiente, ele poderia precisar verificar repetidamente:

Data de modificação
Tamanho
Atributos

de cada arquivo.

Com o Change Journal, ele pode descobrir que apenas:

37 arquivos

sofreram mudanças relevantes desde sua última consulta.

A diferença de trabalho pode ser enorme.

É por isso que a documentação da Microsoft descreve a consulta ao USN Change Journal como muito mais eficiente do que depender de verificações repetidas de timestamps ou de determinadas abordagens baseadas apenas em notificações.

O Windows Search tem relação com isso?

A indexação é um excelente exemplo para entender a utilidade conceitual desse mecanismo.

Imagine que o sistema tenha indexado:

1.500.000 arquivos

Depois você altera apenas:

25 arquivos

Seria extremamente ineficiente reconstruir todo o índice apenas para descobrir quais 25 mudaram.

Um mecanismo de acompanhamento de alterações permite identificar mudanças de maneira muito mais eficiente.

A própria documentação da Microsoft destaca a importância dos Change Journals para recuperação da indexação do sistema de arquivos.

Isso explica por que o Windows consegue acompanhar tantas mudanças?

Em parte, sim.

Mas não devemos atribuir toda a lógica do Windows ao USN Journal.

O sistema operacional possui vários mecanismos diferentes para:

notificações
cache
indexação
sistema de arquivos
sincronização
monitoramento

O USN Change Journal é uma peça importante dessa infraestrutura.

Não é a única.

Onde o USN Journal fica armazenado?

Aqui entramos em uma área interessante do NTFS.

O Change Journal está relacionado a estruturas internas do sistema de arquivos e não aparece como uma pasta comum que você simplesmente abre no Explorer.

Você não encontrará normalmente:

C:\USN Journal

com vários arquivos de texto dentro.

Internamente, o NTFS utiliza estruturas próprias para armazenar essas informações.

Um caminho técnico frequentemente associado ao diário envolve metadados NTFS sob:

$Extend\$UsnJrnl

Isso não significa que devemos começar a tentar abrir, modificar ou excluir manualmente essas estruturas.

Elas pertencem ao funcionamento interno do sistema de arquivos.

O que é $UsnJrnl?

É uma estrutura interna relacionada ao Change Journal do NTFS.

O nome:

$UsnJrnl

pode aparecer em ferramentas que inspecionam estruturas internas do NTFS.

Ela não deve ser tratada como um arquivo comum de usuário.

O sistema de arquivos administra seu conteúdo.

Existe relação entre USN Journal e MFT?

Sim, mas eles não são a mesma coisa.

A:

MFT — Master File Table

é uma das estruturas fundamentais do NTFS.

Ela mantém registros relacionados aos arquivos e diretórios existentes no volume.

Já o:

USN Change Journal

acompanha alterações.

Podemos simplificar:

NTFS
 |
 +-- MFT
 |    ↓
 |  informações sobre
 |  objetos do sistema
 |
 +-- USN Change Journal
      ↓
    alterações
    ocorridas

Essa é uma simplificação didática, mas ajuda bastante.

A MFT será assunto para outro artigo

A Master File Table merece um post próprio porque é uma das estruturas mais importantes do NTFS.

Ela ajuda a explicar:

  • como arquivos são representados;
  • metadados;
  • referências;
  • diretórios;
  • fragmentação da própria MFT;
  • arquivos pequenos residentes;
  • identificação de objetos.

Misturar tudo neste artigo deixaria o assunto excessivamente amplo.

Aqui nosso foco permanece no USN Journal.

Posso visualizar o USN Journal?

Sim.

O próprio fsutil possui comandos relacionados à leitura.

A sintaxe documentada inclui:

fsutil usn readjournal

Além disso, podemos consultar dados USN associados a um arquivo específico.

Por exemplo:

fsutil usn readdata C:\Temp\teste.txt

Esses comandos são muito interessantes porque permitem observar o mecanismo sem instalar programas adicionais.

Vamos criar um arquivo para estudar

Podemos utilizar um arquivo de teste inofensivo.

No PowerShell:

New-Item C:\Temp -ItemType Directory -Force

Depois:

Set-Content C:\Temp\teste-usn.txt "Teste VMIA"

Agora temos:

C:\Temp\teste-usn.txt

Podemos consultar informações USN relacionadas ao arquivo:

fsutil usn readdata C:\Temp\teste-usn.txt

O Windows poderá apresentar informações técnicas relacionadas ao objeto.

Modifique o arquivo

No PowerShell:

Add-Content C:\Temp\teste-usn.txt "Segunda alteração"

Agora o arquivo sofreu uma nova mudança.

Podemos consultar novamente:

fsutil usn readdata C:\Temp\teste-usn.txt

A experiência ajuda a visualizar que o sistema de arquivos acompanha mudanças em um nível muito mais profundo do que aquilo que aparece no Explorer.

readdata e readjournal não são a mesma coisa

Essa diferença é importante.

O comando:

fsutil usn readdata

trabalha com dados USN relacionados a um arquivo especificado.

Já:

fsutil usn readjournal

permite ler registros existentes no Change Journal.

Portanto, não trate os dois comandos como sinônimos.

queryjournal responde outra pergunta

Temos então três comandos com finalidades diferentes:

fsutil usn queryjournal C:

Pergunta:

qual é o estado/configuração do diário deste volume?

fsutil usn readdata arquivo

Pergunta:

quais informações USN estão associadas a este arquivo?

fsutil usn readjournal C:

Pergunta:

quais registros existem no diário?

Separar essas funções deixa o diagnóstico muito mais fácil.

É preciso executar como administrador?

Operações de baixo nível relacionadas ao fsutil podem exigir privilégios administrativos.

Por isso, para acompanhar os exemplos deste artigo, prefira abrir:

Terminal / Prompt de Comando como administrador

quando necessário.

Isso também evita interpretar uma mensagem de falta de permissão como se significasse que o USN Journal não existe.

Posso apagar o USN Journal?

Existe comando para isso.

Mas aqui entra uma recomendação importante:

não faça isso apenas para testar, limpar espaço ou tentar acelerar o Windows.

A Microsoft recomenda extremo cuidado ao desabilitar um Change Journal ativo porque outros componentes e aplicações podem depender dele.

Excluir o diário pode obrigar programas a executar novamente verificações completas do volume.

Portanto, este artigo não recomenda usar:

deletejournal

como ferramenta de limpeza ou otimização.

“Apagar o USN deixa o PC mais rápido” é um mau conselho

Encontrar uma estrutura grande do sistema e concluir:

ocupa espaço
      ↓
vou apagar
      ↓
Windows ficará mais rápido

é uma estratégia perigosa.

O USN Journal existe por um motivo.

Se aplicações conseguem descobrir alterações consultando um diário, eliminar esse diário pode justamente obrigá-las a fazer mais trabalho posteriormente.

Portanto, o objetivo deve ser:

entender
diagnosticar
consultar

e não:

apagar tudo que parece grande

O USN Journal pode ocupar espaço?

Sim.

Como qualquer estrutura armazenada, ele utiliza espaço.

Mas seu tamanho é administrado pelo NTFS de acordo com parâmetros próprios.

O comando:

fsutil usn queryjournal C:

permite observar informações relacionadas ao tamanho configurado.

Isso não significa que devemos alterar esses valores sem motivo.

Em um computador doméstico normal, geralmente não existe razão para ficar ajustando manualmente o USN Journal.

O USN Journal causa desgaste excessivo no SSD?

Não devemos concluir isso simplesmente porque o diário registra alterações.

SSDs modernos e o Windows executam inúmeras operações de metadados durante o uso normal.

O Change Journal faz parte do funcionamento previsto do sistema de arquivos.

Desativá-lo aleatoriamente para “poupar o SSD” não é uma recomendação adequada.

Uma análise real de desgaste deve observar dados de saúde da unidade, volume de gravações, carga de trabalho e especificações do dispositivo.

USN Journal é vírus?

Não.

A presença de:

$UsnJrnl

ou informações relacionadas ao USN faz parte do NTFS.

Naturalmente, programas legítimos e maliciosos podem provocar alterações em arquivos que resultam em registros.

Mas o mecanismo em si pertence ao sistema de arquivos.

Antivírus pode utilizar informações de alterações?

Soluções de segurança possuem arquiteturas próprias e podem usar diversos mecanismos do Windows.

O ponto importante é não afirmar que todo antivírus depende obrigatoriamente do USN Journal para funcionar.

O Change Journal fornece uma maneira eficiente de acompanhar alterações, mas cada produto pode implementar sua lógica de maneira diferente.

Programas de backup podem usar USN?

Algumas soluções podem utilizar mecanismos de acompanhamento de alterações para evitar analisar novamente todos os arquivos a cada execução.

Isso é especialmente útil em tarefas incrementais.

Imagine:

Backup inicial
1.000.000 arquivos

Depois apenas:

500 arquivos mudaram

Saber quais objetos sofreram alterações pode tornar o processo muito mais eficiente.

Mas a implementação depende de cada software.

USN Journal não substitui backup incremental

É importante separar:

descobrir que mudou

de:

guardar a nova versão

O USN pode ajudar um programa a descobrir alterações.

O software de backup ainda precisa:

ler os dados
copiar os dados
armazenar o backup
administrar versões

Portanto:

USN Journal

é um mecanismo de acompanhamento.

Não um destino de backup.

O que acontece se o diário perder registros que um programa precisava?

Essa é uma das limitações mais interessantes.

Imagine:

Programa consultou até USN 1000

Depois ficou muito tempo sem consultar.

Enquanto isso:

milhões de alterações

aconteceram.

O NTFS precisou remover registros antigos.

Agora o registro:

USN 1001

que o programa esperava já não está disponível.

Nesse cenário, a aplicação não pode simplesmente presumir que conhece todas as mudanças.

Ela pode precisar realizar uma nova varredura completa ou outro procedimento de recuperação.

Isso explica por que o gerenciamento correto do diário é tão importante.

Por que o USN Journal é tão interessante?

Porque ele revela uma diferença enorme entre aquilo que enxergamos e aquilo que o Windows precisa administrar.

No Explorer vemos:

Arquivo
Pasta
Data
Tamanho

Por baixo disso existe uma infraestrutura muito mais sofisticada:

NTFS
MFT
identificadores
atributos
metadados
USN
Change Journal
permissões
clusters

O Windows não trabalha apenas com nomes de arquivos.

Ele mantém estruturas projetadas para gerenciar milhões de objetos com eficiência.

O USN Journal é uma dessas estruturas invisíveis

Quando você salva:

foto.jpg

vê apenas um arquivo.

O NTFS precisa lidar com muito mais:

nome
localização
metadados
atributos
segurança
dados
alterações

O Change Journal é uma peça dessa arquitetura.

E justamente por funcionar nos bastidores, muitos usuários nunca ouviram falar dele.

O que aprendemos até aqui?

O USN Change Journal:

  • pertence à infraestrutura do NTFS;
  • funciona por volume;
  • registra alterações em objetos do sistema de arquivos;
  • utiliza Update Sequence Numbers;
  • permite acompanhar mudanças de maneira eficiente;
  • pode ser consultado por aplicações;
  • possui tamanho administrado;
  • pode perder registros antigos;
  • não armazena versões completas dos arquivos;
  • não substitui backup;
  • não é a Lixeira;
  • não deve ser apagado como suposta otimização.

Esse conjunto de conceitos é fundamental antes de começarmos a interpretar os registros reais.

Interpretando o USN Journal na prática

Agora que já entendemos o que é o USN Change Journal, podemos sair da teoria e observar como o NTFS apresenta essas informações no Windows 11.

O primeiro comando é:

fsutil usn queryjournal C:

Ele não mostra uma lista de todos os arquivos alterados. Sua função é consultar o estado atual do diário daquele volume: identificador, limites de USN, capacidade e parâmetros usados para gerenciar o Journal. A própria documentação da Microsoft descreve queryjournal como o comando para coletar informações sobre o diário atual, seus registros e sua capacidade.

Em um computador real, a saída pode variar, mas normalmente veremos campos semelhantes a:

Usn Journal ID
First Usn
Next Usn
Lowest Valid Usn
Max Usn
Maximum Size
Allocation Delta

Vamos entender cada um.

Usn Journal ID: a identidade daquele diário

O campo:

Usn Journal ID

identifica a instância atual do Change Journal.

Isso é importante porque o diário pode ser excluído e recriado. Imagine que um programa tenha armazenado:

Journal ID = A
Último USN = 0x250000

Na próxima execução, ele encontra:

Journal ID = B

Nesse caso, não deve simplesmente continuar lendo depois de 0x250000, porque aquele ponto pertencia a outro Journal.

A lógica correta seria:

Journal ID anterior
        ↓
comparar
        ↓
Journal ID atual
        ↓
igual?
 ┌──────┴──────┐
sim           não
 ↓             ↓
continuar    revisar estado

Esse detalhe é fundamental para aplicações que dependem do Change Journal de forma confiável.

First Usn: até onde o passado ainda está disponível

O:

First Usn

indica o ponto inicial disponível para leitura no estado atual do Journal.

Isso ajuda a entender um dos conceitos mais importantes do USN:

o diário não cresce para sempre.

Imagine que ontem estivessem disponíveis:

1000
1100
1200
1300
1400
1500

Depois de muitas alterações, registros antigos podem ser descartados.

Hoje poderíamos ter:

1300
1400
1500
1600
1700
1800

O programa que ainda precisa do:

1100

tem um problema: aquela informação pode não existir mais.

É por isso que aplicações que utilizam o USN Journal precisam verificar se o ponto no qual pretendem continuar ainda é válido.

Next Usn: onde o Journal continua

Outro valor importante é:

Next Usn

Podemos enxergá-lo conceitualmente como a posição para a continuidade do fluxo.

Imagine:

First USN
   ↓
[ registros existentes ]
                     ↓
                  Next USN

Novos registros são acrescentados ao final do diário. A documentação oficial confirma que os registros USN são adicionados ao final do fluxo conforme objetos NTFS são criados, excluídos ou modificados.

É importante novamente evitar uma interpretação errada.

Se aparecer algo como:

Next Usn = 0x000000004A123000

isso não significa que existam 4 bilhões de arquivos ou determinada quantidade de alterações.

USN é uma posição/número de sequência dentro do mecanismo.

Lowest Valid Usn

O nome praticamente explica a função:

Lowest Valid Usn

é um limite relacionado aos valores USN que ainda podem ser considerados válidos na situação atual do Journal.

Para um programa que guardou um ponto anterior, essa informação é relevante para determinar se ainda consegue continuar seu processamento incremental ou se precisa executar uma nova análise.

Podemos simplificar:

USN salvo pelo programa
        ↓
ainda está dentro
do intervalo válido?
      /       \
    sim       não
     ↓         ↓
continuar    reavaliar

Esse é um dos motivos pelos quais o USN Journal é mais sofisticado do que simplesmente manter uma lista de nomes de arquivos.

Maximum Size: quanto espaço o Journal pretende usar

Outro campo encontrado é:

Maximum Size

Ele está relacionado ao tamanho máximo configurado para o Change Journal.

A documentação do fsutil usn descreve o parâmetro m=<maxsize> como o tamanho máximo, em bytes, que o NTFS aloca ao diário.

Isso não deve ser interpretado de maneira rígida como:

Maximum Size = exatamente o tamanho
do arquivo neste segundo

O gerenciamento do Journal envolve alocação e remoção de espaço conforme o NTFS trabalha.

O importante é entender a ideia:

Journal cresce
    ↓
atinge determinada região
de gerenciamento
    ↓
registros antigos podem
ser removidos

Allocation Delta

Também podemos encontrar:

Allocation Delta

Esse parâmetro define unidades usadas no crescimento e gerenciamento do Change Journal.

A documentação do fsutil descreve allocationdelta como a quantidade adicionada ao final e removida do início do diário durante seu gerenciamento.

Isso ajuda a evitar alterações minúsculas constantes no espaço reservado.

Didaticamente:

Journal precisa crescer
       ↓
adiciona um bloco
       ↓
continua trabalhando

e, ao realizar manutenção:

registros antigos
       ↓
blocos podem deixar
de fazer parte da região útil

Os valores podem aparecer em hexadecimal

Ao executar:

fsutil usn queryjournal C:

é comum encontrar valores iniciados por:

0x

Por exemplo:

0x00000000031f0000

Isso indica representação hexadecimal.

Não precisamos converter todos esses valores para usar o comando como diagnóstico.

No contexto deste artigo, muitas vezes o mais útil é comparar:

antes
versus
depois

ou observar:

First Usn
Next Usn
Journal ID

Agora vamos observar um arquivo real

Vamos criar uma pasta somente para o teste:

mkdir C:\Temp\VMIA-USN

Depois crie um arquivo:

echo Primeira linha > C:\Temp\VMIA-USN\teste.txt

Agora execute:

fsutil usn readdata C:\Temp\VMIA-USN\teste.txt

A Microsoft documenta readdata justamente como o comando usado para ler os dados USN associados a um arquivo.

A saída pode incluir informações técnicas como:

Major Version
Minor Version
File Reference Number
Parent File Reference Number
Usn
Time Stamp
Reason
Source Info
Security Id
File Attributes

A composição exata pode variar conforme versão e formato do registro.

File Reference Number: o NTFS não depende apenas do nome

Um dos conceitos mais interessantes que aparece nesse nível é o:

File Reference Number

Para nós, um arquivo é:

C:\Temp\VMIA-USN\teste.txt

Para o NTFS, o nome não é a única forma de identificar aquele objeto.

Internamente existem referências associadas aos registros da MFT.

Isso se torna particularmente importante quando pensamos em renomeações.

Imagine:

teste.txt

passando a se chamar:

relatorio.txt

O nome mudou.

Mas isso não significa necessariamente que o NTFS tenha criado um arquivo completamente novo apenas porque o texto visível do nome mudou.

A referência ajuda aplicações a acompanhar o objeto mesmo diante de determinadas mudanças de nome e localização.

Parent File Reference Number

Também podemos encontrar uma referência ao objeto pai:

Parent File Reference Number

Se temos:

C:\Temp\VMIA-USN\teste.txt

o arquivo está dentro de:

VMIA-USN

Essa pasta possui sua própria representação dentro do NTFS.

Em registros do Change Journal, a combinação entre referência do objeto, referência do diretório pai e nome permite reconstruir informações importantes sobre o contexto daquela mudança.

O campo Reason é onde a coisa fica realmente interessante

O:

Reason

indica por que aquele registro foi criado.

O Windows define uma série de sinalizadores:

USN_REASON_...

Esses valores podem ser combinados.

Portanto, um registro não precisa representar somente:

arquivo alterado

Ele pode indicar diferentes tipos de mudança.

Vamos conhecer os mais úteis.

USN_REASON_FILE_CREATE

O sinalizador:

USN_REASON_FILE_CREATE

indica que um arquivo ou diretório foi criado.

O valor documentado é:

0x00000100

A documentação da Microsoft define esse motivo como a criação inicial do arquivo ou diretório.

Nosso comando:

echo Primeira linha > C:\Temp\VMIA-USN\teste.txt

acabou de provocar uma criação.

Conceitualmente:

teste.txt não existe
        ↓
arquivo criado
        ↓
FILE_CREATE

USN_REASON_FILE_DELETE

Quando um arquivo ou diretório é excluído, existe:

USN_REASON_FILE_DELETE

com valor:

0x00000200

O motivo registra a exclusão do objeto.

Mais uma vez:

FILE_DELETE

não significa que o conteúdo excluído ficou armazenado dentro do Journal.

Significa apenas que o Journal registrou o evento relacionado à exclusão.

DATA_OVERWRITE: dados foram sobrescritos

O:

USN_REASON_DATA_OVERWRITE

aparece quando dados do arquivo são sobrescritos.

Seu valor é:

0x00000001

A documentação oficial associa esse motivo diretamente à sobrescrita dos dados.

Podemos provocar um exemplo simples:

echo Conteudo novo > C:\Temp\VMIA-USN\teste.txt

O operador:

>

substitui o conteúdo do arquivo.

DATA_EXTEND: o arquivo ganhou dados

Agora execute:

echo Mais uma linha >> C:\Temp\VMIA-USN\teste.txt

Observe a diferença:

>

sobrescreve.

Enquanto:

>>

acrescenta conteúdo ao final.

Uma operação que amplia dados pode envolver:

USN_REASON_DATA_EXTEND

documentado com o valor:

0x00000002

e associado ao acréscimo de dados ao arquivo ou diretório.

DATA_TRUNCATION

Outro sinalizador é:

USN_REASON_DATA_TRUNCATION

Valor:

0x00000004

Ele representa truncamento.

Em termos simples, significa que o conteúdo foi reduzido.

Imagine um arquivo contendo:

Linha 1
Linha 2
Linha 3
Linha 4
Linha 5

que passa para:

Linha 1

O tamanho efetivo dos dados diminuiu.

Esse tipo de situação pode gerar o motivo de truncamento.

BASIC_INFO_CHANGE não significa mudança no conteúdo

Este é um ótimo detalhe para diagnóstico.

Existe:

USN_REASON_BASIC_INFO_CHANGE

Ele pode aparecer quando mudam atributos ou timestamps.

Exemplos incluem:

Somente leitura
Oculto
Sistema
Arquivo
Sparse
timestamps

A Microsoft documenta explicitamente esses casos.

Portanto:

BASIC_INFO_CHANGE

não significa automaticamente:

conteúdo textual do arquivo mudou

Pode ter sido apenas um atributo.

Por exemplo:

attrib +R C:\Temp\VMIA-USN\teste.txt

marca o arquivo como somente leitura.

Isso altera metadados sem necessariamente mudar o conteúdo.

SECURITY_CHANGE

Também existe:

USN_REASON_SECURITY_CHANGE

relacionado a mudanças na segurança do arquivo ou diretório.

Isso pode envolver alterações no descritor de segurança.

É uma lembrança importante de que o NTFS não controla apenas:

nome
dados
tamanho

Ele também gerencia permissões e informações de segurança.

COMPRESSION_CHANGE

O motivo:

USN_REASON_COMPRESSION_CHANGE

indica mudança no estado de compactação do objeto. A Microsoft documenta esse sinalizador para transições de arquivo/diretório compactado para não compactado ou vice-versa.

Isso conecta o USN Journal a outro recurso interessante do NTFS:

compactação

Ou seja, uma mudança que parece simplesmente uma propriedade do arquivo também pode gerar informação no Journal.

ENCRYPTION_CHANGE

Também existe:

USN_REASON_ENCRYPTION_CHANGE

associado a uma mudança no estado de criptografia do arquivo ou diretório.

Novamente percebemos que o Change Journal acompanha muito mais que gravações tradicionais de conteúdo.

RENAME_OLD_NAME e RENAME_NEW_NAME

Renomear um arquivo é particularmente interessante.

Existem dois sinalizadores:

USN_REASON_RENAME_OLD_NAME

e:

USN_REASON_RENAME_NEW_NAME

A documentação descreve o primeiro como o registro contendo o nome antigo e o segundo como o registro contendo o novo nome.

Vamos testar:

ren C:\Temp\VMIA-USN\teste.txt relatorio.txt

Conceitualmente:

teste.txt
   ↓
RENAME_OLD_NAME

relatorio.txt
   ↓
RENAME_NEW_NAME

Essa dupla de registros permite acompanhar uma renomeação.

Renomear não é simplesmente “apagar e criar outro”

Para um usuário olhando o Explorer:

teste.txt

desaparece e:

relatorio.txt

aparece.

Seria fácil imaginar:

teste.txt excluído
+
relatorio.txt criado

Mas o NTFS possui um motivo específico para renomeação.

Isso demonstra por que interpretar apenas nomes pode levar a conclusões erradas.

E mover um arquivo para outra pasta?

Uma movimentação dentro do mesmo volume também pode envolver informações de renomeação/contexto.

Imagine:

C:\Temp\VMIA-USN\relatorio.txt

movido para:

C:\Documentos\relatorio.txt

Não devemos assumir automaticamente que isso equivale a:

arquivo original destruído
+
novo arquivo criado do zero

O comportamento dependerá da operação e, especialmente, se ela ocorre dentro do mesmo volume ou entre volumes diferentes.

Essa diferença é importante.

Mover:

C: → C:

não é conceitualmente idêntico a mover:

C: → D:

porque estamos atravessando sistemas de arquivos/volumes distintos.

O significado especial de CLOSE

Agora chegamos a:

USN_REASON_CLOSE

valor:

0x80000000

Esse sinalizador indica que o arquivo ou diretório foi fechado.

Mas seu papel no Journal é mais interessante do que parece.

A documentação da Microsoft explica que várias alterações durante a mesma abertura de um arquivo podem acumular motivos, e o registro final com CLOSE pode funcionar como um resumo dos tipos de alterações daquela sequência.

Um exemplo oficial ajuda a entender

Imagine um programa que:

abre arquivo
     ↓
grava dados
     ↓
altera timestamp
     ↓
grava novamente
     ↓
trunca
     ↓
grava
     ↓
fecha

Seria intuitivo pensar:

6 operações
=
6 registros independentes

Mas não necessariamente.

A Microsoft explica que, quando o mesmo tipo de alteração ocorre repetidamente sem fechamento e reabertura intermediários, o NTFS pode evitar a criação de um novo registro simplesmente porque aquele motivo já está marcado.

Portanto:

write
write
write
write

não significa obrigatoriamente:

4 × DATA_OVERWRITE

Isso destrói um mito importante sobre o USN Journal

O Journal não é um gravador de cada operação individual.

Ele não deve ser interpretado como:

14:01:01 - byte alterado
14:01:02 - outro byte alterado
14:01:03 - outro byte alterado

Sua lógica é baseada nos tipos de alteração registrados pelo NTFS.

A documentação oficial chama a sequência resultante de um histórico parcial das mudanças no arquivo.

Essa palavra é fundamental:

parcial.

O registro CLOSE não informa a ordem de todas as alterações

Imagine que o registro final tenha sinalizadores equivalentes a:

DATA_OVERWRITE
BASIC_INFO_CHANGE
DATA_TRUNCATION
CLOSE

Podemos concluir que esses tipos de alteração ocorreram naquela sequência de uso.

Mas não podemos usar somente esse registro final para afirmar:

primeiro aconteceu A
depois B
depois C

A própria Microsoft observa que o registro final com CLOSE resume os tipos de mudança, mas não indica a ordem delas.

Vamos montar um teste completo

Crie novamente o arquivo:

echo Inicio > C:\Temp\VMIA-USN\teste.txt

Consulte:

fsutil usn readdata C:\Temp\VMIA-USN\teste.txt

Agora acrescente dados:

echo Segunda linha >> C:\Temp\VMIA-USN\teste.txt

Consulte novamente:

fsutil usn readdata C:\Temp\VMIA-USN\teste.txt

Renomeie:

ren C:\Temp\VMIA-USN\teste.txt teste-renomeado.txt

Consulte:

fsutil usn readdata C:\Temp\VMIA-USN\teste-renomeado.txt

Finalmente, exclua:

del C:\Temp\VMIA-USN\teste-renomeado.txt

Agora já não podemos executar:

fsutil usn readdata ...

sobre aquele caminho porque o arquivo deixou de existir.

É aqui que precisamos olhar para o diário completo.

readjournal: entrando no fluxo de registros

Execute:

fsutil usn readjournal C:

Esse comando lê registros do USN Journal daquele volume. A documentação atual do Windows 11 também permite parâmetros como startusn, além de filtros relacionados às versões dos registros.

Há um problema prático:

o resultado pode ser enorme.

Em um Windows em uso, alterações acontecem continuamente:

logs
cache
Windows Defender
navegadores
serviços
Windows Update
aplicativos
arquivos temporários
indexação

Por isso simplesmente executar:

fsutil usn readjournal C:

pode gerar uma quantidade gigantesca de saída.

É aí que startusn se torna útil

A sintaxe atual suporta:

fsutil usn readjournal startusn=<USN> C:

A Microsoft fornece inclusive exemplo de leitura começando em um USN específico.

A estratégia profissional é:

1. consultar Next Usn
2. guardar esse valor
3. fazer a alteração de teste
4. ler a partir daquele ponto

Assim reduzimos drasticamente o ruído.

Exemplo de metodologia

Primeiro:

fsutil usn queryjournal C:

Anote:

Next Usn

Imagine que seja:

0x0000000012345000

Agora crie:

echo VMIA > C:\Temp\VMIA-USN\observacao.txt

Renomeie:

ren C:\Temp\VMIA-USN\observacao.txt observacao-renomeada.txt

Depois leia a partir do ponto anotado:

fsutil usn readjournal startusn=0x0000000012345000 C:

Agora você estará olhando principalmente para eventos que aconteceram depois daquele ponto.

Ainda pode existir ruído de outros processos, mas a análise fica muito mais prática.

Não espere encontrar apenas seu arquivo

Mesmo que você faça o teste rapidamente, o Windows continua ativo.

Enquanto isso:

serviço A escreve log
navegador atualiza cache
antivírus toca arquivo
Explorer cria informação
programa salva configuração

Todos esses eventos podem gerar alterações no NTFS.

Portanto, o Change Journal fornece uma excelente demonstração de quanto trabalho acontece nos bastidores do Windows.

Por que timestamps sozinhos seriam piores?

Suponha que um programa queira saber quais arquivos mudaram desde ontem.

Uma estratégia seria visitar:

Arquivo 1
Arquivo 2
Arquivo 3
...
Arquivo 3.000.000

e comparar:

LastWriteTime

O USN Journal oferece um modelo muito mais eficiente porque o programa pode trabalhar com alterações registradas desde um determinado ponto.

A Microsoft afirma explicitamente que consultar o Change Journal pode ser mais eficiente do que verificar timestamps ou depender exclusivamente de notificações de arquivo.

Mas o Journal não responde todas as perguntas

Essa limitação é essencial.

Imagine que um registro indique:

DATA_OVERWRITE

Sabemos que dados foram sobrescritos.

Mas não sabemos automaticamente:

qual texto existia antes
qual texto existe depois
qual linha mudou
qual usuário digitou
qual intenção havia

Precisamos de outras fontes para essas respostas.

O USN Journal responde principalmente:

“que tipo de alteração o NTFS registrou para este objeto?”

USN Journal não substitui o Visualizador de Eventos

O Visualizador de Eventos responde perguntas sobre eventos gerados por componentes e aplicações.

O USN Journal trabalha no nível do sistema de arquivos.

São camadas diferentes.

Exemplo:

Visualizador de Eventos
        ↓
serviço falhou
aplicativo travou
driver gerou evento

Enquanto:

USN Journal
        ↓
arquivo criado
dados alterados
arquivo renomeado
arquivo excluído

Combinar fontes pode ser muito poderoso em uma investigação técnica.

Também não substitui auditoria de arquivos

O Windows possui mecanismos específicos para auditoria de acesso a objetos.

Se a pergunta for:

“qual usuário tentou acessar este arquivo?”

o Change Journal sozinho não é necessariamente a ferramenta adequada.

Se a pergunta for:

“o NTFS registrou uma mudança neste objeto?”

aí o USN se torna muito mais relevante.

O que o técnico deve extrair do USN?

Para suporte e diagnóstico, os conceitos mais úteis são:

objeto alterado
tipo de alteração
posição USN
identidade do Journal
continuidade dos registros

Não devemos vender o USN como uma ferramenta mágica de investigação.

Seu valor está justamente em saber qual pergunta ele consegue responder.

Por que isso é útil para entender backups e indexadores?

Agora fica muito mais fácil compreender a arquitetura.

Imagine um programa de backup incremental.

Na última execução:

Journal ID: ABC
Último USN: X

Na execução seguinte:

Journal ID ainda é ABC?
      ↓
sim
      ↓
X ainda é válido?
      ↓
sim
      ↓
ler alterações posteriores

Isso evita necessariamente voltar a verificar milhões de arquivos simplesmente para descobrir quais mudaram.

A implementação real depende de cada software, mas esse modelo mostra por que um Change Journal é tão valioso.

E se o Journal tiver sido recriado?

O fluxo quebra.

Imagine:

ontem
Journal ID = ABC

Hoje:

Journal ID = XYZ

O programa não deve confiar cegamente no antigo USN.

Ele precisa reconhecer que perdeu a continuidade.

Esse é outro motivo para não excluir o Change Journal manualmente sem necessidade.

E se o First Usn já tiver passado do ponto salvo?

Outro cenário:

Programa guardou:
USN 1000

Hoje o volume informa:

First Usn = 5000

Os registros entre:

1000 → 4999

já não estão disponíveis naquele Journal.

Nesse caso, o programa não tem como reconstruir todas aquelas mudanças apenas lendo o diário atual.

Pode ser necessário:

nova varredura
reindexação
resincronização

dependendo da aplicação.

Por isso “limpar o USN” pode causar exatamente o oposto de otimização

O usuário encontra um tutorial:

apague o Journal para liberar espaço

Executa.

Depois determinados componentes precisam:

reanalisar
reindexar
reconciliar

informações.

Resultado possível:

mais I/O
mais CPU
mais tempo

temporariamente.

A documentação oficial alerta para o impacto de excluir/desabilitar um Journal ativo justamente porque aplicações que dependem dele podem precisar executar uma nova varredura completa.

Um pequeno mapa mental do USN Journal

Depois desta parte, podemos resumir o funcionamento assim:

Arquivo/diretório NTFS
        ↓
mudança acontece
        ↓
NTFS identifica motivo
        ↓
USN_REASON
        ↓
registro entra no Change Journal
        ↓
recebe posição USN
        ↓
aplicação consulta o Journal
        ↓
processa somente mudanças relevantes

Mas sempre lembrando:

USN Journal
      ↓
registra a mudança

USN Journal
      X
não armazena automaticamente
a versão anterior do conteúdo

Um diagnóstico interessante: “o arquivo realmente mudou?”

Suponha que um aplicativo diga:

“Detectei que este arquivo foi alterado.”

Mas o usuário acredita que ninguém mexeu nele.

O USN Journal pode fornecer uma pista de que alguma alteração realmente ocorreu.

Porém isso não necessariamente significa:

conteúdo modificado pelo usuário

O motivo poderia ser:

BASIC_INFO_CHANGE

por causa de timestamp ou atributo.

Essa diferença é enorme.

“Arquivo mudou” pode significar várias coisas no NTFS.

E por isso o campo Reason é mais importante que simplesmente observar a data

No Explorer você pode enxergar:

Data de modificação

No Change Journal, o sistema pode distinguir categorias como:

DATA_OVERWRITE
DATA_EXTEND
DATA_TRUNCATION
FILE_CREATE
FILE_DELETE
BASIC_INFO_CHANGE
SECURITY_CHANGE
RENAME_OLD_NAME
RENAME_NEW_NAME
COMPRESSION_CHANGE
CLOSE

Isso oferece uma visão muito mais técnica do que aconteceu com o objeto.

Não tente interpretar cada registro isoladamente

Esse é um erro comum.

Um registro pode possuir vários sinalizadores combinados.

Além disso, uma sequência de operações pode gerar diferentes registros até o fechamento do arquivo.

Portanto, uma boa investigação olha:

objeto
+
USN
+
Reason
+
sequência
+
contexto

e não apenas uma única linha.

USN Journal em diagnósticos reais no Windows 11

Depois de entender a estrutura do Journal e os principais motivos registrados pelo NTFS, surge a pergunta mais importante: como isso pode ajudar em um diagnóstico real?

O USN Journal não substitui ferramentas como Visualizador de Eventos, histórico de versões, backup, auditoria ou antivírus. Mas ele pode responder perguntas muito específicas sobre alterações ocorridas no sistema de arquivos.

Por exemplo:

este arquivo foi criado?
foi apenas renomeado?
teve o conteúdo alterado?
mudou somente um atributo?
foi excluído?
houve uma alteração de segurança?

Esse tipo de diferença é muito útil porque o Explorer normalmente mostra apenas uma visão simplificada do arquivo.

Um arquivo pode “mudar” sem o conteúdo mudar

Imagine:

C:\Documentos\relatorio.docx

O usuário afirma:

“Eu não alterei esse documento.”

Mas um programa diz que o arquivo mudou.

A primeira interpretação costuma ser:

conteúdo foi editado

Só que isso não é obrigatoriamente verdade.

O NTFS também registra mudanças de metadados.

Um exemplo é:

USN_REASON_BASIC_INFO_CHANGE

Esse motivo pode aparecer quando atributos ou determinadas informações básicas do arquivo são alteradas.

Portanto:

arquivo mudou

pode significar:

conteúdo modificado

mas também pode significar:

atributo alterado
timestamp alterado
estado de compactação modificado
informação de segurança modificada

Essa distinção é essencial em uma investigação técnica.

Comparar o Reason muda completamente o diagnóstico

Imagine dois registros.

Primeiro:

Reason:
BASIC_INFO_CHANGE

Segundo:

Reason:
DATA_OVERWRITE

Nos dois casos poderíamos dizer genericamente:

“houve uma alteração.”

Mas tecnicamente são situações bem diferentes.

No segundo caso existe uma indicação muito mais direta de mudança nos dados do arquivo.

No primeiro, a alteração pode ter ocorrido apenas em metadados.

Por isso, ao estudar o USN Journal, o técnico não deve perguntar apenas:

“Existe um registro?”

A pergunta correta é:

“Qual motivo o NTFS registrou?”

Criação ou renomeação?

Outro cenário interessante ocorre quando um arquivo “desaparece” com um nome e aparece com outro.

Imagine:

relatorio.txt

depois:

relatorio-final.txt

Um programa pouco sofisticado poderia interpretar isso como:

relatorio.txt foi excluído
relatorio-final.txt foi criado

Mas o Change Journal possui motivos específicos para renomeação:

RENAME_OLD_NAME
RENAME_NEW_NAME

Isso permite entender que provavelmente estamos acompanhando o mesmo objeto NTFS passando por uma mudança de nome.

É aí que o:

File Reference Number

se torna ainda mais interessante.

O nome não é a identidade completa do arquivo

Para nós:

C:\Relatorios\financeiro.xlsx

parece ser a identidade daquele arquivo.

Para o NTFS, o caminho é apenas parte da história.

O sistema trabalha também com referências internas relacionadas à MFT.

Isso permite acompanhar um objeto mesmo quando seu nome é alterado.

Podemos imaginar:

Objeto NTFS
Reference Number: X
      ↓
financeiro.xlsx
      ↓
renomeado
      ↓
financeiro-2026.xlsx

O nome mudou.

A referência interna ao objeto pode continuar relacionada ao mesmo registro.

Isso é muito mais robusto do que tentar acompanhar arquivos apenas por strings de caminho.

E se o arquivo for movido para outra pasta?

Agora imagine:

C:\Temp\arquivo.txt

sendo movido para:

C:\Documentos\arquivo.txt

Se a movimentação ocorrer dentro do mesmo volume NTFS, o comportamento pode envolver mudança de nome/contexto do diretório pai em vez de uma cópia física completa seguida de exclusão, dependendo da operação executada.

Conceitualmente:

mesmo volume
C: → C:

permite ao NTFS tratar o objeto de maneira diferente de uma transferência entre volumes.

Mover entre volumes é outra história

Agora imagine:

C:\Temp\arquivo.txt

movido para:

D:\Backup\arquivo.txt

Temos:

C:

e:

D:

Cada volume possui sua própria estrutura NTFS e seu próprio USN Change Journal.

Nesse cenário, a operação frequentemente envolve algo conceitualmente semelhante a:

copiar dados para D:
      ↓
criar novo objeto no volume D:
      ↓
remover objeto original do volume C:

Portanto, não devemos interpretar:

mover arquivo

como uma operação idêntica em todos os casos.

Mover dentro do volume e mover entre volumes têm implicações diferentes para o sistema de arquivos.

Dois volumes significam dois Journals

Se temos:

C:
D:

podemos consultar:

fsutil usn queryjournal C:

e:

fsutil usn queryjournal D:

Os dois Journals são independentes.

Portanto, durante uma investigação envolvendo cópia ou movimentação entre unidades, pode ser necessário examinar os dois lados.

Isso é particularmente importante quando o técnico pensa:

“Vou procurar o evento de criação no Journal do C:.”

Mas a criação ocorreu no:

D:

USN Journal e Windows Search

Um dos usos conceituais mais interessantes do Change Journal está relacionado à indexação.

Imagine que o Windows Search já tenha processado:

2.000.000 de arquivos

Depois o usuário altera apenas:

120 arquivos

Reanalisar milhões de arquivos simplesmente para descobrir quais 120 mudaram seria desperdício de processamento e I/O.

Um mecanismo de acompanhamento de alterações permite reduzir muito esse trabalho.

É justamente por isso que Change Journals são úteis para indexadores e outros softwares que precisam acompanhar modificações continuamente.

O que acontece se o Journal desaparecer?

Imagine que um indexador conhece:

Journal ID: ABC
Último USN processado: 500000

Depois alguém exclui e recria o USN Journal.

Agora:

Journal ID: XYZ

O histórico de continuidade foi quebrado.

O software não pode simplesmente assumir:

continuo de 500001

porque aquele valor pertencia ao diário anterior.

A reação pode ser:

reindexação
nova varredura
reconciliação de estado

dependendo da aplicação.

Por isso apagar o USN Journal aleatoriamente pode causar exatamente o efeito contrário do esperado.

O mito da “limpeza do USN”

Alguns tutoriais tratam qualquer estrutura que ocupa espaço como candidata à remoção.

A lógica costuma ser:

arquivo grande
      ↓
apagar
      ↓
mais espaço
      ↓
mais desempenho

Esse raciocínio não funciona bem com estruturas do sistema.

O Change Journal existe para reduzir trabalho futuro.

Se um programa perde o histórico incremental, ele pode precisar fazer:

varredura completa

em vez de:

processar somente mudanças

Ou seja, uma suposta “otimização” pode gerar:

mais leitura
mais processamento
mais tempo

temporariamente.

USN Journal e programas de backup

Programas de backup incremental enfrentam um desafio semelhante.

Depois do backup inicial, eles querem descobrir:

o que mudou?

Imagine:

Backup inicial:
3.000.000 de arquivos

No dia seguinte:

2.300 arquivos alterados

Não seria eficiente verificar todos os três milhões novamente apenas para localizar esses 2.300.

Algumas soluções podem usar mecanismos de rastreamento de mudanças para reduzir esse trabalho.

Mas existe um detalhe importante:

cada software implementa isso de sua própria maneira.

Não devemos afirmar que todo programa de backup depende obrigatoriamente do USN Journal.

O USN apenas ajuda a descobrir mudanças

Mesmo quando um programa utiliza o Change Journal, ainda existem outras etapas.

Ele pode descobrir:

arquivo X mudou
arquivo Y foi criado
arquivo Z foi excluído

Mas ainda precisa decidir:

copiar?
ignorar?
versionar?
compactar?
enviar para nuvem?
manter histórico?

Portanto:

USN

é apenas uma fonte de informação.

Ele não executa o backup.

USN Journal e sincronização em nuvem

O mesmo raciocínio pode aparecer em softwares de sincronização.

Imagine uma pasta com:

500.000 arquivos

Se o cliente precisar descobrir alterações continuamente, mecanismos do sistema de arquivos podem ajudar a reduzir a necessidade de reexaminar tudo.

Porém, novamente, não devemos concluir automaticamente:

OneDrive usa exatamente desta forma
Dropbox usa exatamente desta forma
Google Drive usa exatamente desta forma

sem documentação específica de cada produto.

A ideia geral é que um Change Journal oferece uma maneira eficiente de acompanhar alterações no volume.

Dá para descobrir quem alterou um arquivo pelo USN?

Não necessariamente.

Essa é uma das limitações mais importantes.

O Journal pode informar que ocorreu:

DATA_OVERWRITE

ou:

FILE_DELETE

Mas isso não significa que ele forneça automaticamente:

usuário responsável
processo responsável
programa responsável
motivo humano

Para essas perguntas, precisamos de outras fontes.

Então como descobrir qual programa mexeu no arquivo?

O USN sozinho não resolve essa pergunta.

Ferramentas mais apropriadas podem incluir:

Process Monitor
auditoria de objetos
Visualizador de Eventos
logs do próprio aplicativo
Microsoft Defender

dependendo da situação.

O USN pode confirmar:

“houve uma alteração.”

O Process Monitor, quando configurado previamente, pode ajudar a mostrar:

“qual processo executou determinada operação.”

São ferramentas complementares.

USN Journal não é Process Monitor

Essa comparação ajuda bastante.

O Process Monitor observa operações em tempo real enquanto está sendo executado.

Já o Change Journal mantém informações persistentes sobre alterações registradas pelo NTFS.

Podemos simplificar:

Process Monitor
      ↓
quem fez?
qual processo?
qual operação?
qual resultado?

Enquanto:

USN Journal
      ↓
qual objeto mudou?
qual tipo de mudança?
qual posição no Journal?

Cada ferramenta responde perguntas diferentes.

E se o técnico chegar depois do problema?

Aí o USN pode ficar especialmente interessante.

Imagine que um usuário diga:

“Ontem alguma coisa renomeou centenas de arquivos.”

O Process Monitor não estava aberto ontem.

Logo, ele não pode simplesmente voltar no tempo.

O Change Journal, por ser persistente, pode ainda conter registros relacionados às mudanças.

Se os registros ainda estiverem dentro da janela disponível, eles podem fornecer pistas sobre:

criações
renomeações
exclusões
alterações

ocorridas anteriormente.

Mas devemos sempre lembrar:

persistente
≠
infinito

USN Journal como ferramenta forense: cuidado com exageros

O USN Journal pode aparecer em ferramentas de análise forense porque mantém informações muito úteis sobre atividade no sistema de arquivos.

Mas isso não significa que seja uma fonte perfeita ou completa.

Existem várias limitações:

registros antigos podem desaparecer
Journal pode ser recriado
eventos podem ser consolidados
não há conteúdo anterior do arquivo
não há necessariamente identidade do processo
não há necessariamente identidade do usuário

Portanto, uma análise séria combina diversas fontes de evidência.

Não conclua autoria apenas pelo horário

Imagine:

14:30
arquivo alterado

e você sabe que um usuário estava usando o computador às 14:30.

Isso não prova automaticamente que aquela pessoa realizou a mudança.

Um serviço em segundo plano também poderia ter alterado o arquivo.

Um antivírus poderia ter mexido em metadados.

Um programa poderia ter feito salvamento automático.

O USN fornece contexto técnico, não intenção.

E o Timestamp do registro?

Os registros USN podem conter informações de tempo.

Isso ajuda a organizar a sequência de alterações.

Mas novamente:

timestamp

deve ser interpretado junto com:

Reason
File Reference Number
Parent Reference
nome
contexto do sistema

A investigação fica muito mais confiável quando não dependemos de um único campo.

Como investigar centenas de arquivos renomeados?

Imagine um cenário:

foto1.jpg → foto1.xyz
foto2.jpg → foto2.xyz
foto3.jpg → foto3.xyz
...

O técnico poderia procurar padrões como:

RENAME_OLD_NAME
RENAME_NEW_NAME

em uma janela de USNs próxima ao horário do incidente.

Isso pode ajudar a confirmar que houve uma sequência massiva de renomeações.

Mas para identificar o processo responsável, provavelmente serão necessárias outras evidências.

Como diferenciar exclusão de renomeação?

Se encontramos somente:

FILE_DELETE

a interpretação é diferente de encontrar uma sequência relacionada a:

RENAME_OLD_NAME
RENAME_NEW_NAME

Esse tipo de distinção evita conclusões erradas.

Um arquivo que “sumiu” do caminho original pode ter:

sido excluído

ou:

sido renomeado

ou:

sido movido

O Journal pode fornecer pistas importantes para separar essas possibilidades.

E se o arquivo foi substituído por outro com o mesmo nome?

Esse é um cenário especialmente interessante.

Imagine:

relatorio.txt

sendo excluído.

Logo depois outro arquivo é criado com o mesmo nome:

relatorio.txt

Para o usuário, parece que:

o arquivo continua ali

Mas internamente podemos estar diante de objetos diferentes.

Aí o:

File Reference Number

se torna extremamente útil.

Mesmo nome não significa necessariamente o mesmo objeto NTFS.

Isso explica alguns comportamentos estranhos de programas

Alguns aplicativos acompanham arquivos não apenas pelo caminho, mas também por identificadores internos.

Por isso, substituir um arquivo por outro com o mesmo nome pode produzir comportamento diferente de simplesmente editar o arquivo original.

Exemplo conceitual:

arquivo A
nome: relatorio.txt
ID interno: 100

Depois:

arquivo B
nome: relatorio.txt
ID interno: 900

Visualmente:

mesmo nome

Internamente:

objeto diferente

USN e arquivos temporários

Muitos programas não salvam documentos simplesmente sobrescrevendo o arquivo original.

Uma estratégia comum é algo semelhante a:

criar arquivo temporário
      ↓
gravar conteúdo novo
      ↓
fechar
      ↓
substituir arquivo antigo
      ↓
renomear

Por isso, ao analisar o Journal durante o salvamento de um documento, podemos encontrar muito mais atividade do que o usuário imagina.

Ele clicou:

Salvar

Mas o sistema de arquivos pode registrar uma sequência bem mais complexa.

Salvar um Word não significa uma única gravação

Esse conceito vale para vários aplicativos.

O usuário vê:

Ctrl + S

Mas o programa pode executar:

criação temporária
escrita
metadados
renomeação
substituição
exclusão

Isso é outro motivo para não interpretar cada evento USN isoladamente.

O contexto da aplicação importa.

Como um técnico pode usar isso sem virar analista forense?

Não precisamos transformar cada atendimento em uma investigação de baixo nível.

O USN é útil quando existe uma pergunta específica.

Exemplos:

esse arquivo foi realmente renomeado?
houve exclusão?
houve sobrescrita?
o objeto é o mesmo ou foi recriado?
o Journal foi reiniciado?
o programa perdeu continuidade incremental?

Se a pergunta for simplesmente:

“Meu computador está lento.”

o USN Journal provavelmente não é o primeiro lugar onde devemos olhar.

Quando o USN não é a ferramenta certa

Não use o Change Journal como primeira ferramenta para:

Internet lenta
Wi-Fi caindo
temperatura alta
CPU em 100%
aplicativo travando
erro de tela azul
SSD com SMART ruim

Esses problemas exigem outros diagnósticos.

O valor do USN está em problemas relacionados à:

atividade de arquivos e diretórios

Diagnóstico VMIA: sequência prática para investigar alteração em arquivo

Quando existe suspeita de alteração inesperada, uma sequência organizada pode ser:

1. identificar o volume
2. verificar se ele utiliza NTFS
3. consultar o estado do Journal
4. anotar Journal ID
5. observar First Usn e Next Usn
6. localizar a janela temporal relevante
7. procurar o arquivo ou objeto
8. analisar Reason
9. comparar File Reference Number
10. correlacionar com logs e outras ferramentas

Essa ordem evita começar com conclusões antes de entender o estado do sistema.

Passo 1: identificar o volume

No PowerShell:

Get-Volume

Confirme:

DriveLetter
FileSystem

Se o arquivo estiver em:

D:

não adianta analisar somente o Journal de:

C:

Passo 2: verificar o Journal

Execute:

fsutil usn queryjournal D:

Observe principalmente:

Usn Journal ID
First Usn
Next Usn

Esses campos ajudam a entender se existe continuidade suficiente para aquela investigação.

Passo 3: não altere o sistema antes de coletar informações

Um erro comum é começar executando:

limpeza
reindexação
deletejournal
CHKDSK sem necessidade
programas de otimização

antes de observar o estado.

Cada mudança pode gerar novos registros e aumentar o ruído da investigação.

Primeiro:

observe

Depois:

interprete

Só então:

modifique

se realmente necessário.

Passo 4: combine com outras fontes

Se existe suspeita de programa específico, examine:

Visualizador de Eventos
logs do aplicativo
Process Monitor
Histórico do Defender
Agendador de Tarefas

dependendo do caso.

O USN não precisa responder tudo sozinho.

Um exemplo de interpretação errada

Imagine que encontramos:

BASIC_INFO_CHANGE

e imediatamente concluímos:

“Alguém editou o conteúdo.”

Isso pode estar errado.

Agora imagine:

DATA_OVERWRITE

e concluímos:

“O usuário X editou o arquivo.”

Também pode estar errado.

O primeiro registro indica tipo de mudança.

O segundo não necessariamente identifica autoria.

Diagnóstico técnico exige separar:

o que aconteceu

de:

quem fez

Outro erro: achar que FILE_DELETE significa perda definitiva

O registro:

FILE_DELETE

indica que o objeto foi excluído daquele contexto NTFS.

Isso não responde automaticamente:

arquivo ainda está na Lixeira?
existe backup?
há cópia na nuvem?
há versão anterior?

Essas são outras camadas.

O Journal registra o evento.

Não determina todas as possibilidades de recuperação.

Outro erro: acreditar que o Journal guarda o conteúdo

Mesmo depois de três partes deste artigo, vale reforçar.

Se o Journal mostra:

DATA_OVERWRITE

ele não fornece automaticamente:

dados antigos

nem:

dados novos completos

Ele registra o tipo de alteração.

Não funciona como sistema de versionamento.

Outro erro: considerar todos os Reason como eventos independentes

Os motivos podem ser combinados.

Um registro pode conter mais de um sinalizador.

Exemplo:

DATA_OVERWRITE
BASIC_INFO_CHANGE
CLOSE

Portanto, um analisador precisa interpretar os bits combinados em vez de imaginar que cada linha representa uma ação única e isolada.

Outro erro: esperar um log perfeito desde a instalação do Windows

O Change Journal possui limites.

Registros antigos podem desaparecer.

O Journal pode ser:

removido
recriado
redimensionado

Além disso, uma aplicação pode perder a janela necessária para sua leitura incremental.

Por isso ele não é equivalente a:

histórico completo de toda a vida do computador

E se First Usn avançou demais?

Imagine:

Último USN conhecido:
100000

Mas agora:

First Usn:
500000

O intervalo necessário já saiu da região disponível.

A conclusão correta não é:

“Nada aconteceu.”

A conclusão é:

“Não possuímos mais aqueles registros através deste Journal atual.”

Essa diferença é fundamental.

Ausência de registro disponível não prova ausência de evento.

O Journal pode ser usado para “vigiar” alguém?

Esse não é o objetivo adequado do mecanismo.

O USN é uma infraestrutura do NTFS para acompanhamento de mudanças no sistema de arquivos.

Seu uso técnico correto está relacionado a:

diagnóstico
indexação
backup
sincronização
administração
análise de alterações

e não a conclusões invasivas sobre comportamento pessoal.

O que um técnico realmente ganha entendendo USN?

Principalmente uma visão mais precisa de como o Windows gerencia arquivos.

Depois de entender o Change Journal, fica mais fácil compreender por que sistemas modernos conseguem:

indexar rapidamente
fazer backup incremental
acompanhar alterações
sincronizar diretórios
detectar renomeações
evitar varreduras completas constantes

Ele também ajuda a abandonar uma visão simplista de que o Windows trabalha apenas com:

nome
pasta
data
tamanho

Na prática, existe uma camada rica de metadados e identificadores.

Relação final entre MFT e USN Journal

Podemos resumir assim:

NTFS
 |
 +-- MFT
 |    ↓
 | registros e metadados
 | dos objetos
 |
 +-- USN Change Journal
      ↓
   histórico parcial
   de alterações

A MFT ajuda o NTFS a representar os objetos.

O Change Journal ajuda a acompanhar alterações nesses objetos.

Eles se complementam, mas não devem ser confundidos.

O USN Journal muda a forma de olhar para arquivos no Windows

Depois de conhecer esse mecanismo, situações aparentemente simples ganham novas perguntas.

Antes:

arquivo sumiu

Agora:

foi excluído?
foi renomeado?
foi movido?
foi substituído?

Antes:

arquivo mudou

Agora:

dados mudaram?
atributos mudaram?
segurança mudou?
houve compactação?

Antes:

arquivo tem o mesmo nome

Agora:

é realmente o mesmo objeto NTFS?

Esse é o principal valor técnico do USN Journal: transformar afirmações genéricas em perguntas muito mais precisas.

Conclusão

O USN Change Journal é uma das estruturas menos visíveis e mais interessantes do NTFS.

Enquanto o usuário enxerga arquivos e pastas no Explorer, o sistema de arquivos mantém um fluxo de registros que permite acompanhar alterações de maneira muito mais eficiente.

Comandos como:

fsutil usn queryjournal C:
fsutil usn readdata C:\caminho\arquivo.txt

e:

fsutil usn readjournal C:

permitem observar partes desse mecanismo diretamente no Windows 11.

Mas o verdadeiro valor não está em simplesmente executar os comandos.

Está em interpretar corretamente o que eles mostram.

O USN pode indicar:

criação
exclusão
renomeação
sobrescrita
ampliação
truncamento
mudança de atributos
mudança de segurança

mas não devemos confundi-lo com:

backup
Histórico de Arquivos
auditoria completa
Process Monitor
controle de versões

Também não devemos apagar o Journal como uma suposta “otimização”.

Ele existe justamente para permitir que programas acompanhem mudanças sem precisar reexaminar milhões de arquivos continuamente.

Entender esse mecanismo abre uma porta para compreender muito melhor como o Windows trabalha internamente com arquivos, indexação, backup, sincronização e metadados.

FAQ — USN Journal no Windows 11

O que é o USN Journal?
É o Change Journal do NTFS, um mecanismo que registra alterações ocorridas em arquivos e diretórios de um volume NTFS.

USN significa o quê?
USN significa Update Sequence Number.

Todo computador com Windows 11 possui USN Journal?
Ele está relacionado a volumes NTFS. É preciso consultar o volume específico para verificar seu estado.

Como verificar o USN Journal?

fsutil usn queryjournal C:

O USN Journal registra arquivos excluídos?
Ele pode registrar eventos relacionados à exclusão por meio de motivos como FILE_DELETE.

Consigo recuperar um arquivo excluído pelo USN Journal?
Não. O Journal não guarda automaticamente uma cópia completa do conteúdo excluído.

O USN Journal é um backup?
Não.

Ele guarda versões anteriores dos arquivos?
Não funciona como controle de versões.

Posso descobrir se um arquivo foi renomeado?
Registros podem incluir RENAME_OLD_NAME e RENAME_NEW_NAME.

Consigo descobrir quem renomeou o arquivo?
O USN Journal sozinho normalmente não fornece todas as informações necessárias para atribuir autoria.

O que significa DATA_OVERWRITE?
Indica uma alteração envolvendo sobrescrita de dados.

E BASIC_INFO_CHANGE?
Pode indicar alteração em metadados, atributos ou determinadas informações básicas do objeto.

Qual a diferença entre FILE_DELETE e RENAME?
São motivos diferentes. Uma exclusão não deve ser automaticamente confundida com uma renomeação.

O que é File Reference Number?
É uma referência interna relacionada à identificação do objeto no NTFS, associada à estrutura da MFT.

Dois arquivos com o mesmo nome podem ter File Reference Numbers diferentes?
Sim. Um arquivo pode ser excluído e outro criado posteriormente com o mesmo nome.

O USN Journal cresce para sempre?
Não. O NTFS gerencia seu tamanho e registros antigos podem deixar de estar disponíveis.

O que acontece quando registros antigos são removidos?
Aplicações que precisavam deles podem perder a continuidade incremental e precisar de uma nova varredura.

Posso apagar o USN Journal para liberar espaço?
O comando existe, mas não é uma prática recomendada como “limpeza”. Aplicações podem depender dele.

Apagar o Journal deixa o Windows mais rápido?
Não existe motivo técnico para tratar isso como uma otimização genérica. Em alguns casos, programas podem precisar realizar mais trabalho posteriormente.

Windows Search pode se beneficiar de Change Journals?
Mecanismos de indexação podem usar acompanhamento de alterações para evitar verificar novamente todo o sistema de arquivos.

Backup incremental pode usar USN?
Algumas soluções podem utilizar mecanismos de rastreamento de mudanças, dependendo da implementação do software.

O USN Journal mostra qual programa alterou o arquivo?
Não necessariamente. Para identificar processos, ferramentas como Process Monitor podem ser mais apropriadas.

USN Journal e MFT são a mesma coisa?
Não. A MFT representa objetos e metadados fundamentais do NTFS; o Change Journal acompanha alterações.

Posso usar fsutil usn readjournal C: em qualquer PC?
O comando existe no Windows, mas o volume precisa ser compatível e algumas operações podem exigir privilégios administrativos.

Por que readjournal mostra tanta coisa?
Porque o Windows e seus programas alteram arquivos constantemente em segundo plano.

É possível começar a leitura em um ponto específico?
Sim. O fsutil usn readjournal suporta parâmetros para iniciar a leitura a partir de determinado USN, o que ajuda a reduzir o volume de dados analisado.

O USN Journal é útil para técnicos?
Sim, principalmente em diagnósticos envolvendo arquivos criados, alterados, renomeados, substituídos ou excluídos.

VMIA

Se arquivos estão sendo alterados, renomeados ou excluídos sem uma causa aparente, simplesmente reinstalar programas ou executar ferramentas de limpeza pode esconder as pistas necessárias para descobrir o que realmente está acontecendo.

A VMIA – Manutenção e Configuração realiza diagnóstico técnico de computadores e notebooks Windows, análise de falhas do sistema, programas, armazenamento, desempenho e configurações do Windows.

Atendimento presencial ou por acesso remoto, conforme o tipo de problema.

VMIA – Manutenção e Configuração
Telefone e WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog técnico: https://vmia.com.br

Bibliografia técnica

Para a elaboração deste artigo, as principais referências técnicas são a documentação oficial da Microsoft sobre o USN Change Journal, estruturas USN_RECORD, motivos USN_REASON e o comando fsutil usn. A Microsoft documenta que os registros são acrescentados ao Change Journal quando objetos NTFS são modificados e que o diário fornece um histórico parcial das alterações, não uma cópia dos dados anteriores.

A documentação do fsutil usn também descreve os comandos queryjournal, readdata, readjournal, criação e exclusão do Journal, além dos parâmetros de capacidade e gerenciamento utilizados pelo NTFS.

Seja o primeiro a comentar

Faça um comentário

Seu e-mail não será publicado.


*