[Veritas-bu] Can't restore

This is a multi-part message in MIME format.

------=_NextPart_000_020A_01C26A09.1F214840
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

We're using Netbackup 3.4 with a Solaris master server monitoring 4 =
drives and another media server monitoring 2 drives. The library is a =
L700 with 9840 drives.We're trying to restore on a disk on the master =
server a single directory which contains 1900000 tiny tif files between =
8 Ko and 60 Ko. The backup was originally done on a remote client =
running on OSF1. The total amount of data is about 60 Go which can't be =
compressed so it is on 3 different tapes. The first time we tried to =
restore it restored about 25 Go at about 370 files per second before =
starting to restore only 1 file per second 1 hour after we started the =
job. It had already mounted the second tape. We killed the restore 15 =
hours later. The second time it restored 54 Go before starting to go =
slower. It had mounted the third tape and it used the exact same drives =
for the first two tapes. Since then, we tried various things to get the =
restore done but there's always a point where it starts to go slower. I =
really don't know what the reason is but I think that our buffer =
configuration might be bad. Here is the config on the master monitoring =
4 drives:

[zeus]:/usr/openv/netbackup/db/config>cat NUMBER_DATA_BUFFERS

4

[zeus]:/usr/openv/netbackup/db/config>cat SIZE_DATA_BUFFERS

262144

The drives are supposed to go as fast as 10 Mo/s.

The shared memory allocated is only 8,3 Mo

There's no NET_BUFFER_SZ

We're usually multiplexing every backup but this one was kind of special =
so we didn't.

There's no performance issue on the server.

At the time the restore started and when it went real slow no other =
backup or restore were being done.

If you need any more informations please mail me back.

Thanks

Jerome Bauwens.


------=_NextPart_000_020A_01C26A09.1F214840
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>We're using Netbackup 3.4 with a =
Solaris master=20
server monitoring 4 drives and another media server monitoring 2 drives. =
The=20
library is a L700 with 9840 drives.We're trying to restore on a disk on =
the=20
master server a single directory which contains 1900000 tiny tif files =
between 8=20
Ko and 60 Ko. The backup was originally done on a remote client running =
on OSF1.=20
The&nbsp;total amount of data is about 60 Go which can't be compressed =
so it is=20
on 3 different tapes. The first time we tried to restore it restored =
about 25 Go=20
at about 370 files per second before starting to restore only 1 file per =
second=20
1 hour after we started the job. It had already mounted the second tape. =
We=20
killed the restore 15 hours later. The second time it restored 54 Go =
before=20
starting to go slower. It had mounted the third tape and it used the =
exact same=20
drives for the first two tapes. Since then, we tried various things to =
get the=20
restore done but there's always a point where it starts to go slower. I =
really=20
don't know what the reason is but I think that our buffer configuration =
might be=20
bad. Here is the config on the master monitoring 4 drives:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3Dr_ansi size=3D2>
<P>[zeus]:/usr/openv/netbackup/db/config&gt;cat NUMBER_DATA_BUFFERS</P>
<P>4</P><FONT face=3Dr_ansi size=3D2>
<P>[zeus]:/usr/openv/netbackup/db/config&gt;cat SIZE_DATA_BUFFERS</P>
<P>262144</P>
<P>The drives are supposed to go as fast as 10 Mo/s.</P>
<P>The shared memory allocated is only 8,3 Mo</P>
<P>There's no NET_BUFFER_SZ</P>
<P>We're usually multiplexing every backup but this one was kind of =
special so=20
we didn't.</P>
<P>There's no performance issue on the server.</P>
<P>At the time the restore started and when it went real slow no other =
backup or=20
restore were being done.</P>
<P><FONT face=3DArial>If you need any more informations please mail me=20
back.</FONT></P>
<P>Thanks</P>
<P>Jerome Bauwens.</P></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_020A_01C26A09.1F214840--