[prev in list] [next in list] [prev in thread] [next in thread] 

List:       veritas-bu
Subject:    Re: [Veritas-bu] SAP backups / Online / Redo
From:       David McMullin <David.McMullin () CBC-Companies ! com>
Date:       2013-12-19 18:31:24
Message-ID: C83D277D82594A4C8A269B151C83B89A01525DF3C167 () CBCMAIL07 ! cbc ! local
[Download RAW message or body]

Before we bought, we had the vendors replicate the throughput to prove the system \
could handle the ingest and output. A lot of the sales numbers are one way, not both \
at once. We have 16 LTO5 drives and I can drive all 16 while also ingesting data. We \
use NB Storage Lifecycle Policy to automatically duplicate to tape. The 1st copy to \
the DD990 has a 2 week expiration, the 2nd copy (to tape) has the DR expiration, for \
longer retentions we actually make a third copy. Since the DD990 has deduplication, \
we are able to take the 100TB and divide it into 600TB of tapes... That holds the two \
weeks easily. That 6X was trial and error, we have a lot of data that is encrypted or \
voice recording that does not dedupe, and others that gets great compression.

Using this method, the backups do not queue up, the duplications do. There is no \
timeout to worry about, nor backup windows. We send everything everyday to Iron \
Mountain, so everything backed up to DD goes to tape the same day. Nice to have an 18 \
hour backup dupe to tape in 3 hours...

And there is NO multiplexing. And restores from the DD are at that same speed, so we \
have had restores take less time than backups...

The ONLY issue is tape contention on tape restores for DR, where images are not \
spaced on tapes optimally. We have backup 6 wide, restores 6 wide, and sometimes all \
the images it wants are on tapes already loaded.

We are solving that by working to get DD in our DR location so we are not restoring \
from tape...


-----Original Message-----
From: Justin Piszcz [mailto:jpiszcz@lucidpixels.com] 
Sent: Thursday, December 19, 2013 1:20 PM
To: David McMullin; veritas-bu@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] SAP backups / Online / Redo

Dave,

Curious how you determined/measured the available capacity on the disk staging area \
(and also to ensure not to fill it up) and how often you have it in cron (or similar) \
to manually purge the data once it bleeds off to tape?

However a DD990 is a pretty beefy box but I suspect if there are/were enough clients \
it could happen if not setup correctly.

Justin.

> -----Original Message-----
> From: veritas-bu-bounces@mailman.eng.auburn.edu [mailto:veritas-bu- 
> bounces@mailman.eng.auburn.edu] On Behalf Of David McMullin
> Sent: Thursday, December 19, 2013 1:11 PM
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] SAP backups / Online / Redo
> 
> 
> If your tape drives are maxed out and jobs are queued too long, think
about
> putting storage in the middle.
> 
> Our infrastructure is fiber based not 10G, so we got two DD990 as an 
> intermediary backup target and now all jobs write there (we have over 
> 200 drives defined) and once backup jobs complete they duplicate to 
> physical tape. Bonus, many servers cannot drive to the tape drive at 
> speed, but the
> 990 get >100MB/Sec throughput on duplication to tape WHILE also 
> reading in data.
> 
> ---------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 18 Dec 2013 19:54:12 +0000
> From: Simon Weaver <Simon.Weaver@iscl.net>
> Subject: [Veritas-bu] SAP backups / Online / Redo
> To: "VERITAS-BU@mailman.eng.auburn.edu"
> 	<VERITAS-BU@mailman.eng.auburn.edu>
> Message-ID: <EF0BBE0D-E406-490C-A05F-5BE16718E214@iscl.net>
> Content-Type: text/plain; charset="us-ascii"
> 
> All
> I've been trying to troubleshoot performance and backup issues at an 
> environment where all LTO4 drives are maxed out with these type of 
> jobs and causing many others to queue or run at an incorrect time.
> 
> There are close to around 60 policies where we have online, off-line, 
> and redo log backups.
> 
> In each policy there was only a single client listed. A lot of these
policies are
> sand media servers therefore they backup themselves.
> 
> The problem is we have too many jobs running concurrently and due to 
> the vast amount of data on the servers, there is insufficient 
> resources
available
> for NBU to resume the queued jobs.
> 
> I would be interested to know if anyone else has a large environment 
> of SAP/Oracle backups and what they do backups, because presently 
> these jobs I can shaming 98% of our resources and our windows phone 
> service I currently struggling to get backed up.
> 
> This separate tape drive all these will be in place, but I want to 
> enquire
if
> there is anything that could be done to may be group the SAP online
backups
> into one policy.
> 
> But I'm also interested to hear of any ideas or methods that you may 
> be using now.
> 
> Thanks
> Si
> 
> ------------------------------
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> https://urldefense.proofpoint.com/v1/url?u=http://mailman.eng.auburn.e
> du/mailman/listinfo/veritas-bu&k=j2AJn6IkQ79ZgTSu1WDHyg%3D%3D%0A&r=VCU
> Kq21iGlRNTAIowzHLezeU0vp4g26cE0qD%2Bhx7PsQ%3D%0A&m=OtTOf1S5kvB6RuFvq09
> x9v0MEB6tC1nAphvq%2BZBy3C0%3D%0A&s=eea993e14db33a9bbcb97b7745ebdee8d72
> 939f0e1fa5a811353c0191be21b48

_______________________________________________
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


[prev in list] [next in list] [prev in thread] [next in thread]