Why a 64GB Card Image May Not Fit Another 64GB Card
- A shared 64GB label does not establish that source and target report the same addressable byte count.
- Check the exact part datasheet for a minimum reported user capacity, then compare it with measured bytes or sector counts on the actual cards.
- File usage, partition layout and the full length of a raw disk image are different measurements.
- Preserve the golden source, measure the target and validate the restore method on expendable cards.
A 64GB image may fail on another card marked 64GB because the restore method needs more addressable space than the target reports, or because the tool will not adapt the saved layout. The amount of free space inside the source filesystem does not settle either question. Check the exact bytes and the image method before blaming the target card.
This is a deployment problem for a customer-managed golden image. The 64GB/128GB unit conversion explains why a decimal capacity label looks smaller in GiB, but it does not establish that two cards have an identical device-reported byte count. The SD Association capacity tiers identify the card class and filesystem family; they are not a substitute for measuring the specific source and target.
Which size is the restore tool checking?
| Measurement | What it tells you | Why it can mislead if used alone |
|---|---|---|
| Files used in a volume | Data currently stored inside the filesystem | A whole-device image may include unused space and disk layout. |
| End of the last partition | The highest partition extent defined by the saved layout | A partition-aware restore may need at least that address range, plus any table metadata. |
| Full raw-image length | Bytes captured when the entire source device was imaged | Writing that file as-is requires a target large enough for the full byte stream. |
| Exact part's minimum user capacity | A vendor datasheet may state a minimum actual/user size for a specific card part number. Record its unit and revision. | It is a part-specific specification, not proof that every card marked 64GB has that byte count or that a particular reader reports it identically. |
| Target device size | Addressable bytes reported through the chosen reader or host | A matching printed capacity does not prove this equals the source or image length. |
Some microSD specifications list an “Actual Size (Min)” beside each part number. Use that entry as a procurement floor only after confirming its unit and the exact card revision. For restore acceptance, record the source and target's reported logical-sector counts and sector sizes, or total bytes, through the intended host. Do not compare a rounded datasheet “GB” figure with a tool's GiB display as if they were the same unit.
The tool and image format determine which limit applies. A byte-for-byte, whole-device image has the length of the source device, even if only a small amount of file data is used. If the target reports fewer bytes, writing the whole image cannot complete. A filesystem-aware tool may skip unused blocks, but it may still retain partition positions or reject a smaller target. Clonezilla documents a smaller-target warning in its beginner mode; Macrium's MRAuto workflow has its own fixed-layout and target-size rule. Those examples describe particular tools and modes, not every imaging product.
Do not bypass a size warning merely because the files appear to fit. A raw image can include a partition or backup table at the end of the source device. Truncating it or forcing a restore may leave an invalid layout or inaccessible data. A different deployment method needs its own tested preparation and recovery plan.
Record the source, image and target before restoring
Protect the only golden source and preserve a verified backup image. Identify each reader and device path before running any command that can write to media. Use a read-only query in the intended environment to capture the following:
| Item | Source card / image | Target sample |
|---|---|---|
| Card model, revision, lot and reader path | Record identity and connection | Record identity and connection |
| Device-reported total bytes and logical-sector size | Measure source; note image file length separately | Measure target through intended reader or host |
| Published minimum user size for the exact card part | Record the vendor datasheet value, unit and revision, if supplied | Check the candidate's own part-specific floor; compare it with the measured byte count |
| Image format, tool and version | Raw whole-device or partition/filesystem aware? | Confirm this target is supported by that mode |
| Last partition end and boot layout | Record from the saved layout | Confirm a supported restore plan |
| System acceptance | Required boot and application behavior | Record results on the deployed sample |
For example, on a Linux test workstation blockdev --getsize64 /dev/<device> reports the identified block device's size in bytes; the util-linux manual distinguishes that read-only query from commands that modify device state. Replace the placeholder only after confirming the device identity. Other operating systems and imaging tools have their own disk-inspection functions; retain the exact output and tool version rather than a rounded “64GB” screenshot.
Prepare a reusable image without risking the master
If the target is too small for the present restore method, the customer's engineering team can evaluate a working copy whose partitions and filesystem have been resized with a tool that supports that filesystem and boot scheme, or a deployment process that creates a target-specific layout before copying files. Neither choice follows automatically from “used files are smaller.” Preserve the original golden image, document every layout change, and prove boot, update and normal write behavior on an expendable target card before approving a fleet procedure.
A restore failure alone does not establish counterfeit capacity. If authenticity is in question, first protect needed data, then follow the separate full-capacity write/read-back test guide on a sacrificial sample. That test answers whether the reported space retained data; it does not fix an oversized image layout.
Kalstor supplies microSD hardware. Image creation, software loading and deployment validation belong to the equipment maker or its appointed provider. In a hardware inquiry, send the exact card part, required capacity, host/reader, expected lot quantity and any minimum addressable-byte requirement established by the customer's image process.
FAQ
Can a mostly empty 64GB card still produce an image too large for another 64GB card?
Does a smaller target byte count prove that a card is fake?
References
We publish measured usable capacity and define trial-batch verification against the quoted product and agreed test scope.