07-27-2015 08:05 AM
Hi All,
I am having trouble backing up the windows file server and keep getting particaly successfull status. I know these are temporary files and should not be backed up. I can also do the exclude of '~$' but I want to resolve instead of exclusion.
if anyone can suggest a quick workaround that will be great.
26/07/2015 09:07:48 - begin writing
26/07/2015 15:45:33 - Warning bpbrm(pid=1876) from client : WRN - can't open file: F:\EU-AMS-SHARE01\Capital Markets Group\Opportunities\Dordrecht Johan de Wittstraat\Q&A\~$150724_QA Dok 40 and Post 120.xlsx (WIN32 32: Unknown error)
26/07/2015 15:48:24 - Warning bpbrm(pid=1876) from client : WRN - can't open file: F:\EU-AMS-SHARE01\Capital Markets Group\Opportunities\Leone portfolio\DD\Q&A\~$150724 Overview asked questions_007.xlsx (WIN32 32: Unknown error)
26/07/2015 15:54:25 - Warning bpbrm(pid=1876) from client : WRN - can't open file: F:\EU-AMS-SHARE01\Capital Markets Group\Opportunities\Propertize\Loan Portfolio\2. Data\~$Rent roll Motonic Bouwstate Tradepoint.xlsx (WIN32 32: Unknown error)
26/07/2015 15:54:32 - Warning bpbrm(pid=1876) from client : WRN - can't open file: F:\EU-AMS-SHARE01\Capital Markets Group\Opportunities\Propertize\Loan Portfolio\2. Data\3. Received documents\6. Tradepoint CV 23 july\~$Huuroverzicht per dd. 01-06-2015.xlsx (WIN32 32: Unknown error)
27/07/2015 04:53:19 - Warning bpbrm(pid=1876) from client WRN - can't open file: F:\EU-AMS-SHARE01\Valuations\FGH Bank\2015\Portefeuille 4x Amsterdam, Marco Polostraat, Hemonystraat, 2e vander Helststraat en Vechtstraat\8. Sheets\~$Waardenoverzicht (J. Bakker).xlsx (WIN32 32: Unknown error)
27/07/2015 07:45:06 - Info bptm(pid=2912) waited for full buffer 1740611 times, delayed 2734456 times
27/07/2015 07:45:13 - Info bptm(pid=2912) EXITING with status 0 <----------
Solved! Go to Solution.
08-07-2015 05:20 AM
Hi All,
Just to update you that I have ended up logging a call with Symantec support and found the root cause of the failure.
under the <installpath>/veritas/netbackup/vfm.conf has the wrong information for the client for some reason its reading the .dll path as unix client.
Delete the file and copy from the client which was working fine, tested the backup and completed with no warnings all blue man :).
07-27-2015 08:39 AM
I can see this backup went on for quite a long time. What probably happened here is that the VSS snapshot could not be maintained any longer by the OS. If you look in the Windows Event logs you'll probably find an error that states something to the effect of "could not grow the shadow copy storage" and that the snapshot was removed. Thereby causing the backup to get status 1 for the files it couldnt find. The Events would be from VSS or volsnap.
07-27-2015 09:01 AM
Are you really using the MS-windows policy or Standart? This sounds like you re not using the correct policy typ!
Best regards,
Cruisen
07-27-2015 09:07 AM
Something like this https://support.symantec.com/en_US/article.DOC2980.html
07-27-2015 11:44 PM
Hi
thanks for your reply.
Yes, I am using the correct policy which is under windows. I have 30 other servers running with same policy types and do not see any issues.
I will check the VSS and events log and update you guys.
07-27-2015 11:59 PM
It is also possible that someone may have previously disabled WOFB (Windows Open File Backup) for the backup client.
What does this command (from master server) show:
bpclient -L -client my-client-name
Assuming the NetBackup Client is v7.x, then if nothing is shown by the above command then the default should be that WOFB is enabled, and that VSS is used as the 'snapshot' tool.
However, if the NetBackup Client is v6.5.x then it could well be using VSP as the WOFB method, and not VSS.
.
Could we ask what version of Windows and what version of NetBackup Client is the troublesome client running? Try this command from the master server:
bpgetconfig -g my-client-name
.
If the client is running v6.5.x, then please, from master server, also show output of:
Windows: bpgetconfig -M my-client-name | find /i "VSP" Unix: bpgetconfig -M my-client-name | grep -i "VSP"
07-28-2015 05:14 AM
Events log - information
Log Name: Application
Source: VSS
Date: 27/07/2015 08:48:17
Event ID: 8224
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: client
Description:
The VSS service is shutting down due to idle timeout.
-----------------
Master server is 7.6.0.3
Client 7.6.0.3
I have run the bpgetconfig command but getting client hostname could not be found also run the bpclient command and getting no entity was found (227).
Thanks.
07-28-2015 05:55 AM
It would be before 26/07/2015 15:45:33
07-28-2015 10:11 AM
Ok - bpclient returns status 227 when a 'Client Attributes' entry does not exist - which is not necessarily a problem.
The bpgetconfig -g command should have worked - as this is a query of the client for its NetBackup installation type and version.
Anyway, NetBackup Client is v7.6.0.3 and so should be using VSS by default - but it's still not clear what version of Windows the troublesome client is running? Are you able to confirm?
Can I ask a few more questions...
How many volumes on the client?
Is the client backed-up using multi-streaming? If so, how many streams go active at once?
Because you don't have a Client Attributes entry for the client, then you cannot be controlling the maximum concurrent active backup streams on a per client basis for this client. Are you able to configrm global maximum streams setting, or policy maximum streams setting?
07-28-2015 01:07 PM
Yes, I think SDO is wright with its asumption. ==>Anyway, NetBackup Client is v7.6.0.3 and so should be using VSS by default - but it's still not clear what version of Windows the troublesome client is running? Are you able to confirm?
Yes this is correct. And I was not able to find any solution to it. If the client is windows 2000 and you cannot set, to use VSP for snaphots, as it is de-activated as you said before in the newer NBU, not client , but master server versions. You will not be able to run open file backups. Anyway the only supported version to backp w2k is to use 6.5 agents.
if this is the case, that the client is w2k, we are not able to help Arsalan 2k :)
best regards,
Cruisen
08-07-2015 05:20 AM
Hi All,
Just to update you that I have ended up logging a call with Symantec support and found the root cause of the failure.
under the <installpath>/veritas/netbackup/vfm.conf has the wrong information for the client for some reason its reading the .dll path as unix client.
Delete the file and copy from the client which was working fine, tested the backup and completed with no warnings all blue man :).