First backup. Puzzling completion process

Mark, welcome to these public User Forums.

Sorry but too little information here at present.

What size is your source drive for this backup task?

What options did you select for the backup task?

Have you waited for the backup to complete fully yet and if so, did it succeed?

Please download the MVP Log Viewer tool (link in my signature below) and use this to review the log file for your backup operation. This should provide more information on what is happening here.

Steve,

Thanks for the help. The log viewer was very helpful and indicated I had file system errors causing the backup to complete with errors. I used sfc to fix the errors and have started up another backup and will post results tomorrow.

Mark

Steve,

I preceded my next run with a sfc confirming no file system problems.

Then ran a Backup with the Single Version scheme and Schedule set to Do Not Schedule.

The log showed 

4/16/2020 3:05:59 PM: -----
4/16/2020 3:05:59 PM: ATI Demon started. Version: 24.6.1.25700.
4/16/2020 3:06:00 PM: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
4/16/2020 3:06:00 PM: Operation MARK-ZT1 started manually.
4/16/2020 3:06:00 PM: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
4/16/2020 3:06:00 PM: Operation: Backup
4/16/2020 3:06:00 PM: Priority changed to Low.
4/17/2020 1:00:40 AM: Error 0x1e50023: File system error is found. Consider checking the disk using Check Disk Utility.
4/17/2020 1:00:41 AM: Error 0x13c0005: Operation has completed with errors.
 

I ran sfc after this detection and it found no errors. Is there something  else I need to do to find this file system error?

Second issue. After this 3:05 backup completed with errors, inspite of the schedule option Do Not Schedule,  ATI seemed to go into perpetual backup mode, you can see this next backup started by schedule less than one minute after the previous manual start.

4/17/2020 1:01:11 AM: -----
4/17/2020 1:01:11 AM: ATI Demon started. Version: 24.6.1.25700.
4/17/2020 1:01:11 AM: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
4/17/2020 1:01:11 AM: Operation MARK-ZT1 started by schedule.
4/17/2020 1:01:11 AM: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
4/17/2020 1:01:11 AM: Operation: Backup
4/17/2020 1:01:11 AM: Priority changed to Low.
4/17/2020 1:01:12 AM: Can't read slices: Error 0x40011: The specified file does not exist.
4/17/2020 6:19:45 AM: Error 0x1e50023: File system error is found. Consider checking the disk using Check Disk Utility.
4/17/2020 6:19:46 AM: Error 0x13c0005: Operation has completed with errors

And after this one another was stated by schedule

4/17/2020 6:20:18 AM: -----
4/17/2020 6:20:18 AM: ATI Demon started. Version: 24.6.1.25700.
4/17/2020 6:20:18 AM: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
4/17/2020 6:20:18 AM: Operation MARK-ZT1 started by schedule.
4/17/2020 6:20:18 AM: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
4/17/2020 6:20:18 AM: Operation: Backup
4/17/2020 6:20:18 AM: Priority changed to Low.
4/17/2020 6:20:20 AM: Can't read slices: Error 0x40011: The specified file does not exist.

How do I disable this perpetual backup activity?

Thanks,

Mark

Mark, SFC is not a file system check tool, you need to use CHKDSK for this purpose.

CHKDSK can only check partitions with allocated drive letters, so any hidden/system partitions cannot be checked unless a drive letter is given to them.

The retries of your failed task is controlled by the Options > Advanced > Error handling settings for your backup task, which defaults to doing 5 retries at 30 seconds intervals.

Steve,

I ran chkdsk before and after the backup, both showed no file system errors and no bad sectors.

But ATI errored, per log file " Error 0x1e50023 File system error is found. Consider checking the disk using Check Disk Utility.

log says The operation completed with errors.

Is there another log file to dig up more details? either ATI or Windows?

Mark

Mark, with ATI 2020 the more detailed messages are found in the backup_worker logs for any Disks & Partitions backup tasks, these can be found at C:\ProgramData\Acronis\TrueImageHome\Logs\backup_worker\ but can be somewhat difficult to read due to being very busy!

If you want help reading these logs, then please zip them (to preserve the original file name) and attach here via the File upload option.

Mark,

Are you running a validation with this task?  If yes please try disabling validation and run the task again.  If errors still persist report those here.

Steve,

Here's the zipped log file.

I see at timestamp 2020-04-17T22:56:14:672-04:00  a common error but the details are unclear.

Thanks,

Mark

Just saw your message regarding validation....will investigate and try again.

Mark, thanks for the backup_worker log, this shows the following:

Backup is of 'Entire PC' thus will include all internal disk drives.
( --resource-type="entire-pc" --vss-mode="vss" --backup-scheme="full" --split-size=4294963200 --keep-versions=1 )

You are splitting the backup into 241 smaller file sizes, which shouldn't normally be needed if writing to a local disk drive such as your K:\\MARK-ZT1.tibx target.

The error reported is happening when closing out the backup to write the file data to the target drive and is showing as a Microsoft VSS issue.  The decoded error message shows the following pertinent information.

17/04/2020 10:56:14:672 PM type=commonerror;
value= A backup error.
Read error.
ReadDrive
Failed to read the snapshot. See VSS logs for details.
win_snapshot_volume:
CRC error.

Please download the Acronis VSS Doctor tool (link in my signature) and run this as Administrator on your computer / let it fix any issues detected that it can.

Steve,

Regarding backing up the Entire PC...The copy of Windows was factory installed. From Disk Management I see three partitions on Disk0:

System (NTFS)

OS (C:) (NTFS)

Recovery Partition.

The System and Recovery Partition do not have drive letters.

If I select Entire PC for the ATI source is ATI attempting to backup  these partitions that have no drive letters?

I have started up a new backup with the source as OS (C:), if I have to do a bare metal restore with the ATI image will that be sufficient to get back the system, all apps, and all data?

Mark

I've attached a screen shot of the Disk Managment view

Mark, you should include all partitions for your Windows OS disk when making a backup image - you would have problems doing a bare-metal recovery without the hidden/system partitions present.  Entire PC on a single disk system is fine.

From your screen image, you should reformat your K: 2TB backup drive to use NFTS and not leave it as being FAT32 as the latter has a maximum file size of 4GB which is probably why your backup file is being split into this size segments (all 241 of them!) instead of a single large backup file.

Mark,

In order to recover your PC you need to backup all partitions on Disk 0 in your screenshot. 

The problem with using Entire PC in your case is that Entire PC infers ALL installed disks in ATI. So the app is attempting to backup all drives shown in Disk Management including drive K: which is where you are creating your backup I believe.  This is known to cause various errors.

Instead of using the Entire PC option, click on the Source icon and select Disk and Partitions, then select all partitions on Disk 0 (this should be dafault).

This will avoid the problem with Entire PC.

Steve, I reformatted the destination drive to NTFS and that eliminated the 241 volume issue. Progress.

Endhantech, I reconfigured the Source. Using Disk and Partitions selected the system volumes excluding K:, the destination.

I did the backup twice once with ST20000xxx level of the tree checked and once with this level not checked. Even when the ST2000xxx level of the volume tree is not checked ATI backs up all three partitions, C:, and the two partitions without drive letters.

In both cases I got the exact same error "File system error found......" and the error string was identical

Wondering if I had a chkdsk problem with the two partitions that did not have drive letters I used MOUNTVOL to get their VolumeNames and used the VolumeNames as arguments into chkdsk. Both of these partitions were error free with chkdsk. I checked c: again and it was error free too.

Attached is a pdf with screenshots of the UI and command prompt activity and a zipped ATI log file with the file system error reported at the end of the report.

Thanks for the help,

Mark

Mark, the latest backup_worker log continues to show the same error:

19/04/2020 09:31:58:541 PM type=commonerror;
value=A backup error.
backup::Commit
Read error.
PartitionBackuper::ReadDrive
Failed to read the snapshot. See VSS logs for details.
win_snapshot_volume::IoOp
CRC error.

Please use the Acronis VSS Doctor to check for snapshot errors on your computer - link in my signature.

If not already done, run CHKDSK K: /F too to ensure the target drive is good.

Concur with Steve of this.  Report back you findings.

Steve,

Seeing two errors in VSS Doctor

--

Timestamp: 4/20/2020 9:26:04 AM
Type: Warning
Source: VSS
Message: Volume Shadow Copy Service warning: VSS was denied access to the root of volume \\?\Volume{74ea0587-0a18-11e1-8c2a-50e549bbaced}\. Denying administrators from accessing volume roots can cause many unexpected failures, and will prevent VSS from functioning properly.  Check security on the volume, and try the operation again.   Operation:    Removing auto-release shadow copies    Loading provider  Context:    Execution Context: System Provider
InstanceId: 12348
SearchLink: https://www.google.com/#newwindow=1&q=VSS+event+id+12348

--

When I use MOUNTVOL to identify this VolumeName it shows a mount point of Q:

But from Disk Management there is no Q:

If I use the /R with MOUNTVOL to remove this mount point I get a response

The directory is not empty

If I try to change from c:\ to q: on the command line I get

Access is denied

I'm guessing this Q: was an external USB drive that was removed long ago.

I can't figure out how to clean this out of the system.

The second error from VSS Doctor is 

Timestamp: 4/19/2020 9:31:57 PM
Type: Error
Source: disk
Message: The device, \Device\Harddisk0\DR0, has a bad block.
InstanceId: -1073479673
SearchLink: https://www.google.com/#newwindow=1&q=disk+event+id+3221487623
 

This is puzzling because I've run chkdsk on all three partitions on Harddisk0 and get a clean error report on every one. Even more puzzling is when I do the google link in the error report it says I'm having trouble between a Fibre Channel HBA and a disk array, and this system has never been any where near a Fibre Channel environment. The one internal drive is SATA.

VSS Doctor report attached.

Mark

Mark,

Have a look Here

Thanks Enchantech,

I reviewed the article at eventid.net, couple of comments

I don't believe I'm running Hyper-V, a guest, or App-V. My system is a garden variety Windows 10 Pro installed by a factory.

Nevertheless, when I browse for a registry entry   ...\Wow6432Node\..... it doesn't exist.

I tried the icacls with the VolumeRoot path for the volume throwing the access denied error and the icacls returns an Access is Denied

I was able to change the run state of the Volume Shadow Copy service from stopped to started and confirmed startup type is set to manual. With this change I've started up a new backup session and will see tomorrow if it completed without error. Will post with results.

Thanks again,

Mark

Ran a backup last night and continue to get the identical error in the backup worker log.

Starting the VSS service did not change the results.

Isn't there some way to clear this Q: mount point out of the operating system even though it does not show up in the disk management tool?

I'm sure it is just some software remnant of a USB external drive that is long gone.

Running chkdsk on the three partitions on disk0 is not turning up any file errors.

I also ran chkdsk on the destination drive k: without any errors reported.

Mark, I have never used it myself but it looks like mountvol might be your ticket. The /r option states...

"Removes volume mount point directories and registry settings for volumes that are no longer in the system, preventing them from being automatically mounted and given their former volume mount point(s) when added back to the system."

Mark,

Mount points are used in conjunction with directories.  How the Q mount point came to be I do not know however, it is the result of directory being assigned the Q mount point.  Do you have such a directory on your C: or K: drive? 

The Mountvol command /r switch will remove the mount directory and the registry entries for volumes that no longer exist on the system but you need to know the path to the directory where Q is assigned.

EDIT: Use Explorer to search for Q and see what the results are.

Enchantech,

VSS Doctor identifies the volumename causing the issue:

Message: Volume Shadow Copy Service warning: VSS was denied access to the root of volume \\?\Volume{74ea0587-0a18-11e1-8c2a-50e549bbaced}\. 

--

When I use MOUNTVOL to identify this VolumeName it shows a mount point of Q:

But from Disk Management there is no Q:

When I use the /R with MOUNTVOL and the volume name above to remove this mount point I get a response

The directory is not empty

If I try to change from c:\ to q: on the command line(admin level) I get

Access is denied

I cannot find any q: mount point on my system.

Mark, create an Acronis System Report then extract the disks.txt file from the zip file to see what that shows for your computer?

Mark, I don't pretend to understand VSS Doctor, but it seems odd that it would have picked Q: for you.  For me it seems to pick the first unused drive letter as seem by Disk Management, but this is obviously not always the case.  But be aware that Disk Management (and whatever Windows processing is behind it) does not see all assigned drive letters.  For instance, it does not see drive letters assigned to "virtual drives" using the SUBST command.

If you issue the SUBST command with no operands you will get a display of all your mapped virtual drives (if any).  Maybe you will find your Q: drive there.  But even if you did, that doesn't explain why VSS Doctor picked it.

VSS Doctor does odd things with its MOUNTVOL function.  (At least they seem odd to me.)  It may select a letter that is already in use on the system (such as for a virtual drive like I mentioned above).  This drive letter seems to be for its own private use and doesn't get in the way of other processes in Windows using that drive letter for its old use, but it means you cannot use the letter that VSS Doctor picked to access the volume VSS Doctor is complaining about.

As an example (but unrelated to the problem in this thread), I have folder on a NAS mapped and mounter as my E: drive.  When I run VSS Doctor it finds two unmapped partitions.  When I click "Assign drive letter" VSS Doctor picks E: (without giving me a choice in the matter).  It also launches File Explorer to show the contents of drive E:, but File Explorer shows the originally mapped E: drive, not the partition in question.

Mark,

See if this link for using PowerShell to locate mount points will help you.

Locate Mount Points

You should be able to find the mount point folder location and determine how much data it contains.  With this you should be able to find and open the folder and either copy the contents to another location if needed or simply delete the contents and then use Disk Management or MountVol to remove the mount point folder and associated registry values.

Steve,

I ran the Acronis Disk Report and examined the disks.txt output and did not see any sign of the locked, phantom Q: disk that is blowing up my Disks and partitions backup by being "locked."

It seems like a bug that if I specify to ATI to only backup partitions on C:  the system should not have a fatal error on Q: particularly if Q: is not accessable and no Q: appears in Disk Management.

I have attached a shortened copy of the disks.txt file from the Acronis System Report. I deleted most of the hex table of the MBR. I could not find any trace of Q: in there. 

Thanks,

Mark

Patrick,

I tried the SUBST command from the PowerShell and there was no output, indicating this phantom Q: drive thats blowing up the backup is not virtual. Which is as expected. 

Thanks,

Mark

Enchantech,

I ran PowerShell in admin mode and it revealed the troublesome Q: drive that is blowing up my backup.

It showed the drive with a Totalsize_GB to be 0.

In PowerShell I tried a CHKDSK on Q: and got Access Denied.

Since I was running in Admin mode I assume there was not a privilege issue but that the drive is "locked"

In Googling around about locked Windows drive I did not find anything that seemed useful to my situation.

The PowerShell transcript  is attached.

Thanks,

Mark

Mark,

Interesting.  Not sure if this will work but worth a try.  Run the command below from an Admin PowerShell instance:

(New-Object -comObject Shell.Application).Namespace(17).ParseName("Q:").InvokeVerb("Eject")

The above should be all on one line in PS.  There is a space between -comObject and Shell.Application.  If you copy the command and paste it into PS it should be fine.

Enchantech,

The PowerShell took your command, no output, no error. Seems like expected behavior for an eject command.

The system just returned to the PS prompt.

Good to see there wasn't an Access Denied error, like CHKDSK returns.

So I'm going to start up another backup and see what happens.

Will report results.

Thanks,

Mark

Yes, that is what i was expecting.  If you run the PS command to locate mount points again Q should be gone.

After the successful eject command I ran the backup again. Source constrained to the partitions on the C: drive.

The same error resulted. Here are the last few entries into the backupworker log.

Steve cracked this code in previous messages.

2020-04-29T08:09:44:410-04:00 14904 I00000000: type=log; level=inf; message=ar#1: archive close (commit_seq=114, reuse_seq=0, file_size=1036881760256, uuid=65f840fb55a0f668658afcd20a3d16db);
2020-04-29T08:09:44:460-04:00 14904 I00000000: type=commonerror; value=ARUAFgLPNWNB0/9Ao0EgYmFja3VwIGVycm9yLgAkbW9kdWxlAEFkaXNrX2JhY2t1cF92c182NTAAJGZpbGUAQWM6XGplbmtpbnNfYWdlbnRcd29ya3NwYWNlXG1vZC1kaXNrLWJhY2t1cFw2NTBccHJvZHVjdFxjb3JlXGRhX2FwaVxiYWNrdXAuY3BwACRmdW5jAEFkYV9iYWNrdXA6OkNvbW1pdAAkbGluZQBOYQEAAAAAAAAAAwAHALi/KKwL+qSLUmVhZCBlcnJvci4AJG1vZHVsZQBBZGlza19iYWNrdXBfdnNfNjUwACRmaWxlAEFjOlxqZW5raW5zX2FnZW50XHdvcmtzcGFjZVxtb2QtZGlzay1iYWNrdXBcNjUwXHByb2R1Y3RcY29yZVxyZXNpemVyXGFyY2hpdmUzXGJhY2t1cF9wYXJ0aXRpb24uY3BwACRmdW5jAEFgYW5vbnltb3VzLW5hbWVzcGFjZSc6OlBhcnRpdGlvbkJhY2t1cGVyOjpSZWFkRHJpdmUAJGxpbmUATmUCAAAAAAAAAIHEEAAMn7h24wTsP0ZhaWxlZCB0byByZWFkIHRoZSBzbmFwc2hvdC4gU2VlIFZTUyBsb2dzIGZvciBkZXRhaWxzLgAkbW9kdWxlAEFkaXNrX2JhY2t1cF92c182NTAAJGZpbGUAQWM6XGplbmtpbnNfYWdlbnRcd29ya3NwYWNlXG1vZC1kaXNrLWJhY2t1cFw2NTBccHJvZHVjdFxjb3JlXGZkaXNrXHdpbl9zbmFwc2hvdC5jcHAAJGZ1bmMAQXdpbl9zbmFwc2hvdF92b2x1bWU6OklvT3AAJGxpbmUAThYCAAAAAAAAAFUBEACvUrgqe8uqAkNSQyBlcnJvci4AJG1vZHVsZQBBZGlza19iYWNrdXBfdnNfNjUwACRmaWxlAEFjOlxqZW5raW5zX2FnZW50XHdvcmtzcGFjZVxtb2QtZGlzay1iYWNrdXBcNjUwXHByb2R1Y3RcY29yZVxmZGlza1x2ZXIyXGFyY2hcd2luZG93c1x3aW5fZXJyb3JzLmNwcAAkZnVuYwBBRmRpc2s6OkFkZEtzdGF0dXNFcnJvcgAkbGluZQBOKwAAAAAAAAAA; id=1;
2020-04-29T08:09:44:471-04:00 14904 I00000000: type=log; level=inf; message=lsm#1: dedup_map nr_lookup=13505477 nr_found=527165 false+=522762 (3.87%/99.16%);
2020-04-29T08:09:44:471-04:00 14904 I00000000: type=retcode; value=4095; id=1;
2020-04-29T08:09:44:483-04:00 14480 I00000000: >>> exit
2020-04-29T08:09:44:543-04:00 14480 I00000000: >>> exit

Here's the Power Shell response, running in admin mode,  to the 

mountvol /l

command

The Q:/ is still there

Then I try to remove it and I get a not empty error, which is weird because the size is reported as 0GB

And then I try to chkdsk it and I get Access Denied because it is locked...

It really does not make sense to me that if I constrain my backup source to C: and related partitions that ACI should fatal the backup on Q:

Possible values for VolumeName along with current mount points are:

    \\?\Volume{00fbce2a-fb18-11e0-9994-806e6f6e6963}\
        *** NO MOUNT POINTS ***

    \\?\Volume{16f2a91f-0000-0000-0000-100000000000}\
        K:\

    \\?\Volume{00fbce2b-fb18-11e0-9994-806e6f6e6963}\
        C:\

    \\?\Volume{2bd2c32a-0000-0000-0000-f0a4d1010000}\
        *** NO MOUNT POINTS ***

    \\?\Volume{00fbce39-fb18-11e0-9994-806e6f6e6963}\
        F:\

    \\?\Volume{00fbce3a-fb18-11e0-9994-806e6f6e6963}\
        G:\

    \\?\Volume{00fbce3b-fb18-11e0-9994-806e6f6e6963}\
        H:\

    \\?\Volume{00fbce3c-fb18-11e0-9994-806e6f6e6963}\
        I:\

    \\?\Volume{74ea0587-0a18-11e1-8c2a-50e549bbaced}\
        Q:\

    \\?\Volume{00fbce2f-fb18-11e0-9994-806e6f6e6963}\
        D:\

New volumes are not mounted automatically when added to the system.  To mount a
volume, you must create a volume mount point.

PS C:\> mountvol Q:\ /r
The directory is not empty.
PS C:\> chkdsk Q:
Access Denied as you do not have sufficient privileges or
the disk may be locked by another process.
You have to invoke this utility running in elevated mode
and make sure the disk is unlocked.
PS C:\>

Mark, the decoded error remains the same:

Base64 decode: A backup error.

Read error.
Failed to read the snapshot.
See VSS logs for details.
CRC error.

Mark, take a read of webpage: USB temporary Drive letters not clearing and see if that has anything of help for you?

Mark,

Since this drive Q: shows up as a mounted volume in PowerShell but does not in Disk Management, as far as I can tell based on your posted screenshots), and the attempt to eject that volume using PowerShell failed (presumably due to the physical absence of the volume), I would suggest the following:

Using again an admin PowerShell prompt type:

• Get-Volume

This should return a list of all volumes including the drive letters assigned to them.  Verify that the Q: lettered volume appears in this list.  Once verified at the PS prompt  type:

• Remove-PartitionAccessPath -AccessPath Q:

Steve, 

The Microsoft article's help depends on the drive being visible to Disk Management and in my case it is not.

Mark

Enchantech,

Tried the Get-Volume and the output does not include a Q:

I did a mountvol /l and get the Q: in the list

I tried the Remove-PartitionAccessPath .... and the error

"Parameter set cannot be resolved using the specified named parameters."

I've attached the transcript of the PowerShell output with this activity.

A new dimension on this....Sometime, presumably in trying to figure out this Q: thing. The Q: drive started showing up in my File Manager screen. I've attached a screenshot. The drive designation looks like this!!!

Microsoft Office Click-to-Run 2010(Protected) (Q:)

I've had Microsoft Office on this computer for more than five years and don't recall ever seeing this in File Manager.

It makes it even more weird that ATI would fatal on Q:

In Googling on this it appears the Click-to-Run function is required to launch any Microsoft Office apps, so getting rid of this does not seem like an option.

Mark

The offending Q drive is a part of MS Office 2010 Starter which came with some PC's It can be safely removed along with the Q drive.

Refer to the MS link below for instructions on removal.

MS Office 2010 Starter Removal