Last winter I watched a buddy of mine spend most of a Sunday wondering why his “complete” backup of a failing 1 TB drive was a fraction of the original size. He’d dragged the visible files across to an external disk, called it a backup, and was confident the operating system would boot from it. It wouldn’t. The boot sector was missing. The partition table was missing. The recovery partition Lenovo had hidden between the EFI system partition and his C drive was also missing. He’d copied his data, but he hadn’t copied the disk. That’s the thing nobody explains until it bites you, and it’s the whole reason sector-by-sector imaging exists.
I’ve been making sector-level images of SD cards, USB sticks, failing HDDs, and oddball embedded boards since around 2014, mostly with Win32 Disk Imager 1.0.0 (the March 2017 release that’s still the current version on SourceForge in 2026), occasionally with dd from coreutils 9.5 in WSL, and a couple of times with FTK Imager 4.7.1 when something needed forensic-grade chain-of-custody. So this isn’t a textbook definition. It’s what the term actually describes, why Win32 Disk Imager defaults to that approach, and when you want it versus when you’d rather use a file-aware backup.
Quick answer: Sector-by-sector imaging copies every byte of a storage device in physical order, regardless of which sectors hold real files, partition tables, boot code, or empty space. The output is a raw image identical in size to the source disk and bootable when written back. Win32 Disk Imager works this way by default.
The 30-Second Definition
I’ll keep this short. A sector is the smallest addressable chunk of a storage device. On most modern drives that’s 512 bytes (legacy “512n” sectors) or 4,096 bytes (modern “Advanced Format” 4Kn sectors). When you image a disk sector by sector, the tool walks from logical block address (LBA) 0 to LBA N, where N is the last sector on the drive, and writes every byte to an output file in the exact order it sat on the source. Nothing gets skipped, reordered, or interpreted.
Compare that to a file-level backup, which walks the file system tree, finds every file the OS knows about, and copies those files to a destination. A file-level backup understands NTFS or ext4 or FAT32. A sector-level image doesn’t know any of those exist. It’s filesystem-blind, and that’s the entire point.
If you want a one-sentence working definition: a sector-by-sector image is a photograph of every byte on a drive, in physical order, stored as a single file. I describe it that way because that’s what finally clicked for me when I first wrapped my head around why my 32 GB Pi backup was eating 32 GB on my laptop. The IMG file didn’t care that only 4 GB of the card had real data. Every empty sector got copied too, because the tool had no way to tell which ones mattered.
Sector-by-Sector vs File-Level Backup: The Real Difference
People mix these up constantly because tools rarely label themselves clearly. File Explorer copy is file-level. Robocopy is file-level. Macrium’s “image” mode is mostly file-level (it skips unallocated space by default). Time Machine on macOS is file-level. Win32 Disk Imager is sector-level. dd is sector-level. FTK Imager raw mode is sector-level. The distinction shapes what you can recover and what you can’t.
| Property | Sector-by-sector image | File-level backup |
|---|---|---|
| Output size | Identical to source disk | Sum of file sizes only |
| Captures boot sector | Yes | No |
| Captures partition table | Yes | No |
| Captures unallocated space | Yes | No |
| Captures deleted files | Yes (until overwritten) | No |
| Captures slack space | Yes | No |
| Bootable when restored | Yes (if source was) | Only with extra steps |
| Filesystem aware | No | Yes |
| Skips bad sectors gracefully | Tool dependent | Usually yes |
| Restore time | Full disk write | Per-file write |
| Compresses well | Yes (if source mostly empty) | Depends on file types |
I think the second-order consequences matter more than the first-order ones. Yes, a sector image is bigger. The deeper point is that it captures structure that file-level tools throw away. Boot loaders, hidden recovery partitions, encrypted volume headers, GPT backup tables sitting in the last 33 sectors of the drive, vendor-specific firmware regions on industrial flash, all of that comes along for the ride whether you asked for it or not.
Why Would You Want Sector-by-Sector? (5 Real Use Cases)
This is where the abstraction becomes practical. Here’s what I actually use sector-level imaging for, in roughly the order I run into them most often.
1. Bootable disk preservation
If a disk boots an OS, a sector image of that disk also boots the OS when written back. That’s the simplest reason most Raspberry Pi users end up here. You’ve spent three weekends configuring Home Assistant or OctoPrint, and now you want a backup so you can rebuild fast if the SD card dies. A file copy of /home/pi/ won’t do that. A sector image will. I cover the full read-side workflow in the SD card to IMG backup guide, and the restore side in the Raspberry Pi restore guide.
2. Partition table integrity
The MBR sits in the first 512 bytes of the disk. GPT sits at sectors 1 through 33, with a backup copy in the last 33 sectors. If either gets corrupted, Windows can’t find your partitions even though the data is still physically present. A sector-by-sector image preserves both copies of the GPT, so a corrupted partition table on the source can be repaired by reading the GPT backup out of the image. File-level tools never see this layer at all.
3. Hidden filesystem regions
NTFS keeps its $MFT (Master File Table) in the middle of the volume by default, plus mirror copies, journal data, and reparse-point metadata. ext4 has superblock backups scattered every 32,768 blocks. FAT32 stores two copies of the FAT itself for redundancy. None of that is “files” the way a user thinks of files, but it’s all critical to mounting the volume. Sector imaging grabs every byte of it. File-level imaging walks the directory tree and skips the metadata layer entirely, which is fine for restoring documents but useless for forensic analysis or volume repair.
4. Forensic acquisition
This is the use case that drove the standardization of sector-level imaging in the first place. When law enforcement seizes a drive, they have to be able to prove in court that the image is byte-identical to the source. That means hashing the source, hashing the image, and demonstrating both hashes match. You can’t do that with file-level backup, because slack space, unallocated regions, and deleted-but-not-overwritten data are the whole game in a forensic investigation. The default forensic tools (FTK Imager 4.7.1, Guymager 0.8.13, EnCase, X-Ways, the Linux dcfldd fork of dd) all do sector-level acquisition because nothing else holds up.
5. Encrypted volumes
If a disk is BitLocker-encrypted, VeraCrypt-encrypted, or LUKS-encrypted, the file system inside the encrypted container isn’t visible to a file-level backup tool unless the volume’s already unlocked. A sector image, by contrast, copies the encrypted blob verbatim. Restore that image to a new drive, unlock with the same password or recovery key, and you’ve got the exact same encrypted volume. This is the only sane way to back up a BitLocker-encrypted Windows drive without first decrypting it, and that matters when you’re imaging a machine you can’t unlock.
Why You Don’t Always Want Sector-by-Sector (The Size Problem)
Here’s the trade-off nobody mentions in the marketing copy. A sector image of a 1 TB drive is 1 TB on disk, even if the user only had 80 GB of actual files. That’s the question I get asked most often, and I covered it in detail in Why Win32 Disk Imager backups are larger than used space, but the short version is: empty sectors aren’t tagged as empty, they’re just sectors full of zeros (or leftover bytes from previous data), and the imaging tool copies them all because it has no way to tell which ones the filesystem considers “free.”
For a 32 GB SD card with a 4 GB Pi OS install, that means a 32 GB IMG file. For a 1 TB laptop SSD with 200 GB of files, that means a 1 TB image. Storage cost adds up fast. Six Raspberry Pi setups eat 192 GB of backup space even if each Pi is barely using 8 GB. Cloud backup quotas evaporate. External drives fill up.
There are three reasonable mitigations, and I’ve used all of them in different combinations.
- Compression after the fact. Empty sectors are mostly zeros, and zeros compress beautifully.
7z a -mx9 backup.img.7z backup.imgturns a 32 GB IMG with 4 GB of real data into roughly a 4 to 5 GB archive. Free, works on any Windows install. Same withxz -9on Linux, which is what Raspberry Pi OS itself ships compressed with. - PiShrink. The PiShrink script reads the actual used size of the ext4 partition inside a Pi IMG and resizes both the partition and the file to match. The output IMG auto-expands on first boot. Needs Linux or WSL. I walk through the workflow in the PiShrink shrink IMG guide.
- Sparse images. Some imaging tools can write a sparse file, where empty regions consume zero filesystem blocks even though the logical file size shows the full disk capacity. dd does this with
conv=sparse. Win32 Disk Imager doesn’t (as of 1.0.0), and that’s a real limitation if you’re trying to keep storage costs down on Windows.
None of these change the fundamental physics. If you want full sector-level fidelity, you’re going to pay for it in bytes. The compression and shrinking tricks just hide the cost; they don’t eliminate it.
How Does Win32 Disk Imager Actually Do It? (The dd-on-Windows Model)
Under the hood, Win32 Disk Imager 1.0.0 is a few hundred lines of C++ wrapped around the Windows CreateFile, ReadFile, and WriteFile APIs. It opens the raw block device using the \\.\PhysicalDriveN path syntax (which bypasses the filesystem entirely and gives the program a handle to the literal hardware), reads in 1 MB chunks, and writes those chunks straight to the output file. There’s no magic. It’s the same algorithm dd has been running on Unix since 1974.
If you’re a Linux person, this is essentially:
dd if=/dev/sdb of=backup.img bs=1M status=progressThat command tells dd to read from the input file /dev/sdb (a raw block device, in this case an SD card or USB stick) and write to the output file backup.img using a block size of 1 megabyte, showing progress as it goes. Win32 Disk Imager is doing the same thing with a checkbox-and-button interface instead of command-line flags. I cover the full button-by-button walkthrough in the Win32 Disk Imager beginner’s guide.
Why a 1 MB block size? Because reading one sector at a time would be glacially slow due to per-call overhead, and reading too large a chunk wastes RAM without speeding things up much past a certain point. 1 MB is a balance most utility-style imagers settle on. dd defaults to 512 bytes if you don’t specify, which is why dd with default settings is famously slow.
The program doesn’t understand filesystems at all. It doesn’t know an ext4 partition from a region of unallocated empty sectors. It just copies bytes from offset 0 to offset N where N is the disk capacity, in physical order, no interpretation. That’s why it works equally well on FAT32, NTFS, ext4, exFAT, HFS+, ZFS, raw firmware blobs, or completely blank cards. It doesn’t care.
What Does the “Read Only Allocated Partitions” Checkbox Do?
The most useful Win32 Disk Imager 1.0.0 feature most people overlook is the “Read Only Allocated Partitions” checkbox added in March 2017. When checked, the program stops reading once it hits the end of the last allocated partition, instead of continuing through the trailing empty space to the end of the device. That’s still sector-by-sector inside the partitions, but it skips the often-massive trailing gap.
On a 32 GB SD card with a 256 MB boot partition and a 4 GB root partition, the trailing empty space might be 27+ GB. Ticking the checkbox cuts the IMG to roughly the size of the partitions instead of the size of the card, which is a noticeable win. The IMG still contains the whole partition contents (including unallocated space inside each partition), so you don’t lose forensic fidelity inside the partitions, only the post-partition tail gets skipped.
One catch worth knowing: an IMG produced with this option is smaller than the source disk’s reported capacity. When you write it back to a card later, you’ll need to either expand the filesystem manually (using raspi-config or GParted) or rely on the OS to auto-expand on first boot, which Raspberry Pi OS does and most other distros don’t.
Sparse Files, PiShrink, and Compressing the Result
Sparse files are a filesystem-level optimization that lets you store a “logical” file size larger than the actual disk space the file occupies. Empty regions, instead of consuming blocks of zeros, consume nothing. NTFS supports sparse files, ext4 supports sparse files, APFS supports sparse files. The trick: most tools need an explicit flag to create one.
If you image a 1 TB disk that’s mostly empty and write the output as a sparse file, the file appears to be 1 TB but only consumes maybe 80 GB of actual disk space. dd does this with conv=sparse or by detecting all-zero blocks and seeking past them. cp --sparse=always can convert a non-sparse IMG into a sparse one after the fact on Linux. On Windows, fsutil sparse setflag backup.img followed by zeroing the empty regions can simulate the same thing, but it’s much fiddlier.
Win32 Disk Imager, as of 1.0.0, doesn’t write sparse output. The IMG you get is fully allocated. If you want a sparse copy, your easiest path is: image normally with Win32DI, then either compress with 7-Zip (if you just want a smaller archive) or convert to sparse with the Linux tools above (if you want it browsable and mountable as if it were the original size). For Pi backups specifically, PiShrink is usually the best answer because it actually resizes the partition before producing the smaller image, which keeps the IMG mountable, browseable, and bootable.
Is Sector-by-Sector the Same as Bit-by-Bit?
Practically, yes. Theoretically, almost. The terms get used interchangeably and that’s fine in 99% of contexts. The pedantic distinction is that “bit-by-bit” implies the tool reads and writes individual bits, which would be agonizingly slow and isn’t how any real imager works. Real tools work at the sector level (512 bytes or 4 KiB at a time), which is the smallest unit the underlying hardware exposes anyway.
So when a marketing page says “bit-by-bit copy,” they almost certainly mean sector-by-sector. When a forensic tool says “sector-by-sector,” they mean exactly what they say. The end result is identical: every byte from the source ends up in the image, in physical order, nothing skipped. Whether you call that bit-level or sector-level fidelity is a labeling preference, not a technical one.
The real distinction worth caring about is “sector-level” versus “block-level” versus “file-level.” Block-level usually means the tool understands filesystem allocation blocks (4 KiB or 64 KiB, depending on filesystem) and only copies allocated blocks. Macrium Reflect’s “intelligent sector copy” is block-level in this sense; it knows which clusters NTFS marks as in use and skips the rest. That’s much smaller than sector-by-sector, but it can’t preserve unallocated space, so deleted-file recovery and forensic analysis are off the table.
What Does a Sector Image Actually Look Like Inside?
Here’s the layout of the first chunk of a typical Raspberry Pi OS IMG file, the way it sits on disk in physical sector order. I generated this by running hexdump -C raspios.img | head -50 on a fresh 2026-01-28 Raspberry Pi OS Bookworm image.
Offset 0x00000000 (LBA 0): MBR boot code + partition table
├─ 0x000-0x1BD : 446 bytes of x86 boot code (mostly unused on Pi)
├─ 0x1BE-0x1FD : 4 partition entries (16 bytes each)
├─ 0x1FE-0x1FF : 0x55 0xAA boot signature
Offset 0x00000200 (LBA 1): Empty (reserved)
└─ ... padding to first partition ...
Offset 0x00200000 (LBA 8192): First partition (FAT32 boot)
├─ Volume boot record
├─ FAT 1 + FAT 2
├─ Root directory: config.txt, cmdline.txt, kernel*.img, *.dtb
└─ ... files ...
Offset 0x21800000 (LBA 1097728): Second partition (ext4 root)
├─ Superblock + group descriptors
├─ Inode tables
├─ /boot, /etc, /home, /usr, /var ... entire Linux tree
└─ ... 1.5 GiB of unused inodes + free blocks ...
Offset 0x100000000 (LBA 33554432, 16 GiB mark): End of source SD
card; tail-empty if <32 GiBRead that diagram top to bottom and that’s literally the order bytes come off the SD card. Win32 Disk Imager doesn’t reorder anything. It opens \\.\PhysicalDrive2 at offset 0, reads, advances, reads, advances, all the way to the last sector. The IMG file you end up with has identical byte-for-byte layout. Mount it with OSFMount or 7-Zip and you can browse the partitions exactly as if it were the original card.
That sector-0 layout (446 bytes of boot code, 64 bytes of partition table entries, 2 bytes of magic signature) has been the MBR format since IBM PC DOS 2.0 in 1983. GPT, introduced with EFI in the late 1990s, replaces this with a protective MBR at sector 0 plus a real GPT header at sector 1 and partition entries at sectors 2 through 33. Either way, sector 0 has to be exactly right or the disk doesn’t boot. That’s why every imaging tool that aims to produce bootable output works at the sector level and starts at LBA 0.
When Does Forensic Imaging Become Sector-by-Sector? (dd vs FTK Imager)
Forensic imaging is sector-by-sector by definition. The discipline depends on it. The interesting question is what each forensic tool does on top of the basic sector-level copy.
| Tool | Output formats | Hashing | Bad-sector handling | Typical use |
|---|---|---|---|---|
| Win32 Disk Imager 1.0.0 | Raw IMG | None built-in (use Get-FileHash separately) | Aborts on read error | SD/USB consumer imaging |
| dd (coreutils 9.5) | Raw | External (md5sum, sha256sum) | Aborts unless conv=noerror,sync set | Linux scripting, basic forensics |
| ddrescue 1.27 | Raw + log file | External | Skip-and-retry algorithm, designed for failing drives | Failing-drive recovery |
| FTK Imager 4.7.1 | Raw, E01, AFF, SMART | MD5 + SHA1 inline | Configurable retry | Windows forensic acquisition |
| Guymager 0.8.13 | Raw, E01, AFF | MD5 + SHA256 inline, parallel | Configurable retry | Linux forensic lab |
| dcfldd | Raw + hash log | MD5/SHA1 inline, multi-output | Configurable | DoD-derived dd fork |
The key forensic difference is that FTK Imager and Guymager hash the data in-stream while reading. They calculate MD5 and SHA256 (or SHA1) on the fly and write the hash to a metadata file alongside the image. That lets investigators prove the image is byte-identical to the source without reading the source a second time. dd doesn’t do this on its own; you’d run md5sum /dev/sdb separately, which means a second full read of the device. For evidence handling on a multi-terabyte drive, that second read can take hours.
The E01 format (also called EWF, EnCase Witness Format) is the de facto forensic standard. It chunks the raw sector data into segments, embeds metadata, embeds hashes, and supports compression and encryption. An E01 image is still a sector-by-sector copy underneath; the wrapper just adds chain-of-custody metadata and lets the file be split across multiple smaller files (useful when your output filesystem can’t handle a 4 TB single file).
Win32 Disk Imager doesn’t produce E01. If you need that, you need FTK Imager or Guymager. For non-evidentiary use (Pi backups, USB images, drive cloning for lab work), raw IMG is fine and Win32 Disk Imager is the simplest tool that gets you there on Windows.
One more note from the data-recovery community: a thread that comes up repeatedly on r/datarecovery is the question of which tool to use on a drive that’s actually failing. The community consensus, summarized well in the r/datarecovery FAQ at DiskTuna, is that ddrescue is the right tool, not dd or Win32 Disk Imager. ddrescue handles bad sectors gracefully (it skips ahead, comes back later, retries, logs progress) where naive sector imagers will either abort or hang. If you’re reading from a healthy disk, dd or Win32DI is fine. If you’re reading from a failing one, switch tools.
How Do You Verify a Sector-by-Sector Image?
Once you’ve made the image, you’ll want to confirm it’s intact. The standard procedure is hashing both the source and the image, then comparing. If they match, you’ve got a clean sector-level copy. If they don’t, something went wrong and you need to redo it.
On Windows, the simplest path is PowerShell:
Get-FileHash -Algorithm SHA256 .\backup.img
Get-FileHash -Algorithm SHA256 \\.\PhysicalDrive2The first command hashes the IMG file. The second hashes the raw device the IMG was made from. If both hex strings match, you’ve confirmed sector-level fidelity. There’s a longer walkthrough in the SHA256 hash verification guide, including BLAKE3 (which is much faster than SHA256 on modern CPUs) and the certutil command-line equivalent that’s been in Windows since XP.
Win32 Disk Imager 1.0.0 also has a built-in “Verify Image” button that re-reads the destination drive after writing and compares it sector-by-sector to the source IMG. This is genuinely useful because it catches cases where the write succeeded but the destination has bad sectors. If verify fails, the card itself is suspect, not the IMG.
FAQ
Is sector-by-sector imaging the same as cloning a disk?
Almost, but not quite. Sector-by-sector imaging produces a file. Cloning writes directly from one disk to another with no intermediate file. The underlying read operation is identical (every sector, in order, no filesystem interpretation), but cloning skips the file-output step. Win32 Disk Imager only does imaging, not direct cloning. Clonezilla can do either. For SD card and USB work, imaging is what most people want because the IMG file is itself useful as a backup you can keep, ship, or restore later.
Why is my sector-by-sector backup the same size as the disk and not the size of my files?
Because every sector gets copied, including the empty ones. The tool has no way to know which sectors hold real data and which are unallocated. A 32 GB SD card with 4 GB of files produces a 32 GB IMG. To shrink it, either tick “Read Only Allocated Partitions” in Win32 Disk Imager, run PiShrink afterwards on Linux or WSL, or compress the IMG with 7-Zip (mostly-empty IMG files compress to roughly the size of the actual data).
Will sector-by-sector imaging recover deleted files?
It captures them, which is the prerequisite for recovery. Deleted files persist on disk in unallocated sectors until something else overwrites them. A sector image preserves those unallocated regions, so you can run a recovery tool (PhotoRec, R-Studio, Autopsy) against the IMG file later to extract deleted files. A file-level backup throws this away because it only copies files the filesystem still tracks. This is the main reason forensic acquisition is always sector-by-sector.
Can Win32 Disk Imager handle drives with bad sectors?
Not gracefully. As of version 1.0.0, Win32 Disk Imager will abort on a read error rather than skip past it. For healthy SD cards and USB sticks this is fine. For failing HDDs, use ddrescue (under WSL or a Linux live USB) instead. ddrescue is purpose-built for failing drives: it skips bad regions, comes back later, retries with smaller block sizes, and logs everything, so you end up with the maximum recoverable data even if some sectors are unreadable.
What’s the difference between a raw IMG and an E01 forensic image?
The sector data is the same. E01 wraps it in a forensic container with embedded metadata, embedded hashes, optional compression, and split-file support. Raw IMG is just the sectors with no wrapper. For court-evidence work you want E01 (or AFF) so the image is self-documenting. For Pi backups, USB flashing, and general lab use, raw IMG is fine and tools like Win32 Disk Imager, Rufus, and balenaEtcher can write it back without fuss.
Does Win32 Disk Imager do bit-by-bit copying?
Yes, in the sense people usually mean. Every byte from the source ends up in the image, in physical order, with no skipping or interpretation. Technically the operation works at the sector level (512 bytes or 4 KiB at a time) rather than the literal bit level, but the practical result is identical to “bit-by-bit.” When marketing copy says bit-by-bit, that’s almost always what they mean.
Can I mount a sector-by-sector IMG file like a regular disk?
Yes. OSFMount (free, PassMark Software) can mount IMG partitions as drive letters in File Explorer on Windows. 7-Zip can browse partition contents directly without mounting. On Linux, losetup followed by mount attaches the IMG as a loop device and exposes its partitions. For ext4 partitions inside an IMG on Windows specifically, you’ll need DiskInternals Linux Reader or ext2fsd because Windows doesn’t read ext4 natively.
How long does sector-by-sector imaging take?
It’s bounded by the slower of the source-read speed and the destination-write speed. A 32 GB SD card on a USB 3.0 reader takes 6 to 10 minutes. The same card on USB 2.0 takes 30 to 45 minutes. A 1 TB SATA SSD imaged to another SSD takes about an hour. A 4 TB spinning HDD can take 8 to 12 hours. The math is straightforward: divide capacity by transfer rate and add 5% for overhead. There’s no magic shortcut because every byte has to physically move.
Does sector-by-sector preserve BitLocker or VeraCrypt encryption?
Yes, and that’s one of its strongest selling points. The encrypted blob gets copied verbatim, header and all. Restore the IMG to a fresh disk, unlock with the same password or recovery key, and the encrypted volume mounts identically to the original. This is the only sane way to back up an encrypted volume without first decrypting it, which matters when you’re imaging a machine where you don’t have decryption keys but you still need a forensic-quality copy.
Is sector-by-sector imaging legal?
Imaging a disk you own is legal everywhere I know of. Imaging someone else’s disk depends on consent and jurisdiction. For employer-owned hardware, IT staff with documented authority typically have the right to image. For law enforcement seizures, a warrant is usually required. For data recovery work on a customer drive, written authorization is standard practice. The technical operation is neutral; the legal weight comes from who’s authorized to do it.
Bottom Line
Sector-by-sector imaging means copying every byte of a storage device in physical order, regardless of whether those bytes hold real files, partition tables, boot code, or empty space. It’s the only approach that produces a bootable, forensically valid, encryption-preserving copy of a disk. It’s also the reason your Win32 Disk Imager IMG files are the same size as the source drive, even when most of the source is empty.
For Raspberry Pi backups, bootable USB preservation, encrypted volume copying, and forensic acquisition, sector-level is the right answer and Win32 Disk Imager 1.0.0 is one of the simplest tools that does it on Windows. For everyday document backup, file-level tools like Robocopy or File History are cheaper, faster, and more flexible. The two approaches solve different problems, and knowing which one you actually need is the whole point of understanding what sector-by-sector means in the first place.
If you’re new to all of this, start with the Win32 Disk Imager beginner’s guide, then read What is an IMG file for the file format side, and circle back here when you want to know what’s actually happening underneath.