Using BCVs with Linux for backup

[Mark Bly]

We are trying to use BCVs on an XP512 disk array to perform backups of our Oracle databases running on Linux.

We want to use the same procedure that we currently use with our HP-UX systems which is:

1. Put Database in backup mode
2. Split the BCVs
3. Re-mount the BCV on a new mount point.
4. Copy the archive logs to the BCV
5. Return the Database to normal mode
6. Take a tape backup of the BCV (using Data Protector)
7. After the backup completes unmount the BCV and resync.


The part where we can see possible problems is the remounting of the BCVs on new mount points.

How would linux see these disks?
What about headers on the disks?

Has anybody had any experience with this kind of setup?

Thanks for any help.


Mark

[morganelan]

I think the technical things are same with your HPUX system.You must export BCV mapfile and reimport them to another linux server that running backup job.

[Colin Topliss]

This is a very interesting problem.

- Are you running RH or SuSE?
- Are you just using Linux filesystems (by that I mean ext3, reiserfs etc) or LVM?

The things you need to consider:

1) How many systems are being backed up on this node?
2) If you have more than one system being backed up, are the mount points different across the nodes?

The other added pain is that if you do have more than 1 node being backed up, and you run more than one backup at a time, your drive assignments may change (unless you have implemented persistance on your FC controller) or....

you can use labels to work out where to mount a filesystem (look at e2label) - so that takes care of mounting ext2/ext3 filesystems if you don't care about drive assignments.

I just verified that this also works with reiserfs (I wasn't sure when I started writing this).....

javelin:~ # umount /distribution
javelin:~ # reiserfstune /dev/hda13
reiserfstune: Journal device has not been specified. Assuming journal is on the main device (/dev/hda13).

Current parameters:

Filesystem state: consistent

Reiserfs super block in block 16 on 0x30d of format 3.6 with standard journal
Count of blocks on the device: 5494222
Number of bitmaps: 168
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 5443261
Root block: 64777
Filesystem is clean
Tree height: 3
Hash function used to sort names: "r5"
Objectid map size 962, max 972
Journal parameters:
Device [0x0]
Magic [0x31470a22]
Size 8193 blocks (including 1 for journal header) (first block 18)
Max transaction length 1024 blocks
Max batch size 900 blocks
Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x0:
sb_version: 2
inode generation number: 13033
UUID: 54939eea-0c71-477d-916f-a35a9a9ef329
LABEL:
Set flags in SB:
ATTRIBUTES CLEAN

No label - so lets define one.....

javelin:~ # reiserfstune -l distro /dev/hda13
reiserfstune: Journal device has not been specified. Assuming journal is on the main device (/dev/hda13).

Current parameters:

Filesystem state: consistent

Reiserfs super block in block 16 on 0x30d of format 3.6 with standard journal
Count of blocks on the device: 5494222
Number of bitmaps: 168
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 5443261
Root block: 64777
Filesystem is clean
Tree height: 3
Hash function used to sort names: "r5"
Objectid map size 962, max 972
Journal parameters:
Device [0x0]
Magic [0x31470a22]
Size 8193 blocks (including 1 for journal header) (first block 18)
Max transaction length 1024 blocks
Max batch size 900 blocks
Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x0:
sb_version: 2
inode generation number: 13033
UUID: 54939eea-0c71-477d-916f-a35a9a9ef329
LABEL: distro
Set flags in SB:
ATTRIBUTES CLEAN

Your fstab entry will look like:

LABEL=distro /distribution reiserfs defaults 1 2

or you can use:
mount -L distro /distribution

So, as long as your labels are unique, you can take care or mounting your filesystems ready for a backup. You then don't really care *how* linux sees the disks!

The only issue you're going to have is if you are trying to mount the BCV onto the same system you are trying to back up.

Hope that points you in the right direction.

Col

[Mark Bly]

Closing old thread.