John - In a logging-files environment such as you cite, where the data is largely write-only and historic, a hierarchical storage approach would be a more reasonable thing, where data over like a week old would migrate to a cheaper, lower level mass storage area whose entirety would not have to be regularly scanned for backup. (It's easy to incite an Incremental backup on just the data identified by the migration task.) Recent data would be held in a higher level area of much smaller size, whose performance would meet the needs of the application and be much more reasonable to scan for backup.
We TSM administrators often end up the victims of data architectures which weren't thought out for all aspects of their management (in our case, Backup and Restore), and we aren't in a position to re-engineer the layout. If the new data is in some way identifiable by name or timestamp in the directory name, or by identification in some application logging, it might be possible to focus Incremental backups on that subset of the file system, rather than Incremental over the whole thing. Beyond that, Image or CDP backups may be worth pursuing further. Also have the organization consider whether just mirroring will meet recovery needs: in some implementations, conventional file backups may not be necessary. Richard Sims
