Backup schedule, rotation, retention

Thread needs solution
truwrikodrorowrelupicugojestutroclulachosaswunuhospikigawakijosaswenomaruclojeueclikaspedrubewidebrisubrohutrurifruuagothunugekedrumucisiuobrobrecrupeslapuswosluprothethibakaslechurathikucli
Beginner
Beiträge: 1
Kommentare: 0

I am an Acronis True Image (ATI) user.

Simply put, I want to delete old back ups. I apologize for the length of the note, but I wanted to try to be complete. Furthermore, I think others would be thrilled to have this feature.

What I want to do is this,

Set up an incrmental backup job which, of course, will begin with a full back up (F1) and then do (N) incremental backups. When I have F+N backups, start a new incremental backup (F2), and will do (N) incremental backups. I now have (F1+N) and (F2+N) backups. This cycle continues. After I have (S) sets of backups, when the S+1 full backups completes, then the oldest set of backups is deleted. Ok, I admit that may be hard to picture,

If N (the number of incrementals) is 2 and S (the max number of full backups) is 3, I want this behavior from my backup scheduler:

F1 (full_backup)
F1_001 (incremental)
F_002 (incremental)
F2 (full_backup)
F2_001 (incremental)
F2_002 (incremental)
F3 (full_backup)
F3_001 (incremental)
F3_002 (incremental)
F4 (full_backup)
.. at this time, the number of full backups (S) in this location are exceeded
.. so the *oldest* backup F001 an it's related incrementals are deleted
.. on disk I now have
F2 (full_backup)
F2_001 (incremental)
F2_002 (incremental)
F3 (full_backup)
F3_001 (incremental)
F3_002 (incremental)
F4 (full_backup)

.. and the pattern continues

F4_001 (incremental)
F4_002 (incremental)
F5 (full_backup)

.. at which time F002 and it's related incrementals are deleted

Keeping track of the next number for F is problematic. Don't bother. Query the bakcup location and make a run time determination. If you have a rock solid naming convention, you are set. The number with the full backup could be a timestamp (like 20091001083914 for Oct 1, 2009 at 08:39:14 am) that could give the next set of backups a unqique name, yet ensure proper sorting. If you issue incrementals as 001 to 999 you can have up to 999 incrementals per full backup. *Yes, I a programmer (architect actually)*

Recommended back up naming

ATI_20091001083914 (full backup "id" number is timestamp of full backup)
ATI_20091001083914_001 (incremental keeps full backup "id")
ATI_20091001083914_002

If someone manually deletes or renames backups, the runtime determination auto-corrects, as it will only consider backups that fit the naming pattern. (Be sure to document this, perhaps also stuff a ATI_README.txt in the backup location if one does not exist when the backup starts).

My understanding is that for a partition backup that a full backup might be forced if ATI determines a lot changed (perhaps due to a defrag). I can live with that, I suppose.

I do not want the system to consolidate backups. I do want the system to monitor my disk space as follows:
(1) Estimate the space needed for backup, notify me (popup and email) if there is not enough space.
(2) Notify me if the backup location is more than X% full.

I have pretty much give up getting the ATI to do what I want. So, I just put a notification on my calendar to go and manually clean up old backups.

But, I am somewhat confused by what to delete. I do both file and partition backups. I do file backups of important files daily, and partition backups weekly. The backup naming is confusing and seems to be somewhat inconsistent. I guess an I can "infer" when a full backup is occuring by it's size.

MY QUESTION IS THIS: Is it absolutely safe to "infer" that? And simply delete everything (based on date) from the oldest inferred full backup up to the next inferred backup. In the real life below, I've marked these with a (*)

Partion Backups

10/02/2009 09:03 PM 1,944,882,688 SystemPartition(1)82.tib
09/25/2009 09:17 PM 44,890,513,408 SystemPartition(1)8.tib
09/18/2009 09:03 PM 1,991,258,112 SystemPartition(1)7.tib
09/11/2009 09:03 PM 2,490,334,208 SystemPartition(1)6.tib
09/04/2009 09:03 PM 2,234,251,776 SystemPartition(1)5.tib
08/28/2009 09:03 PM 1,343,578,112 SystemPartition(1)4.tib
08/21/2009 09:03 PM 2,182,923,776 SystemPartition(1)3.tib
08/14/2009 09:03 PM 2,321,921,024 SystemPartition(1)2.tib
08/07/2009 09:17 PM 44,138,819,072 SystemPartition(1).tib
* 07/31/2009 09:02 PM 1,538,490,368 SystemPartition3.tib
* 07/28/2009 04:49 PM 511,075,840 SystemPartition2.tib
* 07/25/2009 08:49 PM 44,060,637,184 SystemPartition.tib

File Backups:

10/02/2009 06:32 PM 88,355,840 DocumentAndSettings2(2)14.tib
10/01/2009 06:32 PM 106,007,040 DocumentAndSettings2(2)13.tib
09/30/2009 06:32 PM 83,433,472 DocumentAndSettings2(2)12.tib
09/29/2009 06:32 PM 110,460,928 DocumentAndSettings2(2)11.tib
09/28/2009 06:32 PM 85,576,192 DocumentAndSettings2(2)10.tib
09/27/2009 06:32 PM 108,721,664 DocumentAndSettings2(2)9.tib
09/26/2009 06:32 PM 111,775,744 DocumentAndSettings2(2)8.tib
09/25/2009 06:32 PM 110,068,736 DocumentAndSettings2(2)7.tib
09/24/2009 06:32 PM 113,600,000 DocumentAndSettings2(2)6.tib
09/23/2009 06:32 PM 161,492,480 DocumentAndSettings2(2)5.tib
09/22/2009 06:32 PM 106,181,120 DocumentAndSettings2(2)4.tib
09/21/2009 06:32 PM 87,422,464 DocumentAndSettings2(2)3.tib
09/20/2009 06:32 PM 88,613,888 DocumentAndSettings2(2)2.tib
09/19/2009 09:50 PM 22,866,921,984 DocumentAndSettings2(2).tib
09/06/2009 06:32 PM 111,122,432 DocumentAndSettings2(1)29.tib
09/05/2009 06:32 PM 115,857,408 DocumentAndSettings2(1)28.tib
09/04/2009 06:32 PM 171,196,928 DocumentAndSettings2(1)27.tib
09/03/2009 06:32 PM 111,766,528 DocumentAndSettings2(1)26.tib
09/02/2009 06:32 PM 121,844,736 DocumentAndSettings2(1)25.tib
09/01/2009 06:32 PM 115,009,536 DocumentAndSettings2(1)24.tib
08/31/2009 06:32 PM 87,977,984 DocumentAndSettings2(1)23.tib
08/30/2009 06:32 PM 110,817,280 DocumentAndSettings2(1)22.tib
08/29/2009 06:32 PM 117,107,200 DocumentAndSettings2(1)21.tib
08/28/2009 06:32 PM 121,647,616 DocumentAndSettings2(1)20.tib
08/27/2009 06:32 PM 84,257,792 DocumentAndSettings2(1)19.tib
08/26/2009 06:32 PM 108,429,312 DocumentAndSettings2(1)18.tib
08/25/2009 06:32 PM 109,398,016 DocumentAndSettings2(1)17.tib
08/24/2009 06:32 PM 96,560,128 DocumentAndSettings2(1)16.tib
08/23/2009 06:32 PM 101,894,144 DocumentAndSettings2(1)15.tib
08/22/2009 06:32 PM 117,783,552 DocumentAndSettings2(1)14.tib
08/21/2009 06:32 PM 153,075,200 DocumentAndSettings2(1)13.tib
08/20/2009 06:32 PM 107,789,824 DocumentAndSettings2(1)12.tib
08/19/2009 06:32 PM 112,877,568 DocumentAndSettings2(1)11.tib
08/18/2009 06:32 PM 142,716,416 DocumentAndSettings2(1)10.tib
08/17/2009 06:32 PM 88,731,136 DocumentAndSettings2(1)9.tib
08/16/2009 06:32 PM 110,570,496 DocumentAndSettings2(1)8.tib
08/15/2009 06:32 PM 109,253,120 DocumentAndSettings2(1)7.tib
08/14/2009 06:32 PM 158,348,288 DocumentAndSettings2(1)6.tib
08/13/2009 06:32 PM 101,892,608 DocumentAndSettings2(1)5.tib
08/12/2009 06:32 PM 108,068,352 DocumentAndSettings2(1)4.tib
08/11/2009 06:32 PM 111,496,192 DocumentAndSettings2(1)3.tib
08/10/2009 06:32 PM 62,491,136 DocumentAndSettings2(1)2.tib
08/09/2009 07:00 PM 22,760,042,496 DocumentAndSettings2(1).tib
* 08/08/2009 06:32 PM 109,656,064 DocumentAndSettings15.tib
* 08/07/2009 06:32 PM 107,307,008 DocumentAndSettings14.tib
* 08/06/2009 06:32 PM 101,497,344 DocumentAndSettings13.tib
* 08/05/2009 06:32 PM 111,827,456 DocumentAndSettings12.tib
* 08/04/2009 06:32 PM 112,862,208 DocumentAndSettings11.tib
* 08/03/2009 06:32 PM 77,107,200 DocumentAndSettings10.tib
* 08/02/2009 06:32 PM 105,838,080 DocumentAndSettings9.tib
* 08/01/2009 06:32 PM 109,862,912 DocumentAndSettings8.tib
* 07/31/2009 07:26 PM 106,161,664 DocumentAndSettings7.tib
* 07/30/2009 06:32 PM 112,708,096 DocumentAndSettings6.tib
* 07/29/2009 06:32 PM 106,406,912 DocumentAndSettings5.tib
* 07/28/2009 06:32 PM 105,857,536 DocumentAndSettings4.tib
* 07/27/2009 07:02 PM 96,833,024 DocumentAndSettings3.tib
* 07/27/2009 07:02 PM 131,378,176 DocumentAndSettings2.tib
* 07/27/2009 07:01 PM 22,810,646,528 DocumentAndSettings.tib

Anhang Größe
AcronisFileQuestion.txt 8.48 KB
Sa, 10/03/2009 - 13:07
0 Users found this helpful
truwrikodrorowrelupicugojestutroclulachosaswunuhospikigawakijosaswenomaruclojeueclikaspedrubewidebrisubrohutrurifruuagothunugekedrumucisiuobrobrecrupeslapuswosluprothethibakaslechurathikucli
Regular Poster
Beiträge: 11
Kommentare: 229

I too am very interested in the answer to this.
I have TI-11 and recently bought TI_2010.

For several years now I have been using TI v11 and successfully doing something very close to what described .
With TI11 I had the process totally automated.
Like youi, I have NOT been able to figure out how to get this done with newer versions (TI_2010). The issue is the dang recovery catalog is always getting in the way.
I have paid for support and have an open question about this with them.

Anyway until I get an answer here's is How I have been doing this in TI-11.
The key was a simple "dos" batch script which maintained 3 folders (the number history I wanted to maintain).
The batch script was pretty easy I called it "rotate.bat".
I had some error checking in this batch file but at its heart all "rotate.bat" did was:
- delete *.* from folder set3
- issue "move" command from folder set2 into folder set3
- issue a move command from folder set1 into folder set2
- issue a move command from folder set0 into folder set1

The net effect was after "rotate" completed folder "set0" was guaranteed to be empty.
versions of historical backups were in folders 1,2,3
"rotate.bat" was lighting fast finishing in mere seconds regardless of how much data I had.
The reason why is the dos "move" command is pretty smart, if the target/dest folders are the same device it doesn't actually move gigs of data around it simply updates the disk directory headers so the file now registered to the target folder.

With the above script written everything you described was then accomplished with just two TI v11 jobs.
* J1 ran montly - this job had a PRE processing step to call "rotate.bat"
I had this job setup setup to email me the sysout. This email occured regardless of the backup working or failing.
The net effect of J1 was to create a "full" backup into empty folder set0
The 1st of every month I got an e-mail from acronis letting me know backups were still working.
*J2 ran daily it did an "incr" backup into set0.
The net effect of j2 was to keep the backup current (as of prior night).
Email was only sent if there was an error.

With TI v11 what you wanted was pretty easy. The process ran perfectly for me day in, day out month after month for years.
I even had an HD crash once and used the above backups to successfly restore onto a new HD.

I liked the fact that I got a montly email letting me know backups were still working.
Other than this one montly email, the only time acronis would "bother" me is when there were issues with a daily backup. I always knew that:

folder set0 always contained my most recent backup set (full and incrs).
folder set1 was older than set0 and was my next most recent backup set
same could be said for set 2 and finally set3 which was very old to be sure but at least It existed.

There were many advatages to the above the system the single biggest of course once it was going, I could ALWAYS recover any file as it looked on an any day within the last 90 days. (depending on the day of the month I might even be able to go back 120 days but I could ALWAYS go back upto 90 days).

I am trying very hard to get the same thing out of TI_2010.
Like you that dang recovery catalog is getting in the way.
For me at least I wish I could simply disable the entire thing it servers me no purpose at all.

Mo, 10/05/2009 - 17:34
  • Anmelden, um Kommentare verfassen zu können