Questão Como limpar o espaço livre em disco no Linux?


Quando um arquivo é excluído, seu conteúdo ainda pode ser deixado no sistema de arquivos, a menos que explicitamente sobrescrito por outra coisa. o wipe comando pode apagar arquivos com segurança, mas não parece permitir o espaço livre em disco que não é usado por nenhum arquivo.

O que devo usar para conseguir isso?


130


origem


A única solução segura pode ser salvar seus arquivos em outro lugar, limpar toda a partição, recriar o sistema de arquivos e restaurar seus arquivos. Eu corri photorec e ficou chocado com a quantidade de material que poderia ser recuperado mesmo depois de "limpar" o espaço livre. Uma solução de compromisso é mover o limite esquerdo da sua partição em 6% do seu tamanho depois de ter limpado o espaço aparentemente livre. - user39559


Respostas:


Atenção: Modern hardware de disco / SSD e sistemas de arquivos modernos podem esquadrinhar dados em lugares onde você não pode apagá-los, então este processo ainda pode deixar dados no disco. As únicas formas seguras de limpar dados são o comando ATA Secure Erase (se implementado corretamente) ou a destruição física. Veja também Como posso apagar de forma confiável todas as informações em um disco rígido?


99



É difícil localizar a página inicial "oficial" atual de exclusão segura. Uma versão talvez mais antiga afirma que não há relatórios de bugs, mas ao mesmo tempo não existe um sistema aberto de bugs onde eu poderia reportar um bug que eu encontrei. A página de exclusão segura também aponta que pode não limpe todos os blocos de dados não utilizados, dependendo do sistema de arquivos usado, o que é verdadeiro. - user39559
Com discos rígidos modernos (maiores que cerca de 20 GB), é totalmente inútil fazer vários passes e esperar por anos. Portanto, a instalação de ferramentas especializadas também se tornou inútil (o que pode explicar por que o secure-delete não possui mais home page). Basta fazer isso a partir da partição apropriada: cat /dev/zero >nosuchfile; rm nosuchfile. - mivk
@mivk: Por que é inútil fazer mais de um passe? E por que usar / dev / zero em vez de / dev / random? Isso é devido a preocupações de velocidade? - naught101
Usando / dev / zero é muito mais rápido. Se você escrever espaço livre a partir de / dev / random, o kernel precisa gerar todos os dados aleatórios em tempo real. É uma maneira divertida de ver sua média de carga aumentar até o máximo ... - dafydd
A questão de se vários toalhetes são necessários é respondida aqui: Por que escrever zeros (ou dados aleatórios) em um disco rígido várias vezes é melhor do que apenas fazer isso uma vez? - sleske


A maneira mais rápida, se você só precisa de um único passo e quer apenas substituir tudo por zeros, é:

cat /dev/zero > zero.file
sync
rm zero.file

(executado a partir de um diretório no sistema de arquivos que você deseja limpar)
(a sync O comando é uma medida de paranoia que garante que todos os dados sejam gravados no disco - um gerenciador de cache inteligente pode descobrir que pode cancelar gravações para blocos pendentes quando o arquivo é desvinculado)

Haverá um tempo durante esta operação, quando não haverá espaço livre no sistema de arquivos, o que pode ser de dezenas de segundos se o arquivo resultante for grande e fragmentado, portanto, demorará um pouco para ser apagado. Para reduzir o tempo em que o espaço livre é completamente zero:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
cat /dev/zero > zero.file
sync
rm zero.small.file
rm zero.file

Isso deve ser suficiente para impedir que alguém leia o conteúdo antigo do arquivo sem uma operação forense cara. Para uma substituição um pouco mais segura, mas mais lenta, /dev/zero com /dev/urandom. Para mais paranoia, execute vários passos com /dev/urandom, embora se você precisar de tanto esforço shred utilitário do pacote coreutils é o caminho a percorrer:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
shred -z zero.small.file
cat /dev/zero > zero.file
sync
rm zero.small.file
shred -z zero.file
sync
rm zero.file

Note que no arquivo acima o pequeno arquivo é triturado antes de criar o maior, então ele pode ser removido assim que o maior for concluído em vez de ter que esperar que ele seja triturado deixando o sistema de arquivos com zero de espaço livre pelo tempo que leva. O processo de fragmentação com um longo tempo em um arquivo grande e, a menos que você esteja tentando ocultar algo da NSA, não é realmente necessário.

Todos os itens acima devem funcionar em qualquer sistema de arquivos.

Limites de tamanho de arquivo:

Como DanMoulding aponta em um comentário abaixo, isso pode ter problemas com limis de tamanho de arquivo em alguns sistemas de arquivos.

Para FAT32 seria definitivamente ser uma preocupação devido ao limite de arquivo 2GiB: a maioria dos volumes é maior do que isso nos dias de hoje (8TiB é o limite de tamanho do volume IIRC). Você pode contornar isso canalizando o grande cat /dev/zero saída de saída através split para gerar vários arquivos menores e ajustar os estágios de fragmentação e exclusão de acordo.

Com ext2 / 3/4 é menos preocupante: com o bloco padrão / comum de 4K, o limite de tamanho de arquivo é 2TiB, então você teria que ter um enorme volume para isto ser um problema (o tamanho máximo do volume sob estas condições é 16TiB).

Com o (ainda experimental) btrfs ambos os tamanhos máximos de arquivo e volume são 16EiB massivos.

Em NTFS, o tamanho máximo do arquivo é maior que o tamanho máximo do volume em alguns casos, mesmo.

Pontos de partida para mais informações:
http://en.wikipedia.org/wiki/Ext3#Size_limits
http://en.wikipedia.org/wiki/Btrfs
http://en.wikipedia.org/wiki/Ntfs#Scalability

Dispositivos Virtuais

Como mencionado nos comentários recentemente, há considerações extras para dispositivos virtuais:

  • Para discos virtuais escassamente alocados, outros métodos, como os usados ​​por zerofree será mais rápido (embora ao contrário cat e dd esta não é uma ferramenta padrão que você pode confiar em estar disponível em praticamente qualquer sistema operacional unix-a-like).

  • Esteja ciente de que zerar um bloco em um dispositivo virtual esparso pode não limpar o bloco fisica dispositivo, na verdade eu iria tão longe para dizer que é improvável - o gerenciador de discos virtuais fará com que o bloco não seja mais usado para que possa ser alocado para outra coisa mais tarde.

  • Mesmo para dispositivos virtuais de tamanho fixo, você pode não ter controle de onde o dispositivo mora fisicamente para que possa ser movido em sua localização atual ou em um novo conjunto de discos físicos a qualquer momento e o máximo que você pode limpar é o local atual, não quaisquer localizações anteriores, o bloco pode ter residido no passado.

  • Para os problemas acima em dispositivos virtuais: a menos que você controle o (s) host (s) e possa fazer uma limpeza segura do espaço não alocado depois de limpar os discos na VM ou mover o dispositivo virtual, não há nada que você possa fazer sobre isso após o facto. O único recurso é usar criptografia de disco completo do começo então nada descriptografado é todo escrito para a mídia física em primeiro lugar. Ainda pode haver uma limpeza no espaço livre dentro da VM, é claro. Note também que o FDE pode tornar os dispositivos virtuais esparsos muito menos úteis, já que a camada de virtualização não pode realmente ver quais blocos estão sem uso. Se a camada do sistema de arquivos do sistema operacional enviar comandos de ajuste para o dispositivo virtual (como se fosse um SSD) e o controlador virtual os interpretar, isso pode resolver isso, mas não sei de nenhuma circunstância em que isso realmente acontece e discussão sobre isso é uma questão para outros lugares (já estamos chegando perto de estar fora do tópico para a pergunta original, então se isso despertou seu interesse, algumas questões de experimentação e / ou de acompanhamento podem estar em ordem).


65



O zeramento simples aparentemente também pode ser feito com o secure-delete ferramentas: usando sfill -llz reduz todo o procedimento para uma passagem que só grava '0'. - foraidt
Isso leva um tempo. É realmente o caminho mais rápido? Eu acho que escrever GB de dados sempre vai demorar um pouco ... - endolith
@endolith: se você quiser deixar em branco o espaço livre em um sistema de arquivos ativo, você não pode contornar a necessidade de escrever tantos dados através da sobrecarga do sistema de arquivos. As ferramentas secure-delete sugeridas por fnord_ix podem ser mais rápidas, porque são otimizadas para esse tipo de tarefa. - David Spillett
@endolith: a partir da descrição na página man, eu espero que a variante do zerofree seja mais rápida para discos virtuais escassamente alocados, na verdade, pode ser mais lenta em virtuais reais ou de tamanho fixo se estiver fazendo uma leitura antes de escrever para confirmar que o bloco não tem conteúdo. O balão para um disco virtual não deve acontecer, pois a maioria dos drivers de disco esparsos toma zeros como "não aloque este bloco". Além disso, cat e dd estão disponíveis em praticamente qualquer sistema operacional unix-a-like, pois são considerados ferramentas padrão onde zerofree provavelmente não é, a menos que tenha sido explicitamente adicionado. - David Spillett
@endolith: tendo dito o acima, zerofree certamente funcionaria, é claro, a coisa "todo o sistema de arquivos temporariamente cheio" mencionado na página man (quase, mas não totalmente mitigada pela pokery small.file jiggery em meus exemplos) é uma preocupação genuína E se você está fazendo isso em um sistema atualmente ativo e zerofree seria de fato mais rápido na instância específica para a qual ele é otimizado: dispositivos de bloco virtual escassamente alocados. Embora você não possa confiar em qualquer limpeza em um dispositivo virtual por motivos de segurança: a única resposta verdadeira nesse caso é criptografar todos os dispositivos desde o início. - David Spillett


ATENÇÃO

Fiquei chocado com quantos arquivos photorec poderia recuperar do meu disco, mesmo depois de limpar.

Se há mais segurança em preencher o "espaço livre" apenas 1 vez com 0x00 ou 38 vezes com diferentes padrões cabalísticos é mais uma discussão acadêmica. O autor do seminal paper de 1996 sobre trituração escreveu para si mesmo epílogo dizendo que isso é obsoleto e desnecessário para o hardware moderno. Não há nenhum caso documentado de dados sendo zerados fisicamente e recuperados posteriormente.

A verdade elo frágil neste procedimento é o sistema de arquivo. Alguns sistemas de arquivos reservam espaço para uso especial e não são disponibilizados como "espaço livre". Mas seus dados podem estar lá. Isso inclui fotos, e-mails de texto simples, o que for. Acabei de pesquisar no Google + espaço + ext4 e aprendi que 5% do meu home partição foi reservada. Eu acho que isso é onde photorec Encontrei muito das minhas coisas. Conclusão: o método de trituração não é o mais importante, mesmo o método multi-pass ainda deixa os dados no lugar.

Podes tentar # tune2fs -m 0 /dev/sdn0 antes de montá-lo. (Se esta for a partição raiz após a reinicialização, certifique-se de executar -m 5 ou -m 1 depois de desmontá-lo).

Mas ainda assim, de um jeito ou de outro, pode haver algum espaço sobrando.

A única maneira realmente segura é apagar toda a partição, criar um sistema de arquivos novamente e restaurar seus arquivos a partir de um backup.


Caminho rápido (recomendado)

Executar a partir de um diretório no sistema de arquivos que você deseja limpar:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file

Notas: o objetivo do arquivo pequeno é reduzir o tempo em que o espaço livre é completamente zero; O objetivo da sincronização é garantir que os dados sejam realmente gravados.

Isso deve ser bom o suficiente para a maioria das pessoas.

Caminho lento (paranóico)

Não há nenhum caso documentado de dados sendo recuperados após a limpeza acima. Seria caro e exigiria recursos, se possível.

No entanto, se você tem uma razão para pensar que as agências secretas gastariam muitos recursos para recuperar seus arquivos, isso seria o suficiente:

dd if=/dev/urandom of=random.small.file bs=1024 count=102400
dd if=/dev/urandom of=random.file bs=1024
sync ; sleep 60 ; sync
rm random.small.file
rm random.file

Demora muito mais tempo.

Atenção. Se você escolheu o caminho paranóico, depois disso você ainda quer fazer a limpeza rápida, e isso não é paranóia. A presença de dados puramente aleatórios é fácil e barata de detectar, e levanta a suspeita de que são dados realmente criptografados. Você pode morrer sob tortura por não revelar a chave de decodificação.

Caminho muito lento (louco paranóico)

Até mesmo o autor do seminal paper de 1996 sobre trituração escreveu um epílogo dizendo que isso é obsoleto e desnecessário para o hardware moderno.

Mas se você ainda tem muito tempo livre e não se importa em gastar seu disco com muita sobrescrita, lá vai:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
sync ; sleep 60 ; sync
shred -z zero.small.file
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
shred -z zero.file
sync ; sleep 60 ; sync
rm zero.file

Nota: isto é essencialmente equivalente ao uso da ferramenta secure-delete.


Antes da edição, este post foi uma reescrita de David Spillett. O comando "cat" produz uma mensagem de erro, mas não consigo escrever comentários nos posts de outras pessoas.


39



Você pode comentar em posts de outras pessoas com 50 reputação. - Gnoupi
o cat Espera-se que o comando dê um erro "sem espaço à esquerda" em meus exemplos, no final de sua execução. Você pode esconder isso redirecionando o stderr para /dev/null se é um problema. Eu costumo usar pv ao invés de cat ou dd para este tipo de coisa, a fim de obter a indicação de progresso útil. - David Spillett
...raises the suspicion that it is actually encrypted data. You may die under torture for not revealing the decryption key. Isso é exatamente o que eu estava pensando. Eu acho que isso significa que eu sou paranóico ... - Navin
/: write failed, filesystem is full no FreeBSD - Alex G
Raiz é sempre capaz de usar o espaço reservado. Então, se você fizer seu preenchimento com zero como root, você será capaz de preencher o espaço reservado de 5% também; os tunefs são desnecessários. Ainda é concebível que possa haver dados em outras partes do sistema de arquivos. - Nate Eldredge


Há utilitário zerofree pelo menos no Ubuntu:

http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html

   zerofree — zero free blocks from ext2/3 file-systems

   zerofree  finds  the  unallocated, non-zeroed blocks in an ext2 or ext3
   filesystem (e.g. /dev/hda1) and fills them with zeroes. This is  useful
   if  the  device  on  which this file-system resides is a disk image. In
   this case, depending on the type of disk image, a secondary utility may
   be  able  to  reduce the size of the disk image after zerofree has been
   run.

   The usual way to achieve  the  same  result  (zeroing  the  unallocated
   blocks)  is to run dd (1) to create a file full of zeroes that takes up
   the entire free space on the drive, and then delete this file. This has
   many disadvantages, which zerofree alleviates:

      ·  it is slow;

      ·  it makes the disk image (temporarily) grow to its maximal extent;

      ·  it  (temporarily)  uses  all  free  space  on  the disk, so other
         concurrent write actions may fail.

   filesystem has to be unmounted or mounted  read-only  for  zerofree  to
   work.  It  will exit with an error message if the filesystem is mounted
   writable. To remount the  root  file-system  readonly,  you  can  first
   switch to single user runlevel (telinit 1) then use mount -o remount,ro
   filesystem.

Além disso, verifique este link sobre o zerofree: Mantendo as imagens do sistema de arquivos esparsas - é de seu autor - Ron Yorston (9 de agosto de 2012)


24



É importante que o sistema de arquivos seja desmontado ou montado somente leitura para que o zerofree funcione. - AntonioK
Seria bom incluir algumas informações sobre como fazer isso no sistema de arquivos raiz. Meu sentimento é que isso não funcionará, porque você teria que desmontar o sistema de arquivos, enquanto executa simultaneamente a ferramenta do sistema de arquivos. - Ant6n


Veja como fazer isso com uma GUI.

  1. Instalar BleachBit
  2. Executar como root, clicando em Aplicativos - Ferramentas do Sistema - BleachBit como administrador.
  3. Nas preferências, diga quais caminhos você deseja. Geralmente adivinha-os bem. Você deseja incluir um caminho gravável para cada partição. Geralmente isso é / home / username e / tmp, a menos que eles sejam a mesma partição, nesse caso, escolha um.
  4. Marque a caixa System - Wipe Free Disk Space.
  5. Clique em Excluir.

O avanço do BleachBit sobre o dd (que de outra forma é muito bom) é quando o disco está finalmente cheio, o BleachBit cria pequenos arquivos para limpar os inodes (que contém metadados como nomes de arquivos, etc).


3



Inspecionar O código python de código aberto do Bleachbit para limpar o espaço livre de uma unidade para você mesmo. - shadowbq


eu uso dd Para alocar um ou mais arquivos grandes para preencher o espaço livre, use um utilitário de exclusão segura.

Para alocar arquivos com o dd tente:

dd if=/dev/zero of=delete_me bs=1024 count=102400

Isso irá gerar um arquivo chamado delete_me que tem 100 MB de tamanho. (Aqui bs é o "tamanho do bloco" definido como 1k e count é o número de blocos a serem alocados.)

Em seguida, use seu utilitário de exclusão segura favorito (eu tenho usado shred) nos arquivos assim criados.

Mas NOTE ISSO: buffering significa mesmo se você fizer o todo disco, você pode não ter absolutamente tudo!


este ligação recomenda scrub para limpar o espaço livre. Não tentei.


2



Ah, se a memória me serve, eu tentei scrub uma vez e corrompeu todo o sistema de arquivos. Felizmente, tive o bom senso de experimentar primeiro um sistema de arquivos de teste, NÃO em meus dados reais. - landroni


Limpe uma unidade na velocidade máxima.

Instruções típicas para criptografar uma unidade hoje em dia dirão que você primeiro limpe a unidade.

O comando abaixo preencherá sua unidade com o texto cifrado AES.

Use um CD ao vivo se precisar limpar sua unidade de inicialização principal.

Abra um terminal e eleve seus privilégios:

sudo bash

Vamos listar todas as unidades no sistema para serem seguras:

cat /proc/partitions

NOTA: Substitua /dev/sd{x} com o dispositivo que você deseja limpar.

AVISO: Isto não é para amadores! Você poderia tornar seu sistema não inicializável !!!

sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > /dev/sd{x}

Estou chocado com o quão rápido isso é.


2





Você provavelmente já tem o Pacote GNU coreutils instalado no seu sistema. Ele fornece o comando rasgar.


2



O Shred não limpará o espaço em disco não utilizado sem primeiro criar arquivos ... - dmckee