Scott Howard's picture

Confusion re managing backups on Amazon Hub Site

Ok , here I go again ...

I'm a bit confused as to how the backup volumes can be managed on the amazon hub site.

Regular readers will now know that I'm using the lucid file server appliance.

The first back up of my current working system was done on 29-10-2010, and has an ID Label of 3 on the site. My appliance is set to do a full backup each month and incremental in between as is default.

When looking through the backup chains on the amazon site , each day is indeed listed there, and lo and behold on the 29th November , the entry is listed as <FULL> as opposed to <inc>.

So, onto the questions :

1. The original back up size on 29th October is quoted as 4.3 GB, but on the 29th November the <FULL> session size is quoted as 2.7 GB.  The amount of data over the month would have inceased, and the system is otherwize unchanged as far as I can see.

After reading what I can about the backup chains , my understanding is that all that is needed for a full restore of a system is all the incremental sessions leading back to the last <FULL> session. Thus the size difference in the original full back up and the one amonth later concerns me.

2. Leading on from this, as it stands presently , each daily backup is creating one long continuous backup chain with ever increasing  data size on the hub, and increasing cost (although yes it is cheap). Is there a way to start a new backup id session (i.e a new chain starting with a full backup), or alternatively, a way to delete incremental sessions prior to previous <FULL> session in the chain so as to reduce the amount of data stored on the hub ?

3. Currently the system always reports the original creation date of the backup with tklbam-list, the only way I can see to check the last full backup date is to manually look at the hub as I have done or to follow the output as tklbam-backup does its stuff...  It might be nice for ease of checking if the last full back up date was reported somewhere up front ?

Sorry to again be so long winded.

Thanks in anticipation,

Scott H.

Forum: 
Tags: