Re: block chg tracking
Date: Mon, 16 Feb 2015 22:09:43 +0000
Message-ID: <CAEidWqM91gcc2pi=toQRjUkzmGgedX3NQV96gdfQZCOWACqv1A_at_mail.gmail.com>
"Just don't fall into the assumption that these snapshots are also backups of the standby database!"
Haha, that's what the primary is for.
On Mon, Feb 16, 2015, 5:06 PM MARK BRINSMEAD <mark.brinsmead_at_gmail.com> wrote:
> I suppose that's valid. At least the snapshot storage is physically
> independent of the *primary* database storage.
>
> But, by your logic, the standby itself is *already* a backup of the
> primary database, so why bother with snapshots? (Mostly kidding -- I can
> see several advantages.)
>
> Just don't fall into the assumption that these snapshots are also backups
> of the standby database!
>
> On Mon, Feb 16, 2015 at 12:48 PM, Kenny Payton <k3nnyp_at_gmail.com> wrote:
>
>> I'm doing snapshots of our physical standby as backup for the primary
>> database. This is separate storage from the primary database and provides
>> the ability to do RMAN based restores/recoveries and possible switch over
>> capabilities for dire situations.
>>
>> As for retention, I do not have long term data preservation requirements
>> but you can replicate snapshots offsite if needed.
>>
>> Kenny
>>
>>
>> On Mon, Feb 16, 2015 at 12:43 PM, Jeremy Schneider <
>> jeremy.schneider_at_ardentperf.com> wrote:
>>
>>> FWIW, this is partly a terminology thing, but I get a little nervous
>>> when people talk about "snapshot-only backups". Snapshots are awesome
>>> - can be very useful as an intermediate step as you've pointed out,
>>> and can also provide quick & easy rollback points (similar to
>>> flashback database) for maintenance operations. But personally I
>>> think that it's _so_ crucial to have some kind of backup on different
>>> physical media from your primary. (Even the FRA can be on the same
>>> physical disks if you're not attentive to SAN config details!)
>>> Relying on snapshots alone for backups - even with the most
>>> bullet-proof SAN - is really dangerous...
>>>
>>> my 2c... and yeah, i know, ancient oft-beaten dead horse... but it
>>> probably never hurts to mention it once more!
>>>
>>> On Mon, Feb 16, 2015 at 10:16 AM, Mladen Gogala
>>> <dmarc-noreply_at_freelists.org> wrote:
>>> >
>>> > Every four to six hours? Full backup is usually run on daily basis.
>>> And even
>>> > every 4 to 6 hours is possible, if the backup is SAN snapshot.
>>> >
>>> > That's why a lot of attention needs to be devoted for
>>> > scheduling, unless the full backup is actually a snapshot.
>>> >
>>> > what Kenny described is not a typical solution. Kenny
>>> > described the snapshot-only solution which doesn't include long term
>>> data
>>> > preservation, like the one mandated by SOX or HIPAA. Those solutions
>>> can be
>>> > combined. Also, please note that snapshots are fast. Running a full DB
>>> > backup as snapshot every 4 to 6 hours is not a problem. Note that once
>>> you
>>> > have snapshot, copying the files to tape can be done using file system
>>> > utilities like tar, cpio or rm (if 100% compression is needed). The
>>> only
>>> > remaining problem is the one of cataloging these backups and modern
>>> backup
>>> > utilities do that for you.
>>>
>>> rm does indeed provide the best compression i've ever seen. i'd
>>> forgotten just how useful it is!
>>>
>>> --
>>> http://about.me/jeremy_schneider
>>> --
>>> http://www.freelists.org/webpage/oracle-l
>>>
>>>
>>>
>>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Feb 16 2015 - 23:09:43 CET