CommVault Simpana 10 ships with a very powerful webconsole. At this moment, the webconsole is an addendum on the CommVault Simpana Administration Console. It’s not a replacement!
The webconsole allows:
- on-demand & historical reporting;
- end-user data recovery for Microsoft Exchange and various file system backups;
- Edge data & software installation;
- executing workflow runbooks (for example: end-user incident management);
- virtual machine management;
In this blogpost, I would like to touch the “on-demand & historical reporting”. By default, the webconsole is filled up with some default reports which can be executed on the CommServe Databases.
The reporting framework is not restricted to the CommVault databases only. In the configuration section of the webconsole, you can easily define external data sources. The supported “remote databases” are:
- Microsoft SQL Server;
Basically this functionality allows reporting on custom-applications, databases filled-up with scripts and 3rd party applications. For example reporting on a remote Symantec Backup Exec server.
I’m starting a new project to change the backup infrastructure for one of my customers. Currently the customer is using NetBackup 7.5 (installed on Windows) and we will incorporate the remote site in it’s centrally managed CommVault 10 environment to ease the handover to the operational teams and to efficiently use the capacity-based licenses.
To get a good understanding of the environment, including data sizings – we opted to execute the External Data Connector (EDC) Scripts for NetBackup 7.5 provided by CommVault Cloud Services.
Please note, you have the ability to install an “External Data Connector Agent” on one of your clients and use that one to feed the data from the NetBackup environment. However, I’m not in favour for this approach as it will pollute the CommServe Database. This blogpost describes how you can use the Cloud Applications of CommVault to stage the existing configuration without thrashing the production environment.
Recently one of our development servers crashed. Upon recovery we started to receive the following error messages when backing up the Microsoft SQL databases: “Unable to get the SQL Version for the server [DEVSERVER]. Please check if the SQL Services are running.”
It’s important to note:
- Before the crash the backups ran fine;
- the file “SQLServerInstanceList.txt” listed the following information: “(local);Clustered:No;Version:11.0.5058.0“;
- the SQLiDA log only mentions “Unable to get the SQL Version for the server“;
- the server has been restarted and the SQL iDataAgent has been reconfigured (removed keeping software in place and reconfigured).
I have two CommCells which are accessed by about 20 persons. For the ease of access I activated Single SignOn within the configuration. The Single SignOn can be activated in the CommVault Simpana Administration Console in the section “Security” (“CommCell > Security > Name Servers > Domain > Properties”). Check or uncheck the box to activa/deactivate Single SignOn.
We ran into the following error during the migration from Oracle backups taken with HP Data Protection (version 6.20) towards CommVault Simpana (version 10 service pack 8).
The first database backup executed with CommVault Simpana 10 throws the following error message. Please note the filesystem backups are perfectly conducted.
“Description: RMAN Script execution failed with error [ORA-19554: error allocating device, device type: SBT_TAPE, device name: ]. Please check the Logs for more details.
Source: server, Process: ClOraAgent”
I got called this weekend to look at a CommVault restore of a Linux FileSystem which goes in pending modus with the error message mentioned below. This problem has been encountered on CommVault Simpana 9 Service Pack 14.
“Error Code: [32:254] Description: Read operation from media [tapelabel] could not be completed. The reason: Read operation cannot be completed as none of the resources available can be used. Please check the following: 1. There are drives with compatible recording format to the media being read. 2. There are resources (Drives, Libraries, MediaAgents, etc.) that are online and ready to be used. If you still have an issue, please contact customer support.”
So, everybody knows CommVault Simpana is a suite with a wide-spread of features and I’m appreciating the suite everyday a bit more…The thing is, the software is written for enterprise environments providing the highest level of flexibility and the approach is a bit different than other backupproducts.
Today, I had to implement an extended retention on a particular set of backupjobs. In normal cases, you look to the jobs and define which tape have been used to store the backupdata. CommVault Simpana has an entirely different approach and to be honest I had to search a bit to find how you need to do it. I tried to look it up on the world wide web and I was a bit astonished of the number of hits explaining how it needs to be done, so I had the idea to write something about it. I have to admit I was using the wrong keywords such as “extend retention” and “retain media”. Once I found the correct terminology, I quickly found this link on CommVault Simpana Documentation. Here there are some references in the “Retain a job in the copy”-section, explaining how it needs to be done.
If you want the procedure with some screenshots, please read on… This procedure is written by using a CommVault Simpana 9 Service Pack 14 environment, but there should be no change when doing it on CommVault Simpana 10.
Recently we noticed a sudden increase in the completion time for two SQL related backups on two different servers. Other SQL servers were not experiencing the same issue. It caught our eye the affected systems were used for the same application.
- The first one is used for acceptation and test and contains approximately 450GB of data. Initially the backupjob completed after 4 hours, now it needed 10 hours to process and it still failed on 8 databases.
- The second one is used for production and contains approximately 1500GB of data. Initially the backupjob needed 15 hours, now it needed 27 hours and it still throws 11 failed database backups.
So.. I have a customer who is using CommVault Simpana version 9. Within his environment there is one particular server with a lot of data on it. The space allocation on the server is somewhere between 10TB and 12TB. The data type is nothing fancy! Just regular files…
They requested me to propose a solution which provides a swifter restore (better RTO & RPO) and ofcourse with minimal investments required. My first idea was let’s use storage based snapshots and/or – replication. But for a disaster recovery solution the investments required were pretty much not justifiable!
My second idea was to split the backup from the replication part by using CommVault Continuous Data Replicator.
+ Take a backup once a day;
+ Make a replication every 2 hours.
Recently I encountered a SQL cluster throwing this error: “Error Code: [14:96] Description: Failed to start CreateIndex on MediaAgent [MediaAgentFQDN*MediaAgent*8400*8402]. Please check the following: network connectivity between client and MediaAgent, MediaAgent’s name can be resolved, and this product’s services are running on the MediaAgent.”
Network connectivity is as it should! When we try a CVping (network connectivity test utility which can be found in the base folder) on the CommServe and the failing MediaAgent the connectivity test gives us the expected result: SUCCESSFUL.