Aller au contenu principal

ATIH-2014 PRO - REMOVING VERSIONS

Thread needs solution

There is a serious flaw in ACRONIS handling of the option to REMOVE a "Version" - such as when a backup is found to be "corrupted" on Validation.

Rather than "continuing" to add a new backup to the last set of versions (or string of Diffs/INCR's) in the CURRRENT CHAIN - ATIH instead, adds a new version to the very FIRST chain. Then each new backup is incremented to the (#b.#s.#v) FIRST Chain - and even exceeds the number of INCR/DIFF's that were set up in CUSTOM - until it is time for a new FULL backup. It would take many backup sessions for ATIH to finally get back to normal sequencing.

The correct method would be to continue where it had left off in the present versioning sequence.
The PROBLEM it causes is that, should there be a crash, the user would instinctively select the last sequentially numbered backup to RECOVER. But, that backup is in fact older than the actual most recent backup, by date - the one added after a REMOVAL of a flawed one. This would result in new user files created during the most recent versions of the CHAIN being misplaced by being "incorrectly attached" to the wrong "initial FULL Backup", (which may include several INCR/DIFF), and thus be far out of date.

ACRONIS developers programmed the "Version" REMOVE command incorrectly.
Ideally, ATIH should have a user specified OPTION in setup, to "replace an INVALIDATED backup" automatically, at the next run session. This would maintain correct "sequencing" (#b.#s.#v) - and would save the user having to check for bad backups, and go through the entire Version Remove process, every time. It would also save critical backup drive space, which might already be tight, since he present algorithm flaw wrongfully increases the number of saved versions, and if there are a lot of INVALIDATED backups, the present buggy process could create very many useless saved disk backups, far exceeding what the user expected to accommodate on his tiny storage drive.

I suggest the "option", since some users may in some cases NOT wish to delete an INVALID backup, since even a bad set of files can be mounted and retrieved. However, I think that would be a rare exception.

I suspect this ATIH bug has been there since this product was designed - and not just Acronis True Image 2014.

Joe Z.

0 Users found this helpful