fbackup 'not enough space'

[steve_586]

Hi,

Running fbackup and reciving :
fbackup(1105): WARNING: could not open directory /u2/dbtemp
fbackup(9999): Not enough space

This repeats for many locations yet backs up
about 70% of the system fine. I am running HPUX 11.0 and backing up on a Quantum DLT8000.
The fbackup command i am using is :
fbackup -0 -v -n -i / -g /usr/local/bin/graph -f /dev/rmt/1m

I used to run cpio on this system and managed a full backup (approx 14GB) without problem but fbackup fails. Does anyone know if this 'not enough space' refers to tape or disk or a kern param?

Any thoughts would be appreciated.

Regards

[john korterman]

Hi Steve,

it may ot be directly related to fbackup, but could be a generel resource problem; please, check your syslog for messages regarding "cannot fork" or the like.

regards,
John K.

[steve_586]

Thanks for the reply,

I checked the syslog and it is clean. I have had a look around itrc but cannot find anything related to this error. I dont want to revert back to cpio as it takes sooo long. Anything else then please fire away !

Regards

[Steven E. Protter]

Shalom,

Tape compression ratios are estimates. If you are close to tapes rated capacity and the data does not compress well, it could explain blowing the limit.

There also could be a space shortage in /var/tmp where the files may reside temporarily while being backed up.

SEP

[john korterman]

Hi again Steve,

check the use of swap space the next time you try, e.g. swapinfo -tam

regards,
John K.

[steve_586]

Thanks guys,

I dont think it is capacity, cpio runs fine and these errors i get can appear half way through the fbackup and it then continues to backup. /var is mounted and has 1GB free. I can look into increasing this and maybe able to squeeze another 500mb if you think it will make a difference. Swap has approx 850MB free at moment (17% reserve used), will try it whilst backup is run tonight. Thanks ever so for the responses so far. Please keep suggestions coming.


Regards

[john korterman]

Hi again Steve,

if you do not get any better suggestions, please try these commands the next time you see the error:
# vmstat 2 5
and check if the number in the "po" column > 0; if yes, the system is swapping.

and:
# sar -v 2 5
and check the relationship between actual use/limit for the columns proc-sz, inod-sz, and file-sz

regards,
John K.

[Nick W]

Steve,

I suspect you may be looking at a memory resource issue rather than lack of disk/tape space.
fbackup will 'walk' the filesystem tree and stores all of the filenames and pathnames in memory (the index). I think you may need to increase a kernel tunable (maxdsiz). If the data to be backed up consists of a huge number of small files and a deep directory structure too, then this is likely to exacerbate the problem.
(check also if you are using dynamic buffer cache and if yes, then check if this is still set to the default for dbc_max_pct = 50% - tuning this down may also help)

Also, there are various ITRC KB docs which describe how to tune fbackup (eg blocksperrecord, readerprocesses, checkpointfreq) and also check you have the latest fbackup/frecover patches too.

Hope this helps

Regards,
Nick 'dubya'

[steve_586]

Hi John,

Tried them today and all seemed well within range. I tried to restore from the backup and got malloc errors so decided to give something else a try. Ftio is now running and has done so for the last few hours, without failure. As soon as this has backed up and verifyied i will try a test restore. If all ok i will stick with ftio. Hate to leave something unsolved like this but i gotta get a good few days of clean backups, if anyone has suggestions in the mean while then please reply.
Thanks for taking the time guys.