This is a multipart message in MIME format.
--=_alternative 0079916B86256C65_=
Content-Type: text/plain; charset="us-ascii"
i can't say that i have tried this, i just know that it's possible. it's
just done by adding the right thing to the file list. let everyone know
what the difference in performance is.
if you're looking at a windows netbackup system admin guide, it's page 83,
"windows nt/2000 disk-image (raw) backup".
it looks like this /\\.\c:
this note from the manual may be something to be aware of... "Before starting a
disk-image backup, NetBackup locks the logical drive to
ensure that no changes occur during the backup. If there are open files on
the logical drive, a disk-image backup is not performed."
- Scott
Johnny Oestergaard <joe AT joe DOT net>
Sent by: veritas-bu-admin AT mailman.eng.auburn DOT edu
11/02/2002 02:23 PM
To: scott.kendall AT abbott DOT com
cc: Bruno.Bossier AT comparex DOT be, veritas-bu AT
mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Backing up a large amount of small
files
I could live with only a daily backup for DR on the volume with all our
scanned documents (lots and lots of small files) and then do a normal full
backup every weekend and new files every day.
I haven't found out how to do the "track by track" backup, but I know that
flash backup is not supported at the moment on StorageTek SVA9500 and also
not on Windows.
If I get a real nasty problem I could also just restore the volume to a
different LUN and then move the file I need back to the production LUN.
The
SVA9500 (and V960 and V2X) is a great platform for doing this kind of
stuff.
Since we only need a volume of less the 100 GB for our image files a total
restore wouldn't take that long. Compression on that kind of volume with a
lot of free space should be good so restoring 30-60 MB/s should be
something we should see (I would hope)
Do you remember where in the policy you tell that you want a raw backup
and
not a normal file backup?
We run 4.5
/johnny
At 13:48 02-11-2002 -0600, scott.kendall AT abbott DOT com wrote:
>netbackup by itself can do an image, or block by block, backup. you just
>have to use the right thing in the file list. can't remember off the top
>of my head what it is but it is documented in one of the netbackup
>docs. the problem with this is it's really only for full DR. you can't
>restore a single file, only the entire volume.
>
>to take a backup block by block, but be able to restore a single file,
you
>have to also look at and keep the file to block mapping so you can
>reference it to pull a single file out of the image. that's exactly what
>flashbackup from veritas does. unfortunately, it's only available on
>certain platforms and windows isn't one of them yet... but it's supposed
>to be in the works!!! I think a lot of us will be looking at this when
it
>finally comes out.
>
>
>- Scott
>
>
>
>Johnny Oestergaard <joe AT joe DOT net>
>Sent by: veritas-bu-admin AT mailman.eng.auburn DOT edu
>
>11/02/2002 04:43 AM
>
> To: "David A. Chapa" <david AT datastaff DOT com>,
> Bruno.Bossier AT comparex DOT be
> cc: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] Backing up a large amount of
> small files
>
>
>We have the same type of problem and except that we have turned OTM off
and
>have less files the only way I see that we can solve the problem is by
>dividing the directories into different streems and streem the backup to
>disk (so that it doesn't hold a tapedrive for days)
>Later we will move the backup from disk to tape but that should happen at
a
>speed that we can handle.
>
>It's great to have so fast tapedrives as we have today (if NT/Win2K could
>pump the data at that speed)
>
>Our files are on a StorageTek SVA9500 and it's still so slow that we cry.
>It's not the disks that are the problem but the time it takes for the
>operatingsystem to open and close the files.
>It would also be a problem on any other operatingsystem (but could be it
>would be a little smaller)
>
>I have been thinking if NBU could take a physical backup of the drive
>(track by track) This should be fast but would also backup empty tracks
but
>at 30MB/s or more who cares.
>
>/johnny
>
>At 12:03 30-10-2002 -0500, David A. Chapa wrote:
> >Well, I did see something like this at a client and I always found the
best
> >solution to something like this is to just format the dang thing :-)
> >
> >But Seriously now...
> >
> >What RAID level, 5?
> >
> >RAID5 is great for writes but not for reads, and with as many reads as
you
> >need
> >done for this backup you would definitely hit timeouts. This is
exactly the
> >problem one of my current clients is facing.
> >
> >What about the last time SCANDISK was run? We found a heavily
fragmented
> >disk
> >caused these types of timeouts as well.
> >
> >Some of the other things we tried was to break up the server backup at
the
> >file
> >list. This was a bit more labor intensive, but it did work to some
degree.
> >
> >HTH
> >
> >David
> >
> >Quoting Bruno.Bossier AT comparex DOT be:
> >
> > > We have a server with a directory which contains over 3 million
files
> for a
> > > total amount of nearly 150 Gb. We are trying to back this up in a
> > > reasonable amount of time (12 to 14 hours maximum). OTM is enabled.
> We have
> > > not succeeded so far. A lot of time is lost at the beginning of the
> backup
> > > when the backup is going through the directory structure to check
all
> > > files. This takes several hours. The first we already did until now
is to
> > > set the maximum cache size to 0 (unlimited). This stopped the errors
> we saw
> > > in the Windows eventlog when OTM is started and then aborted after
40
> > > minutes, then restarted again ....
> > >
> > > Can someone give some suggestions to speed up this backup ?
> > >
> > > Thanks,
> > > Bruno
> > >
> > >
> > > _______________________________________________
> > > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > >
> >
> >
> >
> >_______________________________________________
> >Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> >http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
--=_alternative 0079916B86256C65_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="Arial">i can't say that i have tried this, i just know
that it's possible. it's just done by adding the right thing to the file
list. let everyone know what the difference in performance is.</font>
<br>
<br><font size=2 face="Arial">if you're looking at a windows netbackup system
admin guide, it's page 83, "windows nt/2000 disk-image (raw)
backup".</font>
<br>
<br><font size=2 face="Arial">it looks like this </font><font
size=2><tt>/\\.\c:</tt></font>
<br>
<br><font size=2 face="Arial">this note from the manual may be something to be
aware of... "</font><font size=2><tt>Before starting a disk-image backup,
NetBackup locks the logical drive to ensure that no changes occur during the
backup. If there are open files on the logical drive, a disk-image backup is
not performed."</tt></font>
<br>
<br>
<br><font size=2 face="Arial">- Scott</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Johnny Oestergaard <joe AT joe DOT
net></b></font>
<br><font size=1 face="sans-serif">Sent by: veritas-bu-admin AT
mailman.eng.auburn DOT edu</font>
<p><font size=1 face="sans-serif">11/02/2002 02:23 PM</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
scott.kendall AT abbott DOT com</font>
<br><font size=1 face="sans-serif"> cc:
Bruno.Bossier AT comparex DOT be, veritas-bu AT
mailman.eng.auburn DOT edu</font>
<br><font size=1 face="sans-serif"> Subject:
Re: [Veritas-bu] Backing up a large amount of small
files</font></table>
<br>
<br>
<br><font size=2 face="Courier New">I could live with only a daily backup for
DR on the volume with all our <br>
scanned documents (lots and lots of small files) and then do a normal full <br>
backup every weekend and new files every day.<br>
<br>
I haven't found out how to do the "track by track" backup, but I know
that <br>
flash backup is not supported at the moment on StorageTek SVA9500 and also <br>
not on Windows.<br>
<br>
If I get a real nasty problem I could also just restore the volume to a <br>
different LUN and then move the file I need back to the production LUN. The <br>
SVA9500 (and V960 and V2X) is a great platform for doing this kind of stuff.<br>
<br>
Since we only need a volume of less the 100 GB for our image files a total <br>
restore wouldn't take that long. Compression on that kind of volume with a <br>
lot of free space should be good so restoring 30-60 MB/s should be <br>
something we should see (I would hope)<br>
<br>
Do you remember where in the policy you tell that you want a raw backup and <br>
not a normal file backup?<br>
We run 4.5<br>
<br>
/johnny<br>
<br>
At 13:48 02-11-2002 -0600, scott.kendall AT abbott DOT com wrote:<br>
<br>
>netbackup by itself can do an image, or block by block, backup. you
just <br>
>have to use the right thing in the file list. can't remember off the top
<br>
>of my head what it is but it is documented in one of the netbackup <br>
>docs. the problem with this is it's really only for full DR.
you can't <br>
>restore a single file, only the entire volume.<br>
><br>
>to take a backup block by block, but be able to restore a single file, you
<br>
>have to also look at and keep the file to block mapping so you can <br>
>reference it to pull a single file out of the image. that's exactly
what <br>
>flashbackup from veritas does. unfortunately, it's only available on
<br>
>certain platforms and windows isn't one of them yet... but it's supposed
<br>
>to be in the works!!! I think a lot of us will be looking at this
when it <br>
>finally comes out.<br>
><br>
><br>
>- Scott<br>
><br>
><br>
><br>
>Johnny Oestergaard <joe AT joe DOT net><br>
>Sent by: veritas-bu-admin AT mailman.eng.auburn DOT edu<br>
><br>
>11/02/2002 04:43 AM<br>
><br>
> To: "David A.
Chapa" <david AT datastaff DOT com>, <br>
> Bruno.Bossier AT comparex DOT be<br>
> cc: veritas-bu AT
mailman.eng.auburn DOT edu<br>
> Subject: Re:
[Veritas-bu] Backing up a large amount of <br>
> small files<br>
><br>
><br>
>We have the same type of problem and except that we have turned OTM off
and<br>
>have less files the only way I see that we can solve the problem is by<br>
>dividing the directories into different streems and streem the backup to<br>
>disk (so that it doesn't hold a tapedrive for days)<br>
>Later we will move the backup from disk to tape but that should happen at
a<br>
>speed that we can handle.<br>
><br>
>It's great to have so fast tapedrives as we have today (if NT/Win2K
could<br>
>pump the data at that speed)<br>
><br>
>Our files are on a StorageTek SVA9500 and it's still so slow that we
cry.<br>
>It's not the disks that are the problem but the time it takes for the<br>
>operatingsystem to open and close the files.<br>
>It would also be a problem on any other operatingsystem (but could be it<br>
>would be a little smaller)<br>
><br>
>I have been thinking if NBU could take a physical backup of the drive<br>
>(track by track) This should be fast but would also backup empty tracks
but<br>
>at 30MB/s or more who cares.<br>
><br>
>/johnny<br>
><br>
>At 12:03 30-10-2002 -0500, David A. Chapa wrote:<br>
> >Well, I did see something like this at a client and I always found the
best<br>
> >solution to something like this is to just format the dang thing
:-)<br>
> ><br>
> >But Seriously now...<br>
> ><br>
> >What RAID level, 5?<br>
> ><br>
> >RAID5 is great for writes but not for reads, and with as many reads as
you</font>
<br><font size=2 face="Courier New">> >need<br>
> >done for this backup you would definitely hit timeouts. This is
exactly the<br>
> >problem one of my current clients is facing.<br>
> ><br>
> >What about the last time SCANDISK was run? We found a heavily
fragmented<br>
> >disk<br>
> >caused these types of timeouts as well.<br>
> ><br>
> >Some of the other things we tried was to break up the server backup at
the<br>
> >file<br>
> >list. This was a bit more labor intensive, but it did work to
some degree.<br>
> ><br>
> >HTH<br>
> ><br>
> >David<br>
> ><br>
> >Quoting Bruno.Bossier AT comparex DOT be:<br>
> ><br>
> > > We have a server with a directory which contains over 3 million
files <br>
> for a<br>
> > > total amount of nearly 150 Gb. We are trying to back this up in
a<br>
> > > reasonable amount of time (12 to 14 hours maximum). OTM is
enabled. <br>
> We have<br>
> > > not succeeded so far. A lot of time is lost at the beginning of
the <br>
> backup<br>
> > > when the backup is going through the directory structure to
check all<br>
> > > files. This takes several hours. The first we already did until
now is to<br>
> > > set the maximum cache size to 0 (unlimited). This stopped the
errors <br>
> we saw<br>
> > > in the Windows eventlog when OTM is started and then aborted
after 40<br>
> > > minutes, then restarted again ....<br>
> > ><br>
> > > Can someone give some suggestions to speed up this backup ?<br>
> > ><br>
> > > Thanks,<br>
> > > Bruno<br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > Veritas-bu maillist - Veritas-bu AT
mailman.eng.auburn DOT edu<br>
> > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu<br>
> > ><br>
> ><br>
> ><br>
> ><br>
> >_______________________________________________<br>
> >Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT
edu<br>
> >http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu<br>
><br>
>_______________________________________________<br>
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT
edu<br>
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu<br>
><br>
<br>
_______________________________________________<br>
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu<br>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu<br>
</font>
<br>
<br>
--=_alternative 0079916B86256C65_=--
|
