This post is more than 5 years old
16 Posts
0
1998
June 14th, 2010 05:00
Networker ignoring files
Hi,
We are using 7.4.4 on Solaris 9 and currently backing up a windos 2003 server with some application
which is using a logs folder under the E:\ drive with plenty of .log extension files
There are some files which are being accessed as the modified date is always changing but other log files which are not changing therefore I assume not accessed are being ignored for backup.
Is there any reason why the log files which are not being constantly accessed are being ignored shouldnt Networker at least back these up?
thanks
events found
No Events found!
ble1
6 Operator
•
14.4K Posts
•
56.2K Points
0
June 16th, 2010 08:00
No, I think error in creating No such file or directory you will elsewhere too... it is not related (at least I think so as I have seen that message elsewhere). From what I see, there is no reason not to backup this file. E:\Configuration Manager\Logs\WCM.log looks legimit. But, let's for a moment assume this is VSS related. If you try save with -o option where you disable VSS does it work then?
ble1
6 Operator
•
14.4K Posts
•
56.2K Points
0
June 14th, 2010 05:00
You might have a directive which skips it.
shaha2
16 Posts
0
June 14th, 2010 07:00
no nothing like that theres no directive
I did a save -i to ignore them but still nothing
ble1
6 Operator
•
14.4K Posts
•
56.2K Points
0
June 14th, 2010 07:00
Well, let's try simple approach.
Go to client...go to CLI, and do save for one such file which you know is not being backed up. No debug or anything. Then verify with nsrinfo if this file has been backed up (something like nsrinfo | grep on backup server will do). If you don't see it in index, verify with mminfo if it is saved. If yes, then try to do ssid restore to some temp dest. If that works, it might indicate this gets saved somewhere else (even I can't see the reason why that would be the case for specific file if this is part of local file system - I assume no cluster, right?).
If, log file is not saved at all, then rerun save command, but this time with debug 9 and see what does it say.
Since I assume you save whole E drive I would suggest to run save on client in very same way for easier comparing and troubleshooting.
shaha2
16 Posts
0
June 16th, 2010 03:00
yes no cluster
I have tried saving the file individually with no luck nothing gets saved to confirm there is nothing in the index.
I did a D9 on a using manual save from the client with one for the files and the full txt file is attached.
Seems like a problem with VSS it seems to start when the backup starts and the snaps get created but the file does not backup
The errors seems to be "There was an error in creating the file: "No such file or directory"
More details in the D9 output attached
...
Abid
1 Attachment
euwatsrv15.txt
shaha2
16 Posts
0
June 17th, 2010 03:00
looks like turning off VSS worked!
Attached is the D9 save file
UKSSQBAK02:/ > nsrinfo euwatsrv15 | grep -i WCM.log
E:\Configuration Manager\Logs\WCM.log, date=1276769447 Thu Jun 17 11:10:47 2010
Is there any way we can troubleshooting the problem with VSS...
thanks
Abid
1 Attachment
euwatsrv15_VSS_OFF.txt
ble1
6 Operator
•
14.4K Posts
•
56.2K Points
0
June 18th, 2010 01:00
Probably there is, but I have no idea at the moment how. One thing that can be the case here is the fact that those files are recognized to be handled by some other writer and other type of backup (for example not as part of C backup, but some system * saveset, but I doubt it to be honest). At this point it looks as if the issue is with VSS writer, but why doesn't look to be that obvious.
jkernagh
35 Posts
0
June 18th, 2010 16:00
Good chance it's a file registered with a VSS writer; we don't backup files twice, so a file backed up by, say, the DFS Replication Writer is NOT backed up at a filesystem level. Looks like these .logs are that sort of animal.
You can run the CLI save -vvvvv -D9 and see if you can find the filename, with a corresponding 'invoking internal skip asm' line (or somesuch) telling you, 'I found the file but I'm skipping it because of x'.
You can then run save -vvvvv -D9 against the VSS savesets, and check those logs for your 'skipped' file - you'll probably find it in one of the SYSTEM savesets.
HTH, James.
ble1
6 Operator
•
14.4K Posts
•
56.2K Points
0
June 23rd, 2010 00:00
I would agree with James, but there is a possible catch. I assume here, but I guess before during backups, nsrinfo was run against whole index and not just nsavetime for saveset. In such case, you would expect to see the file reported even if picked up by one of VSS savesets. Of course, based on previously stated assumption...