fbackup files to the disk & than to the tape

[Petr Simik_1]

Hello,

Do you know how to copy /dir/file -> /dev/rmt/tape and keep format of fbackup ???



till now we did fbackup to the tape using this cmd: fbackup -f /dev/rmt/0m -0vi /

now we cannot let system to be down during fbackup and we are looking for procedure how to do that and minimize downtime.

We want to do fbackup to diskfile
cmd: fbackup -f /dir/file -0vi /

and than copy this file to the tape

Do you know how to copy /dir/file -> /dev/rmt/tape and keep format of fbackup ???

[Leif Halvarsson_2 · Accepted solution]

Hi,
There is no support for disk backup in fbackup.

Maybe cpio is an alternative, or better , Data Protector.

[Petr Simik_1]

Yes CPIO may work
what would be the syntax to copy file from disk to tape by cpio??

[Petr Simik_1]

I tried
#echo /tmp/filename | cpio -o > /dev/rmt/0m

but when I try
#frecover -r -f /dev/rmt/0m -N -v

than ERROR:
frecover(2105): did not find expected file marker
frecover(5419): checksum on volume header is incorrect.
frecover(5420): not an fbackup volume; magic value is incorrect
frecover(2105): did not find expected file marker
frecover(5412): Do you wish to try to salvage this volume? (^[yY]/^[nN]) frecover(4302): frecover interrupted, continue? (^[yY

[Steve Steel]

Hi

You would need to cpio it back to disk and then use frecover on the disk file

It just wont work otherwise since the tape is not in fbackup format


Steve Steel

[Steven E. Protter]

It has to be a two step process.

1) Script copies files to disk, perhaps even compresses it.
2) Then have fbackup back up the chesen location.

SEP

[Petr Simik_1]

is there any way how to create fbackup format tape as copy of fbackup_file??

The same thing must be usedin case of duplicating Fbackup ??

We need to have fbackup format tape because of vendor support - in case of emergency they can ask us for that.

I thought about somethning like:

frecover to stdout | fbackup from stdin


????

[D Anderton]

Do you need your application/database to be closed for a cold backup ?

If you need a cold backup the best way to minimise downtime is to either create a mirror or snapshot of the areas which will have open data. This will require either mirrordisk/ux or online jfs.

1. Create mirror.
2. Shutdown app/db
3. Split mirror (takes seconds)
4. Start app/db
5. fsck and mount split lvol(s)
6. Perform backup using split lvol

If insufficient space/disks for mirror investigate using snapshots. I use both methods on site.

You can reduce backup times by also performing a backup of just your data, backup the OS areas at a different time.

To copy fbackup disk file to tape use dd i.e. dd bs=16k if=/dir/file of=/dev/rmt/xm

By default fbackup uses 16k blocksize ensure dd uses the same blocksize.

Example recovery :

dd bs=16k if=/dev/rmt/xm | frecover -r -f -

Good luck.

[Michael Schulte zur Sur]

Hi,

Why do you want to bribg the system down?
have you tried using -I /dir/file
?

greetings,

Michael

[Petr Simik_1]

thank u.
-Split of mirror is good idea - might work - I am going to check it.

-Snapshot - we cannot use this vendor doesn't allow any further instalation to this server.

- I don't need to send system down - I just need consistent fbackup apps (probably need be stopped). Fbackup format is important because it is only supported by vendor.

- Recovery dd bs=16k if=/dev/rmt/xm | frecover -r -f - this recovery works but in case I have really huge file than in case that I need to recover only small amount of data I need to load whole file from the tape.


Our idea was to perform fbackup to disk and than to the tape.

I read that fbackup is using ftio this might work?

[Petr Simik_1]

thank U boys I still didn't find my solution,
but thank U for nice advices.
If you know any other TIP just send it here I keep watchin this thread and any other tips.

[D Anderton]

Sorry my mistake if you copy the fbackup file to tape using :

dd bs=16k if=/dir/file of=/dev/rmt/xm

frecover should be able to read it back no need to perform a pipe from dd !!

The key is to ensure that the block size is the same on dd as that that fbackup uses (16k as default). Only need to use dd with frecover if the block size was not the same.

So :

fbackup to disk
dd to tape
frecover for recovery...

G

[Bernhard Mueller]

Petr,

if you want to *significantly* reduce downtime this way then you have to do it through any way of a snapshot or split mirror copy.

Any other method means that you actually read and write all the data. If this copy goes to a disk you may be a little faster than in writing to tape but not in the order of magnitudes. If you have a slow disk it will give you less write performance than an LTO2 tape drive...

So for copying data (disregarding DataProtector etc) your best choices in terms of performance are dd or vxdump.

If you have relatively full filesystems or filesystems with tens of thousands of files try
dd if=/dev/vgorig/rlvol# of=/dev/vgbackup/rlvol# bs=1024k
(vgbackup lvol needs to be eqaul size or larger than vgorig lvol)
or for relatively empty filesystems try
vxdump -0 -f - -b 16 /orig_mountpoint | (cd /backup_mounpoint ; vxrestore rf -)

Regards,
Bernhard

[Petr Simik_1]

good ,
this is exactrly what I am looking for now
but it doesn't work

[Michael Schulte zur Sur]

Hi,

could you please specify what is still missing/not working?

greetings,

Michael

[Bill Hassell]

fbackup (unlike cpio, tar, dump, etc) know the difference between tape drives and non-tape destinations. When the destination specified in fbackup is either a file or stdout, fbackup can no longer control the tape and write setmarks. So the format of the file, while acceptable to frecover, cannot be simply copied to a tape. You might be able to use a pipe to feed into frecover, something like this:

cat /dev/rmt/0m | frecover -f -

The - represents stdin so frecover will not try to manipulate the non-existant tape. But as a production technique, I'd never try it. Too much risk, extremely slow restore times and too many ways to make a mistake.

[Petr Simik_1]

This is what I did and didn't work.
Otherwise - thank you for other ideas and explanations.This may be is not a way how to do that.:

host1b:/tmp/eurotel#fbackup -i /tmp/mf -f /tmp/fbackup_file
fbackup(1004): session begins on Fri Nov 5 09:37:18 2004
fbackup(3024): writing volume 1 to the output file /tmp/fbackup_file
fbackup(3055): total file blocks read for backup: 134
fbackup(3056): total blocks written to output file /tmp/fbackup_file: 164
host1b:/tmp/eurotel#frecover -r -f /tmp/fbackup_file -N -v
drwxr-xr-x root root /
drwxrwxrwt bin bin /tmp
drwxr-xr-x root sys /tmp/mf
-r-xr-xr-x root sys /tmp/mf/ls
-rw-r--r-- root sys /tmp/mf/syslog.log
host1b:/tmp/eurotel#dd bs=16k if=/tmp/fbackup_file of=/dev/rmt/0m
5+1 records in
5+1 records out
host1b:/tmp/eurotel#frecover -r -f /dev/rmt/0m -N -v
frecover(2105): did not find expected file marker
frecover(5419): checksum on volume header is incorrect.
frecover(5420): not an fbackup volume; magic value is incorrect
frecover(2105): did not find expected file marker
frecover(5412): Do you wish to try to salvage this volume? (^[yY]/^[nN]) frecover(4302): frecover interrupted, continue? (^[yY]/^[nN])

[D Anderton]

Your right sorry.

It does work with the pipe :

TALSMS1:/#fbackup -i /sysinfo -f /tmp/file_out
fbackup(1004): session begins on Fri Nov 5 10:30:19 2004
fbackup(3024): writing volume 1 to the output file /tmp/file_out
fbackup(3055): total file blocks read for backup: 77685
fbackup(3056): total blocks written to output file /tmp/file_out: 78116
TALSMS1:/#dd bs=16k if=/tmp/file_out of=/dev/rmt/0m
2441+1 records in
2441+1 records out
TALSMS1:/#dd bs=16k if=/dev/rmt/0m | frecover -rNv -f -
drwxr-xr-x root root /
drwxrwxrwx root root /sysinfo
etc..etc..

So if you could keep the previous night on disk for 24hrs aswell as copying it to tape, your disk copy will resolve the fast recovery issue for any file required from the previous day..

Hopefully a workable solution.

[Petr Simik_1]

Damian,
yes dd | frecover works, but than it has to load whole file and than do the recovery which takes much more time than frecover only.