Veritas-bu

[Veritas-bu] disk storage units

2005-07-29 23:14:24
Subject: [Veritas-bu] disk storage units
From: kfhemness AT ucdavis DOT edu (Kathryn Hemness)
Date: Fri, 29 Jul 2005 20:14:24 -0700 (PDT)
What wasn't clear to me in this thread was whether the storage
units are "disk storage units" or "disk staging storage units," both of
which are available in NB5.1.  The disk staging storage unit allows
for the setting of duplication "frequency", error-behavior and multiple
copies.

The "disk storage unit" just writes the backup images to disk and the
admin must use scripts to duplicate the images to tape.

Neither disk nor disk-staging storage unit groups behave as tape storage
unit groups, even though both require the setting of fragment size (which
I had assumed enabled them to behave like tape storage unit groups).
However, my assumption was incorrect - when a disk storage unit fills,
the backups fail; NB will not continue the backup on another empty disk
in the storage unit group.

I initially tried to use disk-staging storage units and wound up with the
majority of my backups failing on full storage units.  The success of
disk-staging storage units is dependent on the disk-write speeds being
comparable to the disk-read speeds; my hardware was unable to meet these
requirements.  What I wound up doing was having 2 7TB disk storage units and
alternating their use daily; one day I would write to on storage unit while
duplicating the diskimages on the other storage unit to tape.  Each day,
I modify all of my policies to use the empty storage unit for backups.

My hardware consisted of a 2-cpu/2GB ram Sun V240 attached via 2gb fiber
to 2 Sun 3511 storage arrays and a 3-drive LTO-II library.  The cpu load
of the v240 ran at above 96% for the daily 12-hour backup windows.
Disk writes during the backup window are less than 10000 kb/sec, and
disk reads from the same disk would be 100kb/sec - absolutely dismal.
With writes and reads from different disks, at least the reads during
backup windows are over 2000 kb/sec - not great but much better than 100kb/sec.
I'm in the process of ordering another system for a media server so that
I can split the peripherals.

I hope this helps.

> Message: 2
> To: "'Geyer, Gregory'" <Gregory.Geyer AT Avnet DOT com>,
>    "'Jack L. Forester, Jr.'" <jack.l.forester AT lmco DOT com>,
>    "'Veritas List'"
>        <veritas-bu AT mailman.eng.auburn DOT edu>
> Subject: RE: [Veritas-bu] disk storage units
> Date: Fri, 29 Jul 2005 13:52:43 -0400
> From: "Dellaripa, Rich" <rich.dellaripa AT cingular DOT com>
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C59466.5249F200
> Content-Type: text/plain
>
> We do duplication using scripted bpduplicates. I'm curious, then, where
> these ".ds" files come from and what creates them.
>
> -----Original Message-----
> From: Geyer, Gregory [mailto:Gregory.Geyer AT Avnet DOT com]
> Sent: Thursday, July 28, 2005 5:55 PM
> To: Jack L. Forester, Jr.; Veritas List
> Subject: RE: [Veritas-bu] disk storage units
>
> It depends on what type of duplication.  A DSSU job will leave the *.ds
> file there and thus the image is then eligible to be removed if space is
> needed.
>
> A vault duplication however actually impedes the process.  Vault will
> create a copy 2 of the image, but will not leave the *.ds (as your vault
> job may expire in a much shorter time).  Then when the DSSU job kicks
> off it will fail to stage the image to tape saying that "copy 2 already
> exists".
>
> This is something I want changed....if it hasn't been staged with a DSSU
> job but vault has done its job first, stage it and make it copy 3.
>
>
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Jack L.
> Forester, Jr.
> Sent: Thursday, July 28, 2005 7:58 AM
> To: Veritas List
> Subject: Re: [Veritas-bu] disk storage units
>
> If I'm not mistaken, images are candidates for removal from the DSSU
> after they have been duplicated to tape.  NBU will remove these images
> if it needs to make room.
>
>  From the NBU 5.1 Sysadmin guide, volume 1:
>
> "When a Stage I process detects a full disk staging storage unit, it
> pauses the backup, finds the oldest image that has been successfully
> copied to the destination storage unit, and expires this image copy."
>
> Paul Keating wrote:
>
> >But even frequent duplication won't ensure the DSSU won't fill....
> >The image remains on DSSU after duplication.
> >
> >From what I understand, it only gets flushed from the DSSU when a new
> >backup job determines there is insufficient room on the DSSU, at which
> >time, the two old images on the DSSU, that have already been duped to
> >tape, will be flushed from the DSSU.
> >
> >Also, if I still understand correctly, if that New job going to DSSU is
>
> >bigger than the two oldest jobs that were flushed, then the job will
> >still fill the DSSU and fail.
> >
> >My DSSUs usually sit at 99%.
> >
> >Paul
> >
> >
> >
> >>-----Original Message-----
> >>From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> >>[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Ed 
> >>Wilts
> >>Sent: July 28, 2005 9:59 AM
> >>To: Arne Kloecker
> >>Cc: veritas-bu AT mailman.eng.auburn DOT edu
> >>Subject: Re: [Veritas-bu] disk storage units
> >>
> >>
> >>
> >>Currently, you need to schedule your duplication jobs more frequently
> >>to ensure that your DSSU won't fill.
> >>
> >>
> >>
> >
> >_______________________________________________
> >Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> >http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >
> >
>
>
> --
> Jack L. Forester, Jr.
> UNIX Systems Administrator, Stf
> Lockheed Martin Information Technology
> (304) 625-3946
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>

--kathy


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