Incrementally Updated Image File Backup Multiple Locations

backuporacleoracle-11g-r2

With an Incrementally Updated Image File Backup the same script handles both the initial image backups, and the incremental backups that can be applied to the images to bring them up to date. Is there a way to change a parameter or modify this script so that the image files get created in one location and the incrementals get created in another?

A partial solution is to do the inital image file backups, move them to the alternate location and then re-catalog them there. The next run will then create the incremental backup in the original location, but update the image files in the new location. The problem comes when a new datafile is created. The backup will recognize that it doesn't have an image for it and create one, but in the same location as the incrementals. Aside from repeating the move and re-catalog is there a way to have things happen as desired from the start?

If you're wondering why this would be useful, consider that the image backup volume could be snapped and cloned to a new volume on another server for fast refreshes of lower environments. Having the incrementals and images in separate locations reduces the space requirements for the snap/clone.

Backup Command:

BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'MyImageBackup' DATABASE;

Best Answer

No, it is not possible to have this single backup command do the level 0 to a different location than the level 1. It is possible to change the script to determine which files don't have level zero backups and do a separate backup just for those datafiles before running the existing command to the incremental location.

Related Solutions

Oracle – Why Backup Archive Logs Along with Datafiles?

No, you still need archived redo logs. An RMAN backup is not the same as a cold backup; when you restore it you need to apply all the redo generated from the time you started the backup until the time the backup completed in order to get the SCN consistent across all the datafiles and the controlfile.

Let us consider the old fashioned hot backup. In this mode, entire changed database blocks are written to the redo log stream, and the file is copied in the OS. This causes fractured blocks, i.e. the block has changed during the read by the backup. So to recover the database, we restore the DBFs, then the recovery process overlays the changed blocks from the archived redo logs onto the fractured blocks in the file, and we get back to a consistent database.

In an RMAN backup the problem of fractured blocks is eliminated because the blocks are read by Oracle via the SGA not by a Unix tool like cp. However the DBF changes between the time the first block is read and the last block, so it is the same problem, just at a larger scale. That is to say, the SCN changes between the first and last blocks in a backup. The archived redo logs cover this as well.

RMAN gives you the manageability of the catalog, and a means to do hot backups without needing to generate redo at a much higher rate (which puts its own stress on the disks, the backup system etc). However BACKUP DATABASE will not give you a consistent database in and of itself; the only way to do that in Oracle is the cold backup.

Rman not replacing logs with same name on networked drive

If logging with RMAN, you'd have to set the filename yourself - there's no wildcard. But there is an APPEND option.

spool log to 'my_log_file' append

Similarly, invoking RMAN with the APPEND option causes it to append to any log file specified.

Our backup scripts do the log maintenance at the OS level:

export LOGPREFIX=$ORACLE_ADMIN/$ORACLE_SID/rman/log/my_backup_script
export MYLOG=${LOGPREFIX}.$$   # add the pid to the log file name
rman log=${MYLOG} append <<EOF
... various RMAN commands
EOF

#Perform error checking and notification
fgrep -i RMAN- ${MYLOG}
if [ $? -eq 0 ]
then # we had a failure - email me
   mail -s "$0 : failure for `date +%m/%d/%y`" me@myself_and_i.com < ${MYLOG}
fi
# add the incremental log to the permanent log
cat ${MYLOG} >> ${LOGPREFIX}.log
# clean up the incremental log
/bin/rm -f ${MYLOG}

Related Question