Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[Veritas\-bu\]\s+too\s+many\s+tapes\?\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[Veritas\-bu\]\s+too\s+many\s+tapes\?\s*$/: 8 ]

Total 8 documents matching your query.

1. [Veritas-bu] too many tapes? (score: 1): Author: alevin AT audible DOT com (Adam Levin); Date: Tue, 2 Dec 2003 10:38:24 -0500 (EST); I'm trying to do a backup, and it seems to be taking more tapes than I expect it should. Here are the details: NetBackup Data Center 3.4.1 Solaris 8 master and media servers and clients DLT tapes, 35; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2003-12/msg00033.html (13,144 bytes)
2. [Veritas-bu] too many tapes? (score: 1): Author: Joost Mulders <mail AT j-mulders.demon DOT nl> (Joost Mulders); Date: Tue, 2 Dec 2003 22:46:27 +0100 (CET); Hi Adam, This is interesting. I looked up the native capacities for all types of DLT. Since you say 35GB, I assume you have DLT7000. If not, that may be you problem DLT4000 - 20GB - DLTtape IV DLT700; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2003-12/msg00037.html (15,651 bytes)
3. [Veritas-bu] too many tapes? (score: 1): Author: alevin AT audible DOT com (Adam Levin); Date: Tue, 2 Dec 2003 16:51:19 -0500 (EST); Yes, we're using a DLT7000 drive with DLTtape IV. Density is correct. That's exactly what I don't grok, either, which is the problem. The backup is filling up these tapes, but I can't figure out what; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2003-12/msg00038.html (13,307 bytes)
4. [Veritas-bu] too many tapes? (score: 1): Author: JSimon AT reliant DOT com (Simon, John); Date: Tue, 2 Dec 2003 16:29:41 -0600; Turn on client side logging and see exactly what files it is backing up. Yes, we're using a DLT7000 drive with DLTtape IV. Density is correct. That's exactly what I don't grok, either, which is the p; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2003-12/msg00040.html (13,820 bytes)
5. [Veritas-bu] too many tapes? (score: 1): Author: Mark.Donaldson AT experianems DOT com (Donaldson, Mark); Date: Tue, 2 Dec 2003 15:54:37 -0700; You can check to see if you're "starving" the tape drives in the bptm logs on your media server. If you see "waiting on full buffers", then the data is delivering to the media server too slowly and y; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2003-12/msg00041.html (14,256 bytes)
6. [Veritas-bu] too many tapes? (score: 1): Author: ddunham AT taos DOT com (Darren Dunham); Date: Tue, 2 Dec 2003 14:55:00 -0800 (PST); Not true unless you have a very old model. The first gen had half the buffer space (4MB I think) and would decrease compression (not tracks) when inbound data dropped below a certain amount. It only; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2003-12/msg00042.html (12,333 bytes)
7. [Veritas-bu] too many tapes? (score: 1): Author: William.Enestvedt AT jwu DOT edu (William Enestvedt); Date: Wed, 3 Dec 2003 10:27:02 -0500; Is it writing large fragment sizes -- like over 2GB -- which could leave lots of empty space at the end of each tape? -wde -- Will Enestvedt UNIX System Administrator Johnson & Wales University -- P; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2003-12/msg00058.html (11,192 bytes)
8. [Veritas-bu] too many tapes? (score: 1): Author: tlewick AT hrblock DOT com (Lewick, Taylor); Date: Wed, 3 Dec 2003 10:38:44 -0600; Yeah I wrote a script to sum up all of the waits and delays for full and empty buffers in the daily bptm logs. Each delay is either 20 miliseconds on average for an empty buffer delay, and 30 milisec; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2003-12/msg00060.html (11,720 bytes)

Current List: 1 - 8
Page: [1]