True Image 2019 task OK in Application, but Access is Denied when scheduled.

Andrew, ATI (all versions) require that the application is installed and run from an Administrator account in order to have all the required authorities / privileges etc. 

The behaviour for how automatic cleanup works is also correct per the application design, i.e. ATI will never delete the oldest backup version chain until a new full backup has been created successfully.  If you want a different behaviour then you would need to manually delete the unwanted backup image file via a script running as a Pre Command but which then may cause errors to be generated due to all files being tracked in the internal database used by ATI which would not be updated for any manual deletions of files.

I would recommend investing in a larger backup drive as the best solution here.  Also, although you say the source disk is 1TB, how much of this is actually used, how much is free space?  ATI will use an element of compression normally which can give some size savings, plus the default exclusions for the backup task will also exclude various large files such as pagefile.sys, hiberfil,sys, swapfile.sys and also the System Volume Information folders (where system restore points are stored if System Protection is enabled).  All the excluded data is recreated by Windows on startup (except for restore points).

Hi Steve,

Thanks very much for your reply. 

I was indeed trying to do exactly what you suggested - just to see what would happen.  I created a pre-script which moved the TIB files around prior to backup.

For reference, the account I use is a system administrator account.

My solution works perfectly well if I open ATI and run it from within the program.  All six times it did exactly what is wanted.  However, if I allow the scheduled task to launch itself, it doesn't even run the BAT file.  The task doesn't launch, but event viewer logs the "Error 5: Permission denied".

I did read some posts suggesting you can solve this by changing the "Log On" property of Scheduler2 service from LocalSystemAccount to an actual administrator account.  If I did this, the scheduled task worked perfectly at the scheduled time - until the computer was rebooted - after which it never ran and didn't even log anything in the event viewer.

So I changed it back to the way it was.

There has to be somewhere that would give us more information on what is failing.  It can't be access to any of the disks as they are local SATA drives.  How can I dig down to find out what causes the failure?

Many thanks for your help,

Andrew.

Andrew, if you have Acronis Active Protection active / turned on, then this will prevent backup .tib files from being moved or deleted etc.  Test your script with AAP turned off to see if that removes the Permission denied issue, and if so, then you would need to add some extra lines to your script to turn off AAP before any move / delete actions, then turn it back on again afterwards.

Example of a Powershell script I have used:

$testfiles = "L:\Test\WINPE_inc_b?_s6_*.tib"
$taskfiles = "L:\Test\WINPE_*.tib"

if (test-path $testfiles) {
write-host "$taskfiles found"
sc stop "AcronisActiveProtectionService"
remove-item $taskfiles
write-host "$taskfiles deleted"
sc start "AcronisActiveProtectionService"}

Steve,

Just for clarification...

When moving the files like this, Acronis will "stutter" at recovery time though because those backups will still remain in the database (as far as the application is aware/concerned) and will show up as available recovery points.  I'm assuming that when the third full completes though, it would attempt to remove the oldest backup (which would have just been manually moved or deleted by the script) and that should clean that from the database at that time though?  Or, will it cause the version cleanup any issues?  I haven't tried this, but am assuming it will just ignore that they're missing and purge it from the database since that is what it's supposed to do after the third backup is complete anyway.

Rob, that is the downside to deleting any backup files via script or manually - my example script above was deleting a whole version chain (Full plus 5 Incremental files) as a test for a problem raised by another user.  It works but does nothing about the database references to the deleted chain!  I haven't found any way to script a validation for such a task and even then it would want manual intervention for the pop-up errors presented for missing files!

The only other way of overcoming the database issue would be to blow away the database folder & contents, which in turn requires that the other Acronis Services & Processes are stopped / ended!

Personally, I use automatic cleanup for my own tasks.  The scripts are examples for users wanting to try a different approach and come with the normal caveat emptor (or however the latin phrase for buyer beware! is spelt!).

Ah OK.  I had a feeling it would behave that way so long as that backup was supposed to be there, after it had been moved or deleted outside of Acronis, but was hoping that once the third backup then completed, it would attempt to delete it again, and then just mark it as cleaned up so it wouldn't cause any warning prompts in the console down the road.  It is what it is though as long as the admin knows the behavior.  It won't prevent an actual recovery, just might throw those warnings that files are missing and ask to locate them in some instances.