Skip to main content

Cleanup seems to not work - Set to 7 days and now 8 are in the folder.

Thread needs solution

What am I doing wrong?

I'm having Acronis creating Full backups, and have set the cleanup feature to delete anything over 7 days old. I now have 8 images in the folder.

Attachment 9-16-2012_6-07-28_pm.png shows the configuration and 9-16-2012_6-06-16_pm.png shows the files in the folder.

Attachment Size
9-16-2012_6-07-28_pm.png 40.84 KB
9-16-2012_6-06-16_pm.png 30.16 KB
0 Users found this helpful

I don't think your first backup is over 7 days old yet.

On the 10th, your first backup is one day old.
On the 11th, your first backup is two days old.
On the 12th, your first backup is three days old.
On the 13th, your first backup is four days old.
On the 14th, your first backup is five days old.
On the 15th, your first backup is six days old.
On the 16th, your first backup is seven days old.
On the 17th, you first backup will be eight days old and should then be deleted as it is "more" than 7 days old.

It has now grown to 9 images, and it appears that Acronis is failing, or am I doing something wrong?

Attachment Size
110870-103423.png 33 KB

I would think you are doing everything correctly. The first backup should have been deleted after the new backup was created on the 17th.
Can you post your log?

Michael,
FWIW, if you change the settings after the backup has started, the counting might be reset to zero the day you made the change. I am not sure this is valid for full backup, but for an incremental, here is what I observed.
- let's assume you set a backup chain to produce 9 incrementals, then do a full,
- after backup 3, you now have a full and 4 incrementals,
- at this point, you change to produce 7 incrementals,
- ATI will produce 7 incrementals from that point, so the first chain will get a total of 11 incrementals (7+4),
- the ATI will produce a new full and observe the new settings.

Maybe this is by design so that ATI doesn't delete any incremental if were to change from 9 to 3 in the above example...

Again, I am no sure this applies to full backups, but in case this might apply...

Today there were 9 images labeled b1 - b9. My system failed somewhere overnight and BSOD which caused the backup not to run. I manually kicked off the backup and afterwards the images that were labeled b1 and b2 were gone and now the images are labeled b3 - b10, so I'm guessing that is how it should be. If you specify Acronis it keeps 7 consecutive days of images there will actually be 8 kept, and on the ninth image (last created) Acronis removes the earliest one.

I'll try it and see how it goes for the next few days. What I'm really trying to do is preform a restore from one of the middle images and see if Acronis will remember where it left off. This always failed with 2012 as the database had a case of Alzheimer's everything an image was restored form anything other then the previous days.

Makes sense. Also remember that if you keep 7 images, ATI will need to do 8 images, then delete the oldest one, in this order.

I get it; Having the cleanup set to 7 will create images 1-8. The math doesn't work for me as setting the cleanup to 7 really creates 8, so I guess if you only want 7 you need to set the cleanup to 6. It also looks like the numbering system also grows. IE; I now have 3-10, tomorrow I should have 4-11, day after tomorrow it will be 5-12, strange way to do it.

It'll be interesting to see what happens when one of the images from the middle is restored. Will Acronis lose track of where it left off, or will Acronis think the restored image was the last image created.

Since you are doing full disk backups, Acronis will continue to make new fulls, but the database will not know about the backups created since the restore date. This will probably throw the sequence for auto deletion off, but once the cycle catches up, the deletions should start again.
Any time I perform a full restore to a previous date, I normally delete the backup tasks I had setup and create new tasks to move forward with to prevent any database problems within Acronis.

I'm using Diff backup with a full backup after 13 diff backups with a size limit of 850GB and that doesn't work from TI2013. TI has made 23 diff backups so far with the latest six left on disk due to the size limit. 23 diff backup but no full backup, except for the first one.

It seems that Acronis may have fixed a previous 2012 issue. Creating a single task and placing all the backups in a single folder always hosed the database, eventually in 2012. I an now up top b7 - b14 and so far so good. It time to see if restoring from b8 will screw the whole count up.

Jan,

Remember that if you have edited the settings of the task, the counting starts over at the date of modification. Limiting chains by size is a bit unreliable because if a single chain plus a new full exceeds the size, ATI will not be able to enforce the size limit and you might run out of space. It is better to limit the number of chains, estimating the size needed to complete a chain, multiplying by the number of chains you want to keep and adding the size of a new full plus some margin for security.

I haven't changed the settings and I've set the limit to have room for a full backup. All that calculation is what I have TI for, I'm just using the setting user interface. Too bad if it's not working.

I had 8 images 'System_(C)_full_b7_s1_v1.tibb' - 'System_(C)_full_b14_s1_v1.tib', and I restored image 'System_(C)_full_b8_s1_v1.tib' yesterday.

This morning I had 6 notification in my mailbox:

email 1 to email 6 were identical except replacing the 'b1' with 'b2', then 'b3', then 'b4', then 'b5', and finally 'b6':
=======================================================================
System (C) Task is waiting for user interaction.
Description: Stage Description
Information: Failed to open backup D:\Apollo\System_(C)_full_b1_s1_v1.tib. It may be inconsistent or corrupted.
Details: Click Retry to try to read from the same location. Otherwise, click Cancel to cancel the operation.
=======================================================================

When I originally restored from 'System_(C)_full_b8_s1_v1.tib', there were 8 images; 'System_(C)_full_b7_s1_v1.tib' - 'System_(C)_full_b14_s1_v1.tib'. I still have 8 images (Image 'System_(C)_full_b7_s1_v1.tib' is gone).

System_(C)_full_b8_s1_v1.tib
System_(C)_full_b8_s1_v1-2.tib
System_(C)_full_b9_s1_v1.tib
System_(C)_full_b10_s1_v1.tib
System_(C)_full_b11_s1_v1.tib
System_(C)_full_b12_s1_v1.tib
System_(C)_full_b13_s1_v1.tib
System_(C)_full_b14_s1_v1.tib

Letting it run a few days to see how this goes. Not real concerned with the naming convention, but the errors in my mail box concern me.

Michael,
See post #8. Your backup naming issues and errors are related to the Acronis database being inconsistent when Acronis checks against the actual backup files after restoring your backup to an earlier date. Although Acronis "may" eventually starting pruning the backups again, some of the files will be left in the folder.

Yes, I know but it's an Acronis problem. They have failed from day one to fix this problem. It just shows a lack of innovation from a company that has been around long enough see the problem, which they have, and fix it.

I'm not sure what the solution is, but apparently they have no clue either. How about a maintenance module that runs after a restore and cleans things up, based on the users backup configuration.

Restoring an image should not require user intervention in order to fix a database problem. After restoring an image, why should the user have to go in and delete all the images in order for Acronis to keep its database straight.

The ONLY way to fix this problem in 2012, for me, is to create 7 individual tasks, seven folders, and dump each task in it's own unique folder. I could restore from any day, and it took right back off where it left off.

Another 2012 problem was; if you did create 7 tasks you couldn't place all the images in a single folder, because it would corrupt the database. Maybe in 2013 I can place all the images in a single folder?

The problem when doing a restore to a system that keeps a database to index data that is stored on external media, or in any location other then on the restored system drive(s), exists in many programs. In every case like this, user intervention and maintenace is almost always necessary to correct the discrepancies between the database and the data it is indexing. In the case with your situation, simply deleting the task and re-creating it would fix the issue. You would have to manually clean up the old files, but only after you have successfully run the new task. Even with the "7 tasks" method you suggest works, I can still see issues with Acronis and it's database not matching the data except in those cases where the older database that was restored still matched some of the data files in the folders that had yet to be updated.
I agree that this could be handled better by the program (for example a notification that the databse and the files it is tracking don't match and offer suggestions on how to correct this.), but I don't expect that after a full system restore that every program I have on my system will update itself, or be able to automatically, without user intervention, correct any issues that restoring to an earlier date may cause.

Just my two cents.

James

You create a task to allow automation of a process, and at least in this situation, it certainly isn't that after a restore has been done.

I have a working solution for my needs, and there is no intervention required, ever. For me there isn't enough new innovations in 2013 to make updating worth spending the money, at least while I'm still on Windows 7.

This morning I had another 6 notification in my mailbox:

email 1 to email 6 were identical except replacing the 'b1' with 'b2', then 'b3', then 'b4', then 'b5', and finally 'b6':
=======================================================================
System (C) Task is waiting for user interaction.
Description: Stage Description
Information: Failed to open backup D:\Apollo\System_(C)_full_b1_s1_v1.tib. It may be inconsistent or corrupted.
Details: Click Retry to try to read from the same location. Otherwise, click Cancel to cancel the operation.
=======================================================================

These are the same exact alerts it sent the previous day, after I restored image b8 of an image set labeled b7-b14. I'm guessing the only way to get Acronis to stop sending these alerts is to delete the task, and create a new one.

Here is another quirk with this install: Creating a task and then renaming the image file; If you go back in and rename the image name in the task, it does change the name in the task screen, but when the task runs, it save the image to the disk with the original name. The only way to match the task name with the created image name after a name change is to delete the task and create a new one.

Are you changing the name of the backup image file using the "browse" the backup destination option in the backup settings page, or changing the task name only at the bottom of the settings screen? This may be done on purpose to help the database track the original backup, slices, and volumes of the backup sets if using incremental or differential backups. Changing the task name only changes the displayed task name, not the backup destination file name. They are two separate items, and can be changed independently of each other (even during the task creation). This was true in 2012 as well.

James

Michael,

This is indeed not a bug. The name of the task is not hard-wired to the name of the TIB files. When you change the naming of the TIB files, the proposed task named is changed automatically however.