Best practice to backup (restore) a non-vg00 file system.

[Gino Castoldi_2]

Hi,

We are planning to extend one logical volume - file system. We are looking for the best way to backup/recover this one file system in case we need to. Since this file system in not in the /dev/vg00 volume group could we use Ignite-UX or should we use some other utility?

10 points to any good answer.
Thank you
Gino

[James R. Ferguson · Accepted solution]

Hi Gino:

Ignite is designed and intended for vg00.

Depending upon the size of files in the filesystem, you could use 'tar' or 'pax' or 'cpio'.

My choice would be to use 'fbackup' since it supports largefiles (>2GB) and has intrinsic integrity checking as a tape archive is created and later recovered (via 'frecover').

Regards!

...JRF...

[V. Nyga]

Hi,

use backup and recover from SAM - also good to recover only parts or in new directories.
(same as fbackup and frecover, but with a GUI)

Volkmar

[Mike Shilladay]

Hi Gino,

I would go with fbackup also, it is much better than tar, cpio and pax in that you have more options and has better integrity checking as James has already mentioned.

Hope that helps

Mike.

[A. Clay Stephenson]

While backing up is a good idea, you really shouldn't have to at all. Bear in mind that extending LVOL's and the filesystems housed within them is a very routine task. I have literally never had one of these operations fail and routinely do these "on the fly". In fact, my OV/O routines do this operation automatically after doing some checks. (Shrinking filesystems on the otherhand was problematic especially on older versions.)

Very few production systems can afford the downtime required to back up a filesystem, unmount it, extend the LVOL and filesystem, and remount it.

Assuming that you have a good recent backup, I would "go for it". This is one of the reasons it is so vital to have a Sandbox (or at least a test system) so that you can perfect your procedures before you have to do them "for real".

[whiteknight]

Gino,

I will still prefer fbackup/frestore solution, because it is easy of use (by commandline or SAM GUI)

WK

[Tim Nelson]

Basic:
fbackup -i /path_to_files -i path_to_more_files -f /dev/rmt/?m

more details man fbackup

[David Bellamy]

Gino if you have Data Protector you can just backup that volume group and do what ever you need to do but i agree with clay that you shouldn't have to do anything but extend the filesystem.

[Pupil_1]

For me, how to do it might depend on the size of the filesystem that i'm suspicious of losing. As Clay said, I would not bother about backing them up unless my disk are failing or I'm doing a size reduction.

If the size is small enough, a cp will be easy, if a filesystem with lot of linkfiles, then a dd or a cpio. If the size good enough to fit into a tape, then tar or fbackup. If no tape drives available, then the solution will be to have the Enterprise backup solutions to work for you.

[Bill Hassell]

fbackup uses default settings that are badly out of sync for modern tape drives, so create this config file, perhaps /etc/fbackup.cfg:

Contents of the config-file:
============================

blocksperrecord 4096
records 64
checkpointfreq 4096
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

---------------------------------------------

Example for a complete backup starting at / (root):

fbackup -i / -v -c /etc/fbackup.cfg -f /dev/rmt/0m

------------------

Display the tape header with dates:

frecover -V - -f /dev/rmt/0m

Display the table of contents:

frecover -I - -f /dev/rmt/0m

[tkc]

there is already a standard config file for fbackup for SAM. the file is /etc/sam/br/fbackup_config. you should modify this file to use a higher blocksperrecord and records parameter should you use a dlt or ultrium tape drive for fbackup with the -c option. ignite-ux is more useful for vg00 disk due to its ability to boot up on its own during recovery. i would prefer fbackup to make_tape_recovery for non-vg00 backup.