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

Reply via email to