Re: RMAN backup validate
- From: MARK BRINSMEAD <mark.brinsmead@xxxxxxxxx>
- To: dmarc-noreply@xxxxxxxxxxxxx
- Date: Sun, 15 Mar 2015 16:29:43 -0400
Interesting. I never considered the possible loss of a deduplication
database. (Its not something I have so far had to worry about.)
My concern had more to do with the elimination of duplicate blocks of data,
even though you might *really* want duplicates, sometimes.
A lot of people rely on the self-redundancy of database backups. If, for
some reason, you cannot restore from the backup you made last Sunday, you
have the option of restoring the the backup made the *previous* Sunday, and
rolling forward either with incrementals or archivelogs.
If the backups are stored on a de-duped array, though, and something
happens in the storage layer to invalidate one backup (e.g., loss of a
disk, firmware error, etc.) it could very well invalidate ALL backups by
destroying a block of data that is common to all of them.
Management loves "de-dupe" technology, because it can save a pile of
money. (Much like, in the early days of SAN storage, managers used to love
"RAID-5" and often could not be convinced that sometimes "RAID-1" might be
a better idea for performance reasons.) Just about anywhere we find a
saving in one dimension though, there is usually a cost, often a hidden
one, in some other dimension.
Anyway, I guess I will add dedupe-databases to my mental list of "things I
probably need to worry about some day". Thanks. I think.
---
Dedupe aside, my concern about SNAPSHOTS was not isolated to loss of an
entire disk array. (This is, of course, something that any backup strategy
must account for -- storing your database and all your backups on the same
array is just not sane.)
What I was mainly thinking of was loss of physical storage devices. For
example, physical corruption of a data block or loss of two or more disk
drives before resilvering can take place (the latter is more likely to be a
problem). If your "backups" are snapshots, they will very probably NOT
contain every block of data from the original. When an "original" block is
lost due to media failure, there is an excellent chance that all the
backups will be damaged too.
THIS is why I say you need to make a copy of your snapshots (or, as Mladen
suggests, mount an alternate database instance using the snapshot storage,
and back up to tape with RMAN). In most cases (but not necessarily all), a
"snapshot" is NOT a backup. Not until you write it someplace else.
On Sun, Mar 15, 2015 at 1:12 AM, Mladen Gogala <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
>
> On 03/15/2015 12:13 AM, MARK BRINSMEAD wrote:
>
> Hmmm.
>
>
> Yes, that is of course true. If the original array is lost, as some were
> during the hurricane Sandy, all the snapshots will also be lost, unless
> copied to a different array.. As for the deduplication databases (aka DDB),
> those are usually local to SAN, as relying on the remote DDB would be both
> too slow and unreliable. Most of the modern DDB vendors like CommVault,
> EMC, NetApp or Quantum require local SSD to be used for DDB. However. if
> the local DDB does get corrupted, then there is trouble and the
> deduplicated backups will likely be unusable. I don't know about other
> manufacturers, but Commvault does provide both backup and recovery for
> deduplication databases. I have never seen a backup being unusable because
> of deduplication database being lost.
> Details like that are private property of each vendor. Details about
> Commvault deduplication are available on
> http://documentation.commvault.com. If someone is interested, this would
> be a good place to start:
>
> http://documentation.commvault.com/commvault/v10/article?p=features/deduplication/c_deduplication_overview.htm
>
> --
> Mladen Gogala
> Oracle DBAhttp://mgogala.freehostia.com
>
>
Other related posts:
