Windows Server Backup Failed Issue

Question

Utilizing Windows Server Backup to Backup local folder onto storage onto another server. See Error Message:

The backup operation that started at '‎2025‎-‎12‎-‎01T00:24:09.813692000Z' has failed with following error code '0x80070012' (There are no more files.). Please review the event details for a solution, and then rerun the backup operation once the issue is resolved. Backup was completed successfully 11/23/2025. Backup was attempted 11/30/2025 but failed. There are previous reports of backups failing in the past as well.

Steps Taken:

• Ensured there is enough space on the server
• Restarted the server
• disabled antivirus
• adjust Shadow Copies on destination server
• deleted old shadow copies on destination server
• restarted VSS service

Answer 1

Hello Chamong Lo,

The error code `0x80070012 in Windows Server Backup is a known but misleading error that typically indicates a problem with the Volume Shadow Copy Service (VSS) infrastructure or file system metadata on the source volume, not an actual lack of files. Given your successful backup on 11/23 and the failure on 11/30, the issue is likely due to a corrupted VSS writer or a change in the state of the files being backed up.

First, check the health of all VSS writers. Open an elevated command prompt and run vssadmin list writers. Look for any writers in a failed state. A single failed writer can halt the entire backup. If you find one, attempt to restart the VSS service and the associated service for that writer. For example, if the System Writer is failed, restart the COM+ Event System service. The definitive fix for persistent writer failures is often a server reboot, but since you've already restarted, proceed to more targeted actions.

Next, examine the source volume for file system errors. Run chkdsk C: /f (replace C: with your source drive) on the next restart. Corruption in the file system's metadata can cause this error. Additionally, if the source folder contains an extremely large number of files or deeply nested paths, the backup process may hit an internal limit. Use fsutil dirty query C: to see if the volume is marked dirty, which would explain the sudden failure after a previous success.

If the above steps don't resolve it, the Windows Server Backup catalog may be corrupted. You can rebuild it by navigating to C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe as Administrator and running wbadmin delete catalog. Confirm the deletion, then run wbadmin restore catalog -backupTarget:<TargetDrive> -machine:<ServerName>. This forces a re-inventory of backup sets. Before the next backup attempt, also ensure the destination server's share permissions and NTFS rights grant the source server's machine account full control, not just the user account.

Given the recurrence, implement monitoring for the VSS writers and the backup event logs. A scheduled task that runs vssadmin list writers and logs the output can help catch degradation before the next backup window. Also, consider splitting the backup of very large folders into multiple, smaller jobs to reduce the chance of hitting VSS timeouts.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to ACCEPT ANSWER then. Should you have more questions, feel free to leave a message. Have a nice day!

VPHAN

Answer 2

No, the -backupTarget parameter is not your C: drive. It must point to the specific storage location where your previous backup files (the .vhdx or .spf files) are physically stored. This is the destination drive or network path you configured in the original Windows Server Backup job.

For example, if you set your backups to save to an external drive labeled E:\, then your target is E:\. If you save to a network share like \\BackupServer\ShareName, then that is your target. The command needs to read the catalog information from that exact location to rebuild it. The -machine: parameter should be the name of the server you are repairing (the source server).

A typical command run on the server named Server01 with backups on the D: drive would be: wbadmin restore catalog -backupTarget:D:\ -machine:Server01

You must run this command from an elevated Command Prompt on the server experiencing the backup failure. First, locate where your backup files are actually stored by checking the properties of your existing backup job in the Windows Server Backup console.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer then. Should you have more questions, feel free to leave a message. Have a nice day!

Answer 3

Yes, your syntax for the network share is correct. The full command should be: wbadmin restore catalog -backupTarget:\\DestinationServerName\ShareName\Folder -machine:SourceServerName

Ensure the source server's machine account (SOURCE$ or the service account used for backups) has at least Read permissions to that network share. You may need to map a drive letter to the share (e.g., Z:\) and use that path if the UNC path causes issues.

The wbadmin delete catalog command is run on the source server (where the backup job is configured). After running it, you will receive a confirmation prompt in the command line asking Are you sure you want to delete the catalog? (Y/N). Type Y to proceed. To verify deletion, you can immediately run wbadmin get versions. If the catalog is successfully deleted, this command will return an error stating no backups can be found or will show an empty list. Alternatively, open the Windows Server Backup console; it should appear empty or show no available backups until you restore the catalog.