How to retry a failed incremental backup
My backup scheme for data partition has a full backup every 5 weeks and an incremental bu every week in between.
When an incremental fails (due to system shutdown), how do I retry (restart) that weeks incremental? It doesn't start automatically, although I have the retry option set, and if I press 'Backup Now', it starts a new full backup instead, which I do not want.
What should I be doing?
Richard

- Log in to post comments

Thank you for the information and links - it caused me to check more closely into the failure, and it seems that the problem is different to what I had thought - I am just as puzzled, but for a different reason!
If you look at the first two atachments, it is clear that the original backup was in fact trying to write a new full backup - Data2_full_b2_s1_v1 - inspite of the fact that only two incrementals exist, rather than the 4 called for by the scheme. Therefore the manual retries were in fact consistent in attempting to create full backups - but I do not understand why the original wasn't creating incremental s4 rather than a new full?
I have checked my Scheme definitions, using the information in the reply above, and it all seems to be correct - see attachments 3 & 4 - indeed, one of the other backups running just beforehand (see attchment 5) is identical, and worked perfectly, as attachment 2 shows.
Less significant, but also not what I expected, the status of Data2 backup after the failure - attachment 6 - shows the last backup as the previous week - correct - but the next as the following week, rather than indicating an outstanding backup for this week. I don't understand why the retry settings - attachment 7 - did not trigger an automatic retry when the system restarted?
Attachment | Size |
---|---|
297402-122341.jpg | 82.62 KB |
297402-122344.jpg | 111.57 KB |
297402-122347.jpg | 112.53 KB |
297402-122350.jpg | 84.67 KB |
297402-122353.jpg | 299.96 KB |
297402-122356.jpg | 156.37 KB |
297402-122359.jpg | 100.62 KB |
- Log in to post comments

Richard,
I would agree that a retry at the backup should have been triggered on startup following the missed backup. Have you looked at the log file?
The most usual explanation is the original task was changed by user edits and the program did not implent the changes correctly.
All my references lists advises against editing a task and the changes rarely ever produce the correct results. I don't know why changes are permitted if they cannot be implemented. However, the fact that the task is not working justifies starting over with a new task and ceasing to use the old one.
You many even want to consider running the TI cleanup utility and do a fresh re-install, but your other tasks "appear" to be working correctly.
Editing an existing task is not recommended. Rarely does an edited task perform to user expectations. It is usually better to start with a new task using a new non-identical task name and point to a new storage sub-folder so each task has it own storage folder/sub-folder. Old task can be stopped or deleted from the task listings.
GH25. Understanding differences between Incremental and Differential backups for data recovery.
AGH-1. 64640: Do's & Don'ts--Hints to help prevent issues with your TIB.
GH63-1. 75086: A discussion on how to configure backup schemes.
Rather than a cleanup/re-install, some users delete all the files in the database folder
c:\programdata\acronis\trueimagehome\database
The logs can be found at
c:\programdata\acronis\trueimagehome\logs
The scripts show in the task listing found here.
c:\programdata\acronis\trueimagehome\scripts
- Log in to post comments