fbackup to copy entire filesystem question.

[Gino Castoldi_2]

Hi,

HP-UX 11.0 Oracle 8.1.7 rp5450/L2000 OVO 6.1

I am looking to backup an entire filesystem
that is 8GB in size. It contains an Oracle database so I will shutdown it down first
and perform a "cold" backup. I am thinking that 'fbackup' would be the tool to use.
(disk to disk copy onto a scratch area).

Is fbackup the right tool for this?
What would be the syntax using fbackup?

10 points to any good answer.
TIA, Gino

[Steven E. Protter · Accepted solution]

Its an excellent tool Gino.

It gets files bigger than 2 GB no problem.

Here is the syntax:

/usr/sbin/fbackup -i/fs_name -f/dev/rmt/0m

Make sure the db is down, put a sleep in the script to give it time to completely shut down.

SEP

[Rodney Hills]

fbackup is a good tool for system recovery and for backing up onto tape.

fbackup -f /scratcharea/mybackup -i /myoracle

Would back it up.

You can also pipe the output of fbackup and compress it (to save space).

fbackup -f - -i /myoracle | compress -c >/scratcharea/mybackup.Z

Other tools like "tar" and "cpio" and "pax" are popular and could be used just as well.

HTH

-- Rod Hills

[A. Clay Stephenson]

Yes, fbackup is a good tool for this as long as you don't have to worry about portability. If this is only going to be used for HP-UX to HP-UX backup and restores then that is fine.

Because it is easier to make changes, I suggest that you use a graph file:
You simply need to include the directorries that you want. In your case it's simple (at least now). I do suggest that you use relative paths as that makes restores to other locations easier.

your graph file might look like this
i ./u01
i ./u02

That would get both /u01 and /u02, assuming that yor cd'ed to / before starting fbackup

The syntax is very simple:
cd /
fbackup -f /dev/rmt/2m -g /home/acs/mygraph

You might also want to create a config file and use the -c option to include it to better tune your backup.

[Jean-Luc Oudart]

the doc
http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90742/B2355-90742_top.html&con=/hpux/onlinedocs/B2355-90742/00/00/51-con.html&toc=/hpux/onlinedocs/B2355-90742/00/00/51-toc.html&searchterms=performance%7cfbackup&queryid=20040226-110914

Regards
Jean-Luc

[Alan Turner]

Gino

If your scratch area is used for other things, then I think you have two reasonable options - fbackup, which would be reasonable, or dd, which would probably be faster. Oracle may also have its own backup utiities.

Assuming your scratch area is "/home/scratch" and your 8GB filesystem is "/odb", you could do the fbackup by:
fbackup -i /odb -f /home/scratch/oracle.fbu

To use dd, you need to know which logical volume is used for the filesystem (e.g. use bdf) then umount it and dd from the raw logical volume. If your oracle database is on, say, /dev/vg01/lvol3, then you could do:

umount /odb
dd if=/dev/vg01/rlvol3 \
of=/home/scratch/odb.dd bs=64k
mount /odb

[A. Clay Stephenson]

Actually an even better way to backup using fbackup would be to use an OnlineJFS snapshot mount. The idea is that you shutdown your database; make a snapshot mount; restart the database and then backup the snapshot mount using fbackup either to tape or a file. The beauty of this method is that your database is down for only a few minutes. The snapshot takes only seconds to create and then you have a nice safe copy for a "cold" backup while the database can be running servicing users. You umount the snapshot when finished and you are done.

[Gino Castoldi_2]

Hi,

Thank you everyone for your replies.

Clay:
I agree, some kind of snapshot/mirror/copy technology would be the way to go.
We are planning to migrate our shared disks
(we're running MC/SG) from an AUTORaid 12h to a EMC/DMX 1000 so that we can use BCV's.

10 points to any good answer.
TIA, Gino

[Steven E. Protter]

It would be interesting to see the code for an OnlineJFS snapshot backup.

We're under continuing pressure to lower the backup window.

fbackup is a great tool, which I've used frequently for database migration while re-arranging a filesystem.

SEP

[Steven E. Protter]

Does this make sense?

How to Create and Back Up a JFS Snapshot File System

1. Determine how large the snapshot file system needs to be, and create a logical volume to contain it.

1. Use bdf to assess the primary file system size and consider the following:
* Block size of the file system (1024 bytes per block by default)


* How much the data in this file system is likely to change (15 to 20% of total file system size is recommended)
For example, to determine how large to make a snapshot of lvol4, mounted on /home, examine its bdf output:

# bdf /home
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol4 40960 38121 2400 94% /home

Allowing for 20% change to this 40 MB file system, you would want to create a logical volume of 8 blocks (8 MB).

2. Use lvcreate to create a logical volume to contain the snapshot file system.

For example,

lvcreate -L 8 -n lvol1 /dev/vg02

creates an 8 MB logical volume called /dev/vg02/lvol1, which should be sufficient to contain a snapshot file system of lvol4.

See lvcreate(1M) for syntax.

2. Make a directory for the mount point of the snapshot file system.

For example,

mkdir /tmp/house

3. Make and mount the snapshot file system.

In the following example, a snapshot is taken of logical volume /dev/vg00/lvol4, contained in logical volume /dev/vg02/lvol1, and mounted on /tmp/house:

mount -F vxfs -o snapof=/dev/vg00/lvol4 \
/dev/vg02/lvol1 /tmp/house

See mount_vxfs(1M) for syntax.

4. Back up the snapshot file system with any backup utility except dump.

For example, to use tar(1) to archive the snapshot file system /tmp/house, ensuring that the files on the tape will have relative path names:

cd tmp; tar cf /dev/rmt/0m house

Alternatively, the following vxdump(1M) command backs up a snapshot file system /tmp/house, which has extent attributes:

vxdump -0 -f /dev/rmt/0m /tmp/house

SEP

[A. Clay Stephenson]

Okay Steven, here is a stripped down version
of an actual OB2 pre-exec script. This should serve as an extremely good starting point. I would not bother to create the snapshot buffer LVOL's "on the fly". Your Oracle filesystems are not going to grow much anyway so I would build them and leave them in place. I've never seen a need for a snapshot buffer to exceed 20% of original and that is extremely generous.