Backup Central

NBU5.1
Master : Sun v880 Solaris 9.
3*Media : Sun v880 Solaris 9.
EMC Clariion Cx300.

Can disk storage units / disk staging storage units be configured to work
usefully in a storage unit group?

I have 3 media servers each with a disk staging area. I would like for
backups to go to one, then if full, go to a different one. The way things
stand at the moment, if the disk staging area fills up on the first server,
backups continue to go to it and all fail with 84. The equivalent would
work with tape drives.

Ideally, thinking about it, I'd like backups to go to all three staging
areas in parallel, but I can't think how to achieve this.

Disks / Staging areas / SSO is new ground for me so if the answer's "RTFM"
then I'll go and do so :-)

thanks, Phil

Phil Weber
Egg UNIX Technologist
Phone: 01384 26 4136
Mobile:

-----------------------------------------
Egg is a trading name of the Egg group of companies which includes: Egg plc
(reg no 2448340), Egg Financial Products ltd (reg no 3319027), Egg
International ltd (reg no 4059266), Egg Financial Intermediation ltd (reg
no 382828), Egg Investments ltd (reg no 3403963) and Egg Banking plc (reg
no 2999842. Egg Investments Ltd, Egg Banking plc and Egg Financial
Intermediation Ltd are authorised and regulated by the Financial Services
Authority (FSA) and are entered in the FSA register under numbers 190518,
205621 and 309551 respectively. These members of the Egg group are
registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA. This e-mail is confidential and for
use by the addressee only. If you are not the intended recipient of this
e-mail and have received it in error, please return the message to the
sender by replying to it and then delete it from your mailbox. Internet
e-mails are not necessarily secure. The Egg group of companies do not
accept responsibility for changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by the Egg group of companies in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
This communication does not create or modify any contract.

We have not found a way to get around the 84 errors caused by a dsu filling
up. NB isn't smart enough to try a different dsu. However, we have been
able to run parallel jobs to different dsu's. We have 3 media servers, each
with one dsu. We set job limits per dsu of 6. We then created 3 storage
unit groups. Each storage unit group has all 3 dsu's, however, each group
has a different priority for each dsu. Then each policy has a specific
storage unit group it uses. The policy A will always try to write to STU
group 1 first. Policy B will always try to write to STU group 2 first ,
etc. If one of those dsu's has the maximum number of jobs running, the job
runs on the next available dsu in the STU group. This ensures that the
maximum number of jobs run, but the load is spread out across dsu's. That
is provided you have balanced the policies so that roughly that each dest
STU is used equally.


Ebon Nash
Storage Administrator
Compuware Corporation
313-227-5109

-----Original Message-----
From: veritas-bu-admin < at > mailman.eng.auburn.edu
[mailto:veritas-bu-admin < at > mailman.eng.auburn.edu]On Behalf Of Weber,
Philip
Sent: Wednesday, January 19, 2005 10:16 AM
To: 'veritas-bu < at > mailman.eng.auburn.edu'
Subject: [Veritas-bu] Disk Staging & Storage Unit Groups


NBU5.1
Master : Sun v880 Solaris 9.
3*Media : Sun v880 Solaris 9.
EMC Clariion Cx300.

Can disk storage units / disk staging storage units be configured to work
usefully in a storage unit group?

I have 3 media servers each with a disk staging area. I would like for
backups to go to one, then if full, go to a different one. The way things
stand at the moment, if the disk staging area fills up on the first server,
backups continue to go to it and all fail with 84. The equivalent would
work with tape drives.

Ideally, thinking about it, I'd like backups to go to all three staging
areas in parallel, but I can't think how to achieve this.

Disks / Staging areas / SSO is new ground for me so if the answer's "RTFM"
then I'll go and do so :-)

thanks, Phil

Phil Weber
Egg UNIX Technologist
Phone: 01384 26 4136
Mobile:

-----------------------------------------
Egg is a trading name of the Egg group of companies which includes: Egg plc
(reg no 2448340), Egg Financial Products ltd (reg no 3319027), Egg
International ltd (reg no 4059266), Egg Financial Intermediation ltd (reg
no 382828), Egg Investments ltd (reg no 3403963) and Egg Banking plc (reg
no 2999842. Egg Investments Ltd, Egg Banking plc and Egg Financial
Intermediation Ltd are authorised and regulated by the Financial Services
Authority (FSA) and are entered in the FSA register under numbers 190518,
205621 and 309551 respectively. These members of the Egg group are
registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA. This e-mail is confidential and for
use by the addressee only. If you are not the intended recipient of this
e-mail and have received it in error, please return the message to the
sender by replying to it and then delete it from your mailbox. Internet
e-mails are not necessarily secure. The Egg group of companies do not
accept responsibility for changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by the Egg group of companies in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
This communication does not create or modify any contract.




The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

-----Original Message-----
From: veritas-bu-admin < at > mailman.eng.auburn.edu
[mailto:veritas-bu-admin < at > mailman.eng.auburn.edu] On Behalf Of
Weber, Philip
Sent: January 19, 2005 10:16 AM
To: 'veritas-bu < at > mailman.eng.auburn.edu'
Subject: [Veritas-bu] Disk Staging & Storage Unit Groups

Can disk storage units / disk staging storage units be
configured to work
usefully in a storage unit group?

Should be fine.....


if the disk staging area fills up on the
first server,
backups continue to go to it and all fail with 84.

At least it doesn't cause NB to completely hang/freeze like it did to me
several times.

Ideally, thinking about it, I'd like backups to go to all
three staging
areas in parallel, but I can't think how to achieve this.

Go into Policy, then into Schedules, then open a schedule.
Check "Multiple copies" then click "configure".
In each box, select a different DSSU.

Backup jobs will write the *same* data to each DSU in parallel.
You have the option of telling it what to do if one fails (fail job, or
continue with others)

You'll take a *small* performance hit for each extra parallel job your
write (each additional storage unit)

Paul

Thanks everybody for all the useful suggestions. I haven't really played
much with disk staging yet. These 84s were basically due to not staging to
tape correctly, but they got me to thinking how I can use all the available
space efficiently, i.e. without backups failing until it had run out of
space across the board. I didn't really want to get into multiple storage
units (or groups) but it sounds like this will be the way forward for now.

cheers, Phil

-----Original Message-----
From: Greenberg, Katherine A [mailto:GreenbergKA < at > aetna.com]
Sent: 19 January 2005 16:37
To: Weber, Philip
Subject: RE: [Veritas-bu] Disk Staging & Storage Unit Groups


I've not been able to get the 2 to work together in a STU group.

What patch level of NBU are you running?

What kind of *scrape* schedule are you running at the back end of the
DSSU? Are you not running it often enough causing it to fail with 84
errors? Are you using all your tape drives in regular STUs and when the
DSSU goes to offload images, there are no tape drives available for use?
I've gotten 84 errors on DSSU when that is the case. There is a doc out
on the Veritas site that discusses cleaning images from DSSU.

~Kate
~~~~~~~~~~~~~~~~~~~~~~~~~~
Katherine Greenberg
Systems Engineer
Mid-Range Storage Management
Aetna, Inc.



-----Original Message-----
From: veritas-bu-admin < at > mailman.eng.auburn.edu
[mailto:veritas-bu-admin < at > mailman.eng.auburn.edu] On Behalf Of Weber,
Philip
Sent: Wednesday, January 19, 2005 10:16 AM
To: 'veritas-bu < at > mailman.eng.auburn.edu'
Subject: [Veritas-bu] Disk Staging & Storage Unit Groups


NBU5.1
Master : Sun v880 Solaris 9.
3*Media : Sun v880 Solaris 9.
EMC Clariion Cx300.

Can disk storage units / disk staging storage units be configured to
work usefully in a storage unit group?

I have 3 media servers each with a disk staging area. I would like for
backups to go to one, then if full, go to a different one. The way
things stand at the moment, if the disk staging area fills up on the
first server, backups continue to go to it and all fail with 84. The
equivalent would work with tape drives.

Ideally, thinking about it, I'd like backups to go to all three staging
areas in parallel, but I can't think how to achieve this.

Disks / Staging areas / SSO is new ground for me so if the answer's
"RTFM" then I'll go and do so :-)

thanks, Phil

Phil Weber
Egg UNIX Technologist
Phone: 01384 26 4136
Mobile:

-----------------------------------------
Egg is a trading name of the Egg group of companies which includes: Egg
plc (reg no 2448340), Egg Financial Products ltd (reg no 3319027), Egg
International ltd (reg no 4059266), Egg Financial Intermediation ltd
(reg no 382828), Egg Investments ltd (reg no 3403963) and Egg Banking
plc (reg no 2999842. Egg Investments Ltd, Egg Banking plc and Egg
Financial Intermediation Ltd are authorised and regulated by the
Financial Services Authority (FSA) and are entered in the FSA register
under numbers 190518, 205621 and 309551 respectively. These members of
the Egg group are registered in England and Wales. Registered offices: 1
Waterhouse Square,
138-142 Holborn, London EC1N 2NA. This e-mail is confidential and for
use by the addressee only. If you are not the intended recipient of
this e-mail and have received it in error, please return the message to
the sender by replying to it and then delete it from your mailbox.
Internet e-mails are not necessarily secure. The Egg group of companies
do not accept responsibility for changes made to this message after it
was sent. Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this message and
any attachments will not adversely affect its systems or data. No
responsibility is accepted by the Egg group of companies in this regard
and the recipient should carry out such virus and other checks as it
considers appropriate. This communication does not create or modify any
contract.


-----------------------------------------
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender by
reply e-mail and then delete this e-mail immediately. Thank you. Aetna

-----------------------------------------
Egg is a trading name of the Egg group of companies which includes: Egg plc
(reg no 2448340), Egg Financial Products ltd (reg no 3319027), Egg
International ltd (reg no 4059266), Egg Financial Intermediation ltd (reg
no 382828), Egg Investments ltd (reg no 3403963) and Egg Banking plc (reg
no 2999842. Egg Investments Ltd, Egg Banking plc and Egg Financial
Intermediation Ltd are authorised and regulated by the Financial Services
Authority (FSA) and are entered in the FSA register under numbers 190518,
205621 and 309551 respectively. These members of the Egg group are
registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA. This e-mail is confidential and for
use by the addressee only. If you are not the intended recipient of this
e-mail and have received it in error, please return the message to the
sender by replying to it and then delete it from your mailbox. Internet
e-mails are not necessarily secure. The Egg group of companies do not
accept responsibility for changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by the Egg group of companies in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
This communication does not create or modify any contract.

FWIW, in case you haven't discovered this, it is a good idea to have
FULLs and INCREMEMENTALS go to different DSUs.

If NB thinks there is insufficient space on a DSU, it will delete the
two oldest images that have been purged to tape, in order to make room
for the next backup.

However, if the two oldest images on the DSU are 100 Meg incrementals,
and the backup that is queueing is a 50 gig FULL, you're gonna end up
with the full DSU, and a status 84.

What I've been doing lately, is letting the Friday night FULL run, then
Monday morning, I verify that it is flushed to tape....once on tape, I
promote the tape copy to Primary, and expire the DSU image......that
cleans up the DSU and leaves enough free space to run till the following
Monday.

Currently this is a work around untill our SAN infrastructure is in
place in Q3, as we don't want to buy additional disk arrays now, with
the SAN in the pipe.

Paul

-----Original Message-----
From: veritas-bu-admin < at > mailman.eng.auburn.edu
[mailto:veritas-bu-admin < at > mailman.eng.auburn.edu] On Behalf Of
Nash, Ebon
Sent: January 19, 2005 11:07 AM
To: 'Weber, Philip'; 'veritas-bu < at > mailman.eng.auburn.edu'
Subject: RE: [Veritas-bu] Disk Staging & Storage Unit Groups


We have not found a way to get around the 84 errors caused by
a dsu filling
up. NB isn't smart enough to try a different dsu. However,
we have been
able to run parallel jobs to different dsu's. We have 3
media servers, each
with one dsu. We set job limits per dsu of 6. We then
created 3 storage
unit groups. Each storage unit group has all 3 dsu's,
however, each group
has a different priority for each dsu. Then each policy has
a specific
storage unit group it uses. The policy A will always try to
write to STU
group 1 first. Policy B will always try to write to STU
group 2 first ,
etc. If one of those dsu's has the maximum number of jobs
running, the job
runs on the next available dsu in the STU group. This
ensures that the
maximum number of jobs run, but the load is spread out across
dsu's. That
is provided you have balanced the policies so that roughly
that each dest
STU is used equally.