Should the delete function take hours?
I am trying to delete a backup scheme that kept giving me errors along with the backup files that were already created so I can start fresh. I went to the wheel and pressed 'delete' and it came up with a box with a spinning figure and the label "Deleting backup..". It has been doing this for hours. The backup files total about 200 MB. Is this normal or is it in some endless loop?
I have the same problem. I have to stop the program but forcing a reboot or shutting it down with task manager. I suspect it is looking for files from other full backups on other drives or other folders that are not connected or have been deleted. I've left it running overnight and longer. The referenced link might of helped if I'd initially set the program that way but it's not clear how it would help now.
Any other solutions?
Thomas,
What method did you use to invoke the delete option? Did you delete from inside the task or from inside the Acronis Backup Explorer?
Is the backup task which created the backup still listed on your main menu screen of tasks?
If yes, is it scheduled or non-Scheduled.
If yes, how many files or versions does the task display as existing?
From inside the storage folder where the tib files are stored, how many files are listed which are supposed to have been deleted?
As stated above, this link may help.
http://forum.acronis.com/forum/54475
If task still exists and is scheduled, open the scheduler and check the advanced settings to make sure the option "Run when idle" is NOT checked.
Sorry I've got several posts about the issue. I think it started when the drive letter got changed on the USB drive (later assigned it so it wouldn't get shifted again) one of the backup tasks pointed to a then non-existent drive. After this I created new back up tasks that initially ran but the incremental runs tried to go back to the old drive when consolidating. They gave error when running due to trying to open older flawed backup file from prior tasks. I ran though creating a series of new and presumably independent backup task (new name and new folders) and continued to get errors related to attempting to open older files (the version number kept increment up rather than restarting). With this pattern of attachment/referencing older back up file sets that were flawed (issued errors) attempting to delete individual tasks from the listing using delete from the tool list (gear symbol) for the task started an unending run, requiring stopping from Task Manger or forcing a reboot.
Creating new custom backups (new names new destination) either incremental or differential with automatic cleanup appears to remain connected to prior task backup files (version numbers increment up from previous). Is this always the case or it only happens when the deletion of the prior tasks is messed up?
The following is posted under 45982 where you gave some direction on the clearing the Archive file I've copied it here. This appears to have fixed all of the issues and presumably I won't have to delete any tasks in the near future. Still wondering if new tasks will be tied to older files, Generally I create new ones prior to deleting the old ones so that I have backups until the new one is created and run. Is it necessary to delete the old ones first to prevent the new one from attempting to use the older files?
45982 post
Thanks for the tip on the Archive database. I renamed the file ARCHIVES.XML to a .OLD suffix. Also renamed all of the scripts (.tis extension).
For others, these are located in
C:\ProgramData\Acronis\TrueImageHome\Database\archives.xml
C:\ProgramData\Acronis\TrueImageHome\Scripts\*.tib.tis
It may not have been necessary to rename the script files but it provided clarity on which ones were no longer in use.
I created new and empty folders for new backups and ran a new full backup (disk mode, weekly - differential with automatic cleanup) and a selected files backup (daily - differential w/ automatic cleanup).
All of the old tasks are gone and all of new backups started at version 1 (the prior ones picked up version numbers from other backup and then tried and failed to access them). A few more successful iterations will improve my confidence level but all seems to be well so far.
The only remaining small issue is that the pull down list for destinations for backups continues to show folders that have been deleted and are not referenced by any of the current backup tasks. I don't know if attempting to select one of these would send the program off on a never ending search or not. Hopefully I'll remember which ones are real if I go to create any new backup tasks. If anyone knows where this list is kept I'd like to update it.
The learnings out of this seem to be (any one with more knowledge is invited to elaborate or correct these).
The True Image software is confused by changes in the drive letter and continues to have trouble dealing with the issue
- Use Windows to assign fixed drive letters to any USB devices that you use for backups
- Only delete backup files after deleting the related tasks in the ATI program (if prior issues don't send it into a multi hour/perpetual delete)
- If you errors running a backup that show it tried to open a deleted backup file - you may have to manually rename/delete the archive.xml file and recreate all of your backups.
I created new and empty folders for new backups and ran a new full backup (disk mode, weekly - differential with automatic cleanup) and a selected files backup (daily - differential w/ automatic cleanup).
The additional setting inside this custom/diff backup scheme should also have the option checked to "Store no more than X version chains". I do not recommend that the setting based on elapssed days or consumed disk space be used.
-
If you errors running a backup that show it tried to open a deleted backup file - you may have to manually rename/delete the archive.xml file and recreate all of your backups.
In your example, the easiest solution would be to change the task to "do not schedule". Or anther option would simply be to "Remove task from list" option. Either of these two shoud stop the task from being run by ghe program--thus no interference. It is rarely necessary to delete or modify the Archives.xml file.