Few different solution options I can think of. I don’t know what your underlying disk array tech is so I’m going to mention things I have experience with –
maybe they’ll work for you, maybe not…
Option 1
Leverage underlying disk array technology to move data around. In the case of EMC you might consider BCVs that can incrementally update data to completely separate
disks. You would only need to quiesce Oracle (hotbackupmode) for minutes or less while you split off the BCVs and then import/mount them on a media server that could then spin to tape. Downside to this is that in the case of Oracle, most files get modified
and captured by NBU even if only a small amount of change occurred within.
Option 2
Use Oracle RMAN with the DataDomain Incremental Merge option. This involves a one-time full and indefinite incremental RMAN backups to a DataDomain repository
(typically an NFS mount). By leveraging some data movement tech within the array in combination with RMAN Block Change Tracking, you can have incremental backups indefinitely. Downside to this is if your database is encrypted, you’ll lose out on the de-duplication
of the DataDomain (but it’s great not having tape).
Option 3
If you are using NetApp FAS storage, you can leverage Snapshot & Snapvault technology to perform incremental backups at the array level. High level it works
like this- Hotbackupmode, snapshot primary storage, out of hotbackupmode, incremental snapvault update from primary array to secondary array, snapshot on secondary array. Downside is you need another array but it is probably cheaper disk (1TB SATA or greater)
but upside is traffic is between arrays and no tape. You can also retain the data for longer on the secondary array where your cheaper disk is.
You’ll notice options 2 & 3 don’t even use NBU at all – there are a few use cases that NBU can’t address. Just suggesting you don’t limit your solution assessment
to NBU only.
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu]
On Behalf Of Simon Weaver
Sent: Thursday, April 12, 2012 01:36
To: stefanos; Mark Phillips; JCrowe AT marketforce.com DOT au
Cc: veritas-bu AT mailman.eng.auburn DOT edu; veritas-bu-bounces AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Advice & Help - Linux Server 14TB
Oracle is on here as well :-(
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
on behalf of stefanos
Sent: Thu 12/04/2012 08:38
To: 'Mark Phillips'; JCrowe AT marketforce.com DOT au; Simon Weaver
Cc: veritas-bu AT mailman.eng.auburn DOT edu; veritas-bu-bounces AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Advice & Help - Linux Server 14TB
I agree that synthetic backups are good, but only if you run file backups.
If the system has an oracle, the synthetic backups are useless.
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu]
On Behalf Of Mark Phillips
Sent: Thursday, April 12, 2012 3:56 AM
To: JCrowe AT marketforce.com DOT au; Simon Weaver
Cc: veritas-bu AT mailman.eng.auburn DOT edu; veritas-bu-bounces AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Advice & Help - Linux Server 14TB
I agree. We use synthetic fulls quite a bit.
They work really well for large filesystems that have relatively small incremental backups.
If you’re going to tape you’ll need at least 2 free tape drives for the duration of the synthetic full backup, one for the last full backup and
the other for the one you’re constructing.
Also it’s best if you’re able to send incremental backups to staging disk and they remain on the staging disk when the synthetic full is being
constructed, it saves on tape loading and positioning time.
If the incremental backups are going to tape avoid multiplexing them, it’ll slow things down.
Also if you’re going to tape when doing the first conventional full backup don’t multiplex it – this will make doing the first synthetic full backup
slow.
Mark
I would look at synthetics ... not quite as large as you, but I backup around 8TBs on one linux (RHEL 4) server over the weekend (every weekend) and it completes
in well under 24 hours. (About 16-20 hours from memory)
The very first backup has to be a full, but once that is out of the way, you should be able to do a full synthetic every weekend in well under 48 hours (I'm going on what I
have above so is just a guess - you may be much faster than my infrastructure as its nothing flash ... though it is completely gigabit)
I should add that I've been using synthetics on this particular server for around 4.5 years now, and they are reliable and fast - unless you have to "re-seed" the synthetic
with an initial full backup; I have had a few go bad such that I have had to re-seed the backup, but that's been rare and only happened 2-3 times in all that time. HIGHLY recommended for large backups.
Cheers
Crowey
From: "Simon Weaver" <Simon.Weaver AT iscl DOT net>
To: <veritas-bu AT mailman.eng.auburn DOT edu>,
Date: 11/04/2012 09:16 PM
Subject: [Veritas-bu] Advice & Help - Linux Server 14TB
Sent by: veritas-bu-bounces AT mailman.eng.auburn DOT edu
All
I am hoping you can help....
Im not too familiar with Linux, but we have a RedHat Box, that is a VM Guest on an ESX Host, that has RDM's totalling 14TB
The backups are done over the LAN - Painfully slow as you can imagine.
Im wondering what options I have in terms of trying to improve performance for this client. So far its taking close to 3 days to run.
It is on a 1GB Network, as I understand. But does anyone have any suggestions?
Thanks, Si_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
