Backups fail with error V-79-1000-10660 - 03E829A4 - An error was encountered writing to the on-disk catalogs.

 

Problem

 Backup operations performed with Backup Exec fail with error V-79-1000-10660 - 03E829A4 - An error was encountered writing to the on-disk catalogs.

Error Message

 V-79-1000-10660 - 03E829A4 - An error was encountered writing to the on-disk catalogs.

Cause

The failure occurs because Backup Exec is experiencing one of the following conditions:

• The drive the Catalogs folder is hosted on does not have enough free space to store the Backup Exec temporary catalog files.
• The Catalog path in Backup Exec points to an invalid location. The current location of the Backup Exec catalog files can be viewed by going to the Tools | Options | Catalog menu in Backup Exec.
• The Backup Exec Service Account (BESA) does not have adequate permissions to write to the Catalogs folder. This commonly occurs when a security change affected a top level parent folder and replicated down to the Catalogs folder.
• Anti-virus software was running at the time of the backup

Any of these issues result in a condition which prevents the BE Service Account from writing the temporary catalog files.

 

Solution

 To resolve the issue, perform one of the following:

1. Move the Backup Exec catalog files to a drive that has more free space. 
2. Verify the catalog location exists in the Windows directory. If it does not exist, change the catalog directory in Backup Exec.
   1. Open Backup Exec
   2. Go to Tools -  Options - Catalog
   3. Modify the catalog path
3. Free up space on the drive where the catalog files are currently located.
4. Modify the security restrictions on the Catalogs folder, giving Full Control to the Backup Exec Service Account.
5. Setup an exclusion in any anti-virus software that is running on the Media Server (the server Backup Exec is installed on) so that Backup Exec directories and files will not be scanned.

Backup Exec VffInstall log size keeps increasing

 

Problem

Backup Exec VffInstall log (VffInstall.log) size keeps increasing in the Backup Exec Logs folder.

The VffInstall.log is located by (Default) C:\Program Files\Veritas\Backup Exec\Logs or C:\Program Files\Veritas\Backup Exec\RAWS\LOGS 

 

Error Message

VffInstall log size keeps growing.

Cause

Information is appended to VffInstall log which causes log to grow large in size.

 

Solution

This issue is resolved with Backup Exec 23.0 Hotfix 463014 and Backup Exec 22.2 Hotfix 311011. 
Note: Once the fix is installed on Backup Exec Server and backup exec remote agent is updated, restart BE services to reduce the size of VFFInstall.log on Backup Exec server. On the remote server, the backup exec remote agent service will need to be restarted.

 

Workaround is applicable for setups running without the above fix:

Warning: Incorrect use of the Windows registry editor may prevent the operating system from functioning properly. Great care should be taken when making changes to a Windows registry. Registry modifications should only be carried-out by persons experienced in the use of the registry editor application. It is recommended that a complete backup of the registry and workstation be made prior to making any registry changes.

 

1)  Disable VFF logging by modifying the following registry DWORD values to 0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Virtfile\Parameters\Enable logging

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Virtfile\Parameters\Max Log entry

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Virtfile\Parameters\Log Level

 

2) Change or confirm the DWORD value of "CreateDebugLog" is set to 0

HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\Backup Exec For Windows\Backup Exec\Engine\Logging\CreateDebugLog

 

3) Change or confirm the DWORD value of "Enabled" is set to 0

HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\Backup Exec For Windows\Backup Exec\Debug\Enabled

 

Note: A reboot is required before the Vffinstall.log can be deleted manually.

4) Delete the log file manually from the following path -

X:\Program Files\Veritas\Backup Exec\Logs\VffInstall.log
X:\Program Files\Symantec\Backup Exec\Logs\VffInstall.log

Or
X:\Program Files\Veritas\Backup Exec\RAWS\Logs\VffInstall.log
X:\Program Files\Symantec\Backup Exec\RAWS\Logs\VffInstall.log

Where X above represents the drive Backup Exec is installed on

How to install the Backup Exec 15 and above Agent for Windows (a.k.a. Remote Agent, AWS. RAWS)

 

Problem

This article provides instructions for installing the Backup Exec 15 and above Agent for Windows on a remote machine.

The Remote Agent for Windows Servers (RAWS) has been renamed to Agent for Windows (AWS) in Backup Exec 15 and above.

Error Message

UMI Code: V-225-285

Solution

Click on the desired method to see the installation instructions for the Agent for Windows Systems (AWS):

Automated (Push) Installation (to be performed from the Backup Exec 15 or above media server).

Local (manual) installation (to be performed on each remote machine).
In Backup Exec 15 and above, it is possible to install the Agent for Windows locally with a Graphical User Interface (GUI).

Silent (command line) installation (to be performed on each remote machine).
Command line scripts setupaa.cmd (OS 32-bit) and setupaax64.cmd (OS 64-bit) for a command line installation.

 

Automated (Push) Installation of Backup Exec 15 and above Agent for Windows

 

There are two methods to perform an Automated (Push) installation of the Agent for Windows:

From the Backup and Restore tab (recommended):

1. Open the Backup Exec 15 or above console - go to the Backup and Restore tab.
    
2. Select Add (from the ribbon menu) - select Microsoft Windows computer - click Next.
    
3. Select 'Allow Backup Exec to establish a trust with the servers.' - click Next.
    
4. Browse / Add a server name(s) - then click Next.
    
5. Select/Add a System logon account - click Next.
    
6. Select "Upgrade the Veritas Backup Exec Agent for windows to the current version automatically" (if Agent for Windows is not installed/up to date).
   
   Note: 'Restart the remote computer automatically after installing the Veritas Backup Exec Agent for Windows when a restart is required' should only be selected if down time has been planned or is not problematic for the target server(s).
    
7. Click Install to begin setup.
    
8. Click Finish to complete the installation..

 

By clicking on the Backup Exec button:

1. Open the Backup Exec 15 or above console on the media server.
    
2. Click on the round Backup Exec button which is located to the left of the Home tab.
    
3. Go to Installation and Licensing - select Install Agents and Backup Exec Servers on Other Servers.
    
4. On the Remote Computers section - select Add
   • Choose Add a Single Computer (if remote agent needs to be installed on only one machine).
     
     OR
      
   • Choose Add Multiple Computers with the Same Settings (to select multiple servers for remote agent installation).
     
     Note: The box Save the server list for future remote install sessions enables the names of all of the remote computers and their credentials to be added automatically the next time Backup Exec or any of its options need to be installed to these remote computers.
      
5. On the Select the Remote Product screen - select Agent for Windows and click Next.
    
6. On the Add Single Computer / Choose Remote Computers screen:
   1. When selecting Add a Single Computer:
      1. Enter the Remote Computer name / select Browse Remote Computers to select a remote machine.
          
      2. Enter the Remote computer credentials (type the user name and password of an account that has administrative rights on the server).
          
      3. Click Next.
      
      OR
       
   2. When Selecting Add Multiple Computers with the Same Settings
      1. Enter the Remote computer name / Browse to select a remote computer - click on Add to List
         
         NOTE: Repeat the above steps to select multiple servers for remote agent installation.
          
      2. Enter the Remote Install Credentials (type the user name and password of the account that has administrative rights on the servers).
          
      3. Click Next.
          
7. The destination location for Remote Agent install files can be changed under the Destination Folder section if required.
    
8. On the Remote Agent Publishing screen:
   1. Check the box which says 'Enable remote agent to publish the IP address and name of the remote computer and the version of the Remote Agent to media server'.
       
   2. Click Add and enter the Media Server name or IP address (or both) and press OK.
       
   3. Click Next.
       
9. Click Next when the screen shows Ready to install the Agent for Windows beside the server name(s).
    
10. Click Install to begin the installation.
     
11. Wait for the installation to complete and click Finish.
     
12. An SSL trust relationship will need to be established after a manual installation of the Agent for Windows. This is explained in the following article:
    
    How to establish trust for remote servers in Backup Exec 15 and above

 

 

Local (manual) installation using the GUI method

 

When automated (push) installation of the AWS fails it may be necessary to perform a local installation.
Listed below are two methods to perform a Local (manual) installation of Agent for Windows:

Using the RAWS32/RAWSX64 folder located on Backup Exec 15 and above media server (recommended):

1. Copy the Agents folder which includes the "RAWS32 or RAWSX64", DotNetFx, VCRedist, and MSXML (if it exists) folders, from the Media Server to a drive on a remote computer.
   
   NOTE: The default path for the above mentioned folder is 'X:\Program Files\Symantec\Backup Exec\Agents'  or 'X:\Program Files\Veritas\Backup Exec\Agents" ('X' is the drive letter where Backup Exec is installed.)
   
   For Remote Agent installation on:
   • 32-bit system: Use the RAWS32 folder.
   • 64-bit system: Use the RAWSX64 folder.
      
2. Go to the remote computer and open the RAWS32 or RAWSX64 directory which was copied from the media server.
    
3. Double-click on Setup.exe.
   
   Note: Turn off User Access Control (UAC) for Windows 2008, Vista or 7.
   It is also recommended to right-click on the Setup.exe file and select 'Run as Administrator' to avoid any access issues during the installation process.
    
4. Click Next on the Welcome screen.
    
5. Select Local Install and click Next.
    
6. Select 'Agent for Windows' - click Next.
   
   Note: The destination location for the Remote Agent install files can be changed if desired by clicking on the 'Change' button.
    
7. On the Remote Agent publishing screen:
   1. Check the box which says 'Enable remote agent to publish the IP address and name of the remote computer and the version of the Remote Agent to media server'.
       
   2. Click Add and enter the Media Server name or IP address (or both) and press OK.
       
   3. Click Next.
       
8. Click Install to begin the installation.
    
9. Wait for the Installation to complete and click Finish.
    
10. An SSL trust will need to be established after a manual installation of Agent for Windows. This is explained in the article below:
    
    How to establish trust for remote servers in Backup Exec 15 and above

 

Silent (command line) Installation

1. Copy the Agents folder from the Backup Exec media server's installation folder (by default located in C:\Program Files\Symantec\Backup Exec\Agents on the media server or C:/Program Files/Veritas/Backup Exec/Agents) to the root of the C: drive on the remote server.  Verify it contains the folders "RAWS32 or RAWSX64", DotNetFx, VCRedist, and MSXML (if it exists).  To perform the steps below, you will be using these following folders:
   • RAWS32: For a 32-bit (x86) Windows System.
   • RAWSX64: For a 64-bit Windows System.
2. On the remote server, go to the command prompt (click Start - Run - cmd):
   1. Browse to the RAWS folder which was copied on the local drive using DOS commands.
       
   2. In the command prompt window type setupaa.cmd (for 32-bit OS) or setupaax64.cmd (for 64-bit OS) and press enter to install Agent for Windows.
      
      Note: Installation of AOFO is no longer required. If the operating system is Windows Server 2003 or above, it will use the Microsoft VSS provider for the Advanced Open File Option.
   OR

2. On the remote server, open the RAWS folder which was copied on the local drive:
   1. Double-click on setupaa.cmd (for 32-bit OS) or setupaax64.cmd (for 64-bit OS) to install Agent for Windows.
      
      Note: On Windows Server 2008, Windows Vista or Windows 7, right-click on Setupaa.cmd and select Run as administrator.
      
      Installation of AOFO is no longer required. If the operating system is Windows Server 2003 or above, it will use the Microsoft VSS provider for the Advanced Option File Option.
       
   2. The command prompt will appear blank for a period between a few seconds and a couple of minutes while the remote agent installs.
       
   3. Once completed, the command prompt cursor will appear awaiting further input.
      1. To check if the Agent for Windows was installed: Go to the Windows services console (Start - Run - Services.msc), and see if the Backup Exec Remote Agent for Windows service is present and started.
          
      2. An SSL trust will need to be established after a manual installation of the Agent for Windows. This is explained in the article below:
         
         How to establish trust for remote servers in Backup Exec 15 and above

V-79-57344-33859 - One or more SQL Database consistency checks have failed" appears in the backup job log while backing up Microsoft SQL Server or SQL databases

Problem

Error "0xe0008443 - One or more SQL Database consistency checks have failed" appears in the backup job log while backing up Microsoft SQL Server or SQL databases.

Error Message

Final error: 0xe0008443 - One or more SQL Database consistency checks have failed.
Final error category: Resource Errors
For additional information regarding this error refer to link V-79-57344-33859

The job log also reports the following error:

              "An unknown or unexpected database error occurred while attempting a DBCC."

V-79-65323-3224 - An error occurred on a query to database

Cause

SQL has found some inconsistencies with the database/s mentioned in the job log.

Solution

Backup Exec has the ability to check the logical and physical consistency of SQL data before and/or after a backup. SQL reports any consistency check failures in the Backup Exec job log. Veritas recommends running consistency checks either before or after SQL backups.
 

Backup Exec's backup job definition uses a 'Physical_Only' SQL consistency check before backup by default. Full checks with/without indexes are also options.  Additionally, by default a backup job will continue even if the DBCC fails.  Confirm this setting in the job definition per Figure 1 below.

The consistency check that is run is actually a part of the SQL program and Backup Exec merely triggers the consistency check. If errors are reported, try running the DBCCs manually through SQL.

How  to check the Database consistency in SQL:

1. Open SQL Management Studio and connect to the SQL instance

2. Click on "New Query".

3. Type the following commands and click on "Execute"

use DatabaseName

dbcc checkdb

Note: DatabaseName is the name of the database that is visible in the Job log of the failed SQL job.

For more information, see the Microsoft SQL Server documentation.

The results will show you if SQL has encountered any inconsistencies or not. If inconsistencies are encountered, please contact your SQL Administrator to resolve the inconsistencies.

          Figure 1

        
   

Active Directory Recovery Agent GRT Backups complete with exception "Backup Exec Remote Agent on the resource does not support the option to enable the restore of individual items"

Problem

When performing a GRT (Granular Recovery Technology) enabled Remote Agent backup of a Windows Domain controller the job completes with an exception indicating the backup source or remote server is running a later version of Windows than the Backup Exec server.

Error Message

The Agent for Windows on this backup source does not support Granular Recovery Technology because the backup source is running a later version of Windows than the Backup Exec server. A backup was run, but you will not be able to restore individual items from the backup sets.

 

To ensure that you can restore individual items from the backup sets, rerun the backup. Use a Backup Exec server that runs the same version or a later version of Windows than the backup source is running.

 

The Backup Exec Remote Agent on the resource does not support the option to enable the restore of individual items.  A backup was run, but  you will not be able to restore individual items from this backup set.

 

 

Cause

The Active Directory Application Server and the Backup Exec server must have compatible versions of Microsoft Windows. Also, a version of the Windows operating system that supports minifilter drivers must be installed on the Backup Exec server when you restore GRT-enabled data.

Solution

To perform a GRT-enabled backup of an Active Directory Application Server on Windows 2012 R2 or later, the Backup Exec server must be the same version or a later version of Microsoft Windows. See the following table for compatible versions:
 

AD Application Server	Backup Exec Server
Windows 2008	Windows 2008 or later
Windows 2008 R2	Windows 2008 or later
Windows 2012	Windows 2008 or later
Windows 2012 R2	Windows 2012 R2 or later
Windows 2016	Windows 2016 or later

Restore of Active Directory Users/Group/Organizational Unit from the Active Directory Recovery Agent (ADRA) based backup set fails with the error "Unable to restore File Attributes Security or Directory Security information"

Problem

Restore of Active Directory Users/Group/Organizational Unit from the Active Directory Recovery Agent (ADRA) based backup set fails with the below mentioned error message.

Error Message

0xe000848e - Unable to restore File Attributes Security or Directory Security information.

Cause

This behavior is by design. The restore job fails while restoring the group membership information.

Solution

Even though the restore job status shows failure , the user/group is still restored with all the details.
If the Group being restored has users from another OU's, then the first restore will not restore the membership of those users (belonging to another OU's). Run another restore with only the group selected and the group membership information will be restored. 

Backup jobs fails with the error: "0xe000ff15 - A communication failure has occurred with a system state/shadow copy resource."

Problem

Backup jobs fails with the error: "0xe000ff15 - A communication failure has occurred with a system state/shadow copy resource." 

Error Message

0xe000ff15 - A communication failure has occurred with a system state resource.

Solution

To resolve the issue please follow the steps below :

1. Use a different set of ports for whichever application is using the port(s) in conflict with Backup Exec. For detailed information on port usage with Backup Exec, refer the following technote :http://www.veritas.com/docs/000029930

2. Change the port range inside Backup Exec:

       a.   Open Backup Exec

       b.   Click Tools | Options 

       c.   In the left pane, click Network and Security

 

       d.   For Enable media server TCP dynamic port range and Enable remote agent TCP dynamic port range, specify a port range that does not conflict with existing applications installed on all servers within the network.
 

Note: If the Enable media server TCP dynamic port range check box and Enable remote agent TCP dynamic port range check box have not selected, Backup Exec will use the port range of 1025 - 65535.

 

 

 

1. Unable to backup system resources when AOFO is selected in job properties:

 

 a.    Go to the properties of the backup job - Under AOFO - Select VSS - Use Microsoft Shadow Copy Provider. 

 

 b.     Verify if  "Volume Shadow Copy" and the "Microsoft Software Shadow Copy" services are stopped and set to manual on the target servers.

 

 c.     From the command prompt on the Target Server, run VSSADMIN LIST WRITERS and confirm if the status of all the writers are stable. Reboot Target Server if the issue persists.

2. VSS snapshots require a certain amount of system resources in order to perform the backup.

       a. The local system volume should have an adequate amount of hard disk space available.

       b. The computer must also have an adequate amount of RAM to run installed applications and roles on the system.

Hyper-V backups using Backup Exec 2012 fails to create snapshot indicating a disk signature collision.

Problem

When performing a backup of Hyper V virtual machines the backup jobs may fail while creating snapshots and indicating that disk signatures for vhd's are colliding.

Error Message

\\\Hyper-V?Virtual?Machine\machine-name>". Snapshot technology used: Microsoft Volume Shadow Copy Service (VSS).
A snapshot could not be created.  The most probable cause is a disk signature collision between two or more VHDs that are assigned to the virtual machine.
 
0xa0009650 - A snapshot could not be created.  The most probable cause is a disk signature collision between two or more VHDs that are assigned to the virtual machine.
Also seen error:
0xa0009651 - A snapshot could not be created.  The most probable cause is a disk signature collision between a VHD that is assigned to the virtual machine and physical disk mounted on the Hyper-v host. 

Cause

1. The disk signatures for the virtual machine's (vhd's) are colliding.
2. The Hyper-V writers on the host machine are failing during the backup process.
3. If the disk space of the VM doesn't have enough disk space.
4. Using multi path i/o configuration which creates two identical disks of which one is active and one is passive (seen by IBM but other vendor might have the same configuration).

Solution

1. Check and Fix the Disk Signature Conflict. 

       To check Disk Signature or ID use the Windows DISKPART utility commands "detail disk" and "uniqueid".

       http://technet.microsoft.com/en-us/library/cc770877(WS.10).aspx

       Refer to the following image. The "Disk Id" should be unique.

        Contact Microsoft Support for further assistance changing the Disk Signature.

2. Check the writer status on the Hyper V host machine.

         Reboot the server to check if the writers are stable, re run the backup job.

         If writers continue to fail, Contact Microsoft Technical Support to resolve the issue with the writers.

3. Clear up additional space on the VM if it's out of space. 

    4.      Install an additional IBM driver specific for multi path i/o configuration (for more detailed information where to find the driver please contact your vendor)

Warning "Snapshot provider error 0xe00008526. Backup Exec could not locate a VSS software or hardware snapshot provider for this job."

Problem

Backup Exec unable to locate snapshot providers installed on the computer.

Error Message

V-79-57344-34086 - AOFO: Initalization failure on: "C:". AOFO used: Microsoft VSS. Snapshot provider error 0xe0008526: Backup Exec could not locate a VSS software or hardware snapshot provider for this job. Select a valid VSS snapshot provider for the target computer.

Application Log :

Log Name: Application
Source: VSS
Event ID: 7001
Computer:
 

Description:
VssAdmin: Unable to create a shadow copy: The volume shadow copy provider is not registered in the system.
Command-line: 'C:\Windows\system32\vssadmin.exe Create Shadow /AutoRetry=15

C: Drive properties window shows error about VSS Provider:

1. Go to Windows Explorer

2. Right click on C: drive

3. Click " Shadow Copies" tab.

4. Check for this error:

Initialization Failed:

Error: 0x80042304 : The volume shadow copy provider is not registered in the system.

Cause

The snapshot provider selected for the backup job is not installed on the server being backed up.

Solution

1.  Check that snapshot providers are installed on the system being backed up.

• Open a command prompt.
• Type "vssadmin list providers"
• If nothing is returned, then there is most likely an issue with VSS that will most likely need assistance from Microsoft to resolve
  • You can also verify that VSS is properly registered by checking the following registry key:
    •  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VSS\Providers\{b5946137-7b9f-4925-af80-51abd60b20d5}
• If writers not listed or show they are in an error state, reboot the server and run the command again

 


2.  Change the backup job to use a specific snapshot provider.

•  Open the backup job properties.
•  Navigate to Advance Open File.
•  Confirm the "Use advanced open file option" is checked.
•  Select the appropriate snapshot provider - "Microsoft Volume Shadow Copy Service" with "System" selected in the pull down menu is typically best:

  

 

Since installing Backup Exec FP3 Hyper-V backup jobs leave a checkpoint against the virtual machine

Problem

Before installing Backup Exec 15 Feature Pack 3 (FP3) , a Hyper-V backup job created a checkpoint (usually visible in the Hyper-V manager). This checkpoint results in the creation of  an AVHDX file against each VHDX file inside the storage containing the virtual machine (VM). However at the end of the backup job the checkpoint and associated AVHDX files are merged and removed/deleted.

Since installing FP3, it can be seen that Hyper-V backups now create a checkpoint (and associated AVHDX files), however even when the backup job finishes, a checkpoint now remains linked to the VM although the checkpoint will be updated during subsequent backup processes.

NOTE: Backup Exec 15 Feature Pack 4 (FP4) and later updates or later Backup Exec versions may also see such symptoms, although the default setting for FP4 and later depends on which Feature Pack (FP) was installed prior to installing FP4 and if it was installed over an FP that already includes the choice, what the current setting for Hyper-V processing was prior to updating.

Cause

In the newer versions of Hyper-V, Microsoft have introduced a potentially faster method of performing incremental backups and Backup Exec 15 FP3 implements this new method as a server default (for Hyper-V 2012 and later installations) . This means all Hyper-V jobs (not just newly created jobs) on a given Backup Exec server will use the new settings immediately after FP3 is installed.

The basic concept of the new method is:

    •    A child checkpoint (snapshot) is created to collect the changes.
    •    On incremental backup, a new child checkpoint is created for current changes and then the parent checkpoint is backed up.
    •    When the backup is complete, the child and parent checkpoint is merged leaving only the new combined checkpoint.
    •    This combined checkpoint remains on the system and is used as the new parent for the next backup.
    •    A full backup will backup the current complete state of the VM and not just the parent checkpoint


Extra information:

Within Backup Exec this new method is known as the Faster processing method for Incremental Hyper-V backups with the original method being called the Standard processing method

Backup Exec has supported this new method since Backup Exec 2014 was released however Backup Exec 15 FP3 enabled it as the default method where prior to this, to enable it required the use of Powershell Commands (scripts) which are no longer needed against the FP3 (or later) updates.

FP4 (and later) set the default Hyper-V processing Standard when installing over FP2 and earlier update levels, but honors the current setting when installing over FP3 (or later) update levels. 

The backup job log will clearly show which method was used to perform the backup operation.

With the faster method, a checkpoint is created and remains in place against the VM even if the backup strategy is to only run full backups.

It is possible to revert to the Standard method (see information in the Solution section below), however, it should be noted that if reverting to the Standard method where at least one backup job with the Faster method has already run, then Powershell Commands will be needed to remove the Backup Checkpoints. Typically Hyper-V 2012 R2 installations will not remove the Backup Checkpoints when changing method, but Hyper-V 2012 installations usually will remove the Backup Snapshots. This is because Microsoft changed the behaviour (and the terminology) between these two Operating System versions.

The AVHDX file is often referred to as a differencing disk

The very first time a Faster method backup is performed against a VM, it will result in the Hyper-V-VMMS log on the host containing events 15070 and 10150,  reporting  errors of being unable to remove  a checkpoint. These errors can be ignored unless they happen during every backup operation.

A restore from a backup set created using one method will still work if the server settings have been changed to the other method.

If more than 1 backup checkpoint is present (when a backup job is not running) or more than 2 backup checkpoints present (when a backup job is running) then an issue has occurred that has blocked the removal of a checkpoint. As Backup Exec is calling Microsoft processes it is likely the cause is within the Operating System and not Backup Exec (unless you can see service stability issues against Backup Exec at the time of the backup.)
 

Solution

Backup Admins managing Hyper-V environments should choose between electing to continue using the default Faster method (in which case no further action is necessary) or reverting back to the Standard method. To revert to the Standard method perform the following steps:

• In the Backup Exec console click the Backup Exec button (yellow button top left) and select Configuration and Settings —> Backup Exec Settings.
• In the left sidebar of the Settings screen, click on Virtual Machines
• Change the radio button in the Hyper-V, Incremental Backup Settings to “Use the standard processing method” and click OK
• For Hyper-V Windows 2012 R2 installation then go to the Hyper-V host and open Powershell

To merge and remove all snapshots use the command
Get-VMSnapshot -VMName 'VM' -ComputerName 'HOST' | Remove-VMSnapshot
although if there are manual checkpoints against the VM that need retaining the to remove just the Backup Checkpoints use the command
Get-VMSnapshot -VMName 'VM' -ComputerName 'HOST' -SnapshotType Recovery | Remove-VMSnapshot

Where VM represents the actual name of your virtual machines as seen in the Hyper-V Manager on the host and HOST represents the name of the Hyper-V host

Note: these commands are case sensitive and can also be used to remove backup checkpoints that due to operating system errors have not been removed correctly. However, customers with these types of issue  should also review the Hyper-V-VMMS logs to understand what may have caused the condition.