ADSM-L

Re: [ADSM-L] NBU user considering switch to TSM

2008-09-29 22:43:26
Subject: Re: [ADSM-L] NBU user considering switch to TSM
From: Wanda Prather <wprather AT JASI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 29 Sep 2008 22:42:49 -0400
>
>
>> 1. TSM will be migrating to a full DB2 database (if so, I think it would
>> be
>> the only one to use such a full-featured database for backups).  When will
>> that happen?
>>
>
> True.  I don't know if IBM has announced a date yet


>> TSM 6.1, which is "expected"  to be announced by the end of this year,
available early 09, based on multiple IBM presentations I've seen.  Dates
could slip, of course.


>
> 2. Image backup (for a drive with millions of files) didn't support
>> file-level restore.
>>
>
> AFAIK, this is still the case.  But you can combine image with file-level
> incremental to get fast restore and also file-level restore.  Yes, this
> will take more storage resources.  You can also base an incremental off of
> an image backup.
>
>>And there are other alternatives rather than image backups.  With an image
backup, you have to periodically push all the data across the network
again.  Most of my customers with zillions of files on a host prefer to use
journaling instead.  Doesn't make the restore faster, but works a treat with
the backup time (WIndows & AIX clients).


>
> 3. All migration/reclamation activities had to be done on the TSM server
>> (the LAN-free storage agents couldn't help)
>>
>
> Still true.  Never been a problem for me, tho.


>>Never been a problem for me, either.  Why is it a problem?

>
>
> 4. Upgrading TSM clients to the latest version had to be done manually at
>> at
>> client.
>>
>
> Alas, still true.  But perhaps for good reasons.


>> Not sure what is mean by "manually at the client".  You can push the TSM
client out the way you push out any other client software - like Microsoft's
SMS, Altiris, or an appropriate Tivoli software distribution product.  If
sneakernet is your current method, well....



> 5. You couldn't restore from a backup set using typical TSM GUI/command
>> (they are designed for use outside of TSM)
>>
>
> I'll leave this for others.  We've never used backupsets.


>>You can restore individual files from a backupset now.

>
>
> 6. Adaptive subfile backup would require multiple tapes to restore a single
>> file, as parts of the file would be spread out across tapes.
>>
>
> Well, theoretically this could happen, but if you use collocation (or
> disks), it won't be a problem.  If you have lots of data, you'd probably
> want to use collocation.  There are three options (by storage
> pool):  filespace, node, or collocation group (groups of nodes).


>>I agree - when I've used subfile, I did so in combination with collocation
on the storage pool, had no issues (and it's not like subfile backup is
required - best use is for remote clients on a WAN, where you really really
need to minimize data traffic).

W


>
>