cancel
Showing results for 
Search instead for 
Did you mean: 

Job Status 1 on many polisys

Kristoffer_Lie
Level 4

Hello. 

I need a little help solving my status 1 jobs.

My setup is like this:

Master server: Win2008 - Netbackup 7.6.1

Media server: Win2008 - Netbackup 7.6.1

Job setup: File backup ( windows ), path is set to \\servername\driveletter$\foldername 

( due to reason failure i changed it to this path when the restore did not list all my folders when using the normal browse button and selectin drive to backup. )

After i changed it it now shows me status 1 with diffrent WRN messages and errors. 

For exsample:

06.08.2015 04:01:12 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\pagefile.sys (WIN32 32: Unknown error)
06.08.2015 04:01:13 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store\edb.log (WIN32 32: Unknown error)
06.08.2015 04:01:14 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store\edbtmp.log (WIN32 32: Unknown error)
06.08.2015 04:01:14 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store\HealthServiceStore.edb (WIN32 32: Unknown error)
06.08.2015 04:01:14 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store\tmp.edb (WIN32 32: Unknown error)
06.08.2015 04:01:17 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\System Volume Information\SRM\quota.md (WIN32 32: Unknown error)
06.08.2015 04:01:17 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\System Volume Information\Syscache.hve (WIN32 32: Unknown error)
06.08.2015 04:01:17 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\System Volume Information\Syscache.hve.LOG1 (WIN32 32: Unknown error)
06.08.2015 04:01:43 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\Windows\ServiceProfiles\LocalService\AppData\Local\lastalive0.dat (WIN32 32: Unknown error)
06.08.2015 04:01:43 - Warning bpbrm(pid=5656) from client aprefs05: WRN - can't open file: \\APREFS05\C$\Windows\ServiceProfiles\LocalService\AppData\Local\lastalive1.dat (WIN32 32: Unknown error)
06.08.2015 04:01:43 - Info bpbrm(pid=5656) from client aprefs05: TRV - last message being suppressed after 10 occurrences 
06.08.2015 04:31:33 - Info bptm(pid=3360) waited for full buffer 1447 times, delayed 117074 times    
06.08.2015 04:31:35 - Info bptm(pid=3360) EXITING with status 0 <----------        
06.08.2015 04:31:35 - Info bpbrm(pid=5656) validating image for client aprefs05        
06.08.2015 04:31:38 - Info bpbkar32(pid=3152) done. status: 1: the requested operation was partially successful    
06.08.2015 04:31:38 - end writing; write time: 0:30:32
the requested operation was partially successful (1)

and

03.08.2015 09:55:17 - Info bptm(pid=5640) start            
03.08.2015 09:55:17 - begin writing
03.08.2015 10:36:07 - Error bpbrm(pid=6344) from client iktlfs10: ERR - failure reading file: \\IKTLFS10\F$\HOME\IreLarnr1t\epost\OutlookIrene.pst (WIN32 33: Unknown error)
03.08.2015 10:49:21 - Warning bpbrm(pid=6344) from client iktlfs10: WRN - can't open file: \\IKTLFS10\F$\HOME\thedankons\7 Nord\01 Nordlys\~$2015 Google inntekt.xlsx (WIN32 32: Unknown error)
03.08.2015 10:56:28 - Warning bpbrm(pid=6344) from client iktlfs10: WRN - can't open file: \\IKTLFS10\F$\HOME\vibberfolk\ROTE-BOD\Trasoptunet\~$budsjett_ny.xlsx (WIN32 32: Unknown error)
03.08.2015 11:01:07 - Info bptm(pid=7080) waited for full buffer 46634 times, delayed 253085 times    
03.08.2015 11:01:09 - Info bptm(pid=7080) EXITING with status 0 <----------        
03.08.2015 11:01:09 - Info bpbrm(pid=6344) validating image for client iktlfs10        
03.08.2015 11:01:13 - Info bpbkar32(pid=91752) done. status: 1: the requested operation was partially successful    
03.08.2015 11:01:13 - end writing; write time: 1:05:56
the requested operation was partially successful (1)

 

This jobs are just a small part of alle the diffrent errors i get. ( status 1 )

I have also tryed to exclude the files i dont need, but it looks like i have to use \\servername\driveletter$\filename there to?  

28 REPLIES 28

sdo
Moderator
Moderator
Partner    VIP    Certified

Another option might be to use a 'bpstart_notify' script to shutdown the application at the start of the backup, and a 'bpend_notify' script to restart the application at the end of the backup.

Or amend the application to place/store/locate the ".idlk" files outside of the DFSR protected folders.

Kristoffer_Lie
Level 4

Hmm....  then i have a big problem :p hehe

I can`t move the files due to two things.   1:  its a production folder for indesign. Many companys is using this lokation for their files.   2: the .idlk looks like a ghost file when another file is opend.  

for example:  if you open a Word doc it also lists a hidden word file on the drive ( if you have show hidden files on ).  The same thing happens to this kind of files. Its only lokated on the disk when the file is open or in use. Then it makes ~0filename.idlk ( "ghost" file )    

i cannot browse for the file after the master file is closed.  hard to explain...

It can only be found as i have heard if the indesign crashes and fails to save/complete the file of some kind... 

 

Hmmm.  i realy dont know how to set this backup up then.. 

 

sdo
Moderator
Moderator
Partner    VIP    Certified

The file names beginning with "~" are usually hard locked, and used for that purpose, to act as a flag/lock files, so that an application knows that the original true file is 'essentially' locked for use by another user.  So, even NetBackup Client, and even Windows own VSS (via DFSR) cannot 'read through' these file system hard locks placed on the notional lock files (named "~").  That's just how Windows application developers traditionally do things.  Hence you see a Win32 status 32 of "ERROR_SHARING_VIOLATION" when trying to backup a hard locked "~" file name.

I wonder if the InDesign application has an 'options' or 'ini' file that can be used to redirect where the "~*.*" files are stored/located - but then... if any instance of the application were to start that didn't have your site specific correct setting, then multiple edits/changes could occur - and so this is why the "~" lock files are usually created (by applications) in the very same folder as the file being worked on by the application.

Why can't you simply ignore the failure to backup any files with names beginning with "~" ?

sdo
Moderator
Moderator
Partner    VIP    Certified

IMO, this is not a 'backup issue' per se, and more a user behavioural and/or Windows desktop and/or Windows server and/or Windows application management issue.

If you were to:

1) Place/locate the InDesign files on another smaller DFSR share - maybe even on another server - then your backup window could/would be shorter.

2) And/or ensure that users close their files at the end of the day before backups run.

3) And/or informed the users that their data is at risk IF they don't close their applications and log off.

4) And/or get your Windows administrators to implement a script to actively shutdown their applications before the backups run.

...then you won't have a problem with backups anymore.  i.e. make it their problem, their responsbility, and then you won't have a problem.  There's nothing that you can do, from a NetBackup Client perspective, re 'file system hard locks'.

Kristoffer_Lie
Level 4

I can try to look up this "path change" with my indesingn team. Maybe they can change the location of the ~file.idlk to a destination outside DFS. 

Is there safe to ignore status 1 ???  im worried that if i let this ~filename.idlk go, i might miss other failures.  I cant go in and controll all of this evry day. hehe.   

 

sdo
Moderator
Moderator
Partner    VIP    Certified

Consider this also... if users do not close their applications before a backup occurs then you can never really be sure whether any backed-up files are actually consistent or not.

Also consider that DFSR may be ignoring files that are open for write, or if DFSR is replicating 'open for write' files then it could be replicating 'inconsistent' files anyway, and so... until the files are closed then all copies could be inconsistent... the original file, the DFSR replicated copy, and the backup may all be inconsistent - simply because the user's do not close their applications.

sdo
Moderator
Moderator
Partner    VIP    Certified

I wouldn't say it was safe to ignore status '1'.  But it does appear that it is safe to ignore the failed backups of files named "~*.idlk".  But then see my post just above - re... it's one thing to ignore the failed backups of the 'flag/lock files'... but have you considered the implications of this re the state of the actual data files being amended/edited/changed/updated ?

If your users cannot change their behaviour, due to business working practices, then you may to have to script something to check your status '1' backups and check for files that fail to backup that are not named "~*.idlk" - i.e. filter out those that can be ignored - to generate a true report of what could be a problem - which would resolve your "can I ignore them" question... but then you are still left with the open question of... Are the data files intact at the DFSR replication target, and are they intact in backups?

Nicolai
Moderator
Moderator
Partner    VIP   

Not sure it resolves anything, but have you seen : 

http://indesignsecrets.com/can-i-open-an-indesign-lock-idlk-file.php

 

sdo
Moderator
Moderator
Partner    VIP    Certified

Nicloai's post says that the InDesign data files are in effect databases.  Now it becomes even more important that they are cleanly closed before backups occur - and so that DFSR has a chance to snapshot and replicate them.  Ergo - it is imperative that your users close their files when leaving for the day.