Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[Veritas\-bu\]\s+Windows\s+2003\,\s+NBU\s+6\.0MP3\,\s+VTL\,\s+Media\s+Mount\s+Timeout\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[Veritas\-bu\]\s+Windows\s+2003\,\s+NBU\s+6\.0MP3\,\s+VTL\,\s+Media\s+Mount\s+Timeout\s*$/: 8 ]

Total 8 documents matching your query.

1. [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout (score: 1): Author: mirko_nbu at mac.com (mirko_nbu AT mac DOT com); Date: Thu, 21 Sep 2006 18:45:49 +0200; Hi all, another kind of a problem, that may be a bug in NBU? Expert help appreciated! We're using NetBackup 6.0 on a Windows 2003 Server Master Server. The Server is connected to a FJS CentricStore V; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2006-09/msg00558.html (12,657 bytes)
2. [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout (score: 1): Author: pkeating at bank-banque-canada.ca (Paul Keating); Date: Thu, 21 Sep 2006 13:28:37 -0400; I'm wondering what kind of (mis)configuration is responsible for media having to be pulled back to the VTL to do a restore. Sounds painful. Paul -- -- next part -- == La version fran?aise suit le tex; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2006-09/msg00559.html (15,462 bytes)
3. [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout (score: 1): Author: mirko_nbu at mac.com (mirko_nbu AT mac DOT com); Date: Thu, 21 Sep 2006 19:55:08 +0200; Paul, I wonder too :-( Mainly a timeout of more than 5 minutes would help, but as explained, the NBU internal timeout does not seem to work... Help appreciated :-) Cheers, Mirko On Thursday, Septembe; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2006-09/msg00560.html (17,122 bytes)
4. [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout (score: 1): Author: pkeating at bank-banque-canada.ca (Paul Keating); Date: Thu, 21 Sep 2006 14:00:49 -0400; My point, I suppose, is that if your data isn't on the VTL, it should be on tape. Netbackup should already know this, and pull the data direct from the tape. A higher timeout would treat the symptom,; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2006-09/msg00561.html (20,054 bytes)
5. [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout (score: 1): Author: mirko_nbu at mac.com (mirko_nbu AT mac DOT com); Date: Fri, 22 Sep 2006 09:09:50 +0200; Paul, we speek about a VTL, not backup to disk or something similar. If the data is not in the VTL cache, the VTL will pull the data from fc attached tapes by itself... NetBackup only sees virtual ta; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2006-09/msg00575.html (21,951 bytes)
6. [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout (score: 1): Author: Philip.Weber at egg.com (Weber, Philip); Date: Fri, 22 Sep 2006 10:33:32 +0100; My understanding of CentricStor is that NetBackup only knows about CentricStor's virtual tape devices. CentricStor offlines virtual tapes to physical tape as and when the virtual tapes become full, a; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2006-09/msg00577.html (22,595 bytes)
7. [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout (score: 1): Author: mirko_nbu at mac.com (mirko_nbu AT mac DOT com); Date: Fri, 22 Sep 2006 12:39:33 +0200; Philip, your understanding of CentricStor is right, it does all the stage and de-stage stuff for itself. Regarding the timeout: We get a tpError after magically 6 (?!) minutes, regardless of the "med; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2006-09/msg00580.html (12,757 bytes)
8. [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout (score: 1): Author: pkeating at bank-banque-canada.ca (Paul Keating); Date: Fri, 22 Sep 2006 08:55:19 -0400; I realize what you're talking about. The idea of the VTL fronting the media is a sore point of mine. *shrug* Paul -- -- next part -- == La version fran?aise suit le texte anglais. -- This email may c; /usr/local/webapp/mharc-adsm.org/html/Veritas-bu/2006-09/msg00585.html (13,825 bytes)

Current List: 1 - 8
Page: [1]