Skip to main content

Backup Failures After Updating

Thread needs solution

We recently updated to build 10130.  Since then, some of our backup plans have been failing.  All of the failing plans were working successfully for several weeks prior to the update.

1:  The backup plan for the Acronis Virtual Appliance itself now fails.  It states that the disks could not be found.  I've tried to recreate the task and select the disks again, but no disks are shown.  Please see https://forum.acronis.com/comment/453884#comment-453884 for more details.

2:  Our ESXi Configuration backup plan fails with the message "The archive is invalid or its type is unsupported.".

Message
Backup failed

Additional info:
------------------------
Error code: 61
Module: 309
LineInfo: 0x4A8728DC8A1C9583
Fields: {"$module":"mms_lxa64_10130"}
Message: Command has failed. Command=Backup plan 'Weekly ESXi Configuration Backup'; tenantID=00000000-0000-0000-0000-000000000000
------------------------
Error code: 22
Module: 309
LineInfo: 0x8D165E86FB81959B
Fields: {"CommandID":"D332948D-A7A9-4E07-B76C-253DCF6E17FB","$module":"mms_lxa64_10130"}
Message: TOL: Failed to execute the command. Backup plan 'Weekly ESXi Configuration Backup'
------------------------
Error code: 22
Module: 309
LineInfo: 0x8D165E86FB81959B
Fields: {"CommandID":"D332948D-A7A9-4E07-B76C-253DCF6E17FB","$module":"agent_protection_addon_lxa64_10130"}
Message: TOL: Failed to execute the command. Backup plan 'Weekly ESXi Configuration Backup'
------------------------
Error code: 41
Module: 307
LineInfo: 0xE6792A5EE190DE2C
Fields: {"$module":"agent_protection_addon_lxa64_10130"}
Message: Failed to execute the command.
------------------------
Error code: 53
Module: 309
LineInfo: 0x2E7E9E174F1FB719
Fields: {"FailCount":"3","$module":"agent_protection_addon_lxa64_10130"}
Message: 3 activities have not succeeded. One of them is displayed.
------------------------
Error code: 22
Module: 309
LineInfo: 0x8D165E86FB81959B
Fields: {"CommandID":"F30407D6-601F-11E0-9C67-FF46DFD72085","$module":"mms_lxa64_10130"}
Message: TOL: Failed to execute the command. Backup workflow
------------------------
Error code: 22
Module: 309
LineInfo: 0x8D165E86FB81959B
Fields: {"CommandID":"F30407D6-601F-11E0-9C67-FF46DFD72085","$module":"gtob_backup_command_addon_lxa64_10130"}
Message: TOL: Failed to execute the command. Backup workflow
------------------------
Error code: 507
Module: 64
LineInfo: 0xA1D3981537C68833
Fields: {"id":"Weekly%20ESXi%20Configuration%20Backup-B2E40AE1-1545-4DC9-90C3-551DB4DBDA72-8FBFD77B-B485-32F8-77D0-A010375F1A64A_2018_05_31_12_38_27_256F7.TIB","$module":"disk_bundle_lxa64_10130"}
Message: Failed to open the backup archive by the ID.
------------------------
Error code: 853
Module: 64
LineInfo: 0x6A1198D1B8BE2C36
Fields: {"$module":"disk_bundle_lxa64_10130"}
Message: Failed to open archive 'Weekly%20ESXi%20Configuration%20Backup-B2E40AE1-1545-4DC9-90C3-551DB4DBDA72-8FBFD77B-B485-32F8-77D0-A010375F1A64A_2018_05_31_12_38_27_256F7.TIB'.
------------------------
Error code: 1
Module: 64
LineInfo: 0x098130DB273D2482
Fields: {"$module":"disk_bundle_lxa64_10130"}
Message: The archive is invalid or its type is unsupported.

 

Are these known issues with 10130?  Does 10330 fix them?

Should I be concerned about the state of our other backups (which still report running successfully)?

 

Thanks

 

0 Users found this helpful

For number 2, it looks like the ESXi Configuration Backups work if I recreate the task using backup format version 12, but not if I recreate it using version 11.

In the previous build, it worked fine using version 11.

We prefer version 11 because it allows us to keep the backups in separate files, which allows us to sync it in Google Drive and never delete anything, retaining all backups indefinitely (we have unlimited storage).

Using a single file means that to sync to Google Drive we need to upload the entire file each time, and older versions will be deleted from the file by Acronis automatically.  Thus we have to manually manage versioning on Google Drive to ensure older versions are not lost.

For the ESXi Configurations, this isn't a huge deal because we don't really need to keep older backups around indefinitely, and the file size is small.

Our regular VM backups seem to still work with version 11 and multiple files.  This is critical for us so we can upload backups as individual .TIB files to Google for indefinite retention, as required for various legal reasons.  I hope that version 11 is not dropped from the regular backups any time soon!

 

After testing the job multiple times, it looks like even though version 12 is used, separate files are still maintained for the ESXi Configuration backup plans.  Is this intended behavior?

And after more testing, it looks like this is related to the plan name.  If I name the plan "Test" it works.  If I name it "Weekly ESXi Configuration Backup", it fails.  Is this due to the space?  We had no issues before.  The release notes mention:

[ABR-173518] Backup to NFS shares fails if the name of the backed-up machine contains spaces. Applicable to agentless VM backup performed by Agent for VMware or Agent for Hyper-V.

We are not using NFS, we are using SMB.  And this isn't the machine name that has a space, but the plan name.

Again for number 2:

I've updated one of our instances to build 10330, and I'm still getting this error.

If I run the task with the name "Weekly ESXi Configuration Backup", the files are created in the first location but no copying / verification takes place.  Instead, after all 3 hosts are backed up (3 .TIB files and 1 XML file) I get the error described above.

If I edit the task and change the plan name to "Weekly_ESXi_Configuration_Backup" (using underscores instead of spaces) it works fine.

This problem was introduced with build 10130 and it persists in 10330.  We are using SMB, not NFS.

This problem does not seem to affect our VM backups, which also contain spaces in the plan name (Daily Backup - VMName).  I'll have to check tomorrow to see if they still succeed after updating to 10330 as well as test actual recovery.

 

For number 1:  I now get a list of disks to select from.  It's got more disks than before, but I believe we still only need to select the first disk and the dynamic volumes.  Is that correct?

disklist.jpg

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 22
Comments: 3800

Hi Brian,

For item #1 please see my comment in the referenced thread.

For item #2 - the ESXi configuration backups are special type of backups which are unaffected by "Backup format" version and are always created in single format (version 11). The problem you've run into might be caused by spaces in the name of these archives (VM backups are not affected since there is different format) and we'll check it with our QA team.

Thank you.

FYI after restarting our Acronis Appliance (due to some stuck backup jobs that wouldn't cancel), it appears that all of our backup plans (not just the ESXi Configruation backup plans) are throwing the error if a space is included in the plan name.  The backup runs fine and the file is created, but the error is thrown just before the copy operation starts.  No validation takes place.

I've had to go in and rename all of our plans and scripts to use underscores instead of spaces, and am rerunning our backups again.