The only disadvantages we have come across so far are... If the journaling service is stopped for any reason, the next time a backup is run, it will be a full incremental, meaning it will once again inspect all of the files on the client, because it can't determine which ones may have changed while the service was stopped.
You can however change a setting in the TSMJBDB.ini file that tells TSM to keep the journal database and reuse it if the journaling service is stopped and restarted, the option is 'PreserveDBOnExit=1', the disadvantage to this is that any file changed while the service is stopped will not get backed up then. Otherwise, Journaling has been very useful for us. Ryan Miller Principal Financial Group Tivoli Certified Consultant Tivoli Storage Manager v4.1 -----Original Message----- From: Jon Evans [mailto:Jon.Evans@;HALLIBURTON.COM] Sent: Friday, October 25, 2002 9:54 AM To: [EMAIL PROTECTED] Subject: Re: Very long backup/So many files Can anyone please explain the disadvantages of using journal-based backup? -----Original Message----- From: Gianluca Mariani1 [mailto:gianluca_mariani@;IT.IBM.COM] Sent: 25 October 2002 15:47 To: [EMAIL PROTECTED] Subject: Re: Very long backup/So many files what platform are you running(OS on client and server)? code levels(client & server)? is journaled backup in use? how is the client connected to the server (what network)? Cordiali saluti Gianluca Mariani Tivoli TSM Global Response Team, Roma Via Sciangai 53, Roma phones : +39(0)659664598 +393351270554 (mobile) [EMAIL PROTECTED] ---------------------------------------------------------------------------- ------------------------ "The people of Krikkit,are, well, you know, they're just a bunch of real sweet guys, you know, who just happen to want to kill everybody. Hell, I feel the same way some mornings..." "Gill, Geoffrey L." <GEOFFREY.L.GIL To [EMAIL PROTECTED]> [EMAIL PROTECTED] Sent by: "ADSM: cc Dist Stor Manager" bcc <[EMAIL PROTECTED] ST.EDU> Subject Very long backup/So many files 25/10/2002 16:04 Please respond to "ADSM: Dist Stor Manager" Does anyone think a computer that has this many files on it, that only backed up 12,222 files, should take over 10 hours to complete? I'm having a problem with this node dropping out a couple of times a night for being idle for more than 60 minutes too. We've double checked the NIC and switch port for the proper settings. When I looked at it last night the CPU wasn't doing anything. 10/25/02 06:13:04 ANE4952I (Session: 3357, Node: CP-ITS-DCMECPD) Total number of objects inspected: 4,151,721 10/25/02 06:13:04 ANE4954I (Session: 3357, Node: CP-ITS-DCMECPD) Total number of objects backed up: 12,222 10/25/02 06:13:04 ANE4958I (Session: 3357, Node: CP-ITS-DCMECPD) Total number of objects updated: 0 10/25/02 06:13:04 ANE4960I (Session: 3357, Node: CP-ITS-DCMECPD) Total number of objects rebound: 0 10/25/02 06:13:04 ANE4957I (Session: 3357, Node: CP-ITS-DCMECPD) Total number of objects deleted: 0 10/25/02 06:13:04 ANE4970I (Session: 3357, Node: CP-ITS-DCMECPD) Total number of objects expired: 386 10/25/02 06:13:04 ANE4959I (Session: 3357, Node: CP-ITS-DCMECPD) Total number of objects failed: 0 10/25/02 06:13:04 ANE4961I (Session: 3357, Node: CP-ITS-DCMECPD) Total number of bytes transferred: 1.15 GB 10/25/02 06:13:04 ANE4963I (Session: 3357, Node: CP-ITS-DCMECPD) Data transfer time: 73.02 sec 10/25/02 06:13:04 ANE4966I (Session: 3357, Node: CP-ITS-DCMECPD) Network data transfer rate: 16,571.01 KB/sec 10/25/02 06:13:04 ANE4967I (Session: 3357, Node: CP-ITS-DCMECPD) Aggregate data transfer rate: 32.91 KB/sec 10/25/02 06:13:04 ANE4968I (Session: 3357, Node: CP-ITS-DCMECPD) Objects compressed by: 19%% 10/25/02 06:13:04 ANE4964I (Session: 3357, Node: CP-ITS-DCMECPD) Elapsed processing time: 10:12:51 Geoff Gill TSM Administrator NT Systems Support Engineer SAIC E-Mail: <mailto:gillg@;saic.com> [EMAIL PROTECTED] Phone: (858) 826-4062 Pager: (877) 905-7154
