Veritas-bu

[Veritas-bu] NetBackup Disk Staging Performance Questions

2007-03-05 04:22:51
Subject: [Veritas-bu] NetBackup Disk Staging Performance Questions
From: bernard.verheuen at fortis.com (VERHEUEN Bernard)
Date: Mon, 5 Mar 2007 10:22:51 +0100
Hi,

About the orphan images, I've written a script that scans the DSSU and
interrogates the catalog. When images from DSSU are not found in the catalog
they are orphaned.
Read the DSSU and for each unique image name, extract the image from the
filename look in the catalogue if the image is cataloged.
        bpimagelist -backupid 

If the image is not in the catalogue than it is an orphan image ... :-) 

 
 Hence you want to delete particularly it from the DSSU.Not sure which
version and MP you are running  so that info might help. If the file is left
on the DSSU
 file system, the backup image is held within the name of the file  It will
be the first part of the file name up to "_C1".  
 
The form of the file is this:
CLIENT_STARTTIMESINCEEPOCC_F#.STARTTIMESINCEEPOC.img
 
                                                          where CLIENT is
the client name as configured within your policies
                                                          where
STARTTIMESINCEEPOC is a number of seconds since the epoc
                                                          where C# is copy
number
                                                          where F# is
fragment number.
 
For instance, if the file name is:
Dileep_1164805206_C1_F1.1164805206.img
 
                                                          The backup image
name is:Dileep_1164805206
 
You should be able to search the catalogs for that image name as such:
bpimagelist -backupid  Dileep_1164805206
 
If there is nothing there, you can remove the file.  Don't ever remove a
file from the DSSU if the image still lives in the catalogs.
 
At least this might help you clean up your storage temporarily.  As to the
source of the problem, I'd love to know if that is a bug.
( we are phasing this issues quit some time)
 

There is no point in not deleting it from the DSSU since the image is not in
the catalog.  That means you can't restore from it.
 
Netbackup, will allow for a specific retention period for your Disk Staged
images. the images will stay on disk until your disk staging unit runs out
of space. 
At that time netbackup expires the images beginning with the oldest images
first. Of course, you could schedule a script that would do the expiration
for you manually... You would need to make use of the bpexpdate command,  I
get a listing of files that end with .ds and run bpexpdatebpexpdate -d 0
-force -copy 1 -backupid clientname_1234567891 The copy 1 is necessary so
that you only expire the image on the disk. The image that is on tape will
automatically become the primary copy to be used forrestores.


Bernard
Tel. (32 2 22) 85459 // 0477 390 211
Bernard.Verheuen at fortis.com


-----Original Message-----
From: Ed Wilts [mailto:ewilts at ewilts.org] 
Sent: Thursday, March 01, 2007 2:06 PM
To: Anthony Segran
Cc: veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NetBackup Disk Staging Performance Questions

On 2/28/2007 10:34 PM, Anthony Segran wrote:
> /Is SATA a common choice out there for DSSU's?

We use FATA drives - not much difference between them and SATA really.

> //We experienced slow performance during duplication, on both HDS 9585 
> arrays and NetApp 3020 over FCP. We're currently talking to NetApp 
> about 3020 performance issues, so do you know of other NBU customers 
> using NetApp 3020's for DSSU's?/

This appears to be a NetBackup issue and we're working directly with
Symantec engineering on our destaging performance issues.  We believe we've
got the right people at Symantec involved, we've given them a lot of data,
and they've already been out to visit us.  They're actively working this
issue.  There are many factors involved and we don't know yet if it's a
NetBackup bug, design issue, or a customer configuration issue.  If it's the
latter, it's not going to do you much good.  The logs currently claim that
we can't read off of disk fast enough to drive a single LTO-3 drive but
we've demonstrated using non-NBU tools that we can read at 380+ MB/sec off
of disk (essentially saturating the HBAs) and the LTO-3 isn't that fast
(don't we wish!).  If I get something definitive that I can pass on, I'll
post to the list.  You and I are not the only people that have posted about
destaging performance.

> /Another DSSU related issue we're seeing is orphan images left on the 
> DSSU from failed/incomplete jobs. We've turned the appropriate logs on 
> and will be clearing these out manually and escalate again if/when we 
> see further occurrences. Support assure us that this is not a 
> normal/reported issue with NBU.

We use DSSUs a *lot*.  We saw this issue regularly in pre-6.0MP4 days but
have not seen it since.  We worked with Symantec extensively during the MP3
-> MP4 development cycle.  Continue working with support and escalate the
case if you need to.  Obviously orphan images are a bug and they're supposed
to be cleaned up automatically.

        .../Ed

--
Ed Wilts, Mounds View, MN, USA
mailto:ewilts at ewilts.org



Voir texte francais apres texte neerlandais

 

"Deze e-mail, met inbegrip van elk bijgevoegd document, is vertrouwelijk. 

Indien u niet de geadresseerde bent, is het openbaar maken, kopieren of gebruik 
maken ervan verboden. 

Indien u dit bericht verkeerdelijk hebt ontvangen, gelieve het te vernietigen 
en de afzender onmiddellijk te verwittigen. 

De veiligheid en juistheid van email-berichten kunnen niet gewaarborgd worden, 
aangezien de informatie kan onderschept of gesaboteerd worden, verloren gaan of 
virussen kan bevatten. De afzender wijst bijgevolg elke aansprakelijkheid af in 
dergelijke gevallen. 

Indien een controle zich opdringt, gelieve een papieren kopie te vragen. 

 

Ce message electronique, y compris tout document joint, est confidentiel. 

Si vous n'etes pas le destinataire de ce message, toute divulgation, copie ou 
utilisation en est interdite. 

Si vous avez recu ce message par erreur, veuillez le detruire et en informer 
immediatement l'expediteur. 

La securite et l'exactitude des transmissions de messages electroniques ne 
peuvent etre garanties etant donne que les informations peuvent etre 
interceptees, alterees, perdues ou infectees par des virus; l'expediteur 
decline des lors toute responsabilite en pareils cas. 

Si une verification s'impose, veuillez demander une copie papier."




<Prev in Thread] Current Thread [Next in Thread>