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-da11
6fc45608_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?
