Windows client backups hanging up on /vrts_image_size_record

[mobyslick1999]

Hello,

Some of my windows client (windows 2003)  backups (version 6.5.4x64) are hanging up on /vrts_image_size_record and I have to cancel the job and in most cases reboot the backup server. I've added this file to the exclusion list but Im not sure if this is going work. Has anyone seen this issue?




Joe

[Marianne · Accepted solution]

/vrts_image_size_record is not an actual file on the client - this is the master server finalizing image info right at the end of the backup.

I have seen this when TIR was enabled for the client policy - bpdbm on the master server was sitting at 100% cpu utilization at this point in time. Disabling TIR made the problem go away...

[marekkedzierski]

what version of NB have you got on Master Server ?

Intelligent Disaster Recovery is disabled in backup policy ?

[Nathan_Kippen]

Master server is 6.5.5 (HP-UX 11.23 IA 64)

Not using Intelligent Disaster Recovery ... having problems with shadow copy components/system state:/ streams completing.

Policy Name:       symantec_test
Options:           0x0
template:          FALSE
c_unused1:         ?
Names:             (none)
Policy Type:       MS-Windows-NT (13)
Active:            no
Effective date:    02/08/2005 08:58:22
Client Compress:   no
Follow NFS Mnts:   no
Backup netwrk drvs:no
Collect TIR info:      no
Mult. Data Stream: no
Perform Snapshot Backup:   no
Snapshot Method:           (none)
Snapshot Method Arguments: (none)
Perform Offhost Backup:    no
Backup Copy:               0
Use Data Mover:            no
Data Mover Type:           2
Use Alternate Client:      no
Alternate Client Name:     (none)
Use Virtual Machine:      0
Hyper-V Server Name:     (none)
Enable Instant Recovery:   no
Policy Priority:   0
Max Jobs/Policy:   12
Disaster Recovery: 0
Collect BMR Info:  no
Keyword:           (none specified)
Data Classification:       -
Residence is Storage Lifecycle Policy:    no
Client Encrypt:    no
Checkpoint:        yes
     Interval:    60
Residence:         SL3K1_SL3K2_ALL
Volume Pool:       Onsite
Server Group:      *ANY*
Granular Restore Info:  no
Generation:      13
Client/HW/OS/Pri:  myclient PC WindowsNET 0 0 0 0 ?
Include:           System_State:\
Schedule:          audit_arch_1yr
 Type:            UARC (3)
 Frequency:       7 day(s) (604800 seconds)
 Maximum MPX:     4
 Synthetic:       0
 PFI Recovery:    0
 Retention Level: 8 (1 year)
 u-wind/o/d:      0 0
 Incr Type:       DELTA (0)
 Alt Read Host:   (none defined)
 Max Frag Size:   0 MB
 Number Copies:   1
 Fail on Error:   0
 Residence:       ams_pl2_archive_disk
 Volume Pool:     (same as policy volume pool)
 Server Group:    (same as specified for policy)
 Residence is Storage Lifecycle Policy:     0

[Nathan_Kippen]

On the servers that were receving this error we were seeing the following error message:

"Storage Foundations Flashsnap License is not installed"

To resolve that issue I followed the instructions here:

http://seer.entsupport.symantec.com/docs/282180.htm

Although I don't think this was causing our problem it was something we fixed so I'm posting it as part of the solution. 

The other thing I did was check the client settings in the master server host properties to make sure VSS was selected as the method of doing snapshots for open file backups.

Also here's a handy technote for changing snapshot provider options from the CLI:

http://seer.entsupport.symantec.com/docs/268339.htm

Thanks,

[RollTheBones]

Are there any other resolutions to this? I have been following this thread and the others mentioned and none of the suggested fixes apply in the environment I am having this issue.   These are all Win 2003 servers, Master and Client at 6.5.6,  basic ALL_LOCAL_DRIVES policy so nothing fancy like Exchange.

They are all using VSS.  I dont see any issues on the clients themselves.

These jobs never go anywhere, they will run for days and not make any progress.  And they are impossible to kill; the only way to kill them is to restart the services on the master.

At a real loss here....

[Marianne]

Your problem seems to be a bit different - please start a new thread?