> Guys, > > Sorry, please ignore me - the reason that it is not updating the 'last > backup start/completed date/time' is nothing to do with journaling, > but because the backup script seems to be backing up a particular > filespec/directory path of the filespace, rather than the whole drive, > therefore I will never get an updated date/time. Doh - sorry, I'll > make sure I check everything out before posting next time... > > Whilst I'm here though, I notice in the journaling files directory > that one of my files - tsmG__jdb.pag - is *huge*. Well, around 850MB. > I did an incremental backup with the journal engine engaged (only 10 > minutes - *so* much better), and it remains at 850MB. I would have > expected this to have been decreased somewhat... Am I right in > guessing that the size of this file will grow to the largest size > required, but won't shrink again when not needed? Is there anything I > can do to shrink it? > > Rgds, > > David McClelland > Global Management Systems > > -----Original Message----- > From: David McClelland > Sent: 29 September 2003 14:18 > To: [EMAIL PROTECTED] > Subject: Journaling - not updating 'Last Backup Start/Completion > Date/Time' > > *SMers > > Hurrah! I now have 4 consecutive days worth of successful journal > backups! > > Instead of my 12,000,000 million object filespace taking nearly a > whole day to process, with journaling turned on I've managed to get > this down to anything from 10 minutes to 1.5 hours depending upon how > many files have changed - significantly better :o) Thanks guys! > > *However*, one thing strikes me - I look at the output of a `query > filespace <JOURNALEDNODENAME> f=d` and refer to the 'Last Backup > Start' and 'Last Backup Completed' date and time stamp, and these now > don't ring true. In fact, they appear to point to the last successful > full incremental backup that I performed prior to enabling journaling. > > > Am I correct in assuming that TSM doesn't count a > journaled-incremental as a full backup when it comes to looking at the > `filespaces` table? I'm sure quite a few guys out there use the output > of this for some reports... > > Rgds, > > David McClelland > Management Systems Integrator > Global Management Systems > Reuters > 85 Fleet Street > London EC4P 4AJ > > Telephone +44 (0)207 542 4670 > Mobile +44 (0)7711 120 931 > E-mail [EMAIL PROTECTED] > Reuters Messaging [EMAIL PROTECTED] > >
--------------------------------------------------------------- - Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.