Why didn't True Image delete any backups?

Okay, upon further review, it looks like the consolidation completed successfully one night, and then failed the next night. I have two files in my backup location that look to be temp files created during consolidation.

After reading through Grover's help doc (thank you very much by the way), it looks like a backup set (the full backup and all diff's or inc's) is not deleted until all diff or inc backups have been consolidated. Once they have been consolidated you are left with a single backup from that set that contains all of your diff or inc backups compiled together.

I suppose this becomes an issue if the consolidation does not work correctly, because it appears that TI just straight up ignores the backup rules once something goes wrong. The logs reference the violation, but it doesn't look like it's doing anything to address it. My backup location has a max number of 7. I currently have 10 files in there. 7 backups, two huge consolidation temp files, and the location config file. I am going to reconfigure the scheduled task to do only full backups and see if that is successful.

IMO, this consolidation method is just asking for trouble. As much as it pains me to admit, Ghost actually has excellent and easy to use/understand scheduler and retention options. Sadly, that's about the only thing that app does well, but Acronis would do well to look into how Symantec handles those functions.

 

Just a few words on my experience of TI. Was pretty happy with earlier versions.. upgraded to 11 purely for the quota management 'feature'. I only ever do full images.. no incrementals.. no differentials.. and limited only by backup count. They're run to an internal disk (that's been tested and has no speed/access issues) and I still have the same kinda problems you guys have been talking about.. maybe.. 30% of the time. So.. no consolidation issues (as there's no incrementals or differentials), no usb/firewire to slow things down, no apparent reason why 70% of the time, everything works fine.

 

Although I haven't done enough testing to verify it, I have two suspicions of what may be causing the problem. MrBuckingham's post seems to eliminate one of them. The first possibility is that it is the *consolidation* that is failing, not the deletion, but ATI is not giving the correct error. Maybe consolidation was failing for me because disk space was low, but there should have been enough room and I tried to check the disk usage every few minutes to see if the consolidation was filling the disk. I guess it is good that ATI won't delete if the consolidation fails, it would be nice if it would say why the delete failed.

The other possibility that occurred to me is that ATI is trying to delete old backups into the recycle bin. Since most full backups won't fit into the typical recycle bin, that *might* generate an error that ATI can't handle.

My consolidate and delete seems to be working now, so I am reluctant to mess with it to do much testing. MrBuckingham's experience seems to rule out the first option, at least in his case, but I still have my suspicions. In my case, I both swapped in a larger internal disk so that there is plenty of room to consolidate, and I turned off the use of the recycle bin on the drive where I put the backups using the same account as is used to run the backups. So far, it seems to be working, knock on wooden electrons.

 

Hmm.. hadn't thought about the recycle bin thing.. it's definitely worth a try.. so I've now turned mine off too. Will let you know how it goes. I also realised I had Perfectdisk auto-defragging that drive.. so I've now turned that off too. so the only thing ever using the drive is TI. Fingers crossed...

 

Just a clarification for those readers that might be using ATI12/2009 -- any deletions of any backup files should be done within ATI and not Windows Explorer because ATI12/2009, unlike prior versions keeps a database of the backups it's made and won't know that you've deleted any of them using Explorer. This wasn't an issue with prior versions of ATI.

 

@shieber
Yes, I forgot to mention it. This clarification is a 'must'. THX

 

I believe the reason is an error condition, as indicated by

I have seen more than 100 such consecutive events when creating an archive.

BUT NOW it works perfectly - it succeeds upon the first attempt at ".. .closed"

The difference is that NOW I take extra care. I always ensure that any MOUNTED images are UN-MOUNTED before I start to create an archive.

I have noticed that at the instant an image is UN-mounted, there is an immediate ftdisk error posted in the event log with the warning that data may have been lost, and chkdsk subsequently indicates errors on files $9 and $11. It seems that for some reason TIv11 causes a connection between the USB image that is mounted and some security files and things on C:\, and when the image is UN-mounted I get exactly the same ftdisk error, and exactly the same chkdsk errors, that I get when Windows Explorer was looking at a USB partition (but NOT in the act of reading/writing), and in that quiescent state this village lost all electricity, with the exception of my battery supported Laptop which merely showed that partitions F: to K: had disappeared because the USB drive depended upon a non-battery supported external supply.

Violently disrupting communication between the USB drives and System drive C:\ gives exactly the same errors as UN-mounting an image.

The penny dropped.

Before creating the next archive image, I always mount the previous image and do a folder/file comparison to have a last look at everything which has changed, so I may cancel unwanted changes (e.g. last week's shopping list, or a download which did not work for me, etc. etc.) Once I have purged all the temporary junk I will never want again, then I created the next archive, PROBABLY without thinking about UN-mounting the old image.

My theory is that Acronis wants total control of the access to the USB drive when creating the image, hence it attempts "Archive computer .closed", and this actually fails if a previous existing image is mounted and C:\ is aware of this mounted image partition.

I seem to have cured this problem by ensuring that no image is mounted when I start the creation of a new image.

I only have a quota SIZE limit, and no incrementals, and automatic deletion always seems to work for me.
I suspect that additional rules about how many incrementals etc. etc. could be an extra complication, and the final straw could be multiple "Archive computer .closed" errors (either because you to have got an image mounted at the time, or because of some other reason.)

Regards
Alan

 

Hello all,

Thank you for using Acronis True Image

Acronis True Image Home Backup Location quotas do not function on network share. Quotas always exceed when Backup Location is on a network share or a network drive. This is a known issue.

About USB external and internal hard drives. There can be two main reason for the encountered issue. First of all, please check the backup files for corruption. Acronis program fails to consolidate the corrupted backup files. If all backup archives are valid, please delete the present scheduled task and delete Backup Location. After that contact our Live Chat service here and ask any Live chat operator to provide you with an install.bat file to re-new the scheduler for Acronis True Image 11 Home.

Extract the archive contents and run the install.bat file. Wait for the process to be completed, reboot your machine. Re-create Backup Location and manage a scheduled task again.

This workaround can help to solve the issue.

Thank you.

__

Oleg Lee

 

That's your problem right there: Vista.

 

If you don't like it, leave. If Ghost works so much better, why are you using ATI?