> > >> 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 > >
