Does Windows Server's automatic incremental backup "work well" with multiple backup disks?

Question

Since Windows Server 2008 R2 (up to and including Server 2019, as far as I know), Windows Server Backup performs automatic management of full and incremental backup:

Automatic management of full and incremental backups. You no longer need to manage full and incremental backups. Instead, Windows Server Backup will, by default, create an incremental backup that behaves like a full backup. You can recover any item from a single backup, but the backup will only occupy space needed for an incremental backup. In addition, Windows Server Backup does not require user intervention to periodically delete older backups to free up disk space for newer backups—older backups are deleted automatically.

This sounds like a nice feature.

We, however, use two backup disks: One is always attached to the server for daily backups, and one is always in off-site storage. Every week we switch those disks, to ensure that we always have an off-site server backup that is as most a week old.

How do those incremental backups work with alternating disks?

Obviously, this would be fine (Option 1):

Day  1: Full backup on Disk A.
Day  2: Incremental backup (w.r.t. Day 1 backup) on Disk A.
Day  3: Incremental backup (w.r.t. Day 1+2 backup) on Disk A.
        ...
Day  8: Full backup on Disk B.
Day  9: Incremental backup (w.r.t. Day 8 backup) on Disk B.
Day 10: Incremental backup (w.r.t. Day 8+9 backup) on Disk B.
        ...
Day 15: Incremental backup (w.r.t. Day 1-7 backup) on Disk A.
Day 16: Incremental backup (w.r.t. Day 1-7+15 backup) on Disk A.

But this would not be fine (Option 2):

Day  1: Full backup on Disk A.
Day  2: Incremental backup (w.r.t. Day 1 backup) on Disk A.
Day  3: Incremental backup (w.r.t. Day 1-2 backup) on Disk A.
        ...
Day  8: Incremental backup (w.r.t. Day 1-7 backup) on Disk B.
Day  9: Incremental backup (w.r.t. Day 1-8 backup) on Disk B.
Day 10: Incremental backup (w.r.t. Day 1-9 backup) on Disk B.
        ...
Day 15: Incremental backup (w.r.t. Day 1-14 backup) on Disk A.
Day 16: Incremental backup (w.r.t. Day 1-15 backup) on Disk A.

because it would require both disks to restore (and, thus, defeat the purpose of having two disks).

Does Windows Server Backup use Option 1 or Option 2? And were is this documented?

(To clarify: The question is the previous paragraph in bold. It's not "how do I add a second disk to my backup set", nor is it "how do incremental backups work in general".)

I _think_ option 1 is the way wbadmin handles this, because the previous backup isn't found on the target disk's backup repository, it will create a full one. Don't have any documentation, though. I'd just try it if I were you. Edit: [found a thread](https://social.technet.microsoft.com/Forums/windowsserver/en-US/f9cd6cf1-7846-4364-b0eb-1ac5999ffe6f/forum-faq-windows-server-backup-ui-cannot-add-another-disk-to-a-scheduled-backup?forum=winserverfiles) in which it's discussed. For 2008R2 you had to add the second backup disk via command line, which can now be now done using the GUI, too. — Lenniey, Mar 13 '19 at 10:26
Also check [this SF thread](https://serverfault.com/questions/445881/multiple-usb-backup-targets-with-windows-server-backup), don't know if it's an exact duplicate. — Lenniey, Mar 13 '19 at 10:31
@Lenniey: Thanks, I've seen that thread. Fortunately, adding a second disk is much easier now. I also *think* that it's option 1 (because otherwise the fact that it *"behaves like a full backup"* would not be satisfied), but I'd just like to make sure - backups are too important to rely on gut feelings. Testing is hard, because Windows Server Backup sometimes does full backups on its own (even if it *could* make an incremental backup), so I can't deduce future behavior from looking at previous backups. — Heinzi, Mar 13 '19 at 10:42
Have you tried doing a restore from the offsite backup as a test? It seemed broken when I tried. — Louis Waweru, Feb 13 '20 at 10:20
@Louis: No, unfortunately, since I don't want to buy an expensive second server (or at least a lot of HDDs) just to do a restore test. I did, however, try to manually extract files from the backup, which worked (see my self-answer on [this question](https://serverfault.com/q/853373/17182)). — Heinzi, Feb 13 '20 at 11:00

score 1 · Answer 1 · edited Jun 11 '20 at 10:02

Does Windows Server's automatic incremental backup “work well” with multiple backup disks?

In my opinion, yes.

The following are the arguments I base my answer on, which allows additional discussion. There are still some aspects of how Windows Backup behaves under certain conditions I'm not that sure about and people might want to clarify or correct me. Nevertheless, I think they are worth mentioning here.

Does Windows Server Backup use Option 1 or Option 2? And were is this documented?

First of all, in general I agree with you and am pretty sure that wbadmin/wbengine implements option 1, but I don't have a definitive statement proving this from Microsoft as well. I additionally am somewhat sure that this is not related to Windows Server only, but works the same for non-Server editions of Windows. In fact, I'm using exactly your mentioned setup with 3 different USB-disks since Windows 7 already to create image based backups. 1 disk is off-site, two change regularly within one week.

What I see is that the VHD(X) files contained on the USB-disks are updated always and how long backups take and what files are transferred at all really depends on which files have changed since the USB-disk currently used as backup target has last been used. That's the incremental part mentioned in your docs, only backup differences, but those differences are always written to the existing files in the VHD(X).

Windows Image Backup DOES NOT manage incremental history of backups on its own, it ALWAYS overwrites the existing files in the currently used VHD(X) as backup target. Therefore there's NEVER an incremental history needed to restore from the currently available VHD(X). In case of NTFS-formatted USB-disks, the history is implemented using Volume Shadow Copies: Before doing a new backup, a shadow copy is created in the backup target, only afterwards wbengine opens the VHD(X) and replaces files within that as needed. Replacing files is done IN-PLACE, BLOCK-BY-BLOCK, wbengine really reads the changed source files, compares read blocks to the same blocks in the backup target and only overwrites in case of changes. Because there's a shadow copy in the backup target, VSS recognizes those changed blocks, which are actually changed blocks of the VHD(X) in the end, and copies things away before overwriting. So all shadow copies in the backup target always contain a fully functional VHD(X) of the formerly backed up system and those shadow copies create an incremental history in the end. Because all shadow copies contain a fully functional VHD(X), one doesn't need any additional incremental data, but can simply mount some snapshot, the VHD(X) within that snapshot and restore as needed. VSS will handle the details of collecting the associated blocks.

The following are the points I'm not that sure about:

How does Windows Image Backup decide which files to backup?

Windows/NTFS manages change journals on each volume, keeping track of which file has changed, how it has changed and because those are part of all NTFS volumes by default, they are available in the VHD(X) of the backup target as well. From my understanding, wbengine simply compares those journals to know which files need backup. This makes it easy to support different backup targets without caring about archive bits of files or stuff like that, because those change journals are bound to volume-unique file-IDs and those IDs are exactly the same in the backup target:

C:\>fsutil file queryfileid "C:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datei-ID: 0x000000000000000000080000000ea5f1

C:\>fsutil file queryfileid "D:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
Datei-ID: 0x000000000000000000080000000ea5f1

In the above example, C:\ is my current system volume while D:\ is the mounted last backup on one of the two available backup targets. Even file sizes, timestamps etc. are all the same:

C:\>dir /A "C:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
 Datenträger in Laufwerk C: ist System
 Volumeseriennummer: 266B-2863

 Verzeichnis von C:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin

03.02.2016  17:08           560.640 perlapp.exe
               1 Datei(en),        560.640 Bytes
               0 Verzeichnis(se), 1.337.040.216.064 Bytes frei

C:\>dir /A "D:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin\perlapp.exe"
 Datenträger in Laufwerk D: ist System
 Volumeseriennummer: 266B-2863

 Verzeichnis von D:\Program Files\ActiveState Perl Dev Kit 9.5.1\bin

03.02.2016  17:08           560.640 perlapp.exe
               1 Datei(en),        560.640 Bytes
               0 Verzeichnis(se), 1.281.302.233.088 Bytes frei

By using this approach, backup can decide at any time with any older VHD(X) which files need to be backed up, as long as the current journal and the one in the image have something in common, which are entry-IDs in my understanding. Without such a shared ID, e.g. because too many I/O happend productive and the backup is too old, wbengine would simply do a full backup instead of an incremental one.

Using those journals makes it as well pretty fast to know which files to backup, because one doesn't need to iterate the whole tree of files. That's what one actually sees in practice as well: Backup seems to know pretty soon which files to backup and starts processing those instead of iterating a file tree.

Behaviour in case of network shares as backup target for Windows Server 2008 R2.

In case of backing up to network shares, what wbengine does seems to depend on the version of Windows used, but in general the formerly described approach of only always having one VHD(X) per backed up volume in the backup target seems to hold as well. The main difference seems to be how that is achieved, either by overwriting existing VHD(X) files, deleting and recreating them or, pretty much like is the case with USB-disks, by opening and modifying them in-place.

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.

Behaviour in case of network shares as backup target for Windows Server 2012+.

Things seem to be a little bit different with newer versions of Windows: I'm somewhat sure that one customer of mine ran into troubles with wbadmin and Windows Server 2012 and during debugging those using Process Monitor, I verified that existing VHDX files were kept instead of deleted and recreated. I've tested this right now with Windows Server 2019 again and multiple invocations of wbadmin led to successful backups while KEEPING inodes of VHDX files the same:

root@[...]:~# ls -lisa "/volume1/[...]/Backup 2019-11-02 200024"
total 549063256
 271         0 d---------+ 1 user group          594 Nov  2 20:58 .
 266         0 d---------+ 1 user group          108 Nov  2 20:58 ..
 273 507813736 ----------+ 1 user group 520061190144 Nov  2 22:02 165c4b13-8376-4c55-9643-a8c1b2c17d6b.vhdx
3814         4 ----------+ 1 user group          776 Nov  1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
3816       440 ----------+ 1 user group       450488 Nov  1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_Components.xml
3813         8 ----------+ 1 user group         6212 Nov  1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_RegistryExcludes.xml
3815         4 ----------+ 1 user group         1192 Nov  1 22:47 BackupSpecs.xml
 272  41249064 ----------+ 1 user group  42289070080 Nov  2 22:03 f7650533-11ca-4db4-80f5-2db42f7b900a.vhdx

root@[...]:~# ls -lisa "/volume1/[...]/Backup 2019-11-03 132201"
total 549318872
 271         0 d---------+ 1 user group          594 Nov  2 20:58 .
 266         0 d---------+ 1 user group          108 Nov  3 14:19 ..
 273 507813736 ----------+ 1 user group 520061190144 Nov  3 14:19 165c4b13-8376-4c55-9643-a8c1b2c17d6b.vhdx
3814         4 ----------+ 1 user group          776 Nov  1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
3816       440 ----------+ 1 user group       450488 Nov  1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_Components.xml
3813         8 ----------+ 1 user group         6212 Nov  1 22:47 52e1a857-4620-43af-9f6e-a03fb53c7c30_RegistryExcludes.xml
3815         4 ----------+ 1 user group         1192 Nov  1 22:47 BackupSpecs.xml
 272  41504680 ----------+ 1 user group  42289070080 Nov  3 14:21 f7650533-11ca-4db4-80f5-2db42f7b900a.vhdx

root@[...]:~# ls -lisa "/volume1/[...]/Backup 2019-11-03 133308"
total 41262660
 271        0 d---------+ 1 user group        2504 Nov  3 14:44 .
 266        0 d---------+ 1 user group         108 Nov  3 14:30 ..
3851        4 ----------+ 1 user group         776 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
3853      440 ----------+ 1 user group      450488 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Components.xml
3850        8 ----------+ 1 user group        6212 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_RegistryExcludes.xml
3840        4 ----------+ 1 user group        3138 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer0bada1de-01a9-4625-8278-69e735f39dd2.xml
3848        4 ----------+ 1 user group        2284 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer2707761b-2324-473d-88eb-eb007a359533.xml
3844        8 ----------+ 1 user group        5386 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
3846        4 ----------+ 1 user group        1488 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
3839        4 ----------+ 1 user group        1628 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writer75dfb225-e2e4-4d39-9ac9-ffaff65ddf06.xml
3842       24 ----------+ 1 user group       21686 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writera65faa63-5ea8-4ebc-9dbd-a0c4db26912a.xml
3847        4 ----------+ 1 user group        1484 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
3845        4 ----------+ 1 user group        2940 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
3849        4 ----------+ 1 user group        1850 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerb2014c9e-8711-4c5c-a5a9-3cf384484757.xml
3843        8 ----------+ 1 user group        6048 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
3838        4 ----------+ 1 user group        1746 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writerd61d61c8-d73a-4eee-8cdd-f6f9786b7124.xml
3841    13068 ----------+ 1 user group    13379228 Nov  3 14:44 22c1a052-3d01-438c-87f8-acf63f14f5b5_Writere8132975-6f93-4464-a53e-1050253ae220.xml
3852        4 ----------+ 1 user group         758 Nov  3 14:44 BackupSpecs.xml
 272 41249064 ----------+ 1 user group 42289070080 Nov  3 14:44 f7650533-11ca-4db4-80f5-2db42f7b900a.vhdx

So in theory this should allow incremental backups replacing files in-place and efficient snapshots of e.g. underlying BTRFS or ZFS at the same time. Looking at storage of the snapshots of the tested Windows Server 2019, at least some of those really share some space:

    Total   Exclusive  Set shared  Filename
424.41GiB   417.69GiB     6.72GiB  /volume1/@sharesnap/[...]/GMT+01-2019.10.29-00.00.09
446.53GiB   400.16GiB    46.37GiB  /volume1/@sharesnap/[...]/GMT+01-2019.10.30-00.00.08
483.05GiB   448.36GiB    34.70GiB  /volume1/@sharesnap/[...]/GMT+01-2019.10.31-00.00.08
553.78GiB   209.26GiB   344.52GiB  /volume1/@sharesnap/[...]/GMT+01-2019.11.02-00.00.09
204.68GiB   204.63GiB     0.05GiB  /volume1/@sharesnap/[...]/GMT+02-2019.10.01-00.00.07
410.24GiB   405.37GiB     4.87GiB  /volume1/@sharesnap/[...]/GMT+02-2019.10.27-00.00.06

It's not as much as I would expect, but that might have other reasons, as this system is running into trouble backing up because of too few storage. That's actually why I'm investigating this topic again and came to this question. Looking at snapshots of other Windows 10 clients using image based backups as well, those mostly share much more. But those use the ZIP-based backup as well and the BTRFS subvolumes contain all backup-related directories per user, so the numbers might be a bit misleading.

The thing is that it might be that not much space is shared even though VHDX files are reused, because when I subsequently invoke backing up C: of that server, backup doesn't seem to get faster. The first backup might take longer as much data has changed, but after that is finished and with the server doing nothing, a second backup only a few minutes later should be a lot faster, because of only backing up differences of the files. But that doesn't seem to be the case, instead it seems to take the same time like before. Additionally, while BTRFS can share differences in created snapshots between different invocations of wbadmin with the exact same command line, those are much smaller than expected when really only backing up changed files:

root@[...]:~# btrfs filesystem du -s --gbytes /volume1/@sharesnap/[a-zA-Z]*/GMT*
     Total   Exclusive  Set shared  Filename
 446.53GiB   400.20GiB    46.33GiB  /volume1/@sharesnap/[...]/GMT+01-2019.10.30-00.00.08
 483.05GiB   448.36GiB    34.70GiB  /volume1/@sharesnap/[...]/GMT+01-2019.10.31-00.00.08
 553.78GiB   546.54GiB     7.24GiB  /volume1/@sharesnap/[...]/GMT+01-2019.11.02-00.00.09
  39.35GiB    37.68GiB     1.67GiB  /volume1/@sharesnap/[...]/GMT+01-2019.11.03-15.36.52
  39.35GiB    31.18GiB     8.17GiB  /volume1/@sharesnap/[...]/GMT+01-2019.11.03-15.49.03
  39.35GiB    37.98GiB     1.37GiB  /volume1/@sharesnap/[...]/GMT+01-2019.11.03-16.03.06
 410.24GiB   409.72GiB     0.52GiB  /volume1/@sharesnap/[...]/GMT+02-2019.10.27-00.00.06

That is different to what I see when backing up to my USB-disks, subsequent backups are much faster if nothing has changed. What is interesting is that others seem to be not so sure about how things behave on network shares as well:

If you create a scheduled backup job to network shared folder or a mapped network drive, all the backups will only be performed by full backup because network location is not a volume. If you need to create differential backup or incremental backup to network folder, you need to third party backup software.

https://www.ubackup.com/windows-server/windows-server-backup-differential-4348.html

While the same people write the following, which doesn't make much sense:

Tip: You can also use WBADMIN to create incremental backup to network share, like this:

wbadmin start backup –backupTarget: \backupshare\backup1 -allCritical -include:C: -vssFull –quiet

https://www.ubackup.com/articles/wbadmin-incremental-backup-5740.html

If VHD is recreated always, like seems to be the case for older versions of Windows, in case of backing up to shares, one doesn't get incremental backups. But even though those are kept and incremental backups like with USB-disks would be possible, changing -vssCopy to vssFull doesn't seem to change anything for me. Runtime of backups seems to be around the same in both cases.

Influence of -vssFull and -vssCopy.

There's some discussion on the web once in a while about what -vssFull and -vssCopy does regarding full, incremental and differential backups. In my opinion both arguments simply DON'T influence how wbengine decides which files to backup at all, because change journals are used always. What seems confusing regarding -vssCopy is especially the following:

A copy backup cannot be used for incremental or differential backups or restores.

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

Because of how image based backups work in my opinion and described above, I have no idea what MS means with that warning. I strongly guess that this sentence is NOT related to wbadmin itself at all, but 3rd party products instead and under that assumption the warning would be in line with what is document for -vssFull

Do not use this parameter if you are using a product other than Windows Server Backup to back up applications that are on the volumes included in the current backup.[...]

Even though -vssFull resets archive bits of files, I'm still convinced that those bits are NOT used by wbengine for its decision which files to backup in any setup. Instead, that argument tells other applications only if to do additional backup-related stuff:

All files are backed up, each file's history is updated to reflect that it was backed up, and the logs of previous backups may be truncated.[...]

Not sure if that influences change journals, though. I guess not because both arguments have the following statement in common:

All files are backed up[...]

Other explanations of those arguments seem to focus on 3rd party software as well:

So, when you do a VSS full backup , you create backup of all the files – but after that, the backup application may truncate logs on the file system.

https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/What-is-the-difference-between-VSS-Full-Backup-and-VSS-Copy/ba-p/423575

Those logs are those of Exchange or databases or whatever most likely, I guess not those change journals NTFS manages on its own. Same source like above:

Just a final technical note: The backup type (full, copy, incremental) can be specified by a VSS-based backup application at the beginning of the backup session, using the IVssBackupComponents:: SetBackupState . In response to that, any application that implements a VSS writer can choose to truncate the logs in the OnBackupComplete VSS event. This is one of the last events that a VSS-based backup application (such as DPM ) sends to all affected writer at the end of the backup session.

So in my opinion it's clear that -vssFull and -vssCopy only influence how things behave AFTER files have been backed up and DOES NOT influence which files to backup or how those get backed up. Executing the exact same command line for wbadmin with only -vssFull vs. -vssCopy to a network share doesn't change anything regarding VHD(X) as well for me.

score 0 · Answer 2 · answered Mar 13 '19 at 11:00

0

"Behaves like a full backup" does not mean a full backup. It is still based on the incremental backup system, it's just something optimized for improved recovery like Veeam did long time ago. You need the previous points.

If you alternate disks you will have to do something to keep have all the incremental points on both disks.

To solve your problem you will have to configure 2 separate jobs and schedule them to run when you know a specific disk is online. Example: schedule job 1 for disk 1 on weeks 1,3,5, etc. and jub 2 for disk 2 on weeks 2,4,6, etc. The interval can be the one you want, it does not matter as long as the backup finds the proper disk in place.

For a detailed procedure see the official guide here.

answered Mar 13 '19 at 11:00

Overmind

2,970
2
15
24

So you are claiming that Windows Server Backup uses Option 2? Do you have any source for that? – Heinzi Mar 13 '19 at 12:22
I'm not claiming anything not knowing what configuration you use, but it's safe to say you need previous incremental points for a valid restoration of data and that will not work on a default 'next'-like configuration in the case of 2 disks. Check the guide I provided. – Overmind Mar 13 '19 at 12:49
Yes, I am fully aware of that. Unfortunately, that was not the question. The question was whether Windows Server Backup uses Option 1 or Option 2, and your answer seems to imply the latter. If that was not your intention, I suggest that you mention in your answer that this is not an answer to the question but just a comment about how incremental backups work in general, to prevent others from making the same mistake I did when reading your answer. :-) – Heinzi Mar 13 '19 at 13:15
Both 1 and 2 scenarios depend on your initial configuration. By default, it's case 2. – Overmind Mar 13 '19 at 13:37
1

OK, do you have any source for that claim ("By default, it's case 2")? And how would I "reconfigure" Windows Server Backup to use Option 1? – Heinzi Mar 13 '19 at 14:02
Did you actually read my answer ? – Overmind Mar 14 '19 at 06:01
Yes, I did. I read it again, just now, very carefully. No, I did not find a source for your claim in your answer. I also read the link you provided. It describes exactly the setup that I currently have. No, it does not contain the word "incremental" anywhere on the page. – Heinzi Mar 14 '19 at 08:23
Just for the record: I also understand the workaround you provided (which is a nice idea but too fragile for my purposes). The workaround I currently use is to disable incremental backups in WSB. Still, my original question stands. And I do appreciate your intention to help! You are just answering a different question than the one I asked. – Heinzi Mar 14 '19 at 08:30
Well that is not a work-around; it is a proper setup for the dual removable disk situation. The guide is proper, you just have to set it up for each independent disk. What you actually do with the disks is an improvisation, that is why it will rarely be a case officially documented. A professional approach makes a data duplication and can mount the duplicate disk only when needed to perform the duplicate copy, not needing any user interaction. – Overmind Mar 14 '19 at 09:02
It's not an improvisation, it's *exactly* what the multiple disk feature of Windows Server Backup is designed for, and the official documentation reflects that (see the first two paragraphs [here](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732939(v=ws.11))). – Heinzi Mar 19 '19 at 09:44
And it's no feature, it's a way to make the system do what you want. That part says exactly what I explained that needs to be done. The same 'feature' can be done with .bat files on any type of file-based backup. – Overmind Mar 19 '19 at 11:06
I disagree: You say that two backup jobs should be created. The link does not say that at all. In fact, the link describes how to set up a multi-disk backup *using the GUI*, and setting up *multiple jobs* is not possible with the GUI. – Heinzi Mar 19 '19 at 11:41
I did not say it's not possible to use a single job, of course it is, but it may be more confusing to do so. – Overmind Mar 19 '19 at 11:46