Usando o comando dd no Linux

Mascote do LinuxPro na oficina, com um HD e um pendrive e blocos de dados fluindo entre eles, ao lado de uma placa de alerta

Nota (2026): post de 2017, revisado e completado. O que mudou de mais útil: status=progress deixou de ser truque e virou o jeito normal de acompanhar a cópia, e hoje existem ferramentas melhores que o dd para algumas das tarefas que ele fazia sozinho.

O dd copia dados bloco a bloco, sem interpretar o que está copiando. É isso que o torna capaz de gravar uma ISO num pendrive, clonar um disco inteiro ou salvar o setor de boot — e é exatamente isso que o torna perigoso: ele obedece sem perguntar, e um device errado no of= destrói dados sem confirmação nem lixeira.

Este post mostra o que o comando faz de útil no dia a dia, com os cuidados que separam a ferramenta do desastre.

De onde vem o nome

O dd apareceu na Versão 5 do Unix e foi criado para converter dados entre ASCII e EBCDIC. A sintaxe estranha — if=, of=, bs=, em vez das flags com hífen que todo comando Unix usa — é herança direta da instrução DD (Data Definition) do JCL da IBM. Há quem diga que a semelhança foi piada de programador. O comando é padronizado pelo IEEE Std 1003.1 — hoje na Issue 8, a POSIX.1-2024. Mas atenção: o dd do GNU coreutils, que é o do Linux, vai bem além do padrão. O POSIX define if, of, bs, cbs, conv, count, ibs, obs, seek e skip, e só admite os sufixos k, b e x no tamanho de bloco. status=progress, oflag=, iflag= e o sufixo M são extensões GNU — o próprio manual do coreutils diz isso com todas as letras. Os exemplos deste post valem no Linux; em outro Unix, confira o manual de lá. O status=progress, em particular, existe a partir do coreutils 8.24, de 2015.

O que o torna poderoso em Linux é uma característica do sistema, não dele: aqui, disco, partição, memória e geradores como /dev/zero e /dev/urandom são todos arquivos. O dd só sabe ler de um arquivo e escrever em outro — o resto é consequência.

Antes de qualquer coisa: descubra o device certo

Toda tragédia com dd começa no mesmo lugar: a pessoa achou que o pendrive era /dev/sdb e era /dev/sda. Confira sempre:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS,MODEL

Você vai ver algo assim — repare no tamanho e no modelo, não só na letra:

NAME   SIZE TYPE MOUNTPOINTS MODEL
sda    931G disk             Samsung SSD 870
├─sda1   1G part /boot/efi
└─sda2 930G part /
sdb     29G disk             SanDisk Cruzer
└─sdb1  29G part /media/nilton/PENDRIVE

O de 931 GB é o seu sistema. O de 29 GB é o pendrive. E note: o alvo do dd é o disco (/dev/sdb), não a partição (/dev/sdb1). Antes de gravar, desmonte — mas não ejete:

sudo umount /dev/sdb1

Gravar uma ISO num pendrive

É o uso mais comum, e o único comando deste post que você provavelmente vai repetir:

sudo dd if=ubuntu-24.04.2-desktop-amd64.iso of=/dev/sdb bs=4M status=progress oflag=sync

Cada pedaço importa:

  • if=input file, a origem. Aqui, a imagem.
  • of=output file, o destino. É esta que destrói dados se estiver errada.
  • bs=4M — tamanho do bloco. O padrão é 512 bytes, o que faz milhões de operações minúsculas e deixa a gravação lenta. Com 4 MB a diferença é de minutos para segundos.
  • status=progress — mostra bytes copiados e velocidade em tempo real. Sem isso, o terminal fica mudo e parece travado.
  • oflag=sync — grava de verdade em vez de acumular em cache, para o comando só terminar quando o dado estiver no pendrive.

Ao terminar, force a descarga do cache antes de puxar o dispositivo:

sync

Um detalhe que economiza tempo: para ISO híbrida — que é o caso de praticamente toda distribuição atual — o cp faz o mesmo trabalho, e é bem mais difícil de errar:

sudo cp ubuntu-24.04.2-desktop-amd64.iso /dev/sdb && sync

Apagar o MBR

O MBR (Master Boot Record) é o primeiro setor do disco, com 512 bytes divididos assim:

446 bytes  bootstrap (o código que inicia o boot)
 64 bytes  tabela de particoes
  2 bytes  assinatura 0x55AA
---------
512 bytes

Estes comandos destroem dados. Confira o device duas vezes.

# apaga o MBR inteiro, INCLUSIVE a tabela de particoes
sudo dd if=/dev/zero of=/dev/sdX bs=512 count=1

# apaga so o bootstrap e PRESERVA a tabela de particoes
sudo dd if=/dev/zero of=/dev/sdX bs=446 count=1

Uma ressalva sobre esses 446 bytes: nem todos são código. Os quatro últimos (offsets 440 a 443) guardam a assinatura de disco de 32 bits, que o Windows registra no BCD e que o Linux usa para montar o PARTUUID de discos MBR. Zerá-los pode impedir o Windows de iniciar e muda o PARTUUID das partições. Se você quer preservar a assinatura, o alvo é bs=440 count=1.

A diferença entre 512 e 446 é a diferença entre perder as partições e apenas remover o gerenciador de boot. Antes de qualquer um dos dois, salve uma cópia — são 512 bytes, não custa nada:

sudo dd if=/dev/sdX of=~/mbr-backup.img bs=512 count=1
# para restaurar:
sudo dd if=~/mbr-backup.img of=/dev/sdX bs=512 count=1

Detalhe que pega quem repete esses comandos num arquivo em vez de num device: o dd trunca o arquivo de saída no tamanho escrito. Em /dev/sdX isso não acontece, porque truncar não faz sentido num dispositivo de bloco — mas dd if=/dev/zero of=imagem.img bs=446 count=1 deixa a imagem com 446 bytes. Quando o alvo for arquivo, acrescente conv=notrunc.

Vale saber que isso vale para discos com particionamento MBR. Máquinas com UEFI e GPT, que são a maioria hoje, guardam o boot na partição EFI e têm uma cópia da tabela GPT no fim do disco — ali o remendo é com gdisk ou sgdisk, não com dd.

Outros usos que valem

# criar um arquivo de tamanho fixo (ex.: swap de 2 GB)
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress
sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile
# para sobreviver ao reboot, acrescente ao /etc/fstab:
#   /swapfile none swap sw 0 0

# medir a velocidade bruta de escrita do disco
dd if=/dev/zero of=teste.img bs=1M count=1024 oflag=direct status=progress

# clonar um disco inteiro para outro do mesmo tamanho ou maior
sudo dd if=/dev/sda of=/dev/sdb bs=64M status=progress conv=noerror,sync

# gerar um arquivo com dados aleatorios
dd if=/dev/urandom of=aleatorio.bin bs=1M count=10

Dois detalhes desses exemplos: o oflag=direct no teste de velocidade contorna o cache do sistema, senão você mede a RAM e não o disco. E o conv=noerror,sync na clonagem manda o dd seguir adiante quando encontra um setor ilegível, preenchendo com zeros para não desalinhar o resto — sem ele, um único setor defeituoso aborta a cópia.

Quando não usar o dd

O dd resolve muita coisa, mas em 2026 há ferramentas melhores para alguns casos:

  • Disco com setores defeituosos: use ddrescue (pacote gddrescue). Ele tenta várias passadas, mapeia o que conseguiu ler e permite retomar de onde parou — o dd não faz nada disso.
  • Acompanhar progresso com barra: pv dá barra, percentual e tempo estimado — pv arquivo.iso | sudo dd of=/dev/sdb bs=4M iflag=fullblock — o iflag=fullblock não é opcional aqui: o buffer de um pipe no Linux é de 64 KB e, sem ele, o bs=4M não tem efeito nenhum.
  • Copiar arquivos comuns: cp e rsync são mais rápidos, mais seguros e sabem lidar com permissões e links.
  • Criar arquivo grande sem escrever nada: fallocate -l 2G arquivo é instantâneo, porque só reserva espaço.

E, sim: o dd cai em prova da LPI. Vale saber de cor o que são if, of, bs e count, e a conta dos 512 bytes do MBR.

Para continuar