Simpana 10 – Windows File System iDA installation on Windows Server 2008 R2

Just a quick demo of installing Windows File System iDA on Windows Server 2008 R2.

There is no audio in this clip, so you won’t hear me discuss any aspect of the installation and/or options being used.

Documentation for this operation available here. (Interactive Install – Standard)

If you find this video of benefit, please leave feedback. Thanks.

Simpana 10 – Populate Commserve Software Cache using Bootstrapper

Quick demo in Simpana 10 using Bootstrapper to download some Unix Packages and use these to populate the Commserve Software Cache. Basically you would use this in situations where you would like to manual maintain what gets loaded into the cache and under what conditions that happens, in addition, you might have a Commserve that has no internet access, so you would need to do this so you can subsequently push out packages to other clients.

If you find some value from the video, please post a comment. Please note this video is only available in 720p, however future ones will be higher resolution. I was using some new software so still coming to terms with how record with it.

Thanks

Update: Now updated with a higher resolution video version. Now you will be able to play it in 1080p and see everything I can see.

Simpana 10 – MySQL on Windows Server 2008 R2 – Video example

Just a quick demo of installing MySQL on Windows Server 2008 R2, followed by the installation of Simpana 10 MySQL iDA.

We also enable Binary Logging on MySQL so we can perform Log backups, configure the MySQL instance in Simpana and run some backup tests.

You can watch the following video for the demo/example.

If you find this video of benefit, please leave feedback. Thanks.

Simpana 10 – PostgreSQL on Windows Server 2008 R2 – Video example

I know it’s been a little while since I did one of these, but I suddenly found myself in a position where I could do one so I quickly put this together.

Unfortunately its in 3 parts, so if you watch the 3 clips below end to end it will make sense.

Part 1 of 3

Part 2 of 3

Part 3 of 3

You’ll notice I even made some mistakes in part 3, but I worked with it and used it to demonstrate how you can troubleshoot this type of issue.

If you find this valuable and/or have any questions, just drop me a comment. Always love to hear feedback.

Rebuilt Simpana Test Lab

I’ve been a little busy in recent days. Have been rebuilding a Simpana Test Lab I have running on a bunch of virtual machines. It’s still very much a work in progress, as it no where near back to the setup I original had, but getting very close.

I’ve opted to run it all on Virtual Box this time around, rather than VMware Workstation.

I’ve got a few more machines I need to build and software/applications to install, but I will be sure to post a few blog posts about some interesting things related to my tests as they come up.

Commvault – Demo of using FTP to upload items onto qnftp01 site

When it comes to uploading via FTP to the Commvault support site (qnftp01), it seems the most common problem people face is confusion when they see a directory listing that contains nothing.

I created this video clip several months ago, as it’s a quick reference for someone to watch and to understand why the directory is empty and how to manually change into the blind directory.

The video clip has helped a great deal so far, so I thought I should publish it here on my blog.

Remember to watch the HD version, so you can see what is on the screen.

Just remember the CCID is unique to every installation/deployment of Simpana, so use your one, not the one in the video.

Of course, FTP is not allowed outbound in most corporate sites, so in those situations, it is recommended to use the Commvault – Maintenance Advantage Portal (http://ma.commvault.com/) and the HTTP Log upload feature on the site.

Simpana 10 – Enabling Pre-Check Operations During Update Installation

I wasn’t aware of this until recently, so it was a good thing to find…..

In Simpana 10 a number of Pre-Check Operations performed during the push of Updates from the Commserve are disabled by default.

Those Pre-Check Operations are outlined below;

  • Client connectivity check – Verifies whether the client can communicate with the CommServe.
  • Disk space check – Verifies whether the client has sufficient disk space for the updates to be installed.
  • Package synchronization – Verifies whether the updates are already installed on the client.

Of course since one of them is Disk space check, imagine what happens during an SP push update to a Unix client whereby you don’t have enough disk space to perform the Update operation on client. The client may end up corrupting the existing Simpana software on the client due to the SP update failing due to lack of space if it gets enough of the way through the progress. I saw this first hand recently on a client.

The regkey to set that will enable the Pre-Check Operations to be performed in the future is below;

nNoConnectionLimitsForPushUpdate

I confirmed that Pre-Check Operations didn’t occur as I saw the following log lines during my Push of an SP against a client. The log named below is found on your Commserve.

DistributeSoftware.log

6196  3914  12/17 09:45:47 4825406 [UpdatePatches]() - Initiating update patches on client
6196  3914  12/17 09:45:47 4825406 [UpdatePatches]() - Skipping disk space check for client to reduce client connections

As always, if my post helps you in some way, please drop me some feedback by way of a comment. Love hearing from people.

Source: Simpana 10 – Books Online Documentation.

Simpana 10 – Commserve DR Backup

A demo I put together that shows how to perform a Commserve DR Backup in Simpana 10. It talks about the process of how to do it manually and where you can find the files associated with the process. Sometimes this might need to be performed manually and collected manually so that you can upload it via some manual process due to lack of connectivity in an environment to the outside world. i.e. internet.

It’s a follow on from a previous post that talks about the same process in Simpana 9. Which you can find here.

Hope you enjoy the demo. If this post helps you, please leave a comment.

Simpana 10 – advanced client properties – firewall – outgoing routes UI change

Noticed that the Simpana 10 Advanced client properties – firewall – outgoing routes user interface changed a little between SP5a and SP6. It may have happened on SP5b, but I couldn’t test at the time, but saw the difference certainly between our jump from SP5a to SP6.

Check out the pictures below to see what I mean. Looks like they relabelled some items.

Advanced Client Properties - Outgoing routes - SP5a
Advanced Client Properties – Outgoing routes – SP5a
Advanced Client Properties - Outgoing routes - SP6
Advanced Client Properties – Outgoing routes – SP6

Simpana 10 – PostgreSQL 8.4 backup on CentOS Linux 5.10 x64 – example

I am going to assume that this is a test deployment and as such will expect that you have installed your CentOS 5.10 x64 Linux the way you want it, and I will follow on from that point on what I needed to perform to get the distribution release of PostgreSQL to work with Simpana 10 PostgreSQL iDA to perform a backup. Of course some assumed knowledge present.

  1. Install the postgresql packages onto your  CentOS client.
    $ sudo yum install postgresql84 postgresql-server postgresql-devel
  2. Startup postgresql server for the first time, you need to run initdb switch instead of start for the first time only.
  3. $ sudo service postgresql initdb
  4. We should also enable the service to run at boot moving forward
    $ sudo chkconfig postgresql on
  5. Before we change the authentication method below, we need to set a password that we know for the postgres user in the postgresql database. To perform this we need to change to the postgres user and connect to postgresql database and update the password for the user to something we know.
    $ sudo su –
    # su – postgres
    $ psql
  6. Now at the postgres prompt update the password for the postgres user, unless you want to make your own. Won’t discuss how, just going to show how to set postgresql user password. Be sure to remember what you set the password too, it will be required later on.
    postgres=# ALTER USER postgres WITH PASSWORD ‘password’;
    ALTER ROLE
    postgres=#q
  7. Postgresql packages distributed with CentOS don’t use md5 password authentication, it defaults to peer/ident based authentication. In this example we will flip this to md5 based authentication, and we will touch on a peer/ident based authentication example in a later post. Perform the changes below to enable md5 authentication.
    $ cd /var/lib/pgsql/data
    $ sudo vi pg_hba.conf
    Find the line at the bottom of the file that looks like the one below;
    local     all     all                ident
    You need to change this to have md5 on the end, i.e. replace ident to be md5 instead. Save the changes.
  8. Now restart postgresql for the changes to take effect. (required)
    $ sudo service postgresql stop
    $ sudo service postgresql start
  9. Now you can test that this has worked by execution as root the command below, and when prompted for the postgres user password authenticate using the password set in step 6.
    # psql -U postgres
    If it worked, you will get the famous postgres=# prompt, in which you can enter q [enter] to quit it.
  10. Next up we now need to enable archive logs. We need to edit the postgres.conf file which on CentOS rpm based install is /var/lib/pgsql/data and the lines we need to add in the Archiving section is below;
    archive_mode = on
    archive_command = ‘cp %p /var/postgresql/archive/%f’
    Save those additions and move on below.
  11. Make sure to create the folders/destination used in the archive_command above and ensure postgres user can write to it etc.
  12. Now restart postgresql for the changes to take effect. (required)
    $ sudo service postgresql stop
    $ sudo service postgresql start
  13. Install the Simpana PostgreSQL iDA.
  14. Once installed refresh the Simpana Console and attempt to create your PostgreSQL instance. See the dialog below for the values I used in this configuration. Of course the username is the postgres user and password we configured in step 6. Note the archive log directory is the one we used in the archive_command string at step 10 too.simpana_10-centos-5.10_x64-postgresql_instance_creation
  15. If everything goes to plan you should have your instance created and now you can do configuration against the DumpBaseBackupSet subclient and/or FSBasedBackupSet subclient. For the difference between what each does, I recommend you review the documentation. As each backupset has its own unique capabilities. See the bottom of the Backup documentation page for explanations.
  16. Assign a Storage Policy to each subclient and run a backup of each to confirm it works.

CommVault Documentation references:

Simpana 10 – Linux client prepost command execution failure

Came across an interesting condition today, which took me a bit of testing to identify why the job would go into a pending state. This one relates to Simpana 10 on a Linux client where you have a File System iDA with a PrePost command being executed. In my test below the script is doing nothing special, it’s merely to have something to execute to show the behavior. I’ve provided it below purely for reference.

[root@jldb1 bin]# cat pre-scan.sh
#!/bin/sh
# test
#

echo $1 $2 $3 $4 $5 $6 $7 $8 $9 >> /root/pre-scan.log
exit 0

Job goes pending and produced the following errors and output below;

JPR (Job Pending Record)
Error Code: [7:75]
Description: Unable to run [/usr/local/bin/pre-scan.sh] on client.
Source: jwcs, Process: startPrePostCmd

simpana_10-linux-prepost-command-execution-failure

[JobManager.log – commserve]

3024  d88   03/27 18:16:26 21  Scheduler  Set pending cause [Unable to run [/usr/local/bin/pre-scan.sh] on the client.                 ]::Client [jwcs] Application [startPrePostCmd] Message Id [117440587] RCID [0] ReservationId [0].  Level [0] flags [0] id [0] overwrite [0] append [0] CustId[0].
3024  118c  03/27 18:16:26 21  Scheduler  Phase [Failed] message received from jwcs.lab.heimic.net] Module [startPrePostCmd] Token [21:3:1] restartPhase [0]
3024  118c  03/27 18:16:26 21  JobSvr Obj Phase [3-Pre Scan] for Backup Job Failed. Backup will continue with phase [Pre Scan].

[startPrePostCmd.log – commserve]

4940  e4c   03/27 20:21:46 ### Init() - Initializing job control [token=21:3:7,cn=jwcs], serverName [jwcs.lab.heimic.net], ControlFlag [1], Job Id [21]
4940  e4c   03/27 20:21:47 ### Cvcl::init() - CVCL: Running in FIPS Mode
4940  e4c   03/27 20:21:48 ### CVJobCtrlLog::registerProcess(): successfully created file [C:Program FilesCommVaultSimpanaBaseJobControl4.940]
4940  e4c   03/27 20:21:48 ### ::main() - jobId 21 - restoreTaskId = 0
4940  e4c   03/27 20:21:48 ### ::main() - jobId 21 - adminTaskId = 0
4940  e4c   03/27 20:21:48 ### ::getBackupCmdAndMachine() - jobId 21 - before construct application id
4940  e4c   03/27 20:21:49 ### ::getBackupCmdAndMachine() - appTypeId = 29
4940  e4c   03/27 20:21:49 ### ::getBackupCmdAndMachine() - jobId 21 - symbolic AppId = 2:20
4940  e4c   03/27 20:21:49 ### ::getBackupCmdAndMachine() - jobId 21 - prePostId = 1
4940  e4c   03/27 20:21:49 ### ::getBackupCmdAndMachine() - jobId 21 - preifind cmd = /usr/local/bin/pre-scan.sh
4940  e4c   03/27 20:21:49 ### ::main() - jobId 21 - commandPath = /usr/local/bin/pre-scan.sh
4940  e4c   03/27 20:21:49 21  ::main() - jobId 21 - before execute cmd
4940  e4c   03/27 20:21:49 21  ::main() - jobId 21 - Use Local System Acct.
4940  e4c   03/27 20:21:49 21  ::main() - jobId 21 - remoteexename = [/usr/local/bin/pre-scan.sh]
4940  e4c   03/27 20:21:49 21  ::main() - jobId 21 - args = [ -bkplevel 1 -attempt 7 -job 21]
4940  e4c   03/27 20:21:49 21  executePrePostCmd() -  Attempting to execute remote command on client [jldb1]..
4940  e4c   03/27 20:21:49 21  executePrePostCmd() - jobId 21 - Received error text from server cvsession [Unknown Error]
4940  e4c   03/27 20:21:49 21  executePrePostCmd() - jobId 21 - Error [0] returned from executeRemoteCommand /usr/local/bin/pre-scan.sh
4940  e4c   03/27 20:21:49 21  EvEvent::setMsgEventArguments() - MsgId[0x0700004b], Arg[1] = [117440623]
4940  e4c   03/27 20:21:49 21  EvEvent::setMsgEventArguments() - MsgId[0x0700004b], Arg[2] = [/usr/local/bin/pre-scan.sh]
4940  e4c   03/27 20:21:49 21  EvEvent::setMsgEventArguments() - MsgId[0x0700004b], Arg[3] = []
4940  e4c   03/27 20:21:49 21  EvEvent::setMsgEventArguments() - [MsgId[0x0700004b][]: [3] Args Pushed, [1] Args expected.
4940  e4c   03/27 20:21:49 21  ::exitHere() - jobId 21 - Exiting due to failure.
4940  e4c   03/27 20:21:49 21  BKP CALLED COMPLETE (PHASE Status::FAIL), 21. Token [21:3:7]
4940  e4c   03/27 20:21:53 21  ::exitHere() - jobId 21 - startPrePostCmd Terminating Event.
4940  238c  03/27 20:21:53 21  CVJobCtrlLog::unregisterProcess(): successfully removed file [C:Program FilesCommVaultSimpanaBaseJobControl4.940]

[cvd.log – client]

30846 427e0940 03/27 20:21:50 ### [CVipcD] Requests from non-CS with hostname [jwcs.lab.heimic.net] and clientname [jwcs] to execute in user entered path are not allowed

I worked out this problem is caused by lack of value in regkey sCSGUID as found in the location below;

/etc/CommVaultRegistry/Galaxy/Instance001/CommServe/.properties

Sample below;

[root@jldb1 ]# cat /etc/CommVaultRegistry/Galaxy/Instance001/CommServe/.properties | more
bCSConnectivityAvailable 1
sCSCLIENTNAME jwcs
sCSGUID
sCSHOSTNAME jwcs.lab.heimic.net
sCSHOSTNAMEinCSDB jwcs.lab.heimic.net

sCSGUID should be populated and its lack of value causes this condition with pre-scan script execution.

Fix:

Easiest method to recreate this regkey value is to do a local uninstall of the simpana services on the client. Revoke the client certificate in Simpana Console via Control Panel – Certificate Administration for the client in question. Followed by a reinstall.

Observation:

Subclients that have no scripts being executed as part of the backup will run fine if this regkey value is missing. You will never see a problem until you add a script. In addition, clients that have a simpana firewall configuration will be broken and subclients without scripts will break too. As the regkey value is used for simpana firewall configuration exchange I believe based on my testing.

Hope you enjoy my post… drop me a comment if you like the content and/or it helps you.