data og sånt

A few weeks ago I wrote about Oracle backups and restore/recovery. A company called “DRS” for the sake of anonymity was mentioned. They are still struggling with the (test) restore and recovery of a Windows based Oracle server.

My company has started to take a serious look at this field (cloud backups that is). We have initiated a search for a suitable partner that can provide the infrastructure needed for such services. Recent events have led us to believe that hosting infrastructure should indeed be handled by experts. By that I mean expert in every sense of the word: highly skilled/experienced  and works only/mainly with … The former is just as important as the latter. I sometimes meet people that work only with one technology/product; they automatically assume that this makes them experts.

We want to create a service for backing up Oracle databases. It will use the native backup utilities for creating local backups. These backups will be available for regular restore and recovery operations. In addition, they will be transferred (encrypted and compressed) to a remote site. The encryption key will only be available at the client site, making it safe to store backups from several customers on the same backup server.  Initially this will be a pure off-site storage solutions, future versions will have the ability to perform test restore/recovery operations at the site of the remote backup. The ultimate goal is to create a full disaster recovery solution for small and medium sized businesses.

In future posts I will describe the technical solution in more detail. Specifically; I will discuss bandwidth requirements, Oracle features needed and how to seed the backup with the help of removable media.

If you need to install some components in your Oracle database as sys, you could be in for a surprise. You can have different passwords in your password file (in $ORACLE_HOME/dbs) and inside the database. To make sure that the right one is used, perform the following using the role “sys as sysdba” in sqlplus directly on the database server:

sql> alter user sys identified by yourpasswordhere;

This problem could occur if you use the orapwd utility to create a new password for your instance *and* set it to something different than what you have inside of the database.  I have seen it several times during migrations.

I ran the test with the aws library. It works as expected. I used the tag directive, but I am not sure if that got picked up or ignored. Will research further. I have one tiny database that will get backed up to Amazon once  a week using the following syntax:

backup as compressed backupset copy of database  tag 'some_tag';

rman in the cloud.

We have started experimenting with the cloud backup module of rman (Oracle Recovery Manager). This module adds media management support for aws (Amazons Web Service), specifically the s3 storage service.

For all our databases (clients’ and our own) that run Oracle on 10g or higher we use recoverable image copies instead of backup sets (rman: backupset). We typically have one image copy set in +ASM that trails the database by n days, where n is the recovery window. In addition we have one image copy set on a filesystem (local or remote) that trails the database by less than a day (rman: until time “trunc(sysdate)”).

Our plan is to create backup sets on aws of the image copies once a week. Since the aws driver is a sbt (rman: tape) driver, there are certain restrictions. The most important is that we can only backup sets, not image copies.

According to the documentation (10gR2), the following are legal variations of the “backup … copy of …” command:

backup as copy copy of  database;
backup as backupset copy of tablespace tablespace_name;
backup as backupset copy of datafile datafile;

Based on the syntax diagrams, I am hoping I will be allowed to do:

backup as backupset copy of database;

Will let you know how it plays out.