0x81000019 and 0x8100002F: backup cannot read the shadow copy it just made

Fix it now

The snapshot was created and then could not be used. Neither code has a published meaning, so work from what is documented: every volume in the set needs an NTFS shadow copy storage area with room in it, and the small hidden boot partitions are the ones that never have any.

vssadmin list shadowstorage
vssadmin list shadows
vssadmin list writers

1. Read the associations by volume, not just by drive letter. The volumes without letters are in that output too, and they are the ones this failure usually turns on.
2. Identify the small partitions on the system disk: diskpart, then list disk, select disk 0, list partition.
3. To inspect one, give it a temporary letter from inside diskpart with select partition <n> then assign letter=Q, look at the free space, and remove it again with remove letter=Q.
4. Delete shadow copies that exist on a volume with no room to spare, then re-run the job.
5. If a data-only backup of the same server succeeds and only the system state or bare-metal job fails, you have narrowed it to those partitions without touching anything.

Do not delete boot files to make room. Anything you remove from these partitions can stop the server booting, and that recovery is far worse than a failed backup.

If a full system state backup completes and restores a test file, you can stop here. The next section explains why the small partitions break large backups.

Why it happens

A modern Windows Server disk has more volumes than File Explorer shows. Depending on firmware there is an EFI system partition or a system reserved partition, and usually a recovery partition. They hold boot files, they are deliberately small, and nothing normally grows inside them.

A snapshot changes that. Shadow copies work by copy-on-write: before a block is overwritten, its original contents are written into the shadow copy storage area for that volume, and that area has to live on an NTFS volume with enough space to store it. A volume with a few megabytes free has nowhere to put it, so the copy either cannot be made or cannot be read from once it exists.

Neither 0x81000019 nor 0x8100002F has a published meaning, and it is worth being honest about that before you act on either. What is documented is the mechanism, the storage requirement, and the fact that a system state or bare-metal backup has to include these partitions because they are what makes a restored server bootable. So the productive move is to check every volume in the set for a usable association with room in it – including the ones with no drive letter – rather than to work backwards from the number.

Full reference

What to inspect, by symptom

Working with volumes that have no drive letter

1. Open an elevated Command Prompt and run diskpart.
2. list disk, then select disk 0 for the system disk.
3. list partition to see the system reserved, EFI and recovery partitions.
4. select partition <n> then assign letter=Q to inspect one.
5. Look at free space and at any shadow copies associated with it.
6. remove letter=Q when you have finished, so nothing else starts writing there.
7. Re-run the backup and confirm the stage that failed now passes.

Working on system reserved, EFI and recovery partitions carries real risk. Take a full image or a storage snapshot of the disk before you assign letters, delete anything or change the layout, and confirm you can boot from recovery media before you begin.

What is actually documented here

• The shadow copy storage area can be on any local volume, but it must be NTFS and it must have enough space to store the copy.
• Copy-on-write writes the original block into that area before the overwrite completes, so the area grows with change rate rather than with capacity.
• vssadmin list shadowstorage reports the association with its used, allocated and maximum sizes, and vssadmin resize shadowstorage changes the maximum for an association that already exists – with the published warning that resizing may cause shadow copies to disappear.
• The maximum number of software shadow copies per volume is 512.
• None of the four codes on this page has a published meaning, so treat them as markers of the stage that failed rather than as diagnoses.

Why this appears after an update

Feature and cumulative updates stage files on these partitions, and changes to the recovery environment in particular consume space there. A partition that was adequate for years can cross the line in a single update, which is why this failure so often arrives on a server nobody has otherwise touched. It is also why the fix that lasts is a layout with headroom rather than a one-off clean-up that buys a few megabytes.

Before you accept a workaround

Excluding the failing volume from the job makes the error go away and quietly changes what the backup can do. For a data volume that may be a reasonable trade, made deliberately and written down. For a system state or bare-metal recovery backup it is not: those partitions are exactly what makes the restored server bootable, and a job that skips them produces an image that cannot bring the server back. Test a restore before deciding you have solved anything.

Every code this article covers

Confirm the fix worked

1. A full system state or bare-metal backup completes without error.
2. In diskpart, the EFI or system reserved partition carries no drive letter.
3. vssadmin list shadowstorage shows every volume in the backup set with a usable association that has room in it.
4. A file-level restore from the new backup succeeds, proving the image is readable rather than merely written.
5. The job still completes after the next cumulative update, which is when these partitions usually change.

Questions people ask about this