Re: Very long backup/So many files
2002-10-25 11:16:29
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 AT HALLIBURTON DOT COM]
Sent: Friday, October 25, 2002 9:54 AM
To: ADSM-L AT VM.MARIST DOT EDU
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 AT IT.IBM DOT COM]
Sent: 25 October 2002 15:47
To: ADSM-L AT VM.MARIST DOT EDU
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)
gianluca_mariani AT it.ibm DOT com
----------------------------------------------------------------------------
------------------------
"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
L AT SAIC DOT COM> ADSM-L AT VM.MARIST DOT EDU
Sent by: "ADSM: cc
Dist Stor
Manager" bcc
<ADSM-L AT VM DOT MARI
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 AT saic DOT com> gillg AT saic DOT com
Phone: (858) 826-4062
Pager: (877) 905-7154
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Very long backup/So many files, (continued)
- Re: Very long backup/So many files, Dave Canan
- Re: Very long backup/So many files, Miller, Ryan
- Re: Very long backup/So many files, Justin Case
- Re: Very long backup/So many files, Jon Evans
- Re: Very long backup/So many files, Miller, Ryan
- Re: Very long backup/So many files,
Miller, Ryan <=
- Re: Very long backup/So many files, William Rosette
- Re: Very long backup/So many files, Magura, Curtis
- Re: Very long backup/So many files, Miller, Ryan
- Re: Very long backup/So many files, Miller, Ryan
- Re: Very long backup/So many files, Seay, Paul
- Re: Very long backup/So many files, Rushforth, Tim
|
|
|