I am using HP data protectore 9.0 and want to backup the ESX VMs. I got stuck while adding vCenter into the client list of HPDP.
Even after giving right credentials of vCenter it says " Invalid username or bad password has been specified (Vsphere.com\administrator@vsphere.local). "
Any help would be appreciated. Thanks in advance.
Is it possible to provide read only access to HP DP gui from a Client host.
This is to make them view the completed sessions for client backup.
Client hosts are AIX and Linux.
Hello,
We have Vmware Vcenter 6.0 integrated with HP DP 9.05 as, we configured full backup jobs for VMs with Thick Provision Eager Zeroed disks.
The backup take the whole disks size as backup not the used space. (Ex: SCSI disk with total size 100GB, used space 20GB, the HP DP take as backup the 100GB)
How can full backup VMs and take only the used space with this type of disks ?
Please advise,
Starting with Data Protector 9.06 in copy sessions, copy session manager (csm) uses new procedure to select replacement source device if the original is used in another session. It should pick any free device from same library with "Device may be used as source device for object copy" policy enabled and same device tag as original, but it's failing.
Even if there are plenty of free devices matching this criteria session will remain in:
[Warning] From: CSM@hostname "Copy" Time: 06.05.2016 13:30:01
[64:18] Some of the devices are occupied. Session is waiting
for all the devices to get free.
Workaround is to manually change source devices, change request QCCR2A68250 is raised to resolve this problem.
Starting with Data Protector 9.06 in copy\restore sessions, session managers (csm\rsm) use new procedure to select replacement source device if the original is used in another session. It should pick any free device from same library with "Device may be used as source device for object copy" \ "Device may be used for restore" policy enabled and same device tag as original, but it's failing.
Even if there are plenty of free devices matching this criteria session will remain in:
[Warning] From: CSM@hostname "Copy" Time: 06.05.2016 13:30:01
[64:18] Some of the devices are occupied. Session is waiting
for all the devices to get free.
Workaround is to manually change source devices, change request QCCR2A68250 is raised to resolve this problem.
Hi guys
We use this VEPA Backup job since years to backup all our 24 VM's without any problems. Same job for Full and Incremental Backups, adjusted only in the Adv. Scheduler if Full or Incr.
Since we upgraded from 8.13 to 9.06 we have 7 Vm's, and always the same 7, on which we always get the "Differential/incremental backup not possible. Performing full backup instead..." all other VM's DP can do incremental jobs without any problems.
All VM's are configured the same and use the same "Virtual machine configuration" settings. CBT is enabled on all VM's by default since we upgraded to 9.06. But we are missing the "Advanced" tab in the "Configure machine configuration". Is it by default now not available or doe we have any corruption? Because in the VE Integration manual of DP9 the Advanced tab is still there on all screenshots.
No vMotion active or any other Snapshots during the day and the protecion is set to 4 weeks, so all Fullbackup images are available.
Any suggestions?
Thx
Hallo,
I have get error with replication sessions in HP DataProtector 9.05 as below:
Critical From: CSM@EXAMPLE.com " Example" Time: 24.05.2016 04.04:56
Replication error: Destination device is out of space.
when I check the StoreOnce ( HP StoreOnce 2620 iSCSI )I found no free space on it.
Is there any sugested Solutions? can you help me ?
Thanks in advanced
Al-Rifaie
Ran across this issue. Have an open ticket. Not sure if it's a bug in DP or something on my end. Sharing in the event it can save someone else a headache.
On a Monday 2 weeks ago, I updated my DP 8.14 environment to 9.0 and then patched to 9.06. Everything went fine and ran without issue for 2 days. I have a Monday morning scheduled BRICK (brick --full) run via cron. I decided to run the BRICK report Tuesday afternoon on the way out the door. I came back in Wednesday morning and found that I had several jobs that had stopped on on initializing medium to a file library device and they were In Progress with no activity and jobs that got queued after the devices were used up timed out without issue.
I tried to abort the jobs from Monitor tab of the GUI client (Windows), which resulted in the spinning blue mouse pointer and a "(Not Responding") on the window. Attempting an omniabort -session on the commandline just hung too. I ended up using the omnisv to stop all services and start them back up. The GUI would report the jobs failed but a "ps -ef | grep omni" would show bsm jobs still running. I killed them off and attempted to perform backups again and got intermittent results getting some jobs to go through and then it'd lock up again.
Creating Debug sessions would generate files on the CM and MA but not the DA. I ran Wireshark on the DA and MA and traffic was apparent from CM to DA and CM to MA but nothing between the DA to MA. I attempted to gather debugs and the debug collection would just hang and not show any activity and require me to manually gather them.
I initially didn't put 2 and 2 together and point the finger at the BRICK reports. I got it up and running and did try to run a omnicheck -dns - full after HPE Support suggested there was a DNS issue and noticed the bsm process hang again. Further omnidlc debug collections would hang after that too.
The eventual realization that the omnicheck -full -dns, which BRICK runs in it's report gathering, was what was causing backup jobs to stop functioning has led to me removing my cron job. I plan to use a config file for BRICK to skip the dns check but still gather some reports.
Regarding DNS check - it worked fine on 8.14. I was notified by HPE support that one of my debugs gathered had a bad reverse DNS on a client, however, when DP was running it would run the backup job on that client without issue.
During the past 2 weeks I uninstalled the Patch, reinstall 9 and then repatch it without success. Reboot the server several times. Try multiple omnirc options, change global options, send in multiple logs to HPE.
Resolution when broken to get it going again:
killall bsm
killall omnidlc
omnisv -stop
omnisv -start
run a debug delete on all clients - any of them that it hangs on need to have the INET service restarted, seemed to be only Windows machines - I think these bad INETs resulted in jobs that kicked off when the CM was hosed and it broke the DA clients.
Here's the big one: Don't run omnicheck -dns
Thoughts
I'm not 100% sure, but it seems to me that the busted INET services on the DA's would cause a restart/scheduled job on that client to fail again and continue the CM in it's broken loop for future jobs on all other clients. Killing the bsm and omnidlc processes that are hung and restarting all the INET services that don't respond to the Debug Delete seems to bring all within line, at least the 1.5 days of green check marks in Sessions seems to concure with it.
Technical Information:
BRICK v 2.01 from www.data-protector.org
Cell Manager
Hardware: HP DL320e Server
Software:: centos-release-6-7.el6.centos.12.3.x86_64
/omnicheck -patches
Patch level Patch description
===========================================
DPUX_00175/DPLNX_00464(BDL906) Cell Manager Component
DPUX_00175/DPLNX_00464(BDL906) Cell Server Technology Stack
DPUX_00175/DPLNX_00464(BDL906) Application Server Technology Stack
DPUX_00175/DPLNX_00464(BDL906) Web Services
DPUX_00175/DPLNX_00464(BDL906) Java Runtime Environment Technology Stack
DPUX_00175/DPLNX_00464(BDL906) Job Control Engine Service Dispatcher
DPUX_00175/DPLNX_00464(BDL906) Job Control Engine Service Registry
Number of patches found: 7.
2016-05-27 3:11pm EST - Update
I ran BRICK with as "brick --full -n --path=/var/www/hostname/public_html" with the "-n" meaning no dns check and it completed with out issue and didn't break my backups and I've run 3 backups since it completed and all looks good.
Running the vepa_util only returns *RETVAL*0 on the CM and nodes.
C:\Windows\system32>vepa_util command --check-config --virtual-environment HyperV --host node1
*RETVAL*0
C:\Windows\system32>vepa_util command --check-config --virtual-environment HyperV --host node2
*RETVAL*0
C:\Windows\system32>vepa_util command --check-config --virtual-environment HyperV --host cluster1
*RETVAL*0
OS: Windows 2012 R2
Version: 9.06
Keywords: Hyper-V Windows cluster backup virtual
Can't seem to get VSS to read what's on the server. Get error below.
I've configured the Server, the Backup Server, and the Cell manager with:
omniinetpasswd -add BACKUPUSER@DOMAIN
All of the service accounts are running as BACKUPUSER@DOMAIN.
I'm outta ideas. Did I miss something?
[Critical] From: OB2BAR_VSSBAR@servername "MSVSSW" Time: 5/27/2016 2:20:53 PM [131:51] User "BACKUPUSER.DOMAIN@servername" is not a valid Data Protector user *RETVAL*8010 Specified user is not in the Data Protector users list. * Check if user is on the Data Protector users list. You can check this using Data Protector (Manager) GUI. * If this happens during the integrations backup you must enter the user to the Data Protector admin group.
System
OS: Windows 2012 R2
Data Protector: 9.06
Keywords: Windows, Hyper-V, HyperV, Cluster, Volume Shadow Copy, Virtual
Take the following steps in order to remove Data Protector from Linux machine :
rpm -qa | grep OB2
2. Remove the packages listed above in the order shown :
rpm -e<package_name>
were <package_name> is packages names you got on step (1)
Example:
root@hostname# rpm -qa | grep OB2
OB2-CORE-A.09.00-1.x86_64
And to remove the package run :
root@hostname# rpm -e OB2-SODA-A.09.00-1.x86_64
3. After you complete uninstall all DP packages start remove the remaining directories using the rm command:
rm -fr /var/opt/omni
rm -fr /etc/opt/omni
rm -fr /opt/omni
At this stage, Data Protector references should no longer reside on your system.
If you do not know the full path of a file that you want to restore, you can search for the file in the IDB,
provided that the logging level at backup time was set to Log Files or Log All. You can search for files
and directories using the Restore by Query task if you know at least a part of the file name.
Steps
1. In the Context List, click Restore.
2. Click the Tasks navigation tab at the bottom of the Scoping Pane. The predefined restore tasks are listed in the Scoping Pane.
3. Click Restore by Query to open the wizard.
Hi All, facing the below error.. Any workaround. I've no clue what needs to be done further. Can we reduce the size of the folder?
[Minor] From: VBDA@l70srv52.griffin-domain.net "l70srv52.griffin-domain.net [/Y]" Time: 5/31/2016 9:00:09 PM
Cannot back up files with a pathname longer than 1024 characters!
[Minor] From: VBDA@l70srv52.griffin-domain.net "l70srv52.griffin-domain.net [/Y]" Time: 5/31/2016 9:00:09 PM
Cannot back up files with a pathname longer than 1024 characters!
[Minor] From: VBDA@l70srv52.griffin-domain.net "l70srv52.griffin-domain.net [/Y]" Time: 5/31/2016 9:00:09 PM
Cannot back up files with a pathname longer than 1024 characters!
[Minor] From: VBDA@l70srv52.griffin-domain.net "l70srv52.griffin-domain.net [/Y]" Time: 5/31/2016 9:00:09 PM
Cannot back up files with a pathname longer than 1024 characters!
[Minor] From: VBDA@l70srv52.griffin-domain.net "l70srv52.griffin-domain.net [/Y]" Time: 5/31/2016 9:00:09 PM
Cannot back up files with a pathname longer than 1024 characters!
[Minor] From: VBDA@l70srv52.griffin-domain.net "l70srv52.griffin-domain.net [/Y]" Time: 5/31/2016 9:00:09 PM
Cannot back up files with a pathname longer than 1024 characters!
[Minor] From: VBDA@l70srv52.griffin-domain.net "l70srv52.griffin-domain.net [/Y]" Time: 5/31/2016 9:00:09 PM
Cannot back up files with a pathname longer than 1024 characters!
[Minor] From: VBDA@l70srv52.griffin-domain.net "l70srv52.griffin-domain.net [/Y]" Time: 5/31/2016 9:00:09 PM
Cannot back up files with a pathname longer than 1024 characters!
Sometimes patches fail to install on top of patch bundle b905 and we see this error:
======= 01/11/15 22:51:23 EET BEGIN install AGENT SESSION (pid=11527)
(jobid=myhost-0019)
* Agent session started for user "root@myhost".
(pid=11527)
* Beginning Analysis Phase.
* Source:
myhostt:/tmp/DPUX_00166.depot
* Target: myhost:/
* Target logfile:
myhost:/var/adm/sw/swagent.log
* Reading source for product information.
* Reading source for file information.
WARNING: Before installing this patch, you must install the DPUXBDL_00905 patch.
ERROR: The "checkinstall" script for "DPUX_00166" failed (exit code "1"). The script location was
"/var/tmp/BAA011527/catalog/DPUX_00166/pfiles/checkinstall".
* This script had errors and the execution of this product
cannot proceed until the problem is fixed. Check the above
output from the script for further details.
* Executing preDSA command.
NOTE: All filesets in the product "DPUX_00166,r=1.0" will be
excluded because there was an error in this product.
* Summary of Analysis Phase:
ERROR: Exclude DPUX_00166.OMNI-CF-P,r=1.0
ERROR: Exclude DPUX_00166.OMNI-CORE,r=1.0
ERROR: Exclude DPUX_00166.OMNI-CORE-IS,r=1.0
ERROR: Exclude DPUX_00166.OMNI-INTEG-P,r=1.0
ERROR: Exclude DPUX_00166.OMNI-TS-CF-P,r=1.0
ERROR: Exclude DPUX_00166.OMNI-TS-PEGASUS-P,r=1.0
ERROR: 6 of 6 filesets had Errors.
ERROR: The Analysis Phase had errors. See the above output for
details.
======= 01/11/15 22:51:24 EET END install AGENT SESSION (Cancelled)
(pid=11527) (jobid=myhost-0019)
The root cause for this problem is that for some reason, the file /opt/omni/.b905_Patch was not created on the host after installing the b905 bundle.
If the issue persists after reinstalling b905 we can manually create the file as a workaround.
File permissions and contents should be:
-rw-r--r-- 1 root sys 242 Dec 4 08:48 /opt/omni/.b905_Patch
# more /opt/omni/.b905_Patch
DPUX_00128
DPUX_00129
DPUX_00130
DPUX_00131
DPUX_00132
DPUX_00133
DPUX_00134
DPUX_00135
DPUX_00136
DPUX_00137
DPUX_00138
DPUX_00139
DPUX_00140
DPUX_00141
DPUX_00142
DPUX_00143
DPUX_00144
DPUX_00145
DPUX_00146
DPUX_00147
DPUX_00148
DPUX_00150
I have a server with 20TB of local storage. Which i have avilable as a file library for backups.
Am I able to use dedupe on a file library in the above scenario
Everything i've read seems to suggest its only on a D2D device, which this obiously isn't
Please note i'm currenly running DP 7.03 but we are looking to upgrade to 9.06 soon.
Is a file library the best way of doing disk backups with this storage?
We're running Data Protector 9.06 on a Windows 2012 R2 server. Backups, restores and GUI media operations are all working properly, but we're getting an error using omnimm from the command line:
omnimm -list_pools -detail
You have no permission for the requested media management action.
I'm logged in as a domain admin, the services are all running under an account in the administrators group. Any idea what could cause this error? Do I perhaps need to make sure permissions are set on a particular directory, and if so, for my account or the service account?
Following types of errors are seen in session messages:
[Major] From: VBDA@hostname "Z:" Time: 5/22/2016 1:18:58 AM
[81:78] GLOBALROOT\Device\HarddiskVolumeShadowCopy1991\WindowsImageBackup\hostnaem\Backup 2016-05-20 150016\a15ca12c-c1f2-11e4-8cb8-806e6f6e6963.vhd
Cannot read 261832 bytes at offset 31735345344(:1): ([2] The system cannot find the file specified. )
[Minor] From: VBDA@hostname "I" Time: 5/14/2016 8:18:47 PM
[81:75] \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3058\Common\pd\DATA\June 2012\
Cannot traverse: ([2] The system cannot find the file specified. ) => not backed up.
Those are signs of deleted VSS snapshot. Usually this happens when dedicated VSS shadowstorage space is not sufficient for the amount of volume changes during the session. Windows event logs should contain exact reason eg:
.Error 22/05/2016 1:18:58 AM volsnap 25 None The shadow copies of volume Z: were deleted because the shadow copy storage could not grow in time. Consider reducing the IO load on the system or choose a shadow copy storage volume that is not being shadow copied.
We currently have a media server that we use to make copies of backups to. It has 1 hard drive in it that we use for backups ( D: drive )
If I add more drives to this server, will the cell manager know to use the extra storage I add? I couldnt find anywhere how I orignally told the cell manager to use the D drive!
How can i check the installed directory structure of DP?
The reason for asking is, I had a clustered cell manager (7.03); then due to failure of Domain, we had to change the setup to stand alone on one of the two nodes and tried changing the dpconfig to C:\programdata\omniback.
Now I need to upgrade this to 9.05/6; but i feel i have the CM using some files/directories from C:\programdata\omniback (New standalone file structure) and other few from H:\dpconfig (Old Clusterred file structure).
So if any one can provide the commands by which I can check that what are the directory structure in-use, so that I can delete the other non-used directories.
Thanks in advance.
Hi,
I'm observing rma.exe (9.06 running on 2008R2 CM usually patched to latest MS critical and recommended updates) crashing occasionally within serializer.dll. This didn't happen ever before, but happened three times since the middle of May. The rma.exe is the source of a copy operation from a SOS B2D to LTO6 tape. For the last session that failed this way, I restarted failed objects. The resulting session again crashed the RMA. Application log says:
Faulting application name: rma.exe, version: 9.0.107.0, time stamp: 0x5702e87c Faulting module name: serializer.dll, version: 9.0.107.0, time stamp: 0x5702ea49 Exception code: 0xc0000005 Fault offset: 0x0000000000001088 Faulting process id: 0x1af8 Faulting application start time: 0x01d1b18918257339 Faulting application path: O:\OmniBack\bin\rma.exe Faulting module path: O:\OmniBack\bin\serializer.dll Report Id: 59e9d3bb-1d7c-11e6-8e46-d89d673490b8
I've not seen other reports yet, but it's also only happening every now and then, maybe in a very specific environment that isn't in widespread use. The same backup was mirrored to a SO 4500 appliance via SO Catalyst, and that session did copy flawlessly to another library and tape drive.
Anyone seen this? Given it's a crash, it's probably a software bug introduced in 9.06 which is still relatively new, but maybe support already has cases open for it?
TIA,
Andre.