Unsolved
This post is more than 5 years old
2 Intern
•
14.3K Posts
1
2382
Restore doesn't work because backups just ignore the files...?
Of course your restore won't work if backup is not. However, in my case backup does not fail - it just won't backup specific files. Here is the situation: we use Honeywell Uniformance PHDServer which has its own structure and one of the most important folders is called - Archive. So, imagine structure like this:
E:\Uniformance\PHDServer\Archive and some idx and dat files inside. Now, one usually does scheduled backup and get's all green and forgets about it. So did I. Then restore request came today since disk failed and everything was restored except content of this Archive folder.
I checked mminfo and size of E drive was rather small so I was quite sure I never backed up this. Then I checked another host with same setup and found that data is there, but not backed up under E save set. So, I thought, it must be some VSS SYSTEM saveset and did nsrinfo search - but it is not there at all. Great, so we have everything except perhaps most important data on the box. Let's do manual backup... guess what:
E:\Uniformance\PHDServer\Archive>save -s SERVER -b POOL SCAN00001.dat
save: E:\Uniformance\PHDServer\Archive\SCAN00001.dat 0 KB 00:00:32 0 files
7167:save: save completion time: 15-2-2013 16:37:09
Above file is 4GB - but bloody thing will always finish soon with 0KB saved. Why!? So, I did -D9 - but I do not see anything inside to ring the bell. There is no directive assigned to this host, client side or server side, nothing. It's funny, when you go to GUI and you select file it starts to run, asks for pool and then says - 0KB saved. Before you ask, this is local disk data - no DFS or any other mumbo jumbo.
I did however another test which is also sort of interesting:
- created E:\H folder and copied SCAN00001.dat file there
- backup process against E:\H\SCAN00001.dat works fine
- created folder Archive and moved SCAN00001.dat to that folder
- backup process against E:\H\Archive\SCAN00001.dat works fine
- created folder PHDServer and moved Archive to that folder
- backup process against E:\H\PHDServer\Archive\SCAN00001.dat works fine
- created folder Unifomance and moved PHDServer to that folder
- backup process against E:\H\Uniformance\PHDServer\Archive\SCAN00001.dat works fine
So, from here I see 3 possible outcomes:
- there is some wierd registry setting which instructs these files not to be backed up ever - not sure if such thing exists in first place and I certainly do not see it from debug CLI log
- there is exotic and exclusive lock on files breaking VSS/save the way it does - not sure only why Explorer is able to copy the file without any issues
- there is a bug with software - namely NetWorker
It might be something else, but this little thing took my afternoon and most likely will take away rest of the weekend. Did anyone had experience with events like this before or has some starting point to check against? The affected system is win2k8 R2 running 7.6.3.6 client.
ble1
2 Intern
2 Intern
•
14.3K Posts
0
February 15th, 2013 09:00
Hi,
I did dir /s nsr.dir for whole system - nothing.
As for registry, I just checked and it is not there (I mean, this location is not mentioned). A real puzzle as it seems
bingo.1
2.4K Posts
1
February 15th, 2013 09:00
The registry setting you may want to search is: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\BackupRestore\FilesNotToBackup
However, it could also be a local directive (nsr.dir) file on this drive. Although you state there is none, i would again search the whole drive's directory structure.
I do not expect a NW problem as your tests also show that it can backup the file from another path.
ble1
2 Intern
2 Intern
•
14.3K Posts
0
February 15th, 2013 10:00
I don't think that is the problem. I do see in debug that this thing has its own writer.
Bare in mind this is debug=9 so loads of unnecessary messages, but I see PHD VSS Writer mentioned which is probably in use. I also see that file which is backed up from shadow copy seems to be 0KB. In other words, if I can reproduce this outside NW, I have a winner. But, right now I'm not sure how to:
a) create snapshot in a same way as NW would do using Windows commands
b) mount/browse that snapshot to see size of the file on it
bingo.1
2.4K Posts
1
February 15th, 2013 10:00
Next i would touch a file in the same directory and try NW's bigasm to create a backup stream.
ble1
2 Intern
2 Intern
•
14.3K Posts
0
February 17th, 2013 15:00
In my previous update, I forgot to mention another finding which isolates this issue solely to VSS - if I do save command with VSS enabled, despite the fact that this is win2k8 R2, backup is running then just fine. No VSS, no problems (except DR ones if you wish to have things by the book of course).
ble1
2 Intern
2 Intern
•
14.3K Posts
0
February 17th, 2013 15:00
I did some work on this during the weekend while I could get some time free... one thing I found strange was that verbose save would create bigger log and than debug one. Anyway, highlight of the verbose run shows following:
This is non sense as I do not have any client nor server side directive so I have no idea from where this internal skip comes from. Anyway, I went to check if I will find anything on server side log when running full backup of the machine and I found following:
I doubt data I miss should go under VSS OTHER:, but I'm puzzled as tp why is this not supported. vssadmin list writer is clear:
At this point, I'm thinking writer is sort of strange to whatever NW expects and it builds skip directive on the fly for all data which is covered otherwise by this writer. On second thought, that would be terrible and I can't believe that. So I proceed with vssadmin test of snapshot as indicated in previous message:
I never played with VSS before so this was first time I ever did manually snapshot and browse the it (mount it). A bit of advice, when doing mklink command remember:
Anyway, it works so I doubt VSS Writer is doing anything wrong at this point. Of course, my backup pointed out to monted VSS snapshot instead of original, but that's just matter of masking - and can't be related to the issue.
As last thing to test, I upgraded client from 7.6.3.6 to 7.6.5.0 - same issue. Right now, I believe issue is "internal skip" thingy, but I still don't know from where is that coming from. However enough data collected for support to play around on Monday. I would still like to believe I'm missing the obvious, but somehow I doubt it...
coganb
736 Posts
0
February 18th, 2013 00:00
Hi Hrvoje,
NetWorker develops a list of directories that it needs to skip and your directory for some reason matches the criteria and is being skipped automatically. You might get some explanation by using the diskshadow command to get more info about what the writers are listing: See here for details.
-Bobby
coganb
736 Posts
1
February 18th, 2013 01:00
Hi,
Looks to me like NetWorker is doing what its told. From what I read here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa819132%28v=vs.85%29.aspx
it looks like this exclude was programmed directly into the writer when the writer was developed. I don't know of any way you can modify that. You could try disabling this writer to see if that causes these files to be backed up using the standard writers (since they are not actively excluding the files).
-Bobby
ble1
2 Intern
2 Intern
•
14.3K Posts
0
February 18th, 2013 01:00
Hi Bobby,
Thanks. The files (and writer) of interest give me following (I'm not a VSS expert so certain things here do not make sense to me):
What I see above is PHD VSS Writer and few components - each takking care of their own files. What I find a bit strange, and perhaps part of this puzzle, is the teh fact that it has Exclude Path defined many many times for .idx and .dat which is pretty much everything in Archive directory (so it would apply to components too). I do not understand why it is listed so many times, is this what is causing NW when using VSS to skip these files and finally how to change it. Do you know if this is something that can be changed and if NW interpretation is good one? (given that my interpretation was correct in the first place)