0

This is a follow up to things I've written down in an answer to another question:

I'm somewhat sure that wbengine of Windows Server 2008 R2 always creates new VHD files if targeting a network share. Here's what some docs and other people say to that topic:

If you save a backup to a remote shared folder, that backup will be overwritten if you use the same folder to back up the same computer again.[...]

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc742130(v=ws.10)

Note that if you are backing up to a network share then a full backup will be run every time (because VSS is unavailable) overwriting the previous full backup. In this case there is no backup policy at all, you are simply maintaining a remote shadow/copy of the system.

https://lennox-it.uk/a-complete-guide-to-wbadmin-windows-backups

Das kommt darauf an auf welches Medium du sicherst. Wenn auf Festplatten ect. gesichert wird, dann wird immer inkrementell gesichert. Wird auf ein Share gesichert, dann ist es immer ein Vollbackup, wobei das letzte Backup überschrieben wird.

https://administrator.de/forum/verständnisfragen-windows-server-backup-2012-294395.html

Looking at my own tests using Windows 2008 R2, "overwritten" seems to be a bit misleading here, because it seems that really new files get created, as not only names of the images change, but their inodes as well:

root@[...]:~# ls -lisa "/volume1/[...]/WindowsImageBackup/[...]/Backup 2019-11-01 190024"
total 247604492
 435         0 drwx------+ 1 [...] users         2582 Nov  2 09:12 .
 430         0 drwx------+ 1 [...] users          108 Nov  1 19:58 ..
8200 214832596 -rwx------+ 1 [...] users 220521977856 Nov  1 21:33 3e4779f7-b3e1-11e0-b58f-001999a28c91.vhd
8199  32764536 -rwx------+ 1 [...] users  42484091904 Nov  1 20:12 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
8214         4 -rwx------+ 1 [...] users         1078 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
8216        12 -rwx------+ 1 [...] users        11940 Nov  1 21:34 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Components.xml
8213         8 -rwx------+ 1 [...] users         5500 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_RegistryExcludes.xml
8203         4 -rwx------+ 1 [...] users         3138 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer0bada1de-01a9-4625-8278-69e735f39dd2.xml
8210         4 -rwx------+ 1 [...] users         1934 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer2a40fd15-dfca-4aa8-a654-1f8c654603f6.xml
8208         4 -rwx------+ 1 [...] users         3414 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
8207         4 -rwx------+ 1 [...] users         1488 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
8212         4 -rwx------+ 1 [...] users         1630 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer59b1f0cf-90ef-465f-9609-6ca8b2938366.xml
8202         4 -rwx------+ 1 [...] users         1628 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writer75dfb225-e2e4-4d39-9ac9-ffaff65ddf06.xml
8211         4 -rwx------+ 1 [...] users          950 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writera65faa63-5ea8-4ebc-9dbd-a0c4db26912a.xml
8209         4 -rwx------+ 1 [...] users         1484 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
8206         4 -rwx------+ 1 [...] users         3844 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
8205         8 -rwx------+ 1 [...] users         4288 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
8201         4 -rwx------+ 1 [...] users         1746 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writerd61d61c8-d73a-4eee-8cdd-f6f9786b7124.xml
8204      7284 -rwx------+ 1 [...] users      7455796 Nov  1 21:33 9506dbe7-82a5-4559-96b3-0a2632ae05f9_Writere8132975-6f93-4464-a53e-1050253ae220.xml
8215         4 -rwx------+ 1 [...] users         1098 Nov  1 21:33 BackupSpecs.xml

root@[...]:~# ls -lisa "/volume1/[...]/WindowsImageBackup/[...]/Backup 2019-11-02 190054"
total 247603788
 435         0 drwx------+ 1 [...] users         2582 Nov  2 21:51 .
 430         0 drwx------+ 1 [...] users          108 Nov  2 19:59 ..
8247         4 -rwx------+ 1 [...] users         1078 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
8249        12 -rwx------+ 1 [...] users        11940 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Components.xml
8246         8 -rwx------+ 1 [...] users         5500 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_RegistryExcludes.xml
8236         4 -rwx------+ 1 [...] users         3138 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer0bada1de-01a9-4625-8278-69e735f39dd2.xml
8242         4 -rwx------+ 1 [...] users         1934 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer2a40fd15-dfca-4aa8-a654-1f8c654603f6.xml
8239         4 -rwx------+ 1 [...] users         3414 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
8243         4 -rwx------+ 1 [...] users         1488 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
8241         4 -rwx------+ 1 [...] users         1630 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer59b1f0cf-90ef-465f-9609-6ca8b2938366.xml
8235         4 -rwx------+ 1 [...] users         1628 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writer75dfb225-e2e4-4d39-9ac9-ffaff65ddf06.xml
8244         4 -rwx------+ 1 [...] users          950 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writera65faa63-5ea8-4ebc-9dbd-a0c4db26912a.xml
8245         4 -rwx------+ 1 [...] users         1484 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
8240         4 -rwx------+ 1 [...] users         3844 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
8238         8 -rwx------+ 1 [...] users         4288 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
8234         4 -rwx------+ 1 [...] users         1746 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writerd61d61c8-d73a-4eee-8cdd-f6f9786b7124.xml
8237      7284 -rwx------+ 1 [...] users      7455796 Nov  2 21:51 0d420c40-f14c-4622-85d0-da116fc45608_Writere8132975-6f93-4464-a53e-1050253ae220.xml
8233 214832596 -rwx------+ 1 [...] users 220521977856 Nov  2 21:51 3e4779f7-b3e1-11e0-b58f-001999a28c91.vhd
8232  32763832 -rwx------+ 1 [...] users  42481994240 Nov  2 20:11 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd
8248         4 -rwx------+ 1 [...] users         1098 Nov  2 21:51 BackupSpecs.xml

That is different to what I see on my USB-disks, where images keep their names and file-IDs(/inodes) and only most of the XML files get new UUIDs. On the USB-disks the parent directory of the VHD(X) changes as well, but that is simply a rename and hence doesn't influence the child files in any way. At one point during the tests I managed that wbengine decided to keep names of VHD files, but their inode changed always. Didn't invoke with any new command line, though, but simply subsequently:

8260 32767464 -rwx------+ 1 [...] users 42481994240 Nov  3 12:47 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd

8266 32764416 -rwx------+ 1 [...] users 42481994240 Nov  3 13:18 5d3e4b2f-b386-11e0-ac00-806e6f6e6963.vhd

I don't know why they implemented things this way in case of using shares, as it breaks e.g. underlying BTRFS-snapshots. But that's exactly what I see: All the snapshots my NAS creates for the folder where I store those backups almost have all associated storage exclusively instead of sharing large parts of the data. Additionally, according to log file sizes and runtime lengths of wbengine, all backups almost take the same amount of time, even though files in the backed up source don't change too much.

So, why did MS choose that implementation of recreating image files?

0

The only thing coming into my mind is image file size, as I've read somewhere that VHD files can't be shrinked efficiently and that improved with VHDX. Newer versions of Windows use VHDX and for those I indeed see that these files are reused, keeping their inodes, making them a bit better compatible with snapshots of BTRFS and ZFS.

Other reasons, maybe official statements?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.