Você possui um arquivo de vídeo com 100 GB em uma pasta do Windows 11.
Ele está em:
D:\Videos\projeto.mkv
Você recorta o arquivo com:
Ctrl + X
e cola em:
D:\Arquivo\projeto.mkv
Surpreendentemente, a operação pode terminar quase instantaneamente.
Agora você pega exatamente o mesmo arquivo e copia:
D:\Videos\projeto.mkv
para:
E:\Backup\projeto.mkv
O Windows começa a mostrar:
Copiando...
A velocidade oscila entre centenas de megabytes por segundo e a operação demora vários minutos.
Surge uma pergunta interessante:
como o Windows conseguiu mover 100 GB praticamente instantaneamente na primeira operação?
O SSD realmente leu e gravou 100 GB em alguns segundos?
Normalmente, não.
O segredo está na diferença entre alterar a localização lógica de um arquivo dentro de um volume e transferir seus dados para outro volume.
Para entender essa diferença, precisamos entrar em uma parte do Windows que o usuário raramente enxerga:
o sistema de arquivos.
Mais especificamente, vamos entender como o NTFS organiza arquivos, diretórios, clusters e metadados.
O Explorer não enxerga o armazenamento como uma pilha de arquivos
Para o usuário, uma unidade parece bastante simples:
C:\
D:\
E:\
Dentro dela existem pastas.
Dentro das pastas existem arquivos.
Podemos imaginar:
D:\
↓
Videos
↓
projeto.mkv
Mas essa estrutura visual não significa que os bytes do arquivo estejam fisicamente “dentro” de uma pasta como documentos colocados dentro de uma gaveta.
Essa distinção é fundamental.
Uma pasta não é uma caixa física dentro do SSD
Quando você cria:
D:\Videos
o Windows não reserva necessariamente uma região física do SSD chamada “Videos” e passa a armazenar todos os arquivos daquela pasta naquela região.
O sistema de arquivos mantém estruturas de metadados que permitem organizar e localizar os arquivos.
Isso significa que a relação:
arquivo → pasta
é principalmente uma relação lógica mantida pelo sistema de arquivos.
O que é NTFS?
NTFS significa:
New Technology File System.
Ele é o principal sistema de arquivos utilizado pelo Windows em muitas instalações e unidades internas.
O NTFS precisa controlar muito mais do que simplesmente o conteúdo de um arquivo.
Ele mantém informações relacionadas a:
- nomes;
- diretórios;
- tamanho;
- localização dos dados;
- atributos;
- timestamps;
- permissões;
- identificadores;
- links;
- informações de segurança;
- alocação de armazenamento.
Essa organização permite ao Windows encontrar rapidamente um arquivo sem precisar vasculhar todo o SSD procurando seus bytes.
O arquivo possui dados e metadados
Essa separação ajuda a entender o restante do artigo.
Imagine:
projeto.mkv
O arquivo possui o conteúdo propriamente dito:
100 GB de vídeo
Mas o sistema de arquivos também precisa manter informações sobre esse arquivo.
Essas informações são os metadados.
Exemplos de metadados
Entre outras informações, podemos encontrar conceitos relacionados a:
nome
tamanho
atributos
timestamps
segurança
localização dos dados
relação com diretórios
Portanto:
o arquivo não é apenas seus 100 GB de conteúdo.
Existe uma estrutura que descreve esse arquivo.
É aqui que entra a MFT
No NTFS existe uma estrutura extremamente importante chamada:
Master File Table
ou:
MFT.
Podemos pensar nela como uma das estruturas centrais usadas pelo NTFS para registrar informações sobre arquivos e diretórios existentes no volume.
O que é $MFT?
A MFT possui registros associados aos objetos do sistema de arquivos.
Um arquivo pode ter informações armazenadas em atributos dentro de seu registro e, quando necessário, estruturas adicionais podem participar.
Não devemos imaginar a MFT simplesmente como:
uma planilha com uma linha para cada arquivo
porque a implementação real do NTFS é mais sofisticada.
Mas essa analogia ajuda inicialmente.
Imagine uma tabela conceitual
| Arquivo | Informações |
|---|---|
| foto.jpg | nome, atributos, localização dos dados… |
| trabalho.docx | nome, atributos, localização dos dados… |
| projeto.mkv | nome, atributos, localização dos dados… |
O ponto importante é:
o NTFS sabe onde os dados pertencentes ao arquivo estão localizados.
O arquivo não precisa estar fisicamente contíguo
Outro detalhe importante.
Um arquivo grande pode ocupar diferentes regiões do volume.
Conceitualmente:
Parte 1 → clusters A
Parte 2 → clusters B
Parte 3 → clusters C
O sistema de arquivos mantém as informações necessárias para localizar esses dados.
O que é um cluster?
Um cluster é uma unidade de alocação utilizada pelo sistema de arquivos.
O NTFS normalmente trabalha agrupando setores em unidades de alocação.
Quando um arquivo precisa armazenar dados, o sistema de arquivos aloca clusters.
Exemplo simplificado
Imagine um volume com clusters numerados:
1000
1001
1002
1003
…
Um arquivo pode utilizar uma sequência de clusters.
Arquivos maiores utilizam muito mais unidades de alocação.
O tamanho do cluster não é o tamanho do arquivo
Um arquivo de 100 GB utiliza uma enorme quantidade de clusters.
Mas isso não significa que o Windows precise mover todos esses clusters apenas porque você mudou o arquivo de uma pasta para outra.
Esse é o ponto central.
Vamos voltar ao nosso arquivo
Temos:
D:\Videos\projeto.mkv
com:
100 GB
Agora executamos:
Ctrl + X
e depois:
Ctrl + V
para:
D:\Arquivo\projeto.mkv
Observe:
origem:
D:
destino:
D:
Continuamos no mesmo volume.
O que significa mesmo volume?
Essa definição é mais importante do que simplesmente perguntar se usamos o mesmo computador.
Podemos ter:
C:
e:
D:
no mesmo computador, mas eles podem representar volumes diferentes.
Da mesma forma, partições diferentes do mesmo SSD físico continuam sendo volumes distintos.
Mesmo SSD não significa necessariamente mesmo volume
Imagine um SSD de 2 TB dividido em:
C: 500 GB
D: 1,5 TB
Fisicamente existe apenas um SSD.
Mas para o sistema de arquivos temos volumes diferentes.
Mover:
C:\arquivo.iso
para:
D:\arquivo.iso
não é equivalente a mover:
D:\Pasta1\arquivo.iso
para:
D:\Pasta2\arquivo.iso
Essa diferença é decisiva
Quando origem e destino pertencem ao mesmo volume NTFS, o sistema pode realizar a operação principalmente alterando informações do sistema de arquivos.
Ele não precisa necessariamente copiar todos os bytes para outra região apenas porque o caminho mudou.
O arquivo pode permanecer nos mesmos clusters
Essa é a chave.
Antes:
D:\Videos\projeto.mkv
Dados:
clusters X,Y,Z...
Depois:
D:\Arquivo\projeto.mkv
Os dados podem continuar associados aos mesmos clusters.
O que mudou principalmente foi a organização lógica e os metadados necessários para refletir a nova localização.
Por isso mover pode ser extremamente rápido
O Windows não precisou fazer:
ler 100 GB
↓
gravar 100 GB
↓
apagar 100 GB antigos
Ele pôde realizar uma operação muito menor sobre as estruturas do sistema de arquivos.
Uma analogia simples
Imagine uma biblioteca.
Existe um livro enorme guardado em uma estante.
O catálogo informa:
Livro X pertence à categoria Vídeos
Você decide mudar sua classificação para:
Arquivo
Existem duas maneiras hipotéticas.
Método 1
Copiar todas as páginas do livro para outro livro.
Isso seria extremamente trabalhoso.
Método 2
Alterar o catálogo indicando a nova classificação.
O livro físico pode permanecer onde já estava.
Mover um arquivo dentro do mesmo volume se aproxima mais da segunda ideia.
Isso significa que nada é escrito no SSD?
Não.
Metadados precisam ser atualizados.
O sistema de arquivos também possui mecanismos para manter consistência e registrar determinadas alterações.
Mas a quantidade de dados modificada pode ser minúscula quando comparada aos 100 GB do conteúdo do arquivo.
100 GB de arquivo não significa 100 GB de movimentação física
Essa frase merece destaque:
o tamanho lógico do arquivo não determina necessariamente a quantidade de dados que precisam ser transferidos durante uma movimentação dentro do mesmo volume.
E renomear um arquivo?
A mesma ideia ajuda a entender por que:
video.mkv
pode virar:
ferias-2026.mkv
praticamente instantaneamente.
O Windows não regrava o vídeo inteiro só porque o nome mudou.
Ele altera metadados relevantes.
Imagine renomear uma ISO de 150 GB
Se renomear exigisse reescrever todo o conteúdo, uma simples alteração de nome poderia demorar minutos.
Na prática, normalmente acontece quase instantaneamente.
Isso já oferece uma pista sobre a separação entre:
conteúdo
e:
metadados.
Mover dentro do mesmo volume é semelhante nesse aspecto
A alteração do caminho pode ocorrer sem transportar fisicamente todo o conteúdo.
Mas existe uma diferença entre renomear e mover?
Do ponto de vista do usuário, sim.
Renomear:
D:\Videos\a.mkv
para:
D:\Videos\b.mkv
Move:
D:\Videos\a.mkv
para:
D:\Arquivo\a.mkv
Em ambos os casos, o NTFS precisa atualizar estruturas relacionadas à organização do arquivo, mas o tipo exato de alteração nos metadados não é simplesmente idêntico.
O importante para nosso raciocínio é:
nenhuma das operações exige necessariamente regravar todos os dados do arquivo.
Agora compare com uma cópia
Origem:
D:\Videos\projeto.mkv
Destino:
E:\Backup\projeto.mkv
O volume E: precisa possuir seu próprio arquivo.
Isso significa que o conteúdo precisa chegar ao volume de destino.
Agora temos uma operação completamente diferente.
O sistema precisa ler e escrever os dados
Conceitualmente:
D: lê os dados
↓
Windows transfere
↓
E: grava os dados
↓
E: cria suas estruturas de sistema de arquivos
Para um arquivo de 100 GB, estamos realmente falando de uma quantidade enorme de dados.
Agora a velocidade do armazenamento importa
Se a origem consegue ler:
500 MB/s
e o destino consegue escrever:
100 MB/s
a operação não pode simplesmente copiar sustentadamente a 500 MB/s.
O destino representa um gargalo.
O dispositivo mais lento pode limitar a operação
Mas ainda existem outros fatores:
- interface;
- USB;
- SATA;
- NVMe;
- rede;
- cache;
- tipo de arquivo;
- antivírus;
- temperatura;
- cache SLC do SSD;
- protocolo;
- sistema de arquivos.
Por isso, a velocidade mostrada pelo Explorer pode variar bastante.
E se eu “mover” de D: para E:?
Aqui acontece algo que engana muitos usuários.
Você escolhe:
Recortar
em:
D:\arquivo.iso
e:
Colar
em:
E:\arquivo.iso
Visualmente, pediu uma movimentação.
Mas como os volumes são diferentes, o Windows não consegue simplesmente alterar a referência do arquivo dentro do mesmo sistema de arquivos.
O comportamento se aproxima de copiar e depois remover a origem
Conceitualmente:
copiar conteúdo para E:
↓
confirmar operação
↓
remover entrada original em D:
Por isso, mover entre volumes demora aproximadamente como uma transferência real de dados.
Mesmo se C: e D: estiverem no mesmo SSD?
Sim.
Se C: e D: forem volumes diferentes, existe uma fronteira de sistema de arquivos.
Isso parece estranho porque fisicamente o SSD é o mesmo
Mas o NTFS de C: não pode simplesmente dizer ao NTFS de D:
“aqueles clusters agora pertencem a você.”
Cada volume administra seu próprio espaço e suas próprias estruturas.
O arquivo precisa existir dentro da estrutura do volume de destino
Portanto, os dados precisam ser transferidos para clusters pertencentes ao destino.
Um teste simples demonstra isso
Crie ou utilize um arquivo grande.
Teste:
D:\Pasta1 → D:\Pasta2
Depois:
D:\Pasta1 → E:\Pasta2
Observe o tempo.
Se D: e E: forem volumes distintos, a diferença tende a ser enorme.
Não use documentos importantes no teste
Faça experimentos com arquivos descartáveis ou cópias.
E copiar dentro do mesmo volume?
Agora temos outra situação interessante.
Origem:
D:\Videos\projeto.mkv
Destino:
D:\Backup\projeto-copia.mkv
Estamos no mesmo volume.
Mas você pediu:
Copiar
e não:
Mover.
O NTFS precisa criar outra instância lógica do arquivo com seus próprios dados
Para uma cópia comum, o conteúdo precisa ser duplicado.
Portanto, mesmo dentro do mesmo volume, copiar um arquivo de 100 GB normalmente envolve ler e gravar uma quantidade correspondente de dados.
É por isso que mover e copiar na mesma unidade apresentam tempos completamente diferentes
Mover dentro do mesmo volume
Principalmente alterações de metadados.
Copiar dentro do mesmo volume
Leitura e gravação dos dados para criar a cópia.
Copiar dentro do mesmo SSD pode ser mais lento do que você espera
Agora o mesmo dispositivo pode precisar atender simultaneamente:
leitura da origem
e:
gravação do destino
Além disso, o SSD possui seus próprios limites internos.
SSD NVMe de 7.000 MB/s não significa cópia sustentada a 7.000 MB/s
Esse número de marketing normalmente representa uma condição específica de transferência sequencial.
Uma cópia real pode envolver:
- leitura;
- gravação;
- cache;
- sistema de arquivos;
- controlador;
- temperatura;
- fila;
- características da NAND.
Cache SLC também pode mudar a velocidade
Alguns SSDs conseguem gravar rapidamente enquanto existe cache disponível.
Depois, a velocidade sustentada pode cair.
Isso explica situações como:
2.500 MB/s
↓
1.400 MB/s
↓
600 MB/s
↓
300 MB/s
durante uma cópia grande.
Isso não significa automaticamente defeito.
Temperatura também pode interferir
Um NVMe pode reduzir desempenho quando atinge determinados limites térmicos.
Esse mecanismo é conhecido como:
thermal throttling.
Mas nada disso explica o movimento instantâneo
Esse é justamente o ponto.
Quando o arquivo é movido dentro do mesmo volume, muitas dessas limitações de transferência de dados deixam de ser o fator principal porque o conteúdo não precisa ser copiado fisicamente para outra região.
O tamanho do arquivo quase deixa de importar?
Para uma movimentação simples dentro do mesmo volume, o tamanho do conteúdo pode ter impacto muito menor do que teria em uma cópia.
Mover:
1 GB
ou:
100 GB
pode levar tempos surpreendentemente semelhantes em determinadas condições.
Isso não significa que qualquer movimentação será instantânea
Existem exceções e detalhes importantes.
Permissões, recursos especiais, software de segurança, sincronização, filtros do sistema de arquivos, características do destino e outros componentes podem influenciar a operação.
Vamos aprofundar isso nas próximas partes.
O primeiro diagnóstico: origem e destino estão no mesmo volume?
Quando alguém diz:
“Mover esse arquivo está demorando demais.”
a primeira pergunta deveria ser:
origem e destino pertencem ao mesmo volume?
Não:
“estão no mesmo computador?”
Nem:
“estão no mesmo SSD?”
A pergunta correta é:
“estão no mesmo volume?”
Exemplos
Caso A
C:\Downloads → C:\Videos
Mesmo volume C:.
Movimentação tende a ser principalmente uma operação de metadados.
Caso B
C:\Downloads → D:\Videos
Volumes diferentes.
Existe transferência real.
Caso C
D:\Pasta1 → D:\Pasta2
Mesmo volume D:.
Caso D
SSD físico único:
C: → D:
Mesmo SSD, mas volumes diferentes.
Transferência necessária.
Caso E
C: → pendrive E:
Volumes e dispositivos diferentes.
Transferência necessária.
Caso F
C: → \\NAS\Backup
Destino remoto.
Transferência pela rede.
O caminho revela muita coisa
Antes de executar benchmarks, trocar SSD ou culpar o Windows, observe:
origem
e:
destino.
Essa informação simples pode explicar por que uma operação demora dois segundos e outra leva vinte minutos.
O que já aprendemos
Até aqui:
- arquivos possuem conteúdo e metadados;
- pastas representam organização lógica, não caixas físicas no SSD;
- NTFS mantém estruturas que descrevem arquivos;
- a MFT é central para essa organização;
- arquivos utilizam clusters;
- mover dentro do mesmo volume não exige necessariamente transferir todo o conteúdo;
- copiar exige criar outra cópia dos dados;
- mover entre volumes exige transferência real;
- mesmo SSD físico pode conter volumes diferentes;
- renomear e mover podem ser rápidos porque trabalham principalmente com metadados;
- velocidade anunciada do SSD não determina diretamente o tempo de todas as operações.
MFT, clusters, Data Runs e o que o NTFS realmente altera quando movemos um arquivo
Na Parte 1 vimos que mover:
D:\Videos\projeto.mkv
para:
D:\Arquivo\projeto.mkv
pode acontecer quase instantaneamente mesmo que projeto.mkv tenha 100 GB.
O motivo principal é que origem e destino pertencem ao mesmo volume.
Os 100 GB não precisam necessariamente ser lidos e regravados.
Agora podemos aprofundar a pergunta:
se os dados continuam praticamente no mesmo lugar, o que o NTFS realmente altera?
Para responder, precisamos entender melhor a Master File Table, os atributos NTFS, os clusters e como o sistema de arquivos relaciona um nome visível no Explorer ao conteúdo armazenado na unidade.
A MFT é uma das estruturas centrais do NTFS
Em um volume NTFS existe um arquivo de metadados especial conhecido como:
$MFT
MFT significa:
Master File Table.
Arquivos e diretórios possuem registros relacionados na MFT.
Isso permite que o NTFS mantenha informações necessárias para localizar e interpretar cada objeto.
Um registro da MFT contém atributos
O NTFS é fortemente baseado em atributos.
Conceitualmente, um registro pode conter informações relacionadas a:
- informações padrão;
- nome;
- dados;
- segurança;
- índices;
- outros atributos NTFS.
Os detalhes dependem do objeto e de sua estrutura.
$STANDARD_INFORMATION
Um atributo importante contém informações padrão do arquivo, incluindo determinados timestamps e flags.
$FILE_NAME
Outro atributo importante está relacionado ao nome do arquivo e à sua relação com o diretório pai.
Esse ponto é particularmente interessante para nosso artigo.
$DATA
O conteúdo de um arquivo comum está relacionado ao atributo:
$DATA
Para arquivos pequenos, determinadas informações podem caber dentro do próprio registro.
Para arquivos grandes, os dados ficam fora da MFT e o atributo precisa indicar como localizá-los.
Isso nos leva a dois conceitos importantes
atributos residentes
e:
atributos não residentes.
O que é um atributo residente?
Quando determinado atributo é pequeno o suficiente, seus dados podem ficar armazenados dentro do próprio registro da MFT.
Chamamos isso de:
resident attribute.
Isso pode acontecer até com o conteúdo de arquivos muito pequenos
Em determinadas situações, um arquivo minúsculo pode ter seu conteúdo $DATA armazenado de forma residente.
Isso significa que seus poucos bytes podem ficar diretamente associados ao registro da MFT em vez de exigir clusters separados para o conteúdo.
Mas nosso arquivo de 100 GB obviamente não cabe na MFT
Exatamente.
Um arquivo:
projeto.mkv
com:
100 GB
precisa armazenar seus dados em clusters do volume.
Seu atributo $DATA é não residente.
O que significa não residente?
Significa que o conteúdo não está armazenado diretamente dentro daquele atributo no registro da MFT.
O NTFS mantém informações que permitem localizar os clusters onde os dados estão.
Como o NTFS sabe onde estão esses clusters?
Aqui entra um conceito interessante:
Data Runs, também chamados em alguns contextos de Runlists.
O que são Data Runs?
Em vez de manter uma lista gigantesca dizendo:
cluster 100
cluster 101
cluster 102
cluster 103
…
o NTFS pode descrever sequências de clusters de maneira mais eficiente.
Exemplo conceitual
Imagine que uma parte do arquivo ocupa:
cluster 1000 até 1999
Em vez de registrar mil números individualmente, podemos representar uma sequência.
Depois outra parte pode ocupar:
cluster 5000 até 5999
Temos outra sequência.
Por que existiriam várias sequências?
Uma razão possível é fragmentação.
O arquivo pode não possuir todo seu conteúdo em uma única sequência física contínua de clusters.
Exemplo simplificado
projeto.mkv
pode possuir dados em:
10000–19999
depois:
40000–49999
depois:
80000–89999
O sistema de arquivos conhece essas extensões e consegue reconstruir logicamente o conteúdo.
Fragmentação não significa arquivo quebrado
Esse é outro erro comum.
Um arquivo fragmentado não está necessariamente corrompido.
Se os metadados estão corretos, o NTFS sabe onde encontrar cada parte.
Agora aparece uma consequência importante
Imagine que nosso arquivo de 100 GB esteja bastante fragmentado.
Mesmo assim, movemos:
D:\Videos\projeto.mkv
para:
D:\Arquivo\projeto.mkv
Ele pode continuar sendo movido rapidamente.
Por quê?
Porque o NTFS não precisa reorganizar fisicamente todas as extensões do arquivo apenas para mudar sua localização lógica entre diretórios.
Os dados podem permanecer nos mesmos clusters.
Mover não significa desfragmentar
Essa frase é importante:
mover um arquivo dentro do mesmo volume não significa automaticamente reorganizar fisicamente seus dados.
Portanto, a nova pasta não determina a posição física
Se você move:
D:\A\arquivo.bin
para:
D:\Z\arquivo.bin
isso não significa que os dados precisam ir para uma região do SSD “reservada para a pasta Z”.
Essa região conceitual não existe dessa forma.
Então o que é uma pasta para o NTFS?
Diretórios também são objetos administrados pelo sistema de arquivos.
Eles mantêm estruturas que permitem relacionar nomes aos arquivos e subdiretórios que contêm.
Diretórios podem utilizar índices
O NTFS possui mecanismos de indexação para diretórios.
Isso permite localizar entradas de forma eficiente, principalmente quando existem muitos arquivos.
Imagine uma pasta com 500 mil arquivos
Seria pouco eficiente tratar qualquer busca como uma leitura linear simples de 500 mil nomes.
As estruturas de índice ajudam o NTFS a administrar diretórios grandes.
Então mover um arquivo entre pastas envolve alterar relações de diretório
Conceitualmente, temos:
Diretório A
contém referência ao:
arquivo X
Depois da movimentação:
Diretório B
passa a conter a referência apropriada ao:
arquivo X
Enquanto isso, o conteúdo de $DATA pode continuar apontando para as mesmas regiões alocadas.
É isso que torna a operação tão barata em comparação à cópia
Compare.
Mover dentro do volume
Precisamos principalmente atualizar estruturas e metadados.
Copiar
Precisamos criar um novo arquivo e transferir seu conteúdo.
O tamanho dos metadados é muito menor que o conteúdo
Nosso arquivo:
100 GB
Pode exigir alterações relativamente pequenas de metadados para uma movimentação dentro do mesmo volume.
A diferença de escala é enorme.
É por isso que arquivos gigantes podem “mover” em segundos
O Explorer não está fingindo.
O arquivo realmente mudou de caminho lógico.
Mas isso não significa que seus 100 GB tenham sido fisicamente transportados para outra região do SSD.
E se eu apenas renomear?
Considere:
D:\Videos\filme.mkv
para:
D:\Videos\filme-final.mkv
O conteúdo continua exatamente o mesmo.
O NTFS precisa refletir a alteração de nome nos metadados relevantes.
Renomear 1 KB ou 100 GB pode levar tempo semelhante
Porque o conteúdo não precisa ser reescrito.
Isso vale para extensão?
Imagine:
arquivo.txt
renomeado para:
arquivo.bin
Do ponto de vista do sistema de arquivos, estamos alterando o nome.
O Windows não converte magicamente o conteúdo.
Trocar extensão não converte formato
Essa observação é importante.
Renomear:
foto.jpg
para:
foto.png
não transforma JPEG em PNG.
O conteúdo permanece o mesmo.
Agora vamos falar de permissões NTFS
Mover e copiar arquivos também podem produzir diferenças relacionadas a permissões.
Isso acontece porque as operações não são equivalentes.
Permissões NTFS são armazenadas como metadados
Como vimos no artigo da VMIA sobre SID, o Windows trabalha com descritores de segurança, ACLs e identificadores de segurança para controlar acesso.
Isso significa que permissões também fazem parte do contexto de metadados.
O que pode acontecer ao mover dentro do mesmo volume?
Tradicionalmente, uma movimentação dentro do mesmo volume tende a preservar o descritor de segurança existente do objeto, porque estamos essencialmente mantendo o mesmo objeto e alterando sua localização lógica.
E ao copiar?
Uma cópia cria um novo objeto no destino.
Nesse caso, as regras de segurança do destino e de herança podem participar da criação do novo arquivo.
Exemplo conceitual
Origem:
D:\Restrito\relatorio.xlsx
Possui permissões específicas.
Copiamos para:
D:\Publico\relatorio.xlsx
O arquivo criado no destino pode receber permissões conforme as regras aplicáveis à criação e herança naquele diretório.
Mover e copiar podem, portanto, gerar resultados diferentes
Isso surpreende usuários que pensam:
“O conteúdo é o mesmo, então as permissões também deveriam ser.”
Mas um arquivo movido e um arquivo copiado não necessariamente representam a mesma operação para o sistema de arquivos.
E mover entre volumes?
Agora precisamos lembrar:
mover entre volumes se comporta conceitualmente como:
copiar
remover origem
Portanto, o objeto do destino precisa ser criado no novo volume.
As permissões podem mudar
Principalmente quando:
- volumes possuem configurações diferentes;
- diretórios possuem ACLs diferentes;
- existe herança;
- destino utiliza outro sistema de arquivos.
FAT32 e exFAT complicam ainda mais
Esses sistemas de arquivos não oferecem o mesmo modelo de segurança NTFS.
Se copiamos um arquivo NTFS para FAT32, determinados metadados NTFS simplesmente não possuem equivalente direto.
Um pendrive FAT32 não carrega toda a ACL NTFS como o volume original
Esse é um exemplo de por que:
copiar um arquivo não significa copiar absolutamente todas as características internas do objeto.
E os timestamps?
Arquivos também possuem informações de tempo.
Entre elas podem existir conceitos como:
- criação;
- modificação;
- acesso;
- outras informações internas relacionadas ao NTFS.
Copiar e mover podem afetar timestamps de maneiras diferentes
Como uma movimentação dentro do volume mantém essencialmente o mesmo objeto, o comportamento não é necessariamente igual ao de criar uma nova cópia em outro destino.
Além disso, APIs, programas e sistemas de arquivos podem influenciar quais timestamps são preservados.
Por isso timestamps não devem ser interpretados sem contexto
Se você precisa fazer análise forense ou auditoria, simplesmente olhar:
Data de criação
sem conhecer o histórico de cópia/movimentação pode produzir conclusões erradas.
Agora um detalhe muito interessante: Hard Links
O NTFS suporta Hard Links.
Isso significa que mais de um nome de arquivo pode se referir aos mesmos dados associados ao mesmo registro de arquivo.
Exemplo conceitual
D:\A\arquivo.txt
e:
D:\B\outro-nome.txt
podem ser hard links para o mesmo arquivo subjacente.
Não estamos falando de duas cópias comuns dos dados.
Isso quebra a ideia intuitiva de “um nome = um conjunto exclusivo de bytes”
No NTFS, a realidade pode ser mais interessante.
Apagar um Hard Link não necessariamente apaga os dados
Se ainda existe outro link válido para o arquivo, os dados continuam acessíveis por ele.
Esse assunto merece um post próprio, porque envolve MFT, link count e diferenças para links simbólicos.
Hard Links normalmente precisam permanecer no mesmo volume
Isso faz sentido quando entendemos que eles estão relacionados ao mesmo objeto dentro daquele sistema de arquivos.
Você não cria um Hard Link NTFS atravessando volumes como se os dois sistemas de arquivos compartilhassem a mesma MFT.
Mais uma prova da importância da fronteira do volume
Vários comportamentos mudam quando atravessamos:
C: → D:
ou:
D: → E:
Mesmo quando tudo está fisicamente no mesmo SSD.
E os links simbólicos?
O Windows também suporta links simbólicos.
Mas um Symbolic Link não funciona da mesma forma que Hard Link.
Ele é uma referência que aponta para outro caminho.
Junction Points
O NTFS também suporta Junctions.
Eles aparecem bastante em estruturas do próprio Windows e em compatibilidade entre caminhos.
Reparse Points
Links simbólicos e Junctions estão relacionados ao mecanismo de Reparse Points do NTFS.
Esse mecanismo permite que determinados objetos recebam tratamento especial.
Por que isso importa ao copiar diretórios?
Porque uma ferramenta precisa decidir como tratar um link.
Ela pode:
- copiar o link;
- seguir o link;
- copiar o conteúdo apontado;
- preservar determinado Reparse Point;
- não suportar aquele recurso.
Um diretório aparentemente pequeno pode apontar para outro lugar
Imagine:
D:\Dados\Link
apontando para:
E:\ArquivosGigantes
Uma ferramenta mal configurada pode seguir o link e acabar copiando muito mais dados do que o usuário imaginava.
Isso também pode gerar loops
Links e estruturas de diretório precisam ser tratados corretamente para evitar recursões indesejadas.
Ferramentas modernas possuem mecanismos para lidar com essas situações, mas o comportamento depende da operação.
Explorer e Robocopy não precisam tratar tudo exatamente da mesma forma
Ferramentas diferentes podem utilizar opções e estratégias diferentes para:
- timestamps;
- ACLs;
- links;
- Reparse Points;
- atributos;
- retries;
- arquivos abertos.
Robocopy é particularmente interessante
O Windows inclui:
robocopy
Essa ferramenta oferece controle muito maior sobre operações de cópia.
Por exemplo, ela pode ser utilizada para preservar diferentes tipos de metadados conforme as opções escolhidas.
Isso significa que “copiar” não é uma operação única universal
O resultado depende:
- da API;
- da ferramenta;
- das opções;
- do sistema de arquivos de origem;
- do sistema de arquivos de destino.
O que significa apagar a origem depois de mover entre volumes?
Considere:
D:\arquivo.iso
movido para:
E:\arquivo.iso
Como vimos, os dados precisam ser copiados para E:.
Depois que a operação chega ao ponto apropriado, a origem pode ser removida.
Remover um arquivo também não significa zerar imediatamente todos os seus antigos clusters
Outro conceito importante.
Quando um arquivo é excluído normalmente, o sistema de arquivos atualiza suas estruturas para indicar que aquele espaço pode voltar a ser utilizado.
Isso não equivale necessariamente a sobrescrever imediatamente cada byte antigo com zeros.
SSD acrescenta outra camada: TRIM
Em SSDs, o sistema operacional e o dispositivo podem trabalhar com comandos como TRIM para informar que determinados blocos lógicos não contêm mais dados necessários ao sistema de arquivos.
O controlador do SSD administra internamente a NAND.
Não confunda TRIM com “apagamento seguro instantâneo”
São conceitos diferentes.
TRIM ajuda o SSD a saber que determinados dados não precisam mais ser preservados da perspectiva do sistema de arquivos.
Isso não deve ser interpretado como garantia forense de sobrescrita física imediata de cada célula.
Isso se conecta ao FTL
No artigo anterior da VMIA sobre Flash Translation Layer, vimos que o endereço lógico visto pelo sistema não corresponde diretamente a uma posição fixa de célula NAND.
O controlador mantém seu próprio mapeamento.
Por isso, falar em:
“o arquivo estava fisicamente exatamente naquele setor da NAND”
fica ainda mais complicado em SSDs.
NTFS trabalha com endereços lógicos
Enquanto isso, o controlador do SSD administra:
- NAND;
- páginas;
- blocos;
- Garbage Collection;
- Wear Leveling;
- remapeamentos.
São camadas diferentes.
Podemos visualizar a pilha
Arquivo
↓
NTFS
↓
clusters / endereços lógicos
↓
volume
↓
armazenamento
↓
controlador SSD
↓
FTL
↓
NAND
Isso ajuda a entender por que a “posição física do arquivo” não é tão simples quanto parece.
Mover uma pasta inteira também pode ser muito rápido
Imagine:
D:\Projetos
com:
600 GB
Movemos para:
D:\Arquivo\Projetos
Se tudo permanece no mesmo volume e não existem fatores especiais, a operação pode ser extremamente rápida em comparação com copiar 600 GB.
O Windows não precisa transportar 600 GB
Ele precisa atualizar a organização necessária para que aquele diretório passe a aparecer no novo local.
Mas e milhares ou milhões de arquivos?
Agora existe uma diferença interessante.
Uma pasta com:
1 arquivo de 100 GB
e outra com:
1 milhão de arquivos pequenos
podem ter o mesmo tamanho total.
Mesmo dentro do mesmo volume, operações envolvendo enormes quantidades de objetos podem exigir muito mais trabalho de metadados.
Quantidade de arquivos importa
Porque cada arquivo possui suas próprias estruturas e informações.
É por isso que “100 GB” não conta toda a história
Compare:
Pasta A
1 × 100 GB
Pasta B
1.000.000 × 100 KB
Ambas podem possuir aproximadamente a mesma ordem de grandeza de dados.
Mas o comportamento operacional pode ser completamente diferente.
Arquivos pequenos geram muito overhead
Cada arquivo pode envolver:
- abertura;
- criação;
- metadados;
- diretórios;
- segurança;
- timestamps;
- fechamento.
Durante cópia entre volumes, isso pesa bastante.
Por isso copiar 100 GB em milhões de arquivos pode ser muito mais lento que copiar um arquivo único de 100 GB
Mesmo no mesmo SSD.
Antivírus também pode aumentar o custo
Cada novo arquivo pode passar por análise de segurança.
Um arquivo único significa um objeto grande.
Milhares de arquivos significam milhares de eventos de criação e abertura.
O sistema de arquivos não trabalha sozinho
Durante uma operação real podem participar:
- Explorer;
- NTFS;
- cache do Windows;
- drivers;
- filtros de sistema de arquivos;
- antivírus;
- backup;
- sincronização;
- armazenamento.
Minifilter drivers
Antivírus, backup, criptografia e outras soluções podem utilizar file system minifilter drivers para observar ou participar de operações de arquivo.
Isso explica por que duas máquinas com o mesmo SSD podem apresentar comportamento diferente.
fltmc
Administradores podem usar:
fltmc
para visualizar filtros instalados.
Mas a presença de um filtro não significa automaticamente que ele seja culpado por lentidão.
Precisamos de correlação
Se uma cópia fica lenta:
- meça;
- compare;
- teste;
- altere uma variável;
- meça novamente.
Por que a cópia começa rápida e depois fica lenta? Cache, SSD, USB, rede e arquivos pequenos
Até aqui vimos que existe uma diferença fundamental entre:
mover dentro do mesmo volume
e:
copiar dados.
Agora vamos analisar outra dúvida extremamente comum:
por que uma cópia começa a 2 GB/s e, alguns segundos depois, cai para 500 MB/s, 200 MB/s ou menos?
Esse comportamento é muito comum em SSDs, pendrives, HDs externos, NAS e até transferências entre unidades NVMe.
A resposta quase nunca está em uma única causa.
A velocidade de cópia depende de toda a cadeia:
origem
↓
interface
↓
controlador
↓
cache
↓
sistema de arquivos
↓
destino
Além disso, o tipo e a quantidade de arquivos também podem mudar completamente o resultado.
Velocidade inicial não é necessariamente velocidade sustentada
Esse é um dos primeiros conceitos que precisamos separar.
Um SSD pode anunciar:
3.500 MB/s
ou:
7.000 MB/s
Mas isso não significa que ele escreverá um arquivo de 500 GB inteiro nessa velocidade.
Muitas unidades apresentam desempenho muito alto em rajadas e depois reduzem.
Por que isso acontece?
Existem várias razões possíveis.
Uma das principais é:
cache.
Cache pode existir em diferentes camadas
Durante uma cópia, podem participar:
- cache do Windows;
- DRAM do SSD;
- cache SLC;
- buffers do controlador;
- cache do dispositivo de destino.
Portanto, não existe apenas “um cache”.
O que é cache SLC?
Muitos SSDs TLC e QLC utilizam parte da NAND de forma temporária como se fosse SLC.
Esse recurso é frequentemente chamado de:
pseudo-SLC cache
ou:
SLC cache.
A ideia é melhorar o desempenho de gravação em rajadas.
Como isso afeta uma cópia?
Imagine que um SSD grave inicialmente:
2.500 MB/s
Enquanto o cache possui espaço.
Depois de preencher essa área, ele precisa gravar diretamente na NAND em seu modo normal.
A velocidade pode cair para:
1.000 MB/s
600 MB/s
ou até menos, dependendo da unidade.
Isso não significa necessariamente que o SSD estragou
Pode ser comportamento normal do projeto.
É por isso que testes curtos e cópias reais longas podem mostrar números completamente diferentes.
TLC e QLC podem ter comportamento muito diferente depois do cache
Em geral, QLC costuma depender ainda mais de cache para atingir velocidades altas de gravação.
Quando o cache esgota, o desempenho sustentado pode cair bastante.
Mas não devemos classificar todo SSD QLC como “ruim” por isso.
O desempenho real depende do controlador, firmware, quantidade de NAND, capacidade livre, workload e projeto do fabricante.
Quanto espaço livre também pode influenciar
Em alguns SSDs, o cache dinâmico depende da quantidade de espaço livre.
Uma unidade quase cheia pode ter menos flexibilidade.
Exemplo
SSD com:
2 TB
Livre:
1,5 TB
pode ter comportamento diferente de:
o mesmo SSD com:
40 GB livres.
Isso significa que SSD cheio sempre fica lento?
Não.
Mas pouco espaço pode influenciar diferentes mecanismos internos, inclusive cache e Garbage Collection.
E o FTL?
O controlador do SSD usa o Flash Translation Layer para mapear endereços lógicos para NAND.
Esse mecanismo também participa de:
- Garbage Collection;
- Wear Leveling;
- remapeamentos;
- gerenciamento de páginas e blocos.
Por isso, a velocidade real de gravação não depende apenas da interface PCIe.
Um NVMe Gen4 de 7 GB/s pode copiar a 800 MB/s?
Pode.
Isso não é contraditório.
O número de 7 GB/s pode refletir leitura ou escrita sequencial em condições específicas de benchmark.
Uma cópia real pode envolver:
- leitura e gravação simultâneas;
- cache esgotado;
- temperatura;
- sistema de arquivos;
- origem lenta;
- destino lento;
- arquivos pequenos.
O gargalo sempre está no elo mais lento
Imagine:
Origem:
NVMe = 5 GB/s
Destino:
SSD SATA = 500 MB/s
A transferência não será sustentada a 5 GB/s.
O SSD SATA limita a cadeia.
Outro exemplo
Origem:
SSD SATA = 500 MB/s
Destino:
NVMe = 5 GB/s
Agora a origem pode limitar.
Copiar dentro do mesmo SSD é um caso especial
Imagine:
D:\arquivo.iso
para:
D:\Backup\arquivo.iso
Mesmo volume e mesmo SSD.
Como é cópia, os dados precisam ser duplicados.
O mesmo dispositivo precisa:
ler
e:
gravar
quase ao mesmo tempo.
Isso pode reduzir o throughput
O controlador precisa dividir recursos entre leitura e gravação.
Além disso, a NAND precisa lidar com operações concorrentes.
Por isso copiar dentro do mesmo SSD pode ser mais lento do que copiar entre dois SSDs rápidos
Se usamos:
SSD 1 → SSD 2
cada unidade pode se concentrar em uma função principal.
Uma lê.
A outra grava.
Em dois NVMe rápidos, o barramento também importa
Podemos ter:
- lanes PCIe compartilhadas;
- chipset;
- CPU;
- topologia da placa-mãe;
- slots M.2 com limitações diferentes.
Nem todo slot M.2 oferece a mesma largura de banda
Em algumas placas-mãe:
- um slot vem diretamente da CPU;
- outro passa pelo chipset;
- outro compartilha lanes;
- outro pode reduzir portas SATA ou slots PCIe.
Por isso, “ambos são NVMe” não encerra o diagnóstico.
Temperatura pode reduzir a velocidade
SSDs NVMe trabalham em alta velocidade e podem aquecer bastante.
Quando atingem limites térmicos definidos pelo controlador, podem reduzir desempenho.
Isso é:
thermal throttling.
Como identificar?
Ferramentas de monitoramento podem mostrar:
- temperatura;
- velocidade;
- utilização;
- sensores do NVMe.
Se a velocidade cai exatamente quando a temperatura sobe para determinada faixa, existe uma correlação útil.
Não conclua apenas por uma temperatura isolada
O importante é observar:
tempo
temperatura
velocidade
e:
momento da queda.
HDD possui outra limitação
Discos rígidos mecânicos dependem de:
- rotação;
- movimento das cabeças;
- posição física dos dados;
- fragmentação;
- busca.
Isso muda completamente o comportamento.
Um HDD pode copiar um arquivo grande relativamente bem
Arquivos sequenciais grandes favorecem o acesso contínuo.
Mas milhares de arquivos pequenos podem destruir o desempenho
Agora o disco precisa alternar entre muitas operações.
Isso aumenta seek e overhead.
Compare
Um arquivo
100 GB
Um milhão de arquivos
100 KB cada
Mesmo total aproximado.
O tempo pode ser muito diferente.
SSD também sofre com arquivos pequenos
Mesmo sem partes mecânicas.
Isso acontece por causa de:
- metadados;
- abertura e fechamento;
- criação de arquivos;
- diretórios;
- antivírus;
- fila;
- operações aleatórias.
IOPS passa a importar mais
Para arquivos grandes sequenciais, throughput em MB/s costuma ser muito importante.
Para milhares de arquivos pequenos, IOPS e latência ganham peso.
Por isso benchmark sequencial não prevê tudo
CrystalDiskMark pode mostrar:
SEQ1M: 5.000 MB/s
Mas sua pasta com 500 mil arquivos pequenos pode copiar muito mais devagar.
Não existe contradição.
São workloads diferentes.
Pendrive pode começar rápido e despencar
Pendrives variam enormemente em qualidade.
Alguns possuem:
- NAND lenta;
- controladores simples;
- cache pequeno;
- baixa performance sustentada.
Um pendrive “USB 3.2” não garante gravação rápida
USB 3.x descreve capacidade da interface.
Não garante que a memória flash interna consiga sustentar aquela velocidade.
Exemplo
Interface teórica:
5 Gbit/s
Pendrive gravando:
25 MB/s
Isso é perfeitamente possível.
O gargalo está na própria unidade.
USB-C também não garante velocidade
USB-C descreve principalmente o conector.
Um cabo ou porta USB-C pode trabalhar com capacidades bastante diferentes.
Podemos ter USB-C com USB 2.0?
Sim.
Por isso, olhar apenas o formato físico do conector é insuficiente.
O cabo também importa
Um cabo defeituoso ou inadequado pode:
- limitar velocidade;
- provocar desconexões;
- fazer a conexão negociar modo inferior.
HDD externo em USB 3.x
Um HDD mecânico pode atingir, por exemplo, algumas centenas de MB/s no melhor caso.
A interface USB 3.x pode ter capacidade maior que o disco.
Nesse cenário, o HDD continua sendo o gargalo.
USB 2.0 muda tudo
USB 2.0 possui largura de banda muito menor.
Se um dispositivo rápido negocia como USB 2.0, a cópia pode cair para dezenas de MB/s.
Como perceber?
Se um SSD externo que normalmente copia a centenas de MB/s fica preso perto de:
30–40 MB/s
uma hipótese é fallback ou conexão USB 2.0.
Mas não conclua sem testar.
UASP e BOT
Dispositivos de armazenamento USB podem trabalhar com protocolos diferentes.
Um deles é:
USB Attached SCSI Protocol — UASP
Outro é o modelo mais antigo frequentemente associado a:
Bulk-Only Transport — BOT.
UASP pode permitir melhor utilização de filas e desempenho, dependendo do dispositivo e do controlador.
Isso significa que UASP sempre dobra a velocidade?
Não.
O ganho depende de:
- unidade;
- bridge USB;
- controlador;
- workload.
Adaptadores USB-SATA e USB-NVMe também podem limitar
O SSD interno pode ser muito rápido.
Mas a bridge pode ser limitada.
Exemplo
NVMe:
3.500 MB/s
Caixa USB:
10 Gbit/s
Na prática, você nunca alcançará 3.500 MB/s através daquela interface.
NAS introduz outra cadeia
Agora temos:
SSD/HDD origem
↓
Windows
↓
placa de rede
↓
switch/roteador
↓
SMB
↓
NAS
↓
disco do NAS
Qualquer elo pode limitar.
Rede Gigabit possui limite próprio
Ethernet 1 Gb/s não significa 1 GB/s.
Existe uma diferença entre:
Gb/s
e:
GB/s.
1 Gb/s corresponde teoricamente a cerca de 125 MB/s antes de overhead
Na prática, cópias SMB em rede Gigabit costumam ficar abaixo desse teto teórico.
Então 110 MB/s em rede Gigabit pode ser ótimo
Sim.
Isso pode representar utilização muito boa da interface.
Wi-Fi é ainda mais variável
O valor anunciado:
1200 Mbps
não significa que você terá 150 MB/s de cópia sustentada.
Por quê?
Wi-Fi envolve:
- compartilhamento do meio;
- interferência;
- distância;
- largura do canal;
- MIMO;
- sinal;
- retransmissões;
- protocolo;
- eficiência.
Cópia para NAS via Wi-Fi pode oscilar muito
Exemplo:
80 MB/s
↓
45 MB/s
↓
20 MB/s
↓
70 MB/s
Isso pode refletir condições do link.
Latência também pesa em muitos arquivos pequenos
Uma transferência de arquivos pequenos pela rede pode sofrer mais com round trips e overhead do protocolo.
SMB possui seus próprios mecanismos
SMB moderno trabalha com recursos como:
- caching;
- signing;
- encryption;
- multichannel em ambientes compatíveis;
- leases.
Esses recursos podem influenciar desempenho.
SMB Signing pode afetar velocidade?
Pode haver custo computacional, dependendo da máquina, versão do protocolo, hardware e configuração.
Mas não devemos recomendar desativá-lo apenas por desempenho sem entender implicações de segurança.
Antivírus pode ser o gargalo invisível
Durante uma cópia, cada arquivo novo pode ser examinado.
Em um arquivo único de 100 GB
O impacto pode ser relativamente pequeno dependendo do mecanismo.
Em 200 mil arquivos pequenos
O antivírus pode participar em cada abertura e criação.
Isso pode reduzir muito a velocidade.
Como testar sem comprometer segurança?
Não comece desativando o antivírus.
Primeiro:
- observe uso de CPU;
- veja processos;
- compare tipos de arquivo;
- teste com conjunto conhecido;
- verifique logs e políticas.
Em ambiente administrado, siga as políticas de segurança.
Filtros de sistema de arquivos também podem participar
Comando:
fltmc
pode mostrar minifilters instalados.
Mas lembre:
presença não significa culpa.
Backup e sincronização podem interferir
OneDrive, ferramentas de backup e outros softwares podem reagir à criação de arquivos.
Copiar para uma pasta sincronizada pode iniciar upload
Exemplo:
C:\Users\Nome\OneDrive\Backup
O Explorer termina a cópia local.
Depois o OneDrive começa a sincronizar.
Isso não significa que o upload ocorreu na mesma velocidade da cópia local
São etapas diferentes.
Files On-Demand complica ainda mais
Um arquivo no OneDrive pode aparecer no Explorer sem estar totalmente presente localmente.
Dependendo do estado, abrir ou copiar pode exigir download.
Então “copiar um arquivo de 10 GB” pode envolver internet
Se o conteúdo está apenas na nuvem, sim.
O ícone do OneDrive importa
Ele ajuda a indicar se o arquivo está:
- disponível localmente;
- online-only;
- sempre disponível neste dispositivo.
O Explorer pode mostrar 0 bytes/s por alguns segundos
Isso assusta usuários.
Mas nem sempre significa travamento.
O que pode estar acontecendo?
O sistema pode estar:
- processando metadados;
- aguardando dispositivo;
- finalizando gravações;
- criando muitos arquivos;
- esperando antivírus;
- sincronizando operações;
- lidando com cache.
Se volta a transferir, provavelmente havia uma pausa de processamento
Mas se permanece indefinidamente em 0 B/s, investigue.
CPU alta pode limitar cópia?
Pode, especialmente quando existem:
- compressão;
- criptografia;
- antivírus;
- SMB encryption;
- muitos arquivos pequenos.
Criptografia BitLocker causa lentidão?
Em hardware moderno, o impacto pode ser pequeno em muitas cargas, mas depende do sistema e do dispositivo.
Não atribua queda automática ao BitLocker sem medir.
Compressão NTFS também pode mudar a história
Arquivos comprimidos pelo NTFS precisam de processamento adicional.
Dependendo do conteúdo e CPU, a velocidade pode mudar.
Arquivos já comprimidos não ganham muito
Vídeos, ZIP, JPEG e muitos formatos já utilizam compressão.
Compressão adicional pode trazer pouco benefício.
Como descobrir o gargalo real?
Comece pelo Gerenciador de Tarefas.
Abra:
Ctrl + Shift + Esc
Vá para:
Desempenho
Observe:
- Disco;
- CPU;
- Rede;
- Memória.
Se o disco de destino está em 100%
Ele pode estar limitando.
Mas “100%” significa tempo ativo, não necessariamente throughput máximo.
Um disco pode estar em 100% a 5 MB/s
Sim.
Principalmente em operações aleatórias, latência alta ou problemas.
Portanto, olhe também a taxa de transferência
Não apenas porcentagem.
Monitor de Recursos
Execute:
resmon
Na guia Disco podemos observar atividades por processo e arquivos.
Isso ajuda a descobrir:
- qual processo está lendo;
- qual está gravando;
- quais caminhos estão envolvidos.
Isso é útil quando o Explorer parece lento, mas outro processo está usando o disco
Por exemplo:
- Windows Update;
- antivírus;
- backup;
- indexação.
CrystalDiskMark
É útil para avaliar desempenho de armazenamento em cargas padronizadas.
Mas lembre:
benchmark não é cópia real.
Use como referência, não como resposta absoluta.
CrystalDiskInfo
Pode ajudar a verificar:
- modelo;
- interface;
- SMART;
- temperatura.
HWiNFO
Pode ser útil para observar sensores e throttling durante cópia pesada.
Teste com arquivo grande
Para throughput sequencial, um arquivo grande ajuda.
Teste com muitos arquivos pequenos
Para overhead e desempenho aleatório, use um conjunto diferente.
Não misture os resultados
Um dispositivo pode ser excelente no primeiro e mediano no segundo.
Método de diagnóstico VMIA
Quando uma cópia está lenta:
1. Identifique origem
Exemplo:
C:\
D:\
USB
NAS
2. Identifique destino
Mesmo cuidado.
3. Descubra se é mesmo volume
Isso muda completamente a análise.
4. Descubra se é cópia ou movimento
Não trate como sinônimos.
5. Teste arquivo grande
Avalie throughput.
6. Teste arquivos pequenos
Compare.
7. Observe Disco no Gerenciador de Tarefas
Veja origem e destino.
8. Observe CPU
Principalmente com muitos arquivos.
9. Observe rede
Se destino é remoto.
10. Verifique temperatura
Se SSD/NVMe cai após alguns minutos.
11. Verifique interface
USB 2.0, USB 3.x, SATA, PCIe, rede.
12. Compare com benchmark
Veja se existe diferença extrema.
Exemplo prático 1 — NVMe para SATA
Origem:
NVMe 5 GB/s
Destino:
SATA 500 MB/s
Cópia real:
430–480 MB/s
Isso pode ser totalmente normal.
Exemplo 2 — SSD externo cai depois de 20 GB
Começa:
900 MB/s
Depois:
250 MB/s
Hipóteses:
- cache SLC esgotado;
- temperatura;
- bridge USB;
- NAND lenta.
Exemplo 3 — pendrive a 20 MB/s
Apesar de ser USB 3.x.
Pode ser limitação da própria flash.
Exemplo 4 — NAS a 110 MB/s
Rede Gigabit.
Isso provavelmente está próximo do teto prático.
Exemplo 5 — NAS a 8 MB/s
Agora investigue:
- Wi-Fi;
- cabo;
- duplex;
- sinal;
- disco do NAS;
- SMB;
- CPU;
- antivírus.
Exemplo 6 — um arquivo de 100 GB copia rápido, pasta de 100 GB demora muito
A pasta possui centenas de milhares de arquivos.
Overhead de metadados e arquivos pequenos explica parte do comportamento.
Exemplo 7 — cópia fica em 0 B/s e volta
Pode ser flush, cache ou processamento de metadados.
Observe se a operação retorna.
Exemplo 8 — velocidade cai com temperatura
Se NVMe chega à faixa de throttling, o controlador pode reduzir frequência.
Exemplo 9 — SSD externo só chega a 35 MB/s
Teste se está negociando em USB 2.0.
Exemplo 10 — copiar dentro do mesmo SSD é mais lento que para outro SSD
Pode ser normal porque o dispositivo precisa ler e gravar simultaneamente.
Velocidade de pico é menos importante que velocidade sustentada
Para arquivos grandes, pergunte:
quanto mantém depois de alguns minutos?
Essa métrica costuma ser mais útil que o primeiro número exibido.
O Explorer também suaviza a medição
A velocidade apresentada é uma estimativa.
Pode oscilar conforme a janela de cálculo.
Não interprete cada segundo isoladamente
Observe tendência.
Diagnóstico completo: mover, copiar, renomear, volumes, permissões e velocidade real
Agora podemos fechar a explicação juntando todos os conceitos.
O ponto mais importante é separar três operações que parecem parecidas no Explorer, mas podem exigir trabalhos completamente diferentes do sistema de arquivos:
renomear
mover
copiar
A diferença entre elas explica por que um arquivo de 100 GB pode mudar de pasta em poucos segundos e levar vários minutos para ser duplicado ou transferido para outra unidade.
Renomear não regrava o conteúdo
Considere:
D:\Videos\filme.mkv
para:
D:\Videos\filme-final.mkv
O conteúdo do vídeo permanece o mesmo.
O NTFS precisa atualizar os metadados relacionados ao nome.
Por isso, o tamanho do arquivo praticamente não determina o tempo da operação.
Mover dentro do mesmo volume também pode ser muito rápido
Agora:
D:\Videos\filme.mkv
vai para:
D:\Arquivo\filme.mkv
Continuamos no volume D:.
O arquivo pode manter os mesmos clusters onde seus dados já estavam armazenados.
A principal mudança ocorre nas estruturas lógicas e metadados usados pelo NTFS.
Então o arquivo não mudou de lugar fisicamente?
Em muitos casos, essa é uma boa forma de explicar.
O arquivo mudou de localização lógica na estrutura de diretórios.
Os dados podem continuar nos mesmos clusters.
Mas não devemos transformar isso em regra absoluta
Existem operações especiais, softwares de terceiros, recursos do sistema de arquivos e outras situações em que o comportamento pode envolver etapas adicionais.
A ideia central é:
uma movimentação simples dentro do mesmo volume não exige necessariamente copiar todo o conteúdo.
Copiar é diferente
Quando você copia:
D:\Videos\filme.mkv
para:
D:\Backup\filme.mkv
agora precisa existir um segundo arquivo.
O sistema precisa criar novo objeto e armazenar outra cópia do conteúdo.
Mesmo volume, mas dados duplicados
Isso exige leitura e gravação.
Por isso, a cópia demora.
Mover entre volumes também exige transferência
Exemplo:
D:\Videos\filme.mkv
para:
E:\Backup\filme.mkv
Mesmo usando Recortar e Colar, o sistema precisa transportar os dados para o volume E:.
Depois, a origem pode ser removida.
Podemos resumir
| Operação | Mesmo volume | Volumes diferentes |
|---|---|---|
| Renomear | normalmente metadados | não se aplica da mesma forma |
| Mover | principalmente metadados | transferência de dados + remoção da origem |
| Copiar | leitura + gravação | leitura + gravação |
Mesmo SSD físico não significa mesmo volume
Esse ponto merece ser repetido.
Um SSD pode possuir:
C:
e:
D:
Se são volumes diferentes, mover entre eles exige transferência real de dados.
“Mas está tudo no mesmo SSD”
Isso não muda a fronteira lógica entre os volumes.
Cada volume administra suas próprias estruturas de sistema de arquivos.
Como descobrir se são volumes diferentes?
No Explorer, letras diferentes normalmente indicam volumes diferentes.
Mas ambientes com pontos de montagem podem exigir análise adicional.
Gerenciamento de Disco
Execute:
diskmgmt.msc
Ele ajuda a visualizar:
- discos físicos;
- partições;
- volumes;
- letras de unidade.
Isso revela uma situação comum
Você pode encontrar:
Disco 0
contendo:
C:
e:
D:
Fisicamente é o mesmo dispositivo.
Logicamente são volumes diferentes.
E se duas pastas usam a mesma letra?
Exemplo:
D:\Pasta1
e:
D:\Pasta2
Normalmente pertencem ao mesmo volume D:.
Nesse caso, uma movimentação simples entre elas pode ser muito rápida.
Rede é outro caso
Mover:
C:\Arquivo
para:
\\Servidor\Backup
sempre envolve transferência para outro sistema.
Agora entram:
- rede;
- SMB;
- armazenamento remoto;
- latência;
- servidor.
E um NAS mapeado como Z:?
Mesmo aparecendo como:
Z:\
ele é remoto.
Não confunda letra de unidade com armazenamento local.
Copiar para NAS pela rede Gigabit
Um valor próximo de:
100–115 MB/s
pode representar desempenho excelente em uma rede de 1 Gb/s.
Por que não 125 MB/s exatos?
Porque existem overheads de protocolo e outras limitações.
Em Wi-Fi, a diferença pode ser maior
A taxa de link anunciada não corresponde diretamente ao throughput real.
Agora vamos falar de permissões
Como vimos, mover e copiar podem ter resultados diferentes em NTFS.
Mover dentro do mesmo volume
Normalmente mantém o mesmo objeto do sistema de arquivos.
Isso tende a preservar o descritor de segurança existente.
Copiar
Cria um novo objeto no destino.
As regras de ACL e herança do destino podem participar.
Exemplo
Arquivo em:
D:\Financeiro
com acesso restrito.
Copiado para:
D:\Publico
O novo arquivo pode receber permissões conforme a configuração do diretório Público.
Mover pode produzir resultado diferente
Por isso, administradores precisam conhecer o comportamento quando reorganizam grandes estruturas de pastas.
Não use “copiar e mover são iguais” em ambiente corporativo
Isso pode gerar surpresa em permissões.
FAT32 e exFAT também mudam as regras
Esses sistemas não oferecem o mesmo modelo de permissões NTFS.
Ao copiar para um pendrive FAT32 ou exFAT, determinados metadados NTFS não possuem equivalente direto.
Alternate Data Streams também merecem atenção
NTFS suporta Alternate Data Streams, ou ADS.
Um arquivo pode ter dados associados em streams adicionais.
Exemplo conhecido
Zone.Identifier
pode acompanhar arquivos baixados da Internet em NTFS.
Esse mecanismo participa do Mark of the Web.
Copiar para FAT32 pode perder ADS
Porque o sistema de arquivos de destino não oferece o mesmo recurso.
Portanto, “copiar arquivo” não significa preservar todos os recursos possíveis
O resultado depende do sistema de arquivos e da ferramenta utilizada.
Hard Links tornam tudo ainda mais interessante
Dois nomes podem se referir ao mesmo arquivo subjacente.
Exemplo
D:\A\dados.bin
e:
D:\B\dados2.bin
podem ser hard links.
Apagar um nome não significa necessariamente remover os dados imediatamente se ainda existir outro hard link.
Isso é diferente de uma cópia
Uma cópia comum cria outro conjunto de dados.
Hard Link cria outro nome para o mesmo objeto subjacente dentro do volume.
E links simbólicos?
Eles funcionam como referências para outro caminho.
Não devem ser confundidos com Hard Links.
Junction Points também
São amplamente utilizados no Windows para redirecionamentos e compatibilidade.
Por que isso importa ao copiar uma pasta?
Porque a ferramenta precisa decidir o que fazer com links e Reparse Points.
Robocopy pode ser mais apropriado em cópias complexas
Para migração e cópia de grandes árvores de diretórios, o robocopy oferece opções avançadas.
Ele pode controlar:
- dados;
- atributos;
- timestamps;
- ACLs;
- proprietário;
- auditoria;
- links;
- retries.
Mas use as opções com cuidado
Comandos de cópia avançados podem sobrescrever ou excluir dados se configurados incorretamente.
Sempre teste primeiro em uma estrutura descartável.
Por que milhões de arquivos pequenos demoram tanto?
Mesmo que o total seja apenas:
50 GB
cada arquivo exige operações individuais.
Existe overhead por arquivo
Podemos ter:
- criação;
- abertura;
- segurança;
- metadados;
- timestamps;
- antivírus;
- fechamento.
Um arquivo de 50 GB pode ser mais rápido que 500 mil arquivos totalizando 50 GB
Isso é totalmente normal.
O mesmo vale para rede
Muitos arquivos pequenos amplificam:
- latência;
- round trips;
- SMB;
- metadata operations.
E em HDD isso pode ser ainda pior
As cabeças precisam se movimentar constantemente.
SSD reduz muito a latência, mas não elimina overhead
Por isso ainda existe diferença.
Como interpretar velocidade que começa alta e cai?
Primeiro observe o momento da queda.
Queda depois de quantidade parecida de dados
Pode sugerir:
- cache SLC;
- buffer;
- cache do dispositivo.
Queda depois de alguns minutos com temperatura alta
Pode sugerir thermal throttling.
Queda apenas em arquivos pequenos
Pode indicar overhead de metadados, IOPS ou antivírus.
Queda apenas na rede
Pode envolver:
- Wi-Fi;
- SMB;
- NAS;
- link;
- servidor.
Queda para aproximadamente 30 MB/s em USB
Pode valer verificar se o dispositivo está trabalhando em USB 2.0.
Não use apenas benchmark como diagnóstico
Benchmark mede uma carga controlada.
Explorer mede uma operação real.
Os dois precisam ser comparados
Se CrystalDiskMark mostra:
5 GB/s
e cópia real entre dois NVMe independentes fica em:
100 MB/s
isso merece investigação.
Mas se o destino é um HDD USB
A diferença é esperada.
Diagnóstico completo VMIA
Quando uma cópia ou movimentação parece estranha, siga esta ordem.
1. Identifique a operação
É:
- copiar;
- mover;
- renomear?
2. Identifique origem e destino
Anote os caminhos.
3. Verifique o volume
Mesmo volume ou outro volume?
4. Verifique o dispositivo físico
SSD, NVMe, SATA, HDD, USB ou NAS?
5. Verifique o sistema de arquivos
NTFS, exFAT, FAT32 ou outro?
6. Observe o tamanho dos arquivos
Um arquivo gigante ou muitos pequenos?
7. Meça a velocidade
Observe o comportamento sustentado, não apenas o pico inicial.
8. Abra o Gerenciador de Tarefas
Observe:
- disco;
- CPU;
- rede;
- memória.
9. Use Monitor de Recursos
Execute:
resmon
Veja quais processos estão lendo e gravando.
10. Observe temperatura
Principalmente em NVMe.
11. Verifique interface
USB 2.0, USB 3.x, SATA, PCIe, Ethernet, Wi-Fi.
12. Teste outro arquivo
Isso ajuda a separar problema do dispositivo de problema do conjunto de dados.
13. Teste outra porta ou cabo
Principalmente USB.
14. Compare com benchmark
Use resultado como referência.
15. Mude uma variável por vez
Não troque cinco coisas simultaneamente.
Cenário 1 — arquivo de 100 GB muda de pasta instantaneamente
Origem:
D:\A
Destino:
D:\B
Mesmo volume.
Provavelmente comportamento normal.
Cenário 2 — mesmo arquivo demora 5 minutos para ir para E:
Origem:
D:
Destino:
E:
Volumes diferentes.
Transferência real necessária.
Cenário 3 — C: e D: estão no mesmo SSD
Mesmo assim, volumes diferentes.
Transferência real.
Cenário 4 — copiar 100 GB dentro de D:
É cópia, não movimentação.
O conteúdo precisa ser duplicado.
Cenário 5 — pasta de 100 GB leva uma hora, ISO de 100 GB leva poucos minutos
A pasta possui milhares ou milhões de arquivos pequenos.
Overhead explica parte da diferença.
Cenário 6 — SSD começa a 2 GB/s e cai para 350 MB/s
Pode ser cache SLC esgotado.
Verifique o modelo e comportamento sustentado.
Cenário 7 — NVMe cai junto com temperatura
Investigue throttling.
Cenário 8 — HDD em 100% com 5 MB/s
Pode estar atendendo muitas operações pequenas e aleatórias.
100% de tempo ativo não significa throughput alto.
Cenário 9 — NAS fica em 110 MB/s
Em Gigabit Ethernet, pode estar muito próximo do limite prático.
Cenário 10 — NAS fica em 20 MB/s via Wi-Fi
Investigue o link sem fio.
Cenário 11 — SSD externo fica em 35 MB/s
Verifique USB 2.0, cabo, porta e bridge.
Cenário 12 — cópia local termina, mas OneDrive continua trabalhando
A cópia local terminou.
Agora existe uma segunda operação: sincronização com a nuvem.
Cenário 13 — arquivo online-only demora para copiar
Pode ser necessário baixar o conteúdo primeiro.
Cenário 14 — permissões mudaram depois da cópia
O novo objeto pode ter recebido permissões do destino.
Cenário 15 — permissões permaneceram depois de mover
Dentro do mesmo volume, isso pode ser comportamento esperado.
Mitos comuns
“Mover sempre copia e apaga”
Não dentro do mesmo volume.
“Se o arquivo tem 100 GB, mover precisa escrever 100 GB”
Não necessariamente.
“Mesmo SSD significa movimento instantâneo”
Não se atravessar volumes.
“Copiar dentro do mesmo SSD não deveria usar leitura”
Usa, porque o conteúdo precisa ser duplicado.
“USB-C é sempre rápido”
Não.
“NVMe de 7 GB/s copia qualquer coisa a 7 GB/s”
Não.
“100% de disco significa velocidade máxima”
Não.
“Mover arquivo desfragmenta”
Não necessariamente.
“Renomear extensão converte o arquivo”
Não.
“Copiar preserva absolutamente todos os metadados”
Não necessariamente.
FAQ — Mover e copiar arquivos no Windows 11
1. Por que mover um arquivo grande pode ser instantâneo?
Porque dentro do mesmo volume o NTFS pode alterar principalmente metadados, sem copiar todo o conteúdo.
2. O arquivo realmente mudou de pasta?
Sim, logicamente.
3. Os dados mudaram de clusters?
Não necessariamente.
4. Mover 1 GB e 100 GB pode levar o mesmo tempo?
Pode, dentro do mesmo volume.
5. Copiar 100 GB precisa transferir os dados?
Sim, em uma cópia comum.
6. Copiar dentro do mesmo volume também demora?
Sim, porque cria outra cópia do conteúdo.
7. Mover entre C: e D: demora?
Se forem volumes diferentes, sim.
8. Mesmo quando C: e D: estão no mesmo SSD?
Sim.
9. Por quê?
Cada volume administra seus próprios clusters e metadados.
10. O que é MFT?
Master File Table, uma estrutura central do NTFS.
11. O que é $DATA?
Um atributo NTFS relacionado ao conteúdo do arquivo.
12. O que é atributo residente?
Um atributo cujos dados cabem dentro do registro da MFT.
13. Arquivos grandes são residentes?
Seu conteúdo normalmente não.
14. O que são Data Runs?
Estruturas que descrevem extensões de clusters de dados não residentes.
15. Um arquivo fragmentado pode ser movido rapidamente?
Sim.
16. Mover desfragmenta?
Não necessariamente.
17. Renomear um arquivo regrava seu conteúdo?
Não.
18. Trocar .jpg por .png converte a imagem?
Não.
19. O que é um cluster?
Unidade de alocação do sistema de arquivos.
20. Pasta é uma região física do SSD?
Não dessa forma.
21. O que é localização lógica?
É a posição do arquivo na estrutura de diretórios.
22. O que é localização física?
É um conceito relacionado às regiões de armazenamento onde os dados estão.
23. Em SSD isso fica ainda mais complexo?
Sim, por causa do FTL e gerenciamento interno da NAND.
24. TRIM move arquivo?
Não.
25. TRIM apaga instantaneamente todas as células?
Não devemos interpretar dessa forma.
26. Por que SSD começa rápido e fica lento?
Cache, NAND, temperatura e outras limitações podem explicar.
27. O que é pseudo-SLC?
Uso temporário da NAND em modo que favorece desempenho de gravação.
28. QLC pode cair bastante depois do cache?
Pode, dependendo do SSD.
29. SSD cheio pode influenciar?
Pode em alguns projetos.
30. Thermal throttling reduz velocidade?
Sim.
31. Copiar dentro do mesmo SSD pode ser mais lento?
Pode.
32. Por quê?
A unidade precisa ler e gravar simultaneamente.
33. Dois SSDs podem copiar mais rápido?
Podem, se ambos e a interface suportarem.
34. HDD é pior com arquivos pequenos?
Normalmente sim.
35. SSD também fica mais lento com muitos arquivos pequenos?
Pode ficar.
36. 100% de disco significa velocidade máxima?
Não.
37. O que é IOPS?
Métrica relacionada à quantidade de operações de entrada/saída por segundo.
38. USB 3.x garante velocidade alta?
Não.
39. USB-C garante USB 3.x?
Não.
40. UASP pode melhorar desempenho?
Pode, dependendo do dispositivo e workload.
41. NAS de 1 Gb/s pode copiar a 1 GB/s?
Não.
42. Quanto representa 1 Gb/s teoricamente?
Cerca de 125 MB/s antes de overhead.
43. 110 MB/s em Gigabit é bom?
Sim, normalmente é um resultado forte.
44. Wi-Fi anunciado em 1200 Mbps entrega isso em arquivo?
Normalmente não.
45. Antivírus pode reduzir cópia?
Pode, principalmente com muitos arquivos pequenos.
46. OneDrive pode influenciar?
Sim.
47. Arquivo online-only precisa ser baixado?
Pode precisar.
48. Copiar muda permissões?
Pode.
49. Mover dentro do mesmo volume preserva permissões?
Frequentemente preserva o descritor de segurança existente, embora políticas e cenários específicos precisem ser considerados.
50. Qual é a principal pergunta antes de investigar?
Origem e destino estão no mesmo volume?
Conclusão
A diferença entre mover e copiar arquivos no Windows 11 fica muito mais fácil de entender quando abandonamos a ideia de que uma pasta é simplesmente uma “caixa física” dentro do SSD.
O NTFS trabalha com metadados, registros, índices, clusters e referências.
Quando um arquivo de 100 GB é movido:
D:\PastaA
para:
D:\PastaB
o sistema pode manter seus dados nos mesmos clusters e alterar principalmente as estruturas que indicam onde aquele arquivo aparece logicamente.
Por isso, a operação pode terminar quase instantaneamente.
Quando o mesmo arquivo é copiado:
D: → E:
ou mesmo:
D:\A → D:\B
como uma cópia real, é necessário criar outro conjunto de dados.
Agora entram em jogo:
- velocidade de leitura;
- velocidade de gravação;
- cache;
- SSD;
- HDD;
- USB;
- rede;
- SMB;
- temperatura;
- quantidade de arquivos;
- antivírus.
Isso explica por que duas operações envolvendo exatamente “100 GB” podem levar tempos completamente diferentes.
O tamanho dos arquivos é apenas parte da história.
O diagnóstico correto começa descobrindo:
é cópia ou movimento?
Depois:
origem e destino estão no mesmo volume?
Só então vale investigar armazenamento, interface, cache e desempenho.
Precisa diagnosticar lentidão ao copiar ou mover arquivos?
A VMIA – Manutenção e Configuração realiza diagnóstico de computadores e notebooks Windows, incluindo lentidão em SSD e HDD, problemas de cópia de arquivos, unidades externas USB, NAS, rede doméstica, Windows 11 e desempenho de armazenamento.
O atendimento pode ser realizado por acesso remoto ou visita técnica agendada, conforme o problema.
Site: https://vmia.site
Blog: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br
Telefone/WhatsApp: (11) 99779-7772
E-mail: suporte@vmia.com.br
Faça um comentário