Is the destination storage unit owned by the same media server that wrote the
backup? If not, the dup is going over the network. Use -altreadhost option
to have the STU owner also read it or change the dest STU to be one onwed by
the media server used for the backup.
I still don't really understand why, but I have read that the NET_BUFFER_SZ
value will effect dups, even when they are local??? You might want to play
with this.
- Scott
"Thomas, Douglas L."
<dthomas AT glgt DOT com> To:
"Veritas Mail List (E-mail)" <veritas-bu AT mailman.eng.auburn DOT edu>
Sent by: cc:
veritas-bu-admin AT mailman DOT eng. Subject:
[Veritas-bu] bpduplicate taking a long time.
auburn.edu
03/21/2002 12:31 PM
Hi All,
I'm running the following command:
bpduplicate -dstunit D_stunit -backupid system.name.here_1016672594
-L /tmp/bpdup.ls -dp Duplication_pool -cn 1
The original backup, of 25G, took 1 hour, 47 minutes. The above command has
been running for over 3 hours now, previous attempts were aborted after 6
hours.
I thought the previous attempts may have been slow because I was
multiplexing, so yesterday I stopped all of the multiplexing and am still
having the same problem. Any ideas why it would be taking so long?
Block size is 1000, NetBackup 3.4, OS is Tru64 v5.1. Fiber connected to a
Compaq ESL9198 Library with 4 DLT drives. Traffic on the Fiber Switch
appears small, but I don't no how to get the exact throughput numbers.
Another dup of about 75M completed within 5 minutes.
Douglas L. Thomas
Unix Administrator
Great Lakes Gas Transmission
dthomas AT glgt DOT com
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
