ADSM-L

Re: archive to tape ???

2004-03-03 01:33:16
Subject: Re: archive to tape ???
From: Steven Pemberton <stevep AT IBK.COM DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 3 Mar 2004 17:29:49 +1100
On Wednesday 03 March 2004 16:16, Michael D Schleif wrote:
> * Steven Pemberton <stevep AT IBK.COM DOT AU> [2004:03:03:15:15:57+1100] 
> scribed:

[lots of stuff deleted]

> > The easiest "off-site backup" solution to implement in your environment
> > is probably to simply define a single "copy storage pool" to use the new
> > tape library. Then, follow the next few steps...
> >
> > 1/ Run "backup stgpool" to copy *ALL* the primary backup data to tape.
> > 2/ Send those tapes off-site.
>
> OK
>
> > 3/ The next day, run "backup stgpool" again - this will only copy the new
> > files from disk to tape (as per your requirements)
> > 4/ Send those tapes off-site.
> > 5/ Repeat steps 3 + 4 every day
>
> OK
>
> > 6/ Determine any "empty" off-site tapes that need to return on-site. You
> > can use the DRM commands or TSM queries to identify these tapes.
> > 7/ Repeat step 6 every day.
>
> OK -- how to do this?

As I said in the earlier post, TSM considers data retention and data location
as separate problems. The "copy pool" tapes need to remain off-site for as
long as they contain data, after the data expires (or is "moved" via
reclamation) the tape becomes "empty", and can be returned on-site.

Since you have DRM, it's probably best to use the DRM commands to determine
which tapes to return on-site. Something like the following will list any
empty, off-site, copy pool tapes (that are by definition, read to return
on-site):

q drmedia wherestatus=vaultretrieve

You should read the admin guide for more details on how to use DRM to bring
the tapes back on-site.

> > 8/ Finally, it's *CRITICAL* to backup your TSM database and send it
> > off-site every day also!
>
> OK -- but, this brings me back to calculating tape and magazine
> requirements.  I am told that 4 of the 6 TB disk is being used, and they
> are currently backing up <200GB per night to this disk array.
>
> How many tapes do we need per night?  Will this fit one (1) ten (10)
> slot magazine?  How many magazines are required?  How many total tapes
> are required?

A single LTO tape will hold about 200 GB native, 400 GB compressed.

As you need to duplicate about 4 Tb of existing backup data to tape, you will
need approximately 10 LTO2 tape immediately, plus some extra to cater for
stgpool efficiency, probable compression ratios, etc, etc, perhaps 15 tapes
total?

(Note - These 10-15 tapes are stored *off-site*, they do not need to (and
never should be) located in the tape library)

Then, for the 200 Gb of new data per day, you will need 1 new tape each day.
Plus an additional tape for the TSM database backup.

So, two tapes will need to be sent off-site each day.

Your tape library should usually only contain a handfull of tapes, the two
generated each day, plus some extra "just in case". Over the weekend
(assuming no one move the tapes off-site) this will build up to 4-6 tapes to
go off-site on Monday.

> Moreover, what is the optimal tape rotation?  When should offsite tapes
> come back into production at DC#1?

The tapes should *ONLY* come back when they are empty, otherwise you are
invalidating your off-site backups...

You should expect the number of returning off-site tapes to _roughly_ equal
the number of new tapes going off-site every day. My apologies for the gross
assumptions in that statement. :)

So, perhaps two tapes will return each day.

Eventually your system will reach equilibrium, with perhaps 30+ tapes
off-site, with a daily rotation of 4+ tapes (2 -> on-site, 2  -> off-site)

How long will your 4-6 TB disk array last if you are filling it at the rate of
200 Gb per day???

> OK -- plus, it appears that `backup sets' cannot be _stacked_ on tape,
> which means that one (1) tape is required for each backed up host per
> night.  Is that correct?

Backup sets _can_ be stacked on a single tape, but it may make your head
explode. :)

Refer http://msgs.adsm.org/cgi-bin/get/adsm0305/496/1.html (and a warning at
http://msgs.adsm.org/cgi-bin/get/adsm0305/496/1/1.html)

I'd leave that one until you're a bit more familar with the product. :)

Regards,
Steven P.

--
Steven Pemberton
Senior Enterprise Management Consultant
IBK, Senetas Group

Mobile: +61/0 418 335 136 | Phone: +61/3 9820 5811 | Fax: +61/3 9820 9907
Level 1, 11 Queens Road, Melbourne, Victoria, 3004, Australia
http://www.senetas.com.au | http://www.ibk.com.au | http://www.datum.com.au

<Prev in Thread] Current Thread [Next in Thread>