cancel
Showing results for 
Search instead for 
Did you mean: 

Policy VmWare

PorcoDio
Level 4

Hi,

 i've a vm who fail always backup. On this lun other vm run backup well.

Only difference between this vm is on vm didn' work backup is set memory reservation. When netbackup run on this machine policy fail and machine need disk consolidation.

The problem is the memory reservation parameter?

Regards

Stefano

10 REPLIES 10

Thiago_Ribeiro
Moderator
Moderator
Partner    VIP    Accredited
Hi Stevaz,

Can you share with us more informations about your environment?
This fail happen before or after NBU takes snapshots?
Please send us NBU Master/Media version, Vsphere version and the error logs.

Regards

Thiago Ribeiro

matt077
Level 5
Partner Accredited

Is anything else accessing the VM which is being backed up at the time of the backup running?

Hi Thiago,

 my enviroment have 4 media physical server run on Windows 2008 R2 like the Master but this is a vm running on vCenter 5.5.

If i understood fail during snapshot operation because in tasks sheet of vm enviroment i see the map disk region operations.

I'll report you nbu details policy

18-mag-2017 18.12.48 - Info nbjm (pid=2520) starting backup job (jobid=536661) for client dbcedgeute007.usr.root.jus, policy GE_SIES, schedule VmWare
18-mag-2017 18.12.48 - Info nbjm (pid=2520) requesting STANDARD_RESOURCE resources from RB for backup job (jobid=536661, request id:{BAB43373-EE59-40E1-A822-9B476EDD054E})
18-mag-2017 18.12.48 - requesting resource svcedgeute018_disk_dedup
18-mag-2017 18.12.48 - requesting resource svcedgeute006.NBU_CLIENT.MAXJOBS.dbcedgeute007.usr.root.jus
18-mag-2017 18.12.48 - requesting resource svcedgeute006.NBU_POLICY.MAXJOBS.GE_SIES
18-mag-2017 18.12.48 - granted resource svcedgeute006.NBU_CLIENT.MAXJOBS.dbcedgeute007.usr.root.jus
18-mag-2017 18.12.48 - granted resource svcedgeute006.NBU_POLICY.MAXJOBS.GE_SIES
18-mag-2017 18.12.48 - granted resource MediaID=@aaaao;DiskVolume=PureDiskVolume;DiskPool=Storage_Dedup_Pool_018;Path=PureDiskVolume;StorageServer=svcedgeute018.usr.root.jus;MediaServer=SVCEDGEUTE018
18-mag-2017 18.12.48 - granted resource svcedgeute018_disk_dedup
18-mag-2017 18.12.49 - estimated 0 kbytes needed
18-mag-2017 18.12.49 - Info nbjm (pid=2520) started backup (backupid=dbcedgeute007.usr.root.jus_1495123968) job for client dbcedgeute007.usr.root.jus, policy GE_SIES, schedule VmWare on storage unit svcedgeute018_disk_dedup using backup host svcedgeute018.usr.root.jus
18-mag-2017 18.12.52 - started process bpbrm (pid=7912)
18-mag-2017 18.12.56 - Info bpbrm (pid=7912) dbcedgeute007.usr.root.jus is the host to backup data from
18-mag-2017 18.12.56 - Info bpbrm (pid=7912) reading file list for client
18-mag-2017 18.12.56 - Info bpbrm (pid=7912) starting bpbkar32 on client
18-mag-2017 18.12.56 - Info bpbkar32 (pid=5328) Backup started
18-mag-2017 18.12.56 - connecting
18-mag-2017 18.12.56 - connected; connect time: 0:00:00
18-mag-2017 18.12.56 - Info bpbkar32 (pid=5328) archive bit processing:<enabled>
18-mag-2017 18.12.57 - Info bptm (pid=6232) start
18-mag-2017 18.12.57 - Info bptm (pid=6232) using 262144 data buffer size
18-mag-2017 18.12.57 - Info bptm (pid=6232) setting receive network buffer to 1049600 bytes
18-mag-2017 18.12.57 - Info bptm (pid=6232) using 128 data buffers
18-mag-2017 18.12.59 - Info bpbkar32 (pid=5328) INF - Backing up vCenter server vccedgeute002, ESX host esx20180-ge.esx.local, BIOS UUID 4227e171-e432-a69c-d1cc-a3f95454699d, Instance UUID 5027461c-2e38-8115-ef47-ed462fb09200, Display Name DBCEDGEUTE007, Hostname dbcedgeute007.usr.root.jus
18-mag-2017 18.12.59 - Info bptm (pid=6232) start backup
18-mag-2017 18.13.04 - begin writing
18-mag-2017 18.14.06 - Error bpbrm (pid=7912) socket read failed, An existing connection was forcibly closed by the remote host. (10054)
18-mag-2017 18.14.17 - Info SVCEDGEUTE018 (pid=6232) StorageServer=PureDisk:svcedgeute018.usr.root.jus; Report=PDDO Stats for (svcedgeute018.usr.root.jus): scanned: 3 KB, CR sent: 0 KB, CR sent over FC: 0 KB, dedup: 100.0%, cache disabled
18-mag-2017 18.14.18 - Error bpbrm (pid=7912) could not send server status message
18-mag-2017 18.14.20 - Error bpbrm (pid=7912) cannot send mail to netbackup@monitor.ge.it
18-mag-2017 18.14.22 - Error bpbrm (pid=7912) cannot send mail to root on client svcedgeute018.usr.root.jus
18-mag-2017 18.14.22 - Info bpbkar32 (pid=0) done. status: 13: file read failed
18-mag-2017 18.14.22 - end writing; write time: 0:01:18
file read failed (13)

 

and tasks sheet is attached

 

i don't undestood the question

Thiago_Ribeiro
Moderator
Moderator
Partner    VIP    Accredited

Hi Stevaz,

Please take a look this article, there are best practices and trobleshooting for VMware.

https://www.veritas.com/support/en_US/article.000094725

If its not solve your problem try to check if exists some bkpkar process hung on media server, I already saw this issue.

Other thing, send us your NBU version from master and media and the transport mode that you are using for these backups, NBD, SAN etc.

Regards,

Thiago Ribeiro

Hi Thiago,

 i think this is not solutions beacuse on same lun run other vm who NBU can backup fine so i think user run backup have right permission (now have same permission of root user of vCenter).

This vm was never backed up, this process still fail form the first runned backup.

No solution i still have that problem

What is the VMware tools version on the VM(s) that are being backed up successfully and the VMware tools version of the one that has been failing?

What is the OS(s) of the VM's that are comleting successfully and the OS of the VM that is failing?


@Stevaz wrote:

If i understood fail during snapshot operation because in tasks sheet of vm enviroment i see the map disk region operations.


So the VMware backup policy has the parent job that kicks off all of the snapshots (if multiple VM's) these snapshot jobs either finish and create a backup job or they fail. The detailed status view that you linked earlier in the thread is from the backup job meaning the snapshot job is completing successfully which would mean this isn't a permission issue.

Have you turned up the bpbkar and bpfis logs and reviewed them? Increase the bpfis logs on the media server that is configured as the backup host and bpbkar logs on the client. Both of logs could potentially help.

 

Thiago_Ribeiro
Moderator
Moderator
Partner    VIP    Accredited

Hi,

thanks for answer...So Did you already check this document? Its VMware vSphere 5.5 Release Notes, and from what I read there are some memory issues in this version, take a look.

https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-55-release-notes.html

Regards,

Thiago Ribeiro

I will read the document thanks