On Jul 9, 2008, at 2:25 PM, Bell, Charles (Chip) wrote:
Does that plan apply, considering (something I don't think I mentioned) that only the most recent numerical mount point is getting changed data? Most of the other mount point backups are getting few to no files changed. A co-worker and I were discussing a similar script...
Yes; it would be the most recent generation mount point which would be treated to the Incrbydate, the presumption being that file timestamps reflect when the file was written to the volume, so as to be later than the last such backup. The previous generation mount point would deserve an Incremental at that time, to catch any files added to it which filled it to the app's 80% threshold level to incite going on to a next generation volume. Thereafter, the elder volumes would have assured backups of the older data, and could be gone at every once in a while to pick up the minor deltas. This makes the most sense to me, rather than lavishing TSM attention on essentially static volumes by way of complex Journaling et al. Ye olde philosophy of keeping things as simple as possible. Richard Sims
