Hmmm ..... good questions. I will have to check with the customer.

In the meantime, we talked about this issue several times with our customer
and they explained to us that doing file backups/restores is actually
useless as there is a link bewteen a SQL database and the small files (the
SQL database contains some metadata about these small files). We will look
more into taking raw backups and maybe take only once a week a full file
backup.

The performance we see with the backups on these servers seem to vary quite
a lot. The first full backup we took, took about 17 hours. The next full
backup we took, took only 8 hours ! We're not sure what explains this
behaviour. One of the things we saw is that when the backup is backing up
the C: drive, a virusscan process (mcshield.exe) is consuming quite some
cpu. However, most of the data is on the D: drive and we didn't see this
process popping up when backing up this D: drive. Our customer will check
the configuration of this virusscan and adapt where needed. In the
meantime, we will do some testing with this raw backup method.





                                                                                
                                              
                    "Mark Eisenhardt"                                           
                                              
                    <mark_eisenhardt@stoneybr       To:     "Steve Curry" 
<scurry AT yahoo-inc DOT com>,                             
                    ookfl.com>                       <Bruno.Bossier AT comparex 
DOT be>, "'Rockey Reed'" <Rockey.Reed AT veritas DOT com>   
                                                    cc:     <veritas-bu AT 
mailman.eng.auburn DOT edu>                               
                    11/09/2002 08:39                Subject:     RE: 
[Veritas-bu] Backing up a large amount of small files    
                                                                                
                                              
                                                                                
                                              




Bruno,
You stated that the data is all on an EMC frame, are you using or do you
currently have time finder installed? (BCV utilization)
The reason that I ask is, depending on how the volumes are set up on EMC
(hence 50Gb? physicals cut into hypers or meta volumes) and the amount of
cache on the EMC you could make your situation worse by multi-streaming the
backup off of the same physicals.

Also I'm curious if your bin is set for hardware striping and what the
stripe size is?
It could require a bin change where you go to a smaller stripe size and or
smaller hyper/meta volume in order to allow you to multi-stream and
increase
performance.
Anyway just a thought,
Mark Eisenhardt

 (m) 408.373.7247
  (e)  scurry AT yahoo-inc DOT com

 #That is probably the best thing to do.
 #
 #Thanks !
 #Bruno
 #OK Bruno, let's be honest here.  NBU as with all backup software
 #applications have difficulty with large quantities of small files.
This
 #is
 #caused by the overhead required to catalog the files, retain metadata
of
 #their locations on tape, etcetera.  A recommendation would be to look
at
 #breaking the 150Gb into something like three 50GB chunks.  Do this in
the
 #file selection using the * wildcard and streaming the data.  The file
list
 #would look something like this:
 #
 #NEW_STREAM
 #/path/a*
 #/path/b*
 #|
 #/path/g*
 #NEW_STREAM
 #/path/h*
 #|
 #/path/m*
 #
 #down to /path/z*
 #
 #To write to one drive set multiplexing in both the STU and the
schedule
 #and
 #set it to the number of streams.
 #
 #HTH.
 #
 #Thanks,
 #Rockey Reed
 #
 #-----Original Message-----
 #From: Bruno.Bossier AT comparex DOT be [mailto:Bruno.Bossier AT comparex DOT 
be]
 #Sent: Monday, November 04, 2002 9:34 AM
 #To: David A. Chapa
 #Cc: veritas-bu AT mailman.eng.auburn DOT edu
 #Subject: Re: [Veritas-bu] Backing up a large amount of small files
 #
 #
 #
 #All the data is on EMC via a SAN, so RAID-1.