Steve =>
First, thank you very much for sharing your suggestions, and for your
patience with me.
I have been pouring through manuals and redbooks all day. I ran across
`backup set' and thought that this is ideal for what my client says that
they want to do. Unfortunately, it appears that there is no way to
`stack' multiple clients' backup sets on one tape? Is that correct? Is
that why you do not recommend that?
I am trying to get my brain around the strategy you recommend. Since
this whole system is so non-standard, I admit my confusion when it
comest to some details. Are you suggesting that we can leave alone the
existing backup-to-disk process, except we introduce an intermediary
storage pool from which we can copy to tape and copy to disk?
* Steve Harris <Steve_Harris AT HEALTH.QLD.GOV DOT AU>
[2004:03:03:10:02:42+1000] scribed:
> >>> mds AT HELICES DOT ORG 03/03/2004 8:00:47 >>>
> <Snip>
> >> Each day, run a backup stg from the nightly pool to the tape pool and
> >> send the tapes off site.
> >
> >Will this contain _only_ new files and files that have changed since
> >last backup?
> Yes. The backup stg will copy all files currently in that stgpool.
> Since its emptied every day there will only be last night's backups
> there.
> <Snip>
> >However, I wonder what value these tapes have, since -- by themselves --
> >they are incomplete and cannot facilitate recovery.
> >
> >How do most sites implement rotating tapes offsite?
> >
> >It seems to me, that since my client uses their disk array(s) like sites
> >I have seen use tapes, the only real difference is how to create those
> >tapes that are to be taken offsite.
>
> There's the rub . The scheme that you are trying to create will
> consume resources, give someone a nice feeling but when depended upon
> will disappoint.
>
> The only way to proceed is as you have already suggested - as if the
> primary data was on tape.
OK, I follow this far.
> Backup all stgpools every day to tape. Use DRM to manage those tapes
> offsite.
I have not used DRM to manage offsite tapes. What is the best resource
to get my up to speed on this?
> It sounds like the company has issues with tape handling. If this is so...
History: Until last year, they had a _large_ tape library on a single
DLT drive. It had a long history of `technical difficulties', and it
demanded many, many hundreds of tapes. On top of that, they kept adding
new tapes to the mix, and nobody knew what was on the older tapes, that
never managed to rotate back into production.
Last fall, they replaced the DLT and tape library with 6TB disk array,
and stopped writing to any tapes.
Now, they have gone to the opposite extreme, buying a fast LTO-2 drive
and ten (10) position magazine/autoloader (well, they need one slot for
the cleaning tape.) They have many hundreds of DLT tapes, which are
useless for the LTO, and they are vehemently opposed to investing in
large numbers of tapes again.
Yes, they have tape issues . . .
> Set the reclaim percentage for offsite pools as high as possible to
> minimise reclaims. Place very large files into their own
> onsite/offsite pool hierarchy and never reclaim this, just allow it to
> expire. Only run offsite reclamation once or twice a week. Recall
> tape from offsite only once a week.
OK, I think that I understand how to implement these steps; but, I am
not clear as to _why_ these steps are required.
> Doing this will give full protection, and other than the higher static
> tape usage will not involve significantly more tape handling than the
> 7 day scenario.
>
> Really.
OK, I'll bite, _how_ do I calculate total number of tapes required for
this approach? For that matter, how do I calculate magazine
requirements?
> If the handling of tapes by individual volume rather than by "box of
> tapes" is an issue, there are ways around this. Look for posts by
> Paul Seay in the archives on this topic. (basically just before the
> end of the offsite cycle, run a move data recons=yes on the tapes that
> are coming due for recall)
I do not understand your differentiation between `tapes by individual
volume' and `box of tapes' -- so, I guess my next stop is the archives,
especially now that I have search terms ;>
> HTH
>
> Steve.
Wow, you are sending me on quite a chase! Thank you, for suffering this
fool.
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
signature.asc
Description: Digital signature
|
