Operating System - HP-UX
1753518 Members
5029 Online
108795 Solutions
New Discussion юеВ

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

 
SOLVED
Go to solution
Gino Castoldi_2
Honored Contributor

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

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
10 REPLIES 10
James R. Ferguson
Acclaimed Contributor
Solution

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

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
Honored Contributor

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

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
*** Say 'Thanks' with Kudos ***
Mike Shilladay
Esteemed Contributor

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

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
Acclaimed Contributor

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

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".

If it ain't broke, I can fix that.
whiteknight
Honored Contributor

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


Gino,

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

WK
Problem never ends, you must know how to fix it
Tim Nelson
Honored Contributor

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

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

more details man fbackup

David Bellamy
Respected Contributor

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

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
Trusted Contributor

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

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.
There is always something new to learn everyday !!
Bill Hassell
Honored Contributor

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

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



Bill Hassell, sysadmin