Ted:
Thank you very much. I was unpleasantly surprised at the leap in volume usage when we
added the Groupwise servers and now I have something to work with. To bad there isn't
a redbook that covers the peculiarities of various commonly used products.
Regards,
Larry
>>> [EMAIL PROTECTED] 10/16/00 10:32PM >>>
Larry,
I would suggest using -pitdate rather than -todate.
A description of the option from the manual: "Files that were backed up on
or before the date and time you specified, and which were not deleted
before the date and time you specified, are processed. Backup versions that
you create after this date and time are ignored."
The -todate option, on the other hand, is used "to request a list of backed
up or archived files within a period of time." In your case, since you
supplied no -fromdate, I believe all backed up files prior to your -todate
would be processed.
An additional peculiarity that you are probably encountering is the sheer
number of temporary files that are created by Groupwise as it processes
email. If you do not carefully exclude most of the directories under the
PO directory, you can wind up with a node that is consuming 1000x of its
"live" data volume within TSM.
This happened to us with a Groupwise client. Approximately 150 MB of
"real" data drove the auditoccupancy of the node to 150 GB. Even with a
VEREXISTS=2 and VERDELETED=1, the many, many transient files were retained
for RETONLY=60 days after Groupwise purged them from the system. (and the
files are all uniquely named...) The files are typically named with a
hexidecimal-looking filename.
In your case, this "peculiarity" combined with the -todate option could
easily use up all of your available space.
According to the Groupwise admin we worked with, restoring the following
filespecs is all that you need to restore a PO:
po\ofuser\*
po\wphost.db
po\ngwguard.db
Hope this long-winded reply helps,
Ted
