![\"Mascote](\"\/wp-content\/uploads\/2026\/09\/comando-dd-v4.webp\")
<\/p>\n<\/p>\n
status=progress<\/code> stopped being a trick and became the normal way to monitor a copy, and today there are better tools than dd<\/code> for some of the tasks it once handled alone.<\/div>\nThe dd<\/strong> copies data block by block, without interpreting what it is copying. That is what allows it to write an ISO to a USB drive, clone an entire disk, or save the boot sector \u2014 and it is exactly what makes it dangerous: it obeys without asking, and the wrong device in of=<\/code> destroys data without confirmation or a trash bin.<\/p>\nThis post shows what the command is useful for day to day, with the precautions that separate the tool from disaster.<\/p>\n
<\/p>\n
Where the name comes from<\/h2>\n
The dd<\/code> appeared in Unix Version 5<\/strong> and was created to convert data between ASCII and EBCDIC. The unusual syntax \u2014 if=<\/code>, of=<\/code>, bs=<\/code>, instead of the hyphenated flags every Unix command uses \u2014 is inherited directly from the DD<\/em> (Data Definition) statement in IBM's JCL. Some say the resemblance was a programmer's joke. The command is standardized by IEEE Std 1003.1 \u2014 now at Issue 8, POSIX.1-2024. But note: the dd<\/code> from GNU coreutils, which is the Linux version, goes far beyond the standard. POSIX defines if<\/code>, of<\/code>, bs<\/code>, cbs<\/code>, conv<\/code>, count<\/code>, ibs<\/code>, obs<\/code>, seek<\/code> and skip<\/code>, and only allows the suffixes k<\/code>, b<\/code> and x<\/code> in the block size. status=progress<\/code>, oflag=<\/code>, iflag=<\/code> and the suffix M<\/code> are GNU extensions<\/strong> \u2014 the coreutils manual says so explicitly. The examples in this post apply to Linux; on another Unix, check its manual. The status=progress<\/code>, in particular, has existed since coreutils 8.24, from 2015.<\/p>\nWhat makes it powerful on Linux is a characteristic of the system, not the command: here, disks, partitions, memory, and generators like \/dev\/zero<\/code> and \/dev\/urandom<\/code> are all files. The dd<\/code> only knows how to read from one file and write to another \u2014 everything else follows from that.<\/p>\nBefore anything else: identify the correct device<\/h2>\n
Every disaster with dd<\/code> starts in the same place: someone thought the USB drive was \/dev\/sdb<\/code> and it was \/dev\/sda<\/code>. Always check:<\/p>\nlsblk -o NAME,SIZE,TYPE,MOUNTPOINTS,MODEL\n<\/code><\/pre>\nYou will see something like this \u2014 pay attention to the size and model, not just the letter:<\/p>\n
NAME SIZE TYPE MOUNTPOINTS MODEL\nsda 931G disk Samsung SSD 870\n\u251c\u2500sda1 1G part \/boot\/efi\n\u2514\u2500sda2 930G part \/\nsdb 29G disk SanDisk Cruzer\n\u2514\u2500sdb1 29G part \/media\/nilton\/PENDRIVE\n<\/code><\/pre>\nThe 931 GB one is your system. The 29 GB one is the USB drive. And note: the target of dd<\/code> is the disk<\/strong> (\/dev\/sdb<\/code>), not the partition (\/dev\/sdb1<\/code>). Before writing, unmount \u2014 but do not eject:<\/p>\nsudo umount \/dev\/sdb1\n<\/code><\/pre>\nWriting an ISO to a USB drive<\/h2>\n
This is the most common use, and the only command in this post you will probably repeat:<\/p>\n
sudo dd if=ubuntu-24.04.2-desktop-amd64.iso of=\/dev\/sdb bs=4M status=progress oflag=sync\n<\/code><\/pre>\nEvery part matters:<\/p>\n
\nif=<\/code> \u2014 input file<\/em>, the source. Here, the image.<\/li>\nof=<\/code> \u2014 output file<\/em>, the destination. This is the one that destroys data if it is wrong.<\/strong><\/li>\nbs=4M<\/code> \u2014 block size. The default is 512 bytes, which creates millions of tiny operations and slows writing down. With 4 MB the difference is minutes versus seconds.<\/li>\nstatus=progress<\/code> \u2014 shows bytes copied and speed in real time. Without it, the terminal stays silent and looks frozen.<\/li>\noflag=sync<\/code> \u2014 actually writes instead of accumulating data in cache, so the command only finishes when the data are on the USB drive.<\/li>\n<\/ul>\nWhen finished, force the cache to flush before pulling out the device:<\/p>\n
sync\n<\/code><\/pre>\nOne time-saving detail: for a hybrid ISO \u2014 which describes practically every current distribution \u2014 cp<\/code> does the same job and is much harder to get wrong:<\/p>\nsudo cp ubuntu-24.04.2-desktop-amd64.iso \/dev\/sdb && sync\n<\/code><\/pre>\nErasing the MBR<\/h2>\n
The MBR<\/strong> (Master Boot Record) is the first sector of the disk, with 512 bytes divided as follows:<\/p>\n446 bytes bootstrap (o c\u00f3digo que inicia o boot)\n 64 bytes tabela de particoes\n 2 bytes assinatura 0x55AA\n---------\n512 bytes\n<\/code><\/pre>\nThese commands destroy data. Check the device twice.<\/strong><\/p>\n# apaga o MBR inteiro, INCLUSIVE a tabela de particoes\nsudo dd if=\/dev\/zero of=\/dev\/sdX bs=512 count=1\n\n# apaga so o bootstrap e PRESERVA a tabela de particoes\nsudo dd if=\/dev\/zero of=\/dev\/sdX bs=446 count=1\n<\/code><\/pre>\nOne caveat about those 446 bytes: not all of them are code. The last four (offsets 440 to 443) store the 32-bit disk signature<\/strong>, which Windows records in the BCD and Linux uses to construct the PARTUUID<\/code> of MBR disks. Zeroing them can prevent Windows from booting and changes the PARTUUID<\/code> of the partitions. If you want to preserve the signature, the target is bs=440 count=1<\/code>.<\/p>\nThe difference between 512 and 446 is the difference between losing the partitions and merely removing the bootloader. Before either one, save a copy \u2014 it is 512 bytes and costs nothing:<\/p>\n
sudo dd if=\/dev\/sdX of=~\/mbr-backup.img bs=512 count=1\n# para restaurar:\nsudo dd if=~\/mbr-backup.img of=\/dev\/sdX bs=512 count=1\n<\/code><\/pre>\nA detail that catches people who repeat these commands on a file instead of a device: the dd<\/code> truncates the output file<\/strong> to the size written. On \/dev\/sdX<\/code> this does not happen, because truncating makes no sense on a block device \u2014 but dd if=\/dev\/zero of=imagem.img bs=446 count=1<\/code> leaves the image at 446 bytes. When the target is a file, add conv=notrunc<\/code>.<\/p>\nIt is worth knowing that this applies to disks with MBR partitioning. Machines with UEFI and GPT<\/strong>, which are the majority today, store boot files on the EFI partition and have a copy of the GPT table at the end of the disk \u2014 there the fix uses gdisk<\/code> or sgdisk<\/code>, not dd<\/code>.<\/p>\nOther worthwhile uses<\/h2>\n# criar um arquivo de tamanho fixo (ex.: swap de 2 GB)\nsudo dd if=\/dev\/zero of=\/swapfile bs=1M count=2048 status=progress\nsudo chmod 600 \/swapfile && sudo mkswap \/swapfile && sudo swapon \/swapfile\n# para sobreviver ao reboot, acrescente ao \/etc\/fstab:\n# \/swapfile none swap sw 0 0\n\n# medir a velocidade bruta de escrita do disco\ndd if=\/dev\/zero of=teste.img bs=1M count=1024 oflag=direct status=progress\n\n# clonar um disco inteiro para outro do mesmo tamanho ou maior\nsudo dd if=\/dev\/sda of=\/dev\/sdb bs=64M status=progress conv=noerror,sync\n\n# gerar um arquivo com dados aleatorios\ndd if=\/dev\/urandom of=aleatorio.bin bs=1M count=10\n<\/code><\/pre>\nTwo details in these examples: the oflag=direct<\/code> in the speed test bypasses the system cache; otherwise you measure RAM, not the disk. And the conv=noerror,sync<\/code> in cloning tells dd<\/code> to keep going when it encounters an unreadable sector, padding with zeros to avoid misaligning the rest \u2014 without it, a single bad sector aborts the copy.<\/p>\nWhen not to use dd<\/h2>\n
The dd<\/code> solves many problems, but in 2026 there are better tools for some cases:<\/p>\n\n- Disks with bad sectors:<\/strong> use
ddrescue<\/code> (package gddrescue<\/code>). It makes multiple passes, maps what it managed to read, and lets you resume where it stopped \u2014 dd<\/code> does none of that.<\/li>\n- Monitoring progress with a bar:<\/strong>
pv<\/code> provides a bar, percentage, and estimated time \u2014 pv arquivo.iso | sudo dd of=\/dev\/sdb bs=4M iflag=fullblock<\/code> \u2014 the iflag=fullblock<\/code> is not optional here: a pipe buffer on Linux is 64 KB and, without it, bs=4M<\/code> has no effect at all.<\/li>\n- Copying regular files:<\/strong>
cp<\/code> and rsync<\/code> are faster, safer, and know how to handle permissions and links.<\/li>\n- Creating a large file without writing anything:<\/strong>
fallocate -l 2G arquivo<\/code> is instant because it only allocates space.<\/li>\n<\/ul>\nAnd yes: dd<\/code> appears on LPI exams<\/strong>. It is worth knowing by heart what if<\/code>, of<\/code>, bs<\/code> and count<\/code> are, and how the MBR's 512 bytes add up.<\/p>\nTo keep going<\/h2>\n\n- Using the wget command<\/a> \u2014 to download the ISO you are going to write<\/li>\n
- 500 Linux commands<\/a><\/li>\n
- The dd manual in GNU coreutils<\/a> \u00b7 Linux Professional Institute<\/a><\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"
dd copies data block by block without interpreting what it copies. That is what allows it to write an ISO to a USB drive, clone an entire disk, or save the boot sector \u2014 and it is exactly what \u2026 Read more<\/a><\/p>","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[28,2],"tags":[410,124,409,4,365,117],"class_list":["post-150","post","type-post","status-publish","format-standard","hentry","category-dicas","category-linux","tag-backup","tag-comandos","tag-dd","tag-linux","tag-lpi","tag-terminal"],"_links":{"self":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/150","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/comments?post=150"}],"version-history":[{"count":8,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/150\/revisions"}],"predecessor-version":[{"id":1019,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/150\/revisions\/1019"}],"wp:attachment":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/media?parent=150"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/categories?post=150"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/tags?post=150"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}