Jonathan,
Actually we already tried out different sets of block sizes on the DSSU. 32
seems to be the fastest we can find. We do not use compression and there is no
fragmentation whatsoever (newly formatted disk). Only 1 duplication is done at
a time (only 1 tape drive attached to the DSSU
Ed,
Did you ever heard of NBU users who actually got heir speeds up to acceptable
levels with DSSU ? I asked the same question this morning to NBU support but
I'm pretty sure I already know what the answer will be.
Best Regards,
Bart WALLEBROEK
Backup Admin Systems Applications Management
Dear all,
Thank you for all of your explanation, it's very clear to me now.
--
Best Regards,
Adrian
-Original Message-
From: judy_hinchcli...@administaff.com
[mailto:judy_hinchcli...@administaff.com]
Sent: 23 Juni 2010 21:43
To: Adrian Soetanto; veritas-bu@mailman.eng.auburn.edu
Thank you Judy, you nailed it!
I applied the patch from that bug report and ran a test backup last
night. It succeeded.
I won't mention the fact that after spending eight business days working
with Symantec support on this issue, I got the answer from this list in
less than thirty minutes.
On 6/23/10 8:23 PM, A Darren Dunham wrote:
Also look at /vol/vol0/etc/log/backup. That can have other information
about backup starts and stops.
All you could see there was an abort. We now know that is the result
of a chain of events precipitated by bpdbm dumping core (see Judy's
I know it does not help your configuration but destaging using SLPs from
AdvancedDisk to LTO-4 we get 80-150 MB/s.
William D L Brown
From: veritas-bu-boun...@mailman.eng.auburn.edu
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of WALLEBROEK Bart
Sent: 24 June 2010 07:48
To: Ed
Thank you for the credit.
I feel I should give you some background as to why I knew.
I have been fighting the 233 with core dumps for about 2 years now. And yes I
have been working with Symantec. I have a dedicated person and group of
people. Mine do not happen all the time. I might get 3
I regularly push LTO3 to 100+MB/sec. It just depends on your configuration
(hardware and software.) For example, I've got a 4TB Oracle DB that writes to a
DSSU at 40MB/sec then destages to tape at 100+MB/sec. I understand that you
are running 1 deduplication job at a time to a single tape
On Tuesday 22 June 2010 09:59:22 thomas.h...@sungard.com wrote:
No surprise, there are some bugs in v7.0 pertaining to vStorage that
will be addressed in v7.1 (due to be released in August 2010)
Hi Thomas,
Where can I check this August date (for 7.1) on the Symantec site?
Thanks,
Jorge
2010/6/24 Jorge Fábregas jorge.fabre...@gmail.com
On Tuesday 22 June 2010 09:59:22 thomas.h...@sungard.com wrote:
No surprise, there are some bugs in v7.0 pertaining to vStorage that
will be addressed in v7.1 (due to be released in August 2010)
Where can I check this August date (for 7.1)
Jorge When I was talking with support; they didnt have a firm date.
Only that GA would be sometime in August and that a patch should be made
available sometime in July.
Regardless from what Jon found, it sounds like the patch might not
address this bug anyway. You are probably just better
We have pretty good DSSU destaging to tape performance.
Looks like it's running at between 200GB to 300GB per hour from DSSU to tape -
it's a bit slower if you have lots of small backup images.
We have 10 LTO4 drives a I've found that performance is improved if you limit
the number of jobs
Martin,
Even when we fully format the DSSU disk and we then run 1 backup job to this
disk and directly afterwards we duplicate it to tape we get these speeds
(35-40MB/sec). So at that time no fragmentation at all is involved.
Best Regards,
Bart WALLEBROEK
Backup Admin Systems Applications
13 matches
Mail list logo
