What is the most efficient, native way to image a Windows partition?
There isn't one anymore since Windows Backup is being phased out (probably because this was a bad product to start with).
Windows Backup and Restore is nothing more than a different, albeit inefficient, way than ImageX/DISM to image a partition in Windows:
- Windows 7 Backup and Restore was deprecated due to being rarely used (per Microsoft), and was replaced with File History in Windows ≥8
- Windows Backup and Restore creates individual VHD images with little to no compression, being inefficient for a variety of reasons:
- Little to no compression
(storage inefficient - VHD is created and data copied to it)
- No data verification [parity]
(data within VHDs are subject to corruption, unlike data in WIMs/ESDs)
- VHDs cannot be directly converted to WIMs/ESDs
(ImageX/DISM would need to be used)
- Windows Backup and Restore initially is no different than creating a VHD and using
RoboCopy to copy all data, maintaining ACLs, to the VHD from the source partition; if a user then chooses to perform differential backups, it operates in a similar fashion as the smart compression feature of WIMs/ESDs through hash verification [/Append-Image], and while similar in this specific aspect, Backup and Restore uses little, if any, compression, making it storage inefficient and reliant upon external files
- I have thus far been unable to find anything on Mircosoft Docs that explains what Windows Backup and Restore uses on the backend (perhaps
wbadmin and VSS, robocopy, or Powershell since ACLs must be maintained)
- WIM vs VHD vs FFU: Comparing image file formats
Windows Backup and Restore relies upon a whole host of external files residing outside of the VHD to work correctly [below], in contrast to a self-contained WIM/ESD image that relies upon no external files
- Windows Backup and Restore file hierarchy:
Note VHD size (8.46GB) versus WIM (2.83GB) / ESD (1.93GB) images of the same OS
PS $ Ls "D:\WindowsImageBackup\SandBoxed-PC\Backup 2020-09-01 112553\5930f872-f00e-11e6-92bd-806e6f6e6963.vhd" | Measure-Object -Sum Length
Count : 1
Sum : 8,468,323,328
Property : Length
PS $ Ls "D:\Base.esd" | Measure-Object -Sum Length
Count : 1
Sum : 1,933,984,026
Property : Length
PS $ Ls "D:\Base.wim" | Measure-Object -Sum Length
Count : 1
Sum : 2,833,440,068
Property : Length
PS $ Ls "D:" -Recurse -Force
Directory: "D:"
Mode LastWriteTime Length Name
----- ------------------ ------------- -------------
d-r-- 9/1/2020 6:25AM "SANDBOXED-PC"
d--hs 9/1/2020 6:32AM "System Volume Information"
-a--- 9/1/2020 11:17AM 1,933,984,026 "Base.esd"
-a--- 9/1/2020 10:46AM 2,833,440,068 "Base.wim"
-ar-- 9/1/2020 10:25AM 528 "MediaID.bin"
-a--- 9/1/2020 9:38AM 0 "Windows"
Directory: "D:\SANDBOXED-PC"
Mode LastWriteTime Length Name
----- ------------------ ------------- -------------
d---- 9/1/2020 6:26AM "Backup Set 2020-09-01 062552"
-a-hs 9/1/2020 6:25AM 226 "Desktop.ini"
-ar-- 9/1/2020 6:25AM 528 "MediaID.bin"
Directory: "D:\SANDBOXED-PC\Backup Set 2020-09-01 062552"
Mode LastWriteTime Length Name
----- ------------------ ------------- -------------
d---- 9/1/2020 6:26AM "Backup Files 2020-09-01 062552"
d---- 9/1/2020 6:26AM "Catalogs"
Directory: "D:\SANDBOXED-PC\Backup Set 2020-09-01 062552\Backup Files 2020-09-01 062552"
Mode LastWriteTime Length Name
----- ------------------ ------------- -------------
d--h- 9/1/2020 6:26AM "Catalogs"
-a--- 9/1/2020 6:25AM 1,501,283 "Backup files 1.zip"
-a--- 9/1/2020 6:26AM 51,477,299 "Backup files 2.zip"
Directory: "D:\SANDBOXED-PC\Backup Set 2020-09-01 062552\Backup Files 2020-09-01 062552\Catalogs"
Mode LastWriteTime Length Name
----- ------------------ ------------- -------------
---h- 9/1/2020 6:25AM 4,5540 "Backup files 1.wbcat"
---h- 9/1/2020 6:25AM 0 "Backup files 1.wbverify"
---h- 9/1/2020 6:26AM 11,448 "Backup files 2.wbcat"
---h- 9/1/2020 6:26AM 0 "Backup files 2.wbverify"
Directory: "D:\SANDBOXED-PC\Backup Set 2020-09-01 062552\Catalogs"
Mode LastWriteTime Length Name
----- ----------------- ------------- -------------
-a--- 9/1/2020 6:26AM 55,736 "GlobalCatalog.wbcat"
Directory: "D:\WindowsImageBackup"
Mode LastWriteTime Length Name
----- ------------------ ------------- -------------
d---- 9/1/2020 6:32AM "SandBoxed-PC"
Directory: "D:\WindowsImageBackup\SandBoxed-PC"
Mode LastWriteTime Length Name
----- ------------------ ------------- -------------
d---- 9/1/2020 6:32AM "Backup 2020-09-01 112553"
d---- 9/1/2020 6:32AM "Catalog"
d---- 9/1/2020 6:32AM "SPPMetadataCache"
-a--- 9/1/2020 6:26AM 16 "MediaId"
Directory: "D:\WindowsImageBackup\SandBoxed-PC\Backup 2020-09-01 112553"
Mode LastWriteTime Length Name
----- ------------------ ------------- -------------
-a--- 9/1/2020 6:38AM 41,956,352 "5930f871-f00e-11e6-92bd-806e6f6e6963.vhd"
-a--- 9/1/2020 6:39AM 8,468,323,328 "5930f872-f00e-11e6-92bd-806e6f6e6963.vhd"
-a--- 9/1/2020 6:32AM 1,186 "BackupSpecs.xml"
-a--- 9/1/2020 6:32AM 1,078 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml"
-a--- 9/1/2020 6:32AM 13,850 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_Components.xml"
-a--- 9/1/2020 6:32AM 6,542 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_RegistryExcludes.xml"
-a--- 9/1/2020 6:32AM 3,624 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml"
-a--- 9/1/2020 6:32AM 1,488 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml"
-a--- 9/1/2020 6:32AM 1,484 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml"
-a--- 9/1/2020 6:32AM 3,844 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml"
-a--- 9/1/2020 6:32AM 6,284 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml"
-a--- 9/1/2020 6:32AM 7,110 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_Writercd3f2362-8bef-46c7-9181-d62844cdc0b2.xml"
-a--- 9/1/2020 6:32AM 3,523,696 "cf5c5a6c-de1c-484d-b7af-9dc09006d309_Writere8132975-6f93-4464-a53e-1050253ae220.xml"
Directory: "D:\WindowsImageBackup\SandBoxed-PC\Catalog"
Mode LastWriteTime Length Name
---- ------------------ ------------- -------------
-a--- 9/1/2020 6:26AM 5,812 "BackupGlobalCatalog"
-a--- 9/1/2020 6:32AM 7,726 "GlobalCatalog"
Directory: "D:\WindowsImageBackup\SandBoxed-PC\SPPMetadataCache"
Mode LastWriteTime Length Name
---- ------------------ ------------- -------------
-a--- 9/1/2020 6:32AM 57,752 "{cf5c5a6c-de1c-484d-b7af-9dc09006d309}"
Only DISM is left, but it only does file backup, not partition image backup.
The DISM man page on Microsoft Docs must just be nonsensical gibberish then...
DISM/ImageX CAN do file/directory backups, however it's MAIN USE is to image Windows partitions; the -image portion of the DISM commands does imply this after all:
DISM/ImageX is used daily by all laptop and PC OEMs via either MDT (Microsoft Deployment Toolkit) or SCCM (Service Center Configuration Manager).
It's likely most folks have heard of neither, but each is for the deployment of Windows via master WIMs/ESDs to anywhere from tens to thousands of machines and is why businesses pay thousands of dollars for SCCM licenses
- Once a Task Sequence in either is configured (for example, with Windows customizations, all software & drivers to install, etc.) and the resultant
WinPE.wim is booted, the install of the OS, drivers, and third-party applications is completely automated through the seven Windows install phases
MDT or SCCM Task Sequence example: 
WIMs/ESDs have been the only way to natively image Windows since Windows XP, via ImageX in Windows XP, Vista, & 7, and DISM in Windows 8, 8.1, & 10.
ImageX cannot be used to image in Windows ≥8 and DISM cannot be used to image in Windows ≤7, as Microsoft changed DISM in Windows 8, adding in the imaging features ImageX was previously used for
(Attempting to use either to capture an image in the other will result in an error)- VHDs cannot be directly converted to WIMs/ESDs
- WIMs/ESDs are what Windows is built upon:
- When you boot to WinRE, it's booting:
\\<winre-partition>\Recovery\WindowsRE\WinRE.wim
- When you boot Windows install media, it's booting:
\\<install-media>\sources\boot.wim
- When you install Windows, it's installed via
DISM/ImageX from:
\\<install-media>\sources\(install.esd||install.wim)
Its new Full Flash Update (FFU) images take a sector-by-sector image of the entire disk, which unfortunately also includes unused sectors, so not at all efficient.
FFUs are only intended for OEMs and businesses deploying the same partition images to tens to thousands of machines, simplifying MDT and SCCM deployments, not users looking to image their Windows partition(s):
- This is obvious to anyone actually glancing at the FFU man page, considering the first sentence is:
"Deploy Windows faster on the factory floor by using the Full Flash Update (FFU) image format. "
Why is the native method generally the best method for most users?
It isn't for Windows, as above. Microsoft has left the field in favor of third-party products.
If, as the author states:
- "it isn't for Windows":
The DISM man page on Microsoft Docs must just be nonsensical gibberish then for some unknown BSD or Linux distro...
- "Microsoft has left the field in favor of third-party products":
It appears Microsoft, OEMs, businesses, universities, governmental institutions, and everyday users never received that message... As listed above, combined with the fact Microsoft regularly updates DISM:
- Windows is installed from an
install.wim/install.esd
- WinRE boots from a
WinRE.wim
- Windows 10 bi-annual updates use an
install.wim/install.esd
(Windows Update as of ~v1809 uses the Component Store [%WinDir%\WinSxS])
- If WIMs/ESDs were not the most efficient means to image a Windows partition, businesses and governments wouldn't be paying thousands of dollars for SCCM
How does the native method differ from conventional cloning?
DISM does not do cloning at all.
The DISM man page on Microsoft Docs must just be nonsensical gibberish then...
What are the pros and cons of native versus third-party tools?
The pros of third-party tools is that they work well and efficiently. Most are also free to use.
Perhaps this has been the author's personal experience, however a simple search on StackExchange demonstrates this perspective isn't based in reality:
Example products are AOMEI Backupper, Clonezilla, Macrium Reflect, EaseUS ToDo BackUp. YMMV.
All of which are non-native solutions, making them inefficient since they're not able to be natively used in WinPE/WinRE, many of which introduce configuration issues:
- A conventional partition-level or disk-level image contains offset, alignment, block size, etc., and the vast majority of Windows users have no need for partition-level or disk-level images, as NTFS has been the default filesystem since Windows XP, with WIMs/ESDS being natively supported and vastly more efficient than any partition-level or disk-level image
- These third-party tools lack native Windows support and therefore requires non-standard third-party programs and/or non-standard boot media that isn't the default WinPE/WinRE
- Partition-level and disk-level images lack compression by default, one of the main advantages of the WIM/ESD smart compression image format
- Partition-level and disk-level images lock the user to that specific partition or disk layout (offset, alignment, block size, etc.)
- Partition-level and disk-level images often have no data verification [parity] and are therefore subject to data corruption, unlike WIMs/ESDs, which are impossible to corrupt when commands are always issued with
/CheckIntegrity (ImageX: /Check) and /Verify
Historical note:
DISM was conceived by Microsoft decades ago in an ancient version of Windows (Vista), using the Windows Imaging Format (WIM), which is a file-based disk image format, used mostly for software distribution. For backup, Microsoft has created Windows Backup, of which a limited version is still available in Windows 10 as "Back up and Restore (Windows 7)", but without its problematic image backup feature.
It appears few, if any, actual historical sources were referenced:
DISM in Vista is not the same as DISM in Windows 8, 8.1, or any version of 10 (see 2nd quote above)- There's no purpose to a partition-level or drive-level image since NTFS has been the default filesystem since XP, rendering either pointless when compared to a WIM/ESD
- There's a reason why Microsoft has used WIMs for the better part of two decades, as it's the most efficient means to image partitions on Windows
- If WIMs/ESDs were not the most efficient means to image a Windows partitions, businesses wouldn't be paying thousands of dollars for SCCM.
- A better, more efficient means of imaging partitions in a format immune to corruption at the same or better compression ratios simply does not exist natively outside of WIMs/ESDs, and likely doesn't exist from a third party:
- A third-party would need to be on par with the compression rates of
Max and Recovery, have a manner within the image itself for data parity, and only use tools natively contained within a WinPE.wim
(I'm not aware of any, perhaps others are?)
The use of DISM as a backup utility is very strongly not recommended.
Perhaps by the author, but certainly not by Microsoft and others...
- Common Sense:
If DISM was as problematic and not recommended as the author contends, Microsoft wouldn't continue to have it be the backbone of Windows, from imaging to image servicing [Component Store], and it certainly wouldn't be the backbone of MDT and SCCM.
Please don't take my word for any of this, fact check it via the linked material throughout and source links below:
Sources:
- Microsoft Docs:
- What is DISM?
- ImageX Command-Line Options
- DISM Image Management Command-Line Options
- Append-Image
- Apply-Image
- Capture-Image
- Commit-Image
- Delete-Image
- Export-Image
- Get-ImageInfo
- Mount-Image
- Split-Image
- Unmount-Image
- Windows 7 Backup and Restore deprecated
- WIM vs VHD vs FFU: Comparing image file formats
- Microsoft Deployment Toolkit documentation
- System Center documentation
- Capture and apply Windows Full Flash Update (FFU) images
- WinPE Optional Components (OC) Reference
- DISM Configuration List and WimScript.ini Files
- Microsoft.com:
- How to buy System Center
- Windows Imaging File Format (WIM)
- Linux Man Pages:
- ntfsclone
- Spiceworks Forum:
- Dism /Capture-Image results
- Dism /Append-Image results
- Dism /Apply-Image results
- Dism /Export-Image results
