veeam backup oracle db in a vm is easy and reliable way to protect data
TRANSCRIPT
Aleks Yemets
Veeam SE
Oracle DB in a VM:easy and reliable way to protect your datawith Veeam B&R
test 1
• A bit of theory: Oracle’s self-protection
• Crash-consistent consistent?
• Universal solution – our backup+their logs• Backup process
• Recovery scenarios
• BUT, there are a few "buts"- ASM, pRDM, mnode RAC (?)• Instant recovery – no way…
• Classic DB recovery – yes, indeed…
User
Process
DDL/DML,
Result
Sets
Oracle Server
Process
Database Buffer Cache
(Blocks being used in memory)
Database
writer
Datafiles
BlocksChanged Blocks
(Dirty Buffers)
Oracle Server
Process
Log Buffer
Log Writer
Online Redo
Log Files
Archiver
Archived Redo
Log Files
Control FilesCheckpoint
Red
o stre
am
–Tra
nsa
ction In
form
atio
n
Checkpoint
SCN
Checkpoint
SCN
• At each commit
• Every three seconds
• When the redo log buffer is one-third full
• Oracle uses write-ahead protocol• Any changes are written to Log Buffer
• The Log Writer writes to the online redo files under the following circumstances:
• redo log is cyclically overwritten
• Oracle uses write-ahead protocol• Any changes are written to Log Buffer
• The Log Writer writes to the online redo files under the following circumstances:
• redo log is cyclically overwritten
• DB in archivelog mode archives redo log
• archive logs allow to recover DB to any needed
point in time
• In archivelog mode you can backup whole DB in any of the following ways: • Closed and consistent
• Closed and inconsistent
• Open and inconsistent
The ability to back up a database while it is open and in use is a key benefit of running adatabase in archivelog mode.
&
• Snapshots are OK!
Oracle will officially support the Snapshot Backup and Recovery operations assuming that the third party snapshot technology can meet the prerequisites listed below• If a point-in-time copy of the database is required, the snapshot must
contain all the data files, control files and online redo logs.• If full (i.e. zero data loss) recovery is required, the snapshot must
contain only the data files or have the ability to restore only the data files.
For detailed information refer to Metalink Note 604683.1
Crash-consistent consistent?
• Begin/End backup database vs Crash-consistent• With Begin/End backup
• Stops updating datafile headers
• Duplicates datafile block writes to redo log
Then
• Snapshot whole VM…. redo log writes stopped
• Crash-consistent snapshot • Just snapshot whole VM
- By definition, an online backup is always inconsistent.
Pros for VM: Begin/End backup can affect DB only in “physical” world –
backup(copying) takes a datafile offline for a long period of time
In virtual world – do not affect DB – datafile offline period is very short
RMAN – differense and benefits only on “physics”
• RMAN is to backup online DB
• Doesn’t stop updates to datafile headers• Backs up data up to last fixed SCN
• redo log is not overloaded
Is it a datafile
snapshot at Oracle
DB level?...
• Regular backup with fixed RPO• Veeam VM backup w/o interacting with Oracle DB
• Veeam VM backup with interacting with Oracle DB• Switch current redo log
• Optional – switch DB to hotbackup mode
• Backup for Point-in-Time zero dataloss recovery• Veeam VM backup with/without interacting with Oracle DB
• Sparately backup/mirror the following• Current Control File
• Redo/archive log
• Recovery with fixed RPO
Original:
• data files
• control files
• online redo logs
Backups –
Restore points
Recovered VM:
• data files
• control files
• online redo logs
• Backup for Point-in-Time zero dataloss recovery
Original :
• data files
• control files
• online redo logs
Backups –
Recovery points
Recovered VM:
• data files
• control files
• online redo logs
• control files
• online redo logs
• arch redo logs
Restore
database
Restore/mount
• control files
• logs
• arch logs
Recover
database
• No snapshots – no backups (Veeam point of view, and others)
• No instant recovery available
• Classic approach to backup needed:• Separate OS backup
• Separate DB backup
• Classic recovery – big(long) RTO……..