Skip to main content

Backup failed, then worked?

Thread needs solution

Wasn't home but PC was on at the time. Came home, had 2 emails sent to me.

First said it failed:

====================
2019-12-20T09:00:01:228-05:00 4472 I00000000: -----
2019-12-20T09:00:01:228-05:00 4472 I00000000: ATI Demon started. Version: 24.5.1.22510.
2019-12-20T09:00:01:360-05:00 4472 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
2019-12-20T09:00:01:360-05:00 4472 I00640002: Operation My disks started by schedule.
2019-12-20T09:00:18:784-05:00 4472 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
2019-12-20T09:00:18:784-05:00 4472 I013C0000: Operation: Backup
2019-12-20T09:00:18:784-05:00 4472 I0064000B: Priority changed to Low.
2019-12-20T09:02:17:311-05:00 4472 E02160015: Error 0x2160015: A backup error.
| trace level: error
| line: 0xa340ffd3416335cf
| file: c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\da_api\backup.cpp:353
| function: da_backup::Commit
| line: 0xa340ffd3416335cf, c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\da_api\backup.cpp:353, da_backup::Commit
| $module: disk_backup_vs_650
|
| error 0x70021: Failed to create volume snapshot.
| line: 0x8ba4fa0bac28bf6d
| file: c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\resizer\archive3\backup_partition.cpp:538
| function: `anonymous-namespace'::PartitionBackuper::Init
| line: 0x8ba4fa0bac28bf6d, c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\resizer\archive3\backup_partition.cpp:538, `anonymous-namespace'::PartitionBackuper::Init
| $module: disk_backup_vs_650
|
| error 0x10c443: Failed to unlock the volume snapshot.
| line: 0x3fec04e376b8a1a2
| file: c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\fdisk\win_snapshot.cpp:1196
| function: win_snapshot_core::SnapStart
| line: 0x3fec04e376b8a1a2, c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\fdisk\win_snapshot.cpp:1196, win_snapshot_core::SnapStart
| $module: disk_backup_vs_650
|
| error 0x10c46b: VSS writer 'System Writer' with class ID 'E8132975-6F93-4464-A53E-1050253AE220' has failed to process the snapshot.
| line: 0x3fec04e376b89da6
| file: c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\fdisk\win_snapshot.cpp:176
| function: `anonymous-namespace'::ObtainVSSFailReasonSuberror
| line: 0x3fec04e376b89da6, c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\fdisk\win_snapshot.cpp:176, `anonymous-namespace'::ObtainVSSFailReasonSuberror
| $module: disk_backup_vs_650
|
| error 0xfff0
| line: 0xbd28fdbd64edb8fb
| file: c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\common\error.cpp:317
| function: Common::Error::AddHResult
| line: 0xbd28fdbd64edb8fb, c:\jenkins_agent\workspace\mod-disk-backup\650\product\core\common\error.cpp:317, Common::Error::AddHResult
| code: 0x800423f2
| $module: disk_backup_vs_650
2019-12-20T09:02:17:362-05:00 4472 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bced8
| file: c:\bs_hudson\workspace\23\products\imager\demon\main.cpp:738
| function: main
| line: 0x9f2c53c72e8bced8, c:\bs_hudson\workspace\23\products\imager\demon\main.cpp:738, main
| $module: ti_demon_vs_22510
====================

Note the last time stamp, 2019-12-20T09:02:17:362-05:00

Then I get one that it worked:

=====================
2019-12-20T09:02:50:182-05:00 17732 I00000000: -----
2019-12-20T09:02:50:183-05:00 17732 I00000000: ATI Demon started. Version: 24.5.1.22510.
2019-12-20T09:02:50:219-05:00 17732 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
2019-12-20T09:02:50:220-05:00 17732 I00640002: Operation My disks started by schedule.
2019-12-20T09:02:51:160-05:00 17732 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
2019-12-20T09:02:51:161-05:00 17732 I013C0000: Operation: Backup
2019-12-20T09:02:51:162-05:00 17732 I0064000B: Priority changed to Low.
2019-12-20T10:08:20:624-05:00 17732 I013C0006: Operation has succeeded.
==========
So it tried some 48 minutes later? It worked and was successful.

What was the cause of the error? According to a DIR of the C: drive shows plenty of free space?

32,218,501,120 bytes free

The C drive is an SSD and quite fast, so it wasn't like it was busy and couldn't respond? Never had this happen before?

Any reason why from the first e-mail that tells you something?

I do see this thread, https://forum.acronis.com/forum/acronis-true-image-2020-forum/backup-fa…, but I am on V 22510?

Also https://forum.acronis.com/forum/acronis-true-image-2020-forum/dont-crea…, but I deleted 2016 before installing 2020?

0 Users found this helpful

Looks like I missed a LINK, https://forum.acronis.com/forum/acronis-true-image-2020-forum/received-failure-message-backup-shows-completed-validated-ati2020

 

Said to run VSSDOCTOR, which I just did...

I ran FIX, it fixed the first one, so I closed it and ran again, all OK.

Could that have been the cause? If so it was probably always like that, no? Never had the problem before?

 

Irv, the backup failure log definitely shows a VSS error causing the failure, so can only hope that running the VSS Doctor tool has fixed that VSS issue.

Steve Smith wrote:

Irv, the backup failure log definitely shows a VSS error causing the failure, so can only hope that running the VSS Doctor tool has fixed that VSS issue.

Steve, while I concur with you that VSS seemed to have a problem, the fact is I didn't do anything to make it work? If I really had the VSS error of Max. storage size incorrect that caused ATM to fail, would it not stay like that? What changed in the 42 minutes that the computer was sitting there not touched?

I did check if VSS Doctor did change C: from UNBOUND, it did:

===============

C:\>vssadmin list shadowstorage
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Shadow Copy Storage association
   For volume: (\\?\Volume{1b6d1335-abaf-41cc-97b4-088d0b539402}\)\\?\Volume{1b6d1335-abaf-41cc-97b4
-088d0b539402}\
   Shadow Copy Storage volume: (\\?\Volume{1b6d1335-abaf-41cc-97b4-088d0b539402}\)\\?\Volume{1b6d133
5-abaf-41cc-97b4-088d0b539402}\
   Used Shadow Copy Storage space: 0 bytes (0%)
   Allocated Shadow Copy Storage space: 0 bytes (0%)
   Maximum Shadow Copy Storage space: UNBOUNDED (100%)

Shadow Copy Storage association
   For volume: (\\?\Volume{957ab406-1a4b-4da2-bc19-a11e5e66f76d}\)\\?\Volume{957ab406-1a4b-4da2-bc19
-a11e5e66f76d}\
   Shadow Copy Storage volume: (\\?\Volume{957ab406-1a4b-4da2-bc19-a11e5e66f76d}\)\\?\Volume{957ab40
6-1a4b-4da2-bc19-a11e5e66f76d}\
   Used Shadow Copy Storage space: 0 bytes (0%)
   Allocated Shadow Copy Storage space: 0 bytes (0%)
   Maximum Shadow Copy Storage space: UNBOUNDED (100%)

Shadow Copy Storage association
   For volume: (C:)\\?\Volume{a65d3e7c-8e09-447a-a6be-41c29c2dbf48}\
   Shadow Copy Storage volume: (C:)\\?\Volume{a65d3e7c-8e09-447a-a6be-41c29c2dbf48}\
   Used Shadow Copy Storage space: 0 bytes (0%)
   Allocated Shadow Copy Storage space: 0 bytes (0%)
   Maximum Shadow Copy Storage space: 12.0 GB (10%)

=============

However, like I said, it probably was UNBOUNDed when ATM ran and worked?