Simpler Navigation coming for Servers and Operating Systems
Coming soon: a much simpler Servers and Operating Systems section of the Community. We will combine many of the older boards, and you won't have to click through so many levels to get at the information you need. If you are looking for an older board and do not find it, check the consolidated boards, as the posts are still there.
Showing results for 
Search instead for 
Did you mean: 

fbackup warning after backup

Go to solution
Wilbert Jeuken_1
Occasional Advisor

fbackup warning after backup

We've created a backup of HP-UX 11.31 server using the following command:

fbackup –f /dev/rmt/0m –g /var/adm/fbackupfiles/server.backup.list.txt –I /var/adm/fbackupfiles/index

This writes a lot of files to tape and creates an index file of the files that have been backed up.
The execution also gives warnings like this one:

fbackup(3005): WARNING: file number 145103 was NOT backed up

How can I see what file this is? It would have been easier if fbackup would just state the file it has a problem with instead of a number.
Steven E. Protter
Exalted Contributor

Re: fbackup warning after backup


145103 may be a refernece to the file list which is written to /var/tmp/index

Check there first.

fbackup can not get good copies of open databases and such and should not be used for backing them ups.

Steven E Protter
Owner of ISN Corporation
Dennis Handly
Acclaimed Contributor

Re: fbackup warning after backup

>SEP: 145103 may be a reference to the file list

If SEP's suggestion doesn't work, it may be the inode number of the file?:
find list-of-filesystems -inum 145103
Wilbert Jeuken_1
Occasional Advisor

Re: fbackup warning after backup

The inode number could be the right one.

Can I just add the suffix "> /var/adm/fbackupfiles/fbackup.log" to create a logfile of the fbackup run? We could the schedule the command and check the logfile afterwards for any errors or warnings.
Honored Contributor

Re: fbackup warning after backup

> fbackup(3005): WARNING: file number 145103 was NOT backed up

The WARNING lines go in pairs, right above the WARNING that you showed us above, there is another warning line that tells you something like

fbackup(1102): WARNING: unable to stat file

That's the file that was not backed up.

The number is NOT an inode number neither in the index file. (The numbers in the index file are file sizes in number of blocks).

Yes you should add a log file. That's where you will find the number 145103.
Wilbert Jeuken_1
Occasional Advisor

Re: fbackup warning after backup

@TTr: Thanks, this seems to be the resolution. We have a lot of "stat" messages first, and then al lot of "not backed up" messages. They do not appear neatly in pairs, but the messages are are equal in numbers.

Am I right in my assumption that the addition of "> /var/adm/fbackupfiles/fbackup.log" to the fbackup command line will result in a logfile called fbackup.log?

Also, what do the "stat" messages meam? There are other files that are in use at the time of the backup, and these seem to be backed up just fine.
Honored Contributor

Re: fbackup warning after backup

Yes, that's how you add a log file, with the output redirect. But you have to add the "-v" option in fbackup as well.

The "stat" message comes from a system call by the same name and it means that it could not get a status of the file either because the file does not exist or there is a permissions issue.

When fbackup starts up it creates a list of all the files that need to be backed up based on your include list or graph file. By the time it gets to some of the files, they may have been deleted. That's when you get the warnings. This is most of the time normal with temp files that are created and soon after are deleted by running processes.
Honored Contributor

Re: fbackup warning after backup

Actually for the log file, if you run fbackup by itself you need to add output device redirects as well as in

... > /var/adm/fbackupfiles/fbackup.log 2>&1

If you run fbackup in a script, > /var/adm/fbackupfiles/fbackup log is sufficient but it is always a good practice to add error device redirect.