Qual é a maneira nativa mais eficiente de criar uma imagem de uma partição do Windows?
- Por que o método nativo geralmente é o melhor método para a maioria dos usuários?
- Como o método nativo difere da clonagem convencional?
- Quais são os prós e os contras das ferramentas nativas versus de terceiros?
Como configuro as partições do sistema em uma nova unidade para aplicar uma imagem?
- Como uma resposta factualmente imprecisa de @harrymc ainda está recebendo votos positivos, em grande parte devido à antiguidade de seu site, consulte esta resposta, que verifica cada uma de suas reivindicações.
- Resposta aceita, factualmente precisa
- Anotação:
- Muitos tiveram problemas com a nomenclatura "imagem" com "imagem" [por Microsoft] sendo a terminologia correta
- Não cabe a um indivíduo alterar a nomenclatura de um desenvolvedor e, se eu alterasse a nomenclatura de forma arbitrária e individual, isso só geraria mais confusão ao fazer referência a Microsoft Docs [páginas de manual do Windows]
- Embora eu não possa apontar definitivamente para nenhum whitepaper específico do Windows, a nomenclatura de "imagem" do Windows provavelmente vem de como o Windows é referido do ponto de vista de serviço, que é como uma "imagem" e é por isso que
DISMtem os parâmetros/Onlinee :/Image- O serviço de imagem online lida com um
%SystemDrive%tempo inicializado nele - O serviço de imagem offline lida com um não inicializado para
%SystemDrive% - O gerenciamento de imagens lida com o tópico desta pergunta
- O serviço de imagem online lida com um
- Muitos tiveram problemas com a nomenclatura "imagem" com "imagem" [por Microsoft] sendo a terminologia correta
Para a maioria dos usuários, capturar uma imagem de uma partição do Windows via (Win XP ≤ 7: ) é geralmente o melhor e mais eficiente método, além de não causar os problemas de configuração muito comuns com ferramentas de terceiros.
DISMImageX/Compress:Recovery(algoritmo é ~33% mais eficiente que/Compress:Max): Somente uma instalação inicializável do Windows pode ser capturada como ESD
DISMincluídos neles (Win XP ≤ 7:ImageX) :SHIFTF10
é uma imagem WinPE contendo componentes opcionais WinPE extras vitais para a recuperação)
Anotação:
DISMtem os parâmetros/Onlinee :/Image%SystemDrive%tempo inicializado nele%SystemDrive%Imagem:
(Mapeamento de cmdlet do Powershell)
Especifique exclusões ou exceções criando um
WimScript.iniarquivo de configuração,/ScratchDirsendo necessário no WinPE, pois possui apenas 32 MB de espaço temporário [temp] por padrão:/Compress:Maxpara/Compress:Fastse não estiver salvando a imagem capturada em um SSD.swmarquivos somente leitura por meio de/Split-Image/Delete-Imageou exportados para sua própria imagem via/Export-ImageAcessando dados em um WIM ou ESD:
Somente leitura:
/ReadOnly).wim/.esdna GUI do 7zip/discardalterações)Faça alterações ou adicione dados a uma imagem [índice]:
/Commitalterações)DISM, para salvar as alterações como uma nova imagem anexada, adicione/Append/CheckIntegrity(ImageX:/Check) e/Verifysejam sempre usados.wim/.esdnão é a melhor solução para todos os casos de uso de imagem [clonagem], mas é para a maioria:.wim/.esdrequer um meio de armazenamento para abrigar a imagem capturada (partição sem imagem, unidade USB, compartilhamento de rede, etc.) , servindo ao duplo propósito de também ser uma imagem de base de backup real.wim/.esdquando uma nova imagem [índice] é anexada a ele; imagens recém-anexadas utilizam a mesma cópia de arquivos inalterados já contidos na imagem da(s) imagem(ns) anterior(es) (hash verificado) , permitindo que uma imagem permaneça pequena em relação aos dados noexemplo de imagem anexada:
(observe
Base.wimo tamanho comparado a cada índice contido e soma de todos os dados nele contidos) :A grande maioria dos usuários do Windows não precisa de imagens em nível de partição ou em nível de disco:
DISM/ImageXcreates a filesystem image, not a partition partition-level or disk-level image:(Win ≥ XP uses NTFS as the default filesystem)
C:\],DISM/ImageXcaptures an image of all data on that partition, but not the structure of the partition/drive itself (offset, alignment, block size, etc.), bypassing the inconvenience a conventional partition/drive image creates, as only filesystem data is contained within a.wim/.esd, allowing it to be applied to any partition, regardless of size difference or whether there is existing data on the partition.Third-party tools will almost always fall into one of two categories, Linux-based or Windows-based via
DISM/ImageX/Powershell, with many resulting in configuration issues, and the latter sometimes encompassing developers who use proprietary image file formats and custom boot environments (many of which are Linux-based).DISM(Win XP ≤ 7:ImageX), however thousands of questions, answers, and comments exist for issues arising from third-party imaging tools:Windows cloning problem (3,838 results)
DISM:Dism /Capture-Imageissue (60 results)Windows
Dism /Capture-Imageproblem (44 results)Dism /Append-Imageissue (20 results)Windows
Dism /Append-Imageproblem (12 results)Dism /Apply-Imageissue (85 results)Windows
Dism /Apply-Imageproblem (93 results)ImageX:ImageX /Captureissue (19 results)Windows
ImageX /Captureproblem (20 results)ImageX /Appendissue (10 results)Windows
ImageX /Appendproblem (5 results)ImageX /Applyissue (15 results)Windows
ImageX /Applyproblem (12 results)Ever come across advice telling a BSD or Linux user to boot to Windows or use Wine to back up their data? For example,
ntfsclone(part ofntfs-3g) is a popular Linux utility, with the following from it's man page:WIMs/ESDs don't have these issues since they only contain filesystem information (files and directories), not partition/drive level data, allowing them to be applied to any partition, regardless of size difference or whether there is existing data.
Native Pros:
/CheckIntegrity(ImageX:/Check) &/Verifyare always usedNative Cons:
/Compress:Maxor/Compress:Recovery, it's more efficient to use/Compress:Fast, exporting the image later usingMaxorRecovery/CheckIntegrity(ImageX:/Check) andVerifydo extend the image processing time, they should always be usedDiskPart: (select the OS drive the image is being applied to)Assumes no data on drive is being preserved, as
cleanwipes the drive's partition table UEFI:WinRE.wimis ~300MB in size)C:can't be assigned: change 4 & 5 to another letter)BIOS: UEFI:
If storing User Data directories on a partition other than
C:\(recommended), max size required is ~300GB (multiply size wanted by 1024:200*1024=204800)BIOS: UEFI:
BIOS: UEFI:
UEFI:
What is the most efficient, native way to image a Windows partition?
There isn't one any more since Windows Backup is being phased out (probably because this was a bad product to start with).
Only DISM is left, but it only does file backup, not partition image backup. Its new Full Flash Update (FFU) images takes a sector-by-sector image of the entire disk, which unfortunately also includes unused sectors, so not at all efficient.
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.
How does the native method differ from conventional cloning?
DISM does not do cloning at all.
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.
Example products are AOMEI Backupper, Clonezilla, Macrium Reflect, EaseUS ToDo BackUp. YMMV.
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. The use of DISM as a backup utility is very strongly not recommended.
Windows Backup and Restore is nothing more than a different, albeit inefficient, way than
ImageX/DISMto image a partition in Windows:(storage inefficient - VHD is created and data copied to it)
(data within VHDs are subject to corruption, unlike data in WIMs/ESDs)
(
ImageX/DISMwould need to be used)RoboCopyto 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 fileswbadminand VSS,robocopy, or Powershell since ACLs must be maintained)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
Note VHD size (8.46GB) versus WIM (2.83GB) / ESD (1.93GB) images of the same OS
The
DISMman page on Microsoft Docs must just be nonsensical gibberish then...DISM/ImageXCAN do file/directory backups, however it's MAIN USE is to image Windows partitions; the-imageportion of theDISMcommands does imply this after all:DISM/ImageXis 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
WinPE.wimis booted, the install of the OS, drivers, and third-party applications is completely automated through the seven Windows install phasesMDT or SCCM Task Sequence example:
WIMs/ESDs have been the only way to natively image Windows since Windows XP, via
ImageXin Windows XP, Vista, & 7, andDISMin Windows 8, 8.1, & 10.ImageXcannot be used to image in Windows ≥8 andDISMcannot be used to image in Windows ≤7, as Microsoft changedDISMin Windows 8, adding in the imaging featuresImageXwas previously used for(Attempting to use either to capture an image in the other will result in an error)
\\<winre-partition>\Recovery\WindowsRE\WinRE.wim\\<install-media>\sources\boot.wimDISM/ImageXfrom:\\<install-media>\sources\(install.esd||install.wim)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):
"Deploy Windows faster on the factory floor by using the Full Flash Update (FFU) image format. "
If, as the author states:
The
DISMman page on Microsoft Docs must just be nonsensical gibberish then for some unknown BSD or Linux distro...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:install.wim/install.esdWinRE.wiminstall.wim/install.esd(Windows Update as of ~v1809 uses the Component Store [
%WinDir%\WinSxS])The
DISMman page on Microsoft Docs must just be nonsensical gibberish then...Perhaps this has been the author's personal experience, however a simple search on StackExchange demonstrates this perspective isn't based in reality:
Windows cloning problem (3,838 results)
DISM:Dism /Capture-Imageissue (60 results)Windows
Dism /Capture-Imageproblem (44 results)Dism /Append-Imageissue (20 results)Windows
Dism /Append-Imageproblem (12 results)Dism /Apply-Imageissue (85 results)Windows
Dism /Apply-Imageproblem (93 results)ImageX:ImageX /Captureissue (19 results)Windows
ImageX /Captureproblem (20 results)ImageX /Appendissue (10 results)Windows
ImageX /Appendproblem (5 results)ImageX /Applyissue (15 results)Windows
ImageX /Applyproblem (12 results)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:
/CheckIntegrity(ImageX:/Check) and/VerifyIt appears few, if any, actual historical sources were referenced:
DISMin Vista is not the same asDISMin Windows 8, 8.1, or any version of 10 (see 2nd quote above)MaxandRecovery, have a manner within the image itself for data parity, and only use tools natively contained within aWinPE.wim(I'm not aware of any, perhaps others are?)
Perhaps by the author, but certainly not by Microsoft and others...
If
DISMwas 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: