I'm not familiar with Networker except in it's old i-just-do-full-dumps form.
How does it deal with mixed retention requirements?
Can you set up one directory to be retained for 7 years and another to be
retained for 90 days like you can with TSM/
> On 26/07/2007, at 2:54 AM, Schneider, John wrote:
>
>> Greetings,
>> We have been a TSM shop for many years, but EMC came to our
>> management with a proposal to replace our TSM licenses with Legato
>> Networker, at a better price than what we are paying for TSM today.
>> This came right on the heels of paying our large TSM license bill, and
>> so it got management's attention.
>> We have an infrastructure of 15 TSM servers and about 1000
>> clients, so this would be a large and painful migration. It would
>> also
>> require a great deal of new hardware and consultant costs during the
>> migration, which would detract from the cost savings.
>> So instead of jumping from one backup product to another based
>> on price alone, we have been asked to do an evaluation between the two
>> products. Do any of you have any feature comparisons between the two
>> products that would give me a head start?
>
> Funny you say this. Monash was a Legato (now owned by EMC) shop until
> the TSM migration around 3-4 years ago; I suspect that a large number
> of the problems that were perceived to be Networker's fault were
> actually the fault of the aging DLT silos and drives that underlay
> Networker. I still have fond memories of those silos; they gave me a
> great deal of callout pay every time they had a stuck cartridge or
> similar. :-)
>
> I also suspect that the greater reliability we've had since putting
> in TSM is more because we also got in new tape silos (LTO2, now half
> LTO2 and half LTO3, and soon to be half LTO3 and half LTO4) - if we'd
> stuck with the DLT silos, we'd still be in a world of pain,
> regardless of the software.
>
> There are plusses and minuses to both products. Some points to consider:
>
> * Networker uses the traditional "full plus incrementals, or dump
> levels" system. Monash used a pattern of "full once a month;
> incremental every other day; and a dump level interwoven" - so, for
> example, it might go "full, incremental, level 8, incremental, level
> 7, incremental, level 9, level 2, incremental, level 8, incremental,
> etc." - the idea being to minimise the number of backups needed to
> restore a system.
> * Networker indexes are somewhat analogous to the TSM database. In
> theory, you can scan each tape to rebuild the indexes if they're
> lost; in practice, if you lose the indexes, you're pretty much dead -
> there's just too much data to scan if the system is more than
> moderately sized. Yes, Networker backs up the indexes each day. :)
> * At least the versions of Networker (up to 7.x) we used doesn't
> support the idea of staging to disk - everything goes directly to
> tape. However, data streams from multiple clients are multiplexed
> onto tape to get the write speeds up. This is good for backups, but
> does make recovery slower (since the data read will include a lot of
> data for other clients.)
> * No more reclamation or copy pools to deal with (because of the
> traditional full/incremental/dump level system). So the burden placed
> on the tape drives is probably going to be significantly lower
> (although you will be backing up more data each night than you would
> with TSM.)
> * I don't think Networker has anything analogous to TSM's scratch
> pool: volumes belong to a pool of tapes, and there's no shuffling
> between the pool. So if the "standard" pool has a hundred tapes
> available for use, but the "database" pool is out of tapes and needs
> one more, you need to manually intervene. This *may* have been
> because of the way we configured Networker, though, and it may also
> have changed in the interim. Note that you *have* to have a separate
> pool of tapes for index backups.
>
> My honest assessment mirrors that of the other people who have
> replied: use this as an opportunity to negotiate better pricing from
> IBM, and point out to the powers that be that there are risks
> involved with moving to a different backup product. There's nothing
> wrong with Networker, it's a good system, but you aren't familiar
> with it; it takes time with any new product to learn the tricks of
> the trade. It's only in the past year or two that we've started to
> feel more competent with TSM, as we've found and dealt with problems
> in the production system which never showed up (and would never show
> up) in the smaller scale proof of concept.
>
> You also should note that it took Monash a couple of years to finish
> the migration from Networker to TSM; I would expect a migration in
> the other direction would take at least a year. I definitely would
> not advise a dramatic cut-over - do a small number of servers at a
> time to make sure you're not pushing the server too hard (and
> besides, you want to stagger the full backups so they don't all take
> place on the same day ...)
>
> Oh, one other point that comes directly from Monash's experience with
> Networker (assuming you do go down that path): we had a number of
> large servers (mail in particular) that would take a very long time
> to do a complete full backup. We ended up setting Networker up to
> stagger the full backups on their filesystems: system filesystems on
> day 1; mailbox filesystem 1 on day 3; mailbox filesystem 2 on day 5;
> etc. Whether this is likely to be an issue for you depends on your
> system; the mail servers in question used an mh-like directory tree:
> one file per email message, which is pretty much the pathological
> case for any backup system (especially since the mail volume is
> massive: I don't know how many thousands of staff and students there
> are across our campuses, but it would not be exaggerating to say tens
> of thousands, if not more.)
>
> It's not a direct comparison, but hopefully there's some information
> in there that you'll find useful. Whatever happens, I wish you luck.
>
|
