Hyper-V Backup Error: Could not initiate a checkpoint operation: Element not found. (0x80070490).

The Hyper-V backup error “…could not initiate a checkpoint operation: Element not found. (0x80070490)”

is an old but still existing Hyper-V bug seen on Windows Server 2012 R2 when backing up Hyper-V virtual machines with Windows Server 2003 guest operating systems.

 
Update 2018: A new bug in Hyper-V 2016 (on Windows Server 2016) corrupts file access permissions of your VM folders. You can fix that by following these instructions.

Update 2018 #2: Yet another bug in Hyper-V on Windows Server 2016 has surfaced. If you see in the Event Viewer logs (Hyper-V-Worker -> Admin) event IDs 3280, and event ID 18012 (checkpoint creation error) in Hyper-V-VMMs->Admin, the issue has to do with a differencing file left behind from a previous backup. Look at the folder containing your VHDX file. If there is no backup running, there shouldn’t be a file called {name of VHDX}-AutoRecovery.avhdx. If you see that file in the folder (there could be one for each VHDX), simply delete it and run the backup once again.

See also
The possibilities below were found prior to Windows Server 2016 but sometimes still apply for Server 2016 on some systems:
It appears this is a bug in the Hyper-V VSS Writer. Some may speculate it’s a typical Microsoft attempt to “motivate” people to upgrade their old operating systems (XP, Server 2003). Listed here http://technet.microsoft.com/en-us/library/jj860400.aspx as an “unsupported guest OS for DPM”, and it appears to be Microsoft is trying to get rid of the old Windows Server OSes by making it impossible to back them up when running inside VMs at the VSS level.

There appears to be a fix for the situation using an intermediate step:

You need to uncheck the ‘backup’ option in the VM’s Hyper-V integration settings:

The difference between backing up with this option on or off is that it controls whether the VSS signal is passed into the VM. When off, this means you’ll be getting a crash consistent backup rather than an application consistent VM backup. An application consistent backup is of course always better since applications and services received a signal to prepare their data structures for live backup. In crash consistent backups, the state is similar to a power off event.

Most transaction-based services can handle it well, such as Exchange, SQL Server, etc. But others can’t, such as Microsoft Access and MySQL. On the other hand, Access isn’t VSS aware anyways, so even with application consistent backups you wouldn’t be able to get Access to back up properly live.

Then, run a backup.

The important part: after running a backup with the option OFF, turn it back ON. Then run the backup again and the issue has fixed itself.

Software Options

Use BackupChain’s Hyper-V Backup module to run a test backup of the VM. Try collecting additional error info using VssDiag //backupchain.com/VssDiag.html and worst case have a look at our VSS Troubleshooting Guide //backupchain.com/hyper-v-backup/Troubleshooting.html

Contact the BackupChain Team for assistance if the issue persists.