Grandfather - Father - Son

I am interested in setting up acronis backups to do a grandfather father son rotation as it will give me as far back as possible to recover files. Right now i have setup a full backup on Sunday and incremental on Monday to Saturday. this gives me 1 week of history to recover from. can someone help me setup the schedule for the GFS rotation scheme?

 

I'm curious as to how this thread will end. Here's what I do, it probably isn't the best nor the smartest but it works.
I have used this for about 5 months now.
Last month I had an HD fail (system c:\ drive).
I bought a new HD, and swapped it with the bad one and booted from my acronis recovery cd, used my last generation backup and within the hour my system was working without issue. My god was I impressed.
To that end, I'm 100% pleased with acronis (I use version 11 home) .

As for how I do generation backups, Here's how I'm doing it, if there's a better way, I'm willing to adopt it.

I have just two acronis backup jobs, a "full" and a incremental.
Both jobs write to the same folder/filename.

The key to making the generations is the "full" job calls the attached script as a pre-processing step. This script moves backupfiles from one folder (generation) into the next folder (generation). If all folders are full, the oldest generation is deleted to make room. For me, all folders (generations) are on the same disk drive. Because I'm moving files from one folder to another on the same drive, windows is smart enough to accomplish the move not by actually transporting the 25 gig file around but by updating the file allocation tables/drive catalog. The end result is no mater how big the backups might be, moving them from one folder to another takes less than a second.

Code:

:: ---------------------------------------------------------------------------
:: ---------------------------------------------------------------------------
:: -- rotate_folders.bat
:: -- The concept is we have two acronis jobs (full and incr) which ALWAYS backup
:: -- to hard coded folder (set0).  
:: -- We want to retain several generations of backups.
:: -- One way is to simply move the *.tib files from folder set0 into set1.
:: --
:: -- This script maintains current + 3 generations.
:: -- The intent our "full" job(s) will always call this script as a
:: -- preprocessing task. This script is NOT called by incr/diff backups.
:: -- this script will cascade all the generations up one level.
:: -- The net effect will be folder set0 will be empty and ready to
:: -- to receive the the full backup, any subsequent incr/diff backups
:: -- this script assumes all backups and generations be written to the same 
:: -- disk drive.     
:: ---------------------------------------------------------------------------
:: -- Define 3 three varaibles, script will create folders as needed.  
:: -- TARGETSERVER.. name of remote pc (\\betty\) for local drive set to %blank%
:: -- TARGETDEVICE.. your choice of sharename (xyz\) or drive leter (x:\)
:: -- THISPC........ name of this PC
:: ---------------------------------------------------------------------------
set blank=" " 
set blank=%blank:~1,1%  
set TARGETSERVER=%blank%
set TARGETDEVICE=e:\
set THISPC=sidney
:: 
:: ---------------------------------------------------------------------------
:: -- step 1) Create our target folders (if they don't already exist
:: ---------------------------------------------------------------------------
pushd %TARGETSERVER%%TARGETDEVICE% 
if not exist .\backup\     mkdir .\backup\   
if not exist .\backup\%THISPC%\     mkdir .\backup\%THISPC%\   
if not exist .\backup\%THISPC%\set0 mkdir .\backup\%THISPC%\set0                 
if not exist .\backup\%THISPC%\set1 mkdir .\backup\%THISPC%\set1 
if not exist .\backup\%THISPC%\set2 mkdir .\backup\%THISPC%\set2 
if not exist .\backup\%THISPC%\set3 mkdir .\backup\%THISPC%\set3
:: 
:: 
:: ---------------------------------------------------------------------------
:: step 2) coalesce empty folders
:: This step normally is NOT needed. This step only does useful work
:: in the rare cases where someone manually delted a backup set. 
:: or a full backup failed prior to creating a *.tib file.
:: If an empty generation folder exists, we backport the next higher generation
:: into the empty the folder. We repeat this for all generations. This will
:: "bubble up" an empty folder to end of list. The purpose of doing this
:: bubble up is a later step will delete last generation. We don't want to
:: delete a backup if there was an empty slot that we could have kept
:: the backup.
::
:: FYI:When source/targe folders are on same device the "move" command
:: is very smart and fast. It does NOT copy gigs of data from one folder to the next
:: but rather it updates the windows file system entry.  This update is
:: lighting fast and has the effect of locating the file into the new folder.
::
if NOT exist .\backup\%THISPC%\set0\*.tib if exist .\backup\%THISPC%\set1\*.tib move .\backup\%THISPC%\set1\*.tib .\backup\%THISPC%\set0\ 
if NOT exist .\backup\%THISPC%\set1\*.tib if exist .\backup\%THISPC%\set2\*.tib move .\backup\%THISPC%\set2\*.tib .\backup\%THISPC%\set1\ 
if NOT exist .\backup\%THISPC%\set2\*.tib if exist .\backup\%THISPC%\set3\*.tib move .\backup\%THISPC%\set3\*.tib .\backup\%THISPC%\set2\
:: ---------------------------------------------------------------------------
:: 
:: 
:: ---------------------------------------------------------------------------
:: step 3) rotate_versions up one level which in turn makes version 0 empty
:: 
::     begin by emptying (deleting) any *.tib files from the LAST folder... 
if exist .\backup\%THISPC%\set3\*.tib del /Q /F  .\backup\%THISPC%\set3\*.tib
:: 
:: now rotate/migrate *.tib files from earlier foders up one level
::  (if a ".tib" in x move all *.tib in into x+1)
:: When this step is done, folder set0 will be empty
:: ---------------------------------------------------------------------------
if exist .\backup\%THISPC%\set2\*.tib move .\backup\%THISPC%\set2\*.tib .\backup\%THISPC%\set3\ 
if exist .\backup\%THISPC%\set1\*.tib move .\backup\%THISPC%\set1\*.tib .\backup\%THISPC%\set2\ 
if exist .\backup\%THISPC%\set0\*.tib move .\backup\%THISPC%\set0\*.tib .\backup\%THISPC%\set1\
:: 
::         

 

Just an FYI - Once you create the next Sunday FULL backup, you only have 1 day of history to recover from; all the INCs are now orphaned and useless.

 

Here's my scheme:
I have 9 scheduled tasks, all Full images.
One each for the 1st, 8th, 15th, 22nd and 29th.
A Weekly each Sunday.
Then three more, one each on Mon & Thu, Tue & Fri and Wed & Sat.
Once these 9 images are created, they just cycle through and get written over.

 

Couldn't you do the same thing by doing backups to a Backup location, limit the number of files (when defining the Backup Location) and number of incs (when definingthe backup task.) Just seems tremendously simpler for approximately the same results.

 

Nine full images. wow. Would need a tera-byte drive to house them all.

 

To whom were you speaking?

 

shieber was probably speaking to me.
He said Couldn't you do the same thing by blah blah blah...

My reply is possibly. But dang if I can get it to work.
I just don't understand what how it should behave.
( or I'm not envoking it correctly).
testing so far indicates it doesn't help, or work, at all.

Here's what I did. I created a backup location and limited it to two backups.
I can see the limit of "2" on the "backup locations" panel.

ok so far good.
I then created three backup jobs each writting into that folder.
I ran each job.
All three worked, there are now three different backups in that folder.

"Huh" I say. Not sure what to make of this.
pressing onward my thought is maybe I'm allowed two versions of each file.

So I then re-run all three jobs again.
Each job over-wrote that jobs original file.

Being limited to "two" backups doesn't seem to work like I thought it might.
I am allowed to create three different backups in that folder and when a backup is re-run it over writes the original.

Must be doing something wrong for as things are now,
this doesn't help the us perform generational backups.

any advice?

 

I have used this scheme (which is similar to TheWeaz's plan) on a number of machines for quite some time. It works well for me.

https://www.wilderssecurity.com/showpost.php?p=846178&postcount=4

F.

 

Hi there i looked at your link but doesn't this run the 4 daily tasks simultaneously?

 

agsingh,

You might want to take a look at Bob's script in this thread: problems when archive is full

It's quite flexible and can handle different scenarios easily.

 

Not quite. they are scheduled about 15 minutes apart.

F.

 

I have a similar scheme to the OP, except I have a week 1 and week 2 rotation, so the schedule is set up fortnightly.

I may introduce an extra monthly full as well.

Colin