On Tue, Mar 17, 2009 at 11:18 PM, Conway, Timothy
<Timothy.Conway AT jbssa DOT com> wrote:
> Is this to avoid having two copypools? That's a reasonable goal. I
> have only one copypool, which is my DR offsite pool. Just make your
> onsite copypool an offsite pool, and you can give them 25 times better
> than they're asking for.
No, the idea is to keep offsite 7 days history for very few most
important servers (ERP, HR) on disk. I don't much care if that will
be primary pool or copy pool. As long as I can get my data back off it
- it's fine.
Today, I manage 3 servers here and am sitting on 0.5 peta of backup
data. There is no point to have all that data (most of which is
inactive) at DR site (we do have offsite vault though). At DR site we
want to keep preconfigured turn-key ERP, HR servers, a preconfigured
TSM server with its database and SAN or NAS attached disk that has the
7-days history. I have yet to work out how and by what means my 140GB
database will get to DR site on daily basis. Maybe we will use a
dedupe or maybe we will open a separate TSM instance just for these
few servers so that the DB that we will have to copy to DR site will
be as small as possible. Also the smaller DB, the better in DR
situation.
> Unless most of the data changes every day, the difference between 7 days
> and 180 days worth of copypool is remarkably small.
It can be big. ERP server backs up over 100G nightly. I guess it
dedupes pretty well though.
> If you have no copypool at all, the whole thing is a farce.
> If they're wanting fast portable full restores of a subset of the total
> nodes, how about backupsets? Make a nodegroup containing all the nodes
Backup sets are fine as long as tey are relatively small and you don't
have to generate them on daily basis. Imagine your ERP is about 400GB
worth of active data and you have to generate backup set that big on
daly basis? I don't even know yet what kind of bandwidth I'll have to
our DR location. Assuming I get backupset generated in 4-5 hours, how
many hours will be required to send it off? Also what happens if then
the managment decides they want a few more machine to join the first
one at DR location? This solution sound like a nice idea TSM-wise, but
imho it's not very scalable otherwise. As it looks to me the best
approach is to backup locally, dedupe, send it off deduped.
> they want daily fulls of, and make a backupset of that nodegroup every
> day. Give the backupset a 7 day retention, and keep track of the
> volumes that are in the list of backupset volumes from one day that
> disappear the next (simple to script). That same script can note tapes
> that show up in the list of backupset volumes that weren't there the day
> before, and check them out of the library and throw your operations team
> an email listing every tape to be sent offsite and to be recalled. I
> find that I can generate file-class backupsets(with TOC) at about 27MB/S
> - 8.5 hours to do an 814GB node, single-threaded.
>
|
