Jochen,
I know that relocation within disk staging is restricted to one image at
a time per Disk Staging Storage Unit (DSSU). There is no multi-stream
capability as when data is backed up to the DSSU in phase 1. Veritas
recommend using multiple DSSUs to achieve increased performance within
the process.
http://support.veritas.com/docs/266903
Regards,
Paul Esson
Senior Consultant
Redstor Limited
Direct: +44 (0) 1224 595381
Mobile: +44 (0) 7766 906514
E-Mail: paul.esson AT redstor DOT com
Web: www.redstor.com
REDSTOR LIMITED
Torridon House
73-75 Regent Quay
Aberdeen
UK
AB11 5AR
Disclaimer:
The information included in this e-mail is of a confidential nature and
is intended only for the addressee. If you are not the intended
addressee, any disclosure, copying or distribution by you is prohibited
and may be unlawful. Disclosure to any party other than the addressee,
whether inadvertent or otherwise is not intended to waive privilege or
confidentiality.
-----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
veritas-bu-request AT mailman.eng.auburn DOT edu
Sent: 26 August 2005 18:10
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Veritas-bu digest, Vol 1 #4273 - 8 msgs
Send Veritas-bu mailing list submissions to
veritas-bu AT mailman.eng.auburn DOT edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
or, via email, send a message with subject or body 'help' to
veritas-bu-request AT mailman.eng.auburn DOT edu
You can reach the person managing the list at
veritas-bu-admin AT mailman.eng.auburn DOT edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Veritas-bu digest..."
Today's Topics:
1. Re: Best method to check when a box was successfully
backed up? (Wayne T Smith)
2. Re: Best method to check when a box was successfully backed up?
(Charles Ballowe)
3. RE: Re: Status code 150 (King, Cheryl)
4. Staging performance vs. Backup performance (Jochen Pressler)
5. Re: Staging performance vs. Backup performance
(ida3248b AT post.cybercity DOT dk)
6. drive cleaning frequency change not sticky (Wayne T Smith)
7. Re: drive cleaning frequency change not sticky (Wayne T Smith)
--__--__--
Message: 1
Date: Thu, 25 Aug 2005 15:07:03 -0400
From: Wayne T Smith <wtsmith AT maine DOT edu>
To: "Piszcz, Justin" <jpiszcz AT servervault DOT com>,
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Best method to check when a box was
successfully
backed up?
How about:
bpimagelist -U -hoursago 99999 -client <clientname>|head -3|tail -1
That is, bpimagelist outputs images ("successful" backups) with most
recent first. "head" takes 1st 3 lines of output and "tail" throws away
the 1st two (header) lines, leaving the most recent backup line, that
might look like this:
08/24/2005 21:49 09/21/2005 13496 809836 N Cumulative I
SomePolicy
Of course, that doesn't say all the files of interest were backed up,
nor is it of much usefulness if a client is covered by more than one
policy, or if files are excluded/selected according to schedule.
cheers, wayne
Piszcz, Justin wrote, in part, on 8/25/2005 8:55 AM:
> I know I can utilize various bp* commands as well as a bpreport.pl
> script I found in the archive mailing lists.
>
> But on a per-client basis, what is the best way to determine **when**
> the last successful (full or incremental) backup occurred?
>
--__--__--
Message: 2
Date: Thu, 25 Aug 2005 14:37:35 -0500
From: Charles Ballowe <cballowe AT gmail DOT com>
To: Wayne T Smith <wtsmith AT maine DOT edu>
Subject: Re: [Veritas-bu] Best method to check when a box was
successfully backed up?
Cc: "Piszcz, Justin" <jpiszcz AT servervault DOT com>,
veritas-bu AT mailman.eng.auburn DOT edu
How about occasional random restores of files? Your backups, after
all, are only as good as your restores.
(most of the time i use bpimagelist -- sometimes bperror -backstat )
Of course, if there's only 2 important files on a box and an admin
puts them on an exclude list - I would never know if they were missed
or not - backup was successful, but doesn't do much good if the
important data is missing.
-Charlie
On 8/25/05, Wayne T Smith <wtsmith AT maine DOT edu> wrote:
> How about:
>
> bpimagelist -U -hoursago 99999 -client <clientname>|head -3|tail -1
>
> That is, bpimagelist outputs images ("successful" backups) with most
> recent first. "head" takes 1st 3 lines of output and "tail" throws
away
> the 1st two (header) lines, leaving the most recent backup line, that
> might look like this:
>
> 08/24/2005 21:49 09/21/2005 13496 809836 N Cumulative I
> SomePolicy
>
> Of course, that doesn't say all the files of interest were backed up,
> nor is it of much usefulness if a client is covered by more than one
> policy, or if files are excluded/selected according to schedule.
>
> cheers, wayne
>
> Piszcz, Justin wrote, in part, on 8/25/2005 8:55 AM:
>
> > I know I can utilize various bp* commands as well as a bpreport.pl
> > script I found in the archive mailing lists.
> >
> > But on a per-client basis, what is the best way to determine
**when**
> > the last successful (full or incremental) backup occurred?
> >
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
--__--__--
Message: 3
Subject: RE: [Veritas-bu] Re: Status code 150
Date: Thu, 25 Aug 2005 15:53:16 -0600
From: "King, Cheryl" <cheryl.king AT intrado DOT com>
To: "Tom Burrell" <tburrell_mn AT yahoo DOT com>,
<veritas-bu AT mailman.eng.auburn DOT edu>
I have a memory leak issue where I'm running out of swap. I haven't
found the cause. What was the fix you're referring to. I'm having the
problem on the two master servers running Solaris 8.
-----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 Tom
Burrell
Sent: Wednesday, August 24, 2005 9:04 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Re: Status code 150
Paul,
We had the same issue here- turned out to be caused by a memory leak on
our Solaris Master server. Once the leaking application was fixed, the
150's went away.
The offending applicaition was the user interface to Veritas Volume
Manager. A fix has been issued, but we just shut down the interface
portion since it wasn't necessary for us.
Tom Burrell
> Date: Wed, 24 Aug 2005 12:03:11 +0100
> From: "Paul Esson" <Paul.Esson AT Redstor DOT com>
> To: <veritas-bu AT mailman.eng.auburn DOT edu>
> Subject: [Veritas-bu] Status Code 150
>
> This is a multi-part message in MIME format.
>
> ------_=_NextPart_001_01C5A89B.6AC967E5
> Content-Type: text/plain;
> charset="US-ASCII"
> Content-Transfer-Encoding: quoted-printable
>
> Folks,
>
> =20
>
> Has anyone seen Status code: 150 "Termination requested by
> administrator" when no administrator has terminated the job on
> Enterprise Server v5.0 MP3 Windows 2003 OS? I did find a technote on
> the Symantec support site
> http://seer.support.veritas.com/docs/275149.htm that discussed message
> queue sizing but I have no equivalent output in my bpsched log that
> would suggest this is my problem?
>
> =20
>
> Regards,
>
> =20
>
> Paul Esson
> Senior Consultant
> Redstor Limited=20
>
> Direct: +44 (0) 1224 595381
> Mobile: +44 (0) 7766 906514
> E-Mail: paul.esson AT redstor DOT com
> Web: www.redstor.com
> REDSTOR LIMITED
> Torridon House
> 73-75 Regent Quay
> Aberdeen
> UK
> AB11 5AR
> Disclaimer:
> The information included in this e-mail is of a confidential nature
> and is intended only for the addressee. If you are not the intended
> addressee, any disclosure, copying or distribution by you is
> prohibited and may be unlawful. Disclosure to any party other than
> the addressee, whether inadvertent or otherwise is not intended to
> waive privilege or confidentiality.
>
> =20
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
--__--__--
Message: 4
Date: Fri, 26 Aug 2005 08:41:43 +0200
From: Jochen Pressler <jo AT bacher DOT at>
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Staging performance vs. Backup performance
Hi,
We have a strange performance issue with staging from Disk to Tape.
Config:
Sun V440 as Master/Media Server
Storagetek FlexLine640 used as Staging Device
Storagetek L700 w. LTO3
SIZE_DATA_BUFFERS 2048k
NUMBER_DATA_BUFFERS 16
SIZE_DATA_BUFFERS_DISK 2048k
NUMBER_DATA_BUFFERS_DISK 16
When we use the Flex640 as a "normal" Storage and doing Backups from
Disk to the L700 Storage,
we see ~140MB/sec. throughput to one LTO3 (higher than expected).
When we use the same Volume on the Flex640 as an Disk Staging Unit an do
manual relocate to 1 LTO3
we only see ~70MB/sec.
When we are using two staging units on the flex and are staging to 2
LTO3 we see ~50MB/sec. per drive.
An overall of 100MB/sec.
Since Staging is done via bpduplicate, are there any settings that are
staging, or bpduplicate specific?
It looks like that there is an "internal" limit, because tape, disk and
system have spare resources left (enough idle time)
do you have an ideas?
thx
Jochen
--
-----------------------------------------------------------------
Jochen Pressler
Bacher Systems EDV GmbH
Clemens-Holzmeister-Strasse 4 , A-1100 Wien, Business Park Vienna,
phone: +43 (1) 60 126-34 | fax: +43 (1) 60 126-4
jo AT bacher DOT at | http://www.bacher.at
Sun Certified Professional
Veritas Certified Professional
--__--__--
Message: 5
From: ida3248b AT post.cybercity DOT dk
To: Jochen Pressler <jo AT bacher DOT at>, veritas-bu AT mailman.eng.auburn DOT
edu
Subject: Re: [Veritas-bu] Staging performance vs. Backup performance
Date: Fri, 26 Aug 2005 09:00:03 +0200
Hello Jochen
I think that NET_BUFFER_SZ plays at part in duplicate as it can be done
between two media servers
Regards
Michael
On Fri, 26 Aug 2005 08:41:43 +0200, Jochen Pressler wrote
> Hi,
>
> We have a strange performance issue with staging from Disk to Tape.
>
> Config:
> Sun V440 as Master/Media Server
> Storagetek FlexLine640 used as Staging Device
> Storagetek L700 w. LTO3
>
> SIZE_DATA_BUFFERS 2048k
> NUMBER_DATA_BUFFERS 16
> SIZE_DATA_BUFFERS_DISK 2048k
> NUMBER_DATA_BUFFERS_DISK 16
>
> When we use the Flex640 as a "normal" Storage and doing Backups from
> Disk to the L700 Storage,
> we see ~140MB/sec. throughput to one LTO3 (higher than expected).
>
> When we use the same Volume on the Flex640 as an Disk Staging Unit
> an do manual relocate to 1 LTO3 we only see ~70MB/sec.
>
> When we are using two staging units on the flex and are staging to 2
> LTO3 we see ~50MB/sec. per drive.
> An overall of 100MB/sec.
>
> Since Staging is done via bpduplicate, are there any settings that
> are staging, or bpduplicate specific? It looks like that there is an
> "internal" limit, because tape, disk and system have spare resources
> left (enough idle time)
>
> do you have an ideas?
>
> thx
> Jochen
>
> --
> -----------------------------------------------------------------
> Jochen Pressler
>
> Bacher Systems EDV GmbH
> Clemens-Holzmeister-Strasse 4 , A-1100 Wien, Business Park Vienna,
> phone: +43 (1) 60 126-34 | fax: +43 (1) 60 126-4
> jo AT bacher DOT at | http://www.bacher.at
>
> Sun Certified Professional
> Veritas Certified Professional
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
--
Cybercity Webhosting (http://www.cybercity.dk)
--__--__--
Message: 6
Date: Fri, 26 Aug 2005 09:39:54 -0400
From: Wayne T Smith <wtsmith AT maine DOT edu>
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] drive cleaning frequency change not sticky
Weird problem of the day: If I change my drive cleaning frequency in
the Admin Console (I believe it uses tpconfig under the covers), the
frequency reverts to the old value at the next change of media!
Workaround: If I use the tpclean command to make the change, the change
"sticks". (I'm lowering from 500 hours to 300 hours).
Environment: Solaris 9, NetBackup 5.1MP3, L700, LTO-1 drives, not
shared. NetBackup thinks TapeAlert is on, but it has never worked (the
L700 does see when the drives have "cleaning needed").
Just thought this might lessen the "astonishment factor", if others see
the problem.
P.S. Maintenance packs have been coming out quarterly, but v5.1MP4 seems
several weeks late ... anyone know what's going on?
cheers, wayne
--__--__--
Message: 7
Date: Fri, 26 Aug 2005 11:05:59 -0400
From: Wayne T Smith <wtsmith AT maine DOT edu>
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] drive cleaning frequency change not sticky
McCammont, Anderson (IT) wrote, in part, on 8/26/2005 10:25 AM:
>are you running 64 bit solaris?
>
Yes, perhaps that explains the TapeAlert problem.
Thanks and cheers, wayne
--__--__--
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
End of Veritas-bu Digest
|
