Backup raw volumes

[brian_31]

Greetings and Good Morning!!!!

I do a fbackup for the root by this command
fbackup -f /dev/rmt/0m -i /

and i do a make_tape_recovery -x inc_entire=vg00 (for ignite backup).

I think this should cover the whole system in case of a crash (we can rebuild with this backup).

But i noticed that we have recently created a lot of raw volumes (for oracle)..How do we back them up since they are not laid out as filesystems?

Please let me know.

Thanks

Brian.

[Patrick Wallek]

For the raw volumes used by Oracle, you really need to use Oracle's RMAN utility to back them up.

There really is no other clean way to do it.

[Steven E. Protter]

Shalom,

Ignite is not the tool for backing up databases unless they are cold and shut down.

I experimented with this several years ago. I did manage to get software ag adabase raw devices from one system to another and then bring up the database.

Good backup strategy:
Use ignite for only vg00.
Use other tools for Oracle and the rest of the system.

SEP

[Hein van den Heuvel]

I largely agree with Patrick, Rman is the way to go
(or some split mirror scheme)

That said, it is perfectly reasonable to backup Oracle used raw deviced using 'dd bs=1024k if=...'
You can even feed (and eventually retrieve) the data into a pipe into gzip (or bzip2 -c or such) and get out normal files at the other end.

It'll be tedious, to get it right though.
You'll have to script the whole thing specific to your environment.
For a best chance of succes you woudl already have a carefully maintainded table describing your raw devices and usage.

The Oracle file tables are also an excellent starting point for a script... Oracle knows what it is using right?!

You would adapt a script like the one I made below, to output the DD commands directly, or the base data to have a further perl/awk/sh script generate the commands (on the fly).
You would want to generate the restore commands at the same time.
And you really really really want to test the restore, possibly on a seperate box.

For starter script, see below.
hth,
Hein van den Heuvel
HvdH Peformance Consulting

column status format a9
column file format a40
column id format 999
column type format a10

set lines 80
set pages 9999
set heading off
set FEEDBACK off
select 'Redo' "type", l.group# "Id", l.status, l.bytes/(1024*1024) "MB",
MEMBER "File" from v$logfile f, v$log l where l.group# = f.group#
union
select tablespace_name "type", FILE_ID "Id", status, bytes/(1024*1024) "MB",
file_name "File" from dba_data_files
union
select 'Temp' "type", FILE# "Id", status, bytes/(1024*1024) "MB",
name "File" from v$tempfile
union
select 'Control' "type", rownum "Id", status, 0 "MB",
name "File" from v$controlfile
order by 1,2
/

[A. Clay Stephenson]

The least evil answer is to use Oracle's RMAN utility. The only delivered UNIX command that will backup raw devices is dd. Dd can output to a tape device or to a fully cooked-file but dd is a rather lousy backup tool because there is no error recovery and there is no archive file format other than the one you build. For example, there is nothing to tell you that the raw image of /dev/rdsk/c1t2d0 (or /dev/vg05/rlvol4) is the 3rd file written to the tape. You could have a dd'ed tape that has every Oracle raw file on it as a series of files written to tape and you would have no way to identify which file is which unless your dd script also writes some sort of directory. RMAN takes care of this problem for you. Another option is to use a commercial backup such as Data Protector which can integrate with RMAN or do raw backups itself and it does know what each raw image is. In short, while dd can be made to work, you better be a very good scripter to make it work well.

[Bill Hassell · Accepted solution]

The use of raw volumes dictates a very special backup method. As Clay and others mention, you could use dd but I would put that in the category completely experimental -- never use dd for data you cannot lose. dd is not a backup program, it is just a brain-dead block copier. There is no index and nothing to prevent you from restoring to the wrong volume. Backups are like insurance -- a necessary evil but often overlooked until needed. Only then (in a panic situation) do you get to read the fine print and find out you really don't know how to recover anything.

If the Oracle data has any value at all, purchase a commercial backup program such as Data Protector. And make sure it understands Oracle raw volumes (RMAN support is a good indicator).

You are doing the correct commands (fbackup and Ignite) for file and directories, but raw data requires very careful handling. It will be your 3rd backup process.