Some notes about Oracle Backup with Veeam

Veeam introduced the oracle backup feature with version 9 and a lot of people are very excited about this, because oracle backups were one of the last bastions for the  “old guard” of enterprise backup products.

I was facing a bit of a problem here, since Oracle DB are definitively not my turf but now it is expected that I should be able to handle those in a backup/recovery case.

So, the goal of this post is to establish some basic concepts about oracles DBMS and share some notes how Veeam backup behaves when backing up oracle databases (perhaps this might interest folks who can compare this to RMAN).  Feel free to correct me, as stated above this is not my usual business.



Taken directly from the Veeam documentation center, these are the requirements for enabling log shipping.

  • Veeam Backup & Replication supports archived logs backup and restore for Oracle database version 11 and later. The Oracle database may run on a Microsoft Windows VM or Linux VM.
  • Automatic Storage Management (ASM) is supported for Oracle 11 and later.
  • Oracle Express Databases are supported if running on Microsoft Windows machines only.
  • The database must run in the ARCHIVELOG mode.

So, that is that for version requirements – OK, but what is an archive log?

Oracle Logging

Redo Logs

Knowing the usual pieces  MSSQL I am familiar with transaction logs, but within oracle these are called “redo logs”. Unlike the t-log, you need to have at least two redo logs (quotes are from the oracle DB manual):

The redo log of a database consists of two or more redo log files. The database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived.

Of these (at least two, more likely three) only one is written into:

LGWR (log writer) writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again.

Notice that all logs will be overwritten at some point in time, i.e. when the log files are filled up. This would be more like the SIMPLE log model in MSSQL.

And finally some nomenclature to distinguish those logs who are being written to and those that are currently not in use:

Oracle Database uses only one redo log files at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current redo log file.

Redo log files that are required for instance recovery are called active redo log files. Redo log files that are no longer required for instance recovery are called inactive redo log files.

Archived Redo Logs

I stated that we will lose the content of the logs at some point in time, the solution for keeping the logs is the ARCHIVELOG mode.

An archive log is an “archived redo log” and it will lead to us the equivalent of a FULL recovery model in MSSQL.

I am borrowing the following explanation from Oracle Terminology for the SQL Server DBA

These are redo log files that have been backed up. There are a number of ways to have Oracle automatically manage creating backups of redo log files that vary from manual to completely automated.

If the disks storing these files fills up, Oracle will not be able to write to the data files – active redo log files can’t be archived any more. To ensure safety, writes are stopped.

The last paragraph is an important one, we will come back to this later on.



Veeam with Oracle backup


At this point I will trust that you know how to setup a Veeam job, perhaps I find time to add this more basic stuff later on.

Most people will use a 24 hour image backup schedule for their VMs.  For reduction of RPO you would implement the “log shipping” within the application aware backup tab.

Note 1: Veeam does not use RMAN (Recovery Manager) but rather the Oracle Call Interface (OCI).

Note 2: Veeam will only delete log files will the next image backup (full or incremental), not with the log shipping.

Note 3: Veeam doesn’t delete empty log folders after clearing *.arc files

Note 4: Veeam will issue a (global) log switch as part of the backup. This archives all online redo log files, meaning that you need space on your archive log partition.

So, with note 4 in mind, image a situation where  your archive partition is quite full and you want a backup to clear it up. This might actually lead to more used space before anything can be cleared up. Also, you cannot use Veeam to clear up an already full partition. Right now, there doesn’t seem to be an option to change this.

Note 5: Behavior of Delete logs older than <N> hours or Delete logs over <N> GB may not be so obvious.

First, this will only take effect when you run a full/incremental backup (see note 2). If you let the default “delete after 24 hours” and make an image backup once a day, then you will always have nearly two days worth of logs on your disk: The last day and the current logs.