I have recently taken over our backups and have realized that a specific group keeps failing for the following error:
"Warning inode number changed for /filesystem/directory may not be recoverable."
It runs through the whole save set and will not back up anything when it hits this condition. At first I thought it might be because it is a raid filesystem, but we have another identical system that is backing up just fine. I tried comparing the configs between the two systems to see if there is any difference but did not find anything. I also have run a fsck on this filesystem to fix any possible corruption.
Any suggestions on what might be causing this or how to get around it?
This might be because the file in question keeps changing during backups. Try to find what that file is and confirm if you even need it backed up. Moreover this looks more of a warning and not an error, so get get any other message after this warning, try running a manual backup of the saveset in question to narrow things down.
I can confirm that the files in question do need to be backed up and I do know which ones are not getting backed up. I tail the logs during the backup and as the backup runs, it steps through the files and each one received the inode warning. You are correct, it is a warning and the backup completes with a successful status but none of the files are backed-up that receive the inode warning. The same things happen whether it is run via a scheduled backup or manual backup (either the save cli or Networker GUI). I have also run a recover on the client and verified that the data does not exist to recover.
So is it normal for the file to not be backed up if an inode warning is received? Looking through the savesets on the current tapes, this save group has not successfully backed up this data in many months due to the inode errors. Is there a way in the Networker database to clean up all references for this save group and start with a clean backup? Not sure if this will help or not.
The file is open and is access by a different application, thus the file is locked and cannot be accessed by the backup application. By the way what would you do with a log file anyway. i don't it is useful to get the application up, which application do these log files belong to ?
I am not sure of your question about the logs. These are not logs we are backing up--just flat data files. As for logs I referenced, they are the nsr logs. Are there other ones that can be looked at?
so these files belong to a database ? if so you need to skip them from filesystem backup and use an appropriate module to take a backup of the database.