fbackup & openactive files..with HP UX 10.20..?

[Declan Mc Kay]

Hi,
we seem to have a problem with fbackup in that our Applications need run 24Hrs/Day => we cannon shutdown to do a propper backup.. So as a result any application files which are open are only retried once and then each open file is aborted, thus creating an incomplete backup... Is there options for fbackup to retry files for n number of times before aborting or do other backup packages have better facilities...? I have heard of omiback..but know nothing about it. I would appreciate some information on this if at all possible. Note that some of the open files are D/Base files upto 700MB in size..

[Andy Monks]

by default fbackup tries 5 times to backup a file. However, it also has a size limit. See man 1M fbackup and look at the config file section.

You need to look at maxretries and retrylimit. However, if the file is still active it won't be backed up.

Omniback is a good product, however again it too doesn't like backing up open file. Now if your using Oracle, there are scripts that intergrate with Omniback to allow online backups, so that might be worth considering.

Unless the backup tool can correctly handle your specific open files, the backup isn't worth the tape it's written on.

[melvyn burnard]

fbackup can be configured to retry active or open files, see the -c option for a config file in the man page for fbackup.
I believe, however, that you would do well to start considering HP OmniBack, and suggest you start by visiting:

http://www.openview.hp.com:80/products/omnibacknt/index.asp?lvl=choose

[Bill Hassell]

The permissions and locks placed on files are classic Unix features and every backup utility that backs up files will be prevented from reading a file that has been locked for read access. The reason is simple: if the file were to be read and copied to tape, it will very likely be corrupt as portions of the file are being changed during the backup period. That's why the file(s) are read-locked.

While you could use something simple like dd to bypass the file locks, the resultant backup would be just as corrupt--indexes that point to non-existant records, broken chains, etc. And neither individual files or specific directories can be restored..only the entire physical disk could be restored with dd.

If your database vendor has no suggestions as to backuo strategy for a 24x7 app, you will have to use mirroring to perform the backup. If the database directories are not mirrored, they should be if 24x7 operation is that important. Once mirrored, add a third set of disks and triple mirror the database directories.

To perform a backup, the database must be placed in read-only mode (check with your DB vendor). If this is not possible, the database must be shutdown. Once this is complete, issue the /usr/bin/sync command at least 3 times in a row (to insure the buffer cache is cleared). Now split the 3rd disk from the other two with lvsplit. Once this is done, the database can be put back online. Total downtime = a few minutes.

Now the 3rd disk(s) must be fsck'ed (they were taken out of service in a running system), then mounted to temporary mount point(s). At this point you will have the original data still mirrored plus a 3rd copy of the data mounted at temp mountpoint(s). Backups can now be done at any time including peak hours.

Once the backup is complete, the 3rd disk is reimaged using lvmerge. This technique can be used with any size database. Note that the reimage process takes place in the background but will keep the primary disk quite busy sequentially reading all the data. Plan the reimage period accordingly.

[Kenneth Martin]

Check to see if your D/Base server allows an online export of the data. If it does that may be a solution. Export the data to a temporary directory (hopefully on a different spindle) and backup the exported data. If this does work don't forget to backup any table def's also.

[Tim Malnati]

Another relatively inexpensive method for performing backups would be by using snap disks. I much prefer mirroring technology where snaps can have a big impact on online I/O but in my mind it is far better to have some form of individual file backup than none at all (miissed files = none at all). As some have stated, most databases have some method of suspending write activity to the database. In actuality, your talking about less than two minutes to suspend things, flush the data to disk, and snap off or split off and mount the backup volumes.

[Philip Chan_1]

Hi Andy,

Correct me if I'm wrong, that 5 times retry default is only for auto backups created through SAM, and the default for "fbackup" would be something different, am I right?

For Declan, what database you're running? for example in Sybase it allows dynamic backups and I think that should be a popular feature among big name database vendors.

Regards,
Philip

[Andy Monks]

Philip.

If you run fbackup with the -c option you can specify a config file, with parameters in. Also, by default fbackup uses a builtin config file, that does the same as the default sam one.

Which btw, is pretty useless.

For performance I'd recommend changing :-

blocksperrecord 128
checkpointfreq 256
filesperfsm 2000 (although this depends on how many files you have etc)