Skip to main content

Deleting Intermediate Incremental Files

Thread needs solution

I'm currently working with ATI Server 9.1 (I also run Home 9-12) and have a general question about deleting incrementals. I backup almost every day and they all validate. I had to restore back 3 days and I need to know if it is ok to delete the incremental files (2) after that time.

Will there be any issues if I just delete them outright?
How does TI know what files changed (I heard a long time ago that it may be using the archive bit???)?

I don't want TI to get confused when I backup later today. This is if any file saved during the last two days are part of the good ones 3 days ago.

Thanks for any inputs.

0 Users found this helpful

Re: TrueImageHome--The backup task will fail if you delete any incremental file. Each is an integral part of the chain. If you delete any incremental, the ones deleted contain information not contained elsewhere. All subsequent incrementals rendered useless if any interim backups deleted.

The definition of an incremental is that it saves only the changes that have occurred from the last incremental.

Thanks for letting me know about this. This is not an experiment I want to fool around with. It's not a very good system when you delete something and it corrupts all of the backup files. I've noticed (and pay a lot of attention) that any corruption to these files renders them useless as well. I guess I'll add this case to the list. Acronis should provide more error corrections or fault tolerance against these cases as once an issue crops up, there is virtually no recourse. In this day of many terabyte disks, what is a person to do - just hope and pray? I would pay more for this feature if it was available as it is important.

Also incrementals should be able to back track files when issues are discovered. Why aren't there tools built in to do this safely (also resetting the file tracking change mechanism on each turn)? I would have used this to back out of my corrupted data base files. Instead, I had to blow away all of them and go back to a known good date and start all over with the backups.

So there's no way to remove the newer files in the chain which includes the errors except to start over.

If I had any say, I would work on bullet proofing this area first before adding more bells and whistles. This effort would pay for itself in the long run as people find it to be robust enough to trust.

With the incremental, if the chain is interrupted either by deletion or corruption, your only recourse is to start the backup task over again as new. You may be able to mount the backup (if corrupt) for some file recovery but you will need to start over. Note if backup #4 happens to be the bad one, then the full and 1-2-3 are usable and restorable. If it is #3 which is bad, then #4 is of no use.

You may want to consider using the full plus differential method. Each diff backs up everything since the last full so each diff contains all changes since the full. If one becomes corrupt or missing, your task still becomes useless but the actual files may still be usable.

When restoring a full plus diff, all you need is two files--the full plus any single diff. Any missing files will prevent the chain from validating but you can usually have a successful restore as long as you have the full plus any diff.

If you are consistently or frequently having corrupt files, there has to be other problems. It could be either disk has disk errors so both disk should be checked for disk errors. Or, a frequent cause is bad memory sticks so the memory could be checked. You could also try slowing the write speed on the usb drive. Or, if a desktop, use a rear connector plus a new cable. Do not use a USB hub. If the external disk is in use, if it does not have a power cable, try using a disk with a power cable. Sometimes power via a usb cord is not adequate.

This link may help.
http://kb.acronis.com/content/1517

Let's say the corrupted TIB is #10 in a chain of 20. I can restore up to #9 but not after. what would happen if I removed #10, copied #9 and renamed it #10?

Peter, in your example, your backup chain would still be broken after #9.

Incremental versions each rely on the one before so copying one will not work.

The best advice here is to not create large chains of incremental backups - keep the chains reasonably short, i.e. create a new full backup after 6 daily incrementals, so that the risk of problems arising from a bad file / bad sector etc is minimised.