Based on the definitions above, if you don't plan to preserve any data or user state of the current existing installed OS, you should opt to use Bare Metal deployments. Another thing to note is that Re-imaging only supports the same architecture. You can only upgrade the OS or install a later service pack, but you cannot downgrade architectures (64bit to 32bit) or OS (Wind7 to WinXP). You cannot also change from a server (Win2000) to a desktop (Win7).

According to the documentation, you should be able to find the download link from the Cloud Orchestrator web user interface Home page. There should be a link for Download command-line tools. This is mentioned on the following links:

3. If the error log is not owned by the Tivoli Storage Manager instance user ID, remove it. If the error log is owned by root and you are
currently logged on with the server instance userid, you need root authority to remove the file. For example :

Disasters, by their very nature, cannot be predicted, in either their intensity, timing, or effects. However, all enterprises can and should prepare for whatever might happen in order to protect themselves against loss of data or, worse, their entire business. It is too late to start preparing after a disaster occurs. This article will help you as a TSM Administrator to protect against a disaster - taking you step by step through the planning and recovering stages.

TSM Disaster Recovery Concepts, Constructs and Methodologies:

Before an administrator can start implementing disaster recovery plans for TSM managed data, there are several concepts and constructs that must be understood.

The TSM Database

The TSM database is the heart of a TSM server; without the database, the server is dead! There is no way to restore TSM backups (except for client backup sets) without the database. Most administrators choose to keep 4-5 daily backups of the TSM database. If an administrator is doing off-site disaster recovery planning, he or she usually chooses to keep two sets of 4-5 daily backups of the TSM database; one set is kept on-site for immediate recovery while another is kept at an off-site location in case of total facility loss.

Device Configuration and Volume History

TSM stores information about volumes (e.g. tapes) it uses in its database. Specifically, when a database backup is made, a record is created in the TSM database containing the volume serial number of the tape used for the backup, the date, and the type of backup (e.g. full, snapshot, etc). Since there may be hundreds of tapes in a library, this information is needed in order to find the most recent backup.

A volume history file to be created file contains information on all the volumes used by the TSM server, including the volumes used for database backup. The file is typically created on a daily basis after the database backup is made, and when restoring the database, the file can be used to find the tape that contains the appropriate database backup to restore.

Just like the volume history, TSM stores information on connected storage devices in its database. And just like volume information, an administrator will need to use those devices to restore the database in the event of its loss. The TSM server, thus, allows device information to be written to a text file called a device configuration file. This file is usually created daily and is read by the server when restoring the database from backup.

Copy Storage Pools

TSM backed up and archived data is stored on storage pools which are, by definition, collections of like media. TSM allows a storage pool to be duplicated to protect against loss or failure of media. This storage pool backup is called a copy storage pool. It is recommended to have at least one copy storage pool for all data that is stored on tape. The copy storage pool can be stored at a physical location which is separate from the primary storage pool (i.e. outside the tape library or off-site) for disaster recovery purposes.

These should be included in TSM daily schedule administrative tasks for a server.

Backup database

To keep the Tivoli Storage Manager database safe is to create regular Full backups and periodic Incremental backups. This type of process can be scheduled inside of TSM so that it occurs at regularly scheduled intervals.

Step 1: Defining device classes for database backups

Step 2: Doing Full and Incremental Backup

** The first backup of your database must be a full backup. You can run up to 32 incremental backups between full backups.

Full Backup

Incremental Backup

Backup dsmserv.opt file

Save a copy of dsmserv.opt to your backup directory

Backup Device Configuration (Devconfig) and Volume History (Volhist

For Item I) and III), you can create a backup script. Suggested to gather these items into a single scheduled set of commands. The reason is that some of the steps need to occur in the correct sequence and this makes sure that they do. The steps as below:

Step 1 : Define the script

Step 2 : Test run the script

Step 3 : Define a schedule to run the script daily

B) Recovering the server (after disaster)

This section provides an overview of the tasks involved in recovering the server. The steps are performed by the on-site administrator. Here are the very brief guidelines for recovering your server:

Locate a suitable replacement machine.

Restore the operating system, the Tivoli Storage Manager server software, the Tivoli Storage Manager licenses, and the administrative client on the replacement hardware. Ensure that the environment is in the original. The environment includes:

The directory structure and location of the TSM server executable, enrollment certificates, administrative command line client, and disk formatting utility.

The directory structure for TSM server instance-specific files and the database, log, and storage pool volumes

Copy the TSM server options file (dsmserv.opt) that you backup previously to its original location.

Copy the volume history file (volhist.out) and device configuration file (devconfig.out)required by database restore to its original location.

Issue the DSMSERV RESTORE DB command.

Start the server.

Register TSM server licenses.

Due to changes in hardware configuration during recovery, you might have to update the device configuration file in the restored Tivoli Storage Manager database. You can get the details on this guidelines from IBM Knowledge Center at :

There is no direct IBM Tivoli Storage Manager (TSM) command, which can be used to move/migrate backupsets from one device class to another (from tape to VTL). The workaround that can be used is define another server instance and restore the backupsets, then generate it again to the new dev class (VTL).

Example steps which can be follow for the workaround:

1. Create a further TSM server instance on the same machine with access to the same libraries (new and old) via library sharing.
2. Register the node, whose backupsets needs to be migrated, on the new server instance with the same nodename as on the original TSM server
3. Restore on a client test machine the "old" backupset with this nodename
4. Backup the data to the new server instance using the same nodename
5. Generate a backupset on the new server instance with a devclass pointing to the new library for this clients data
6. Define the newly generated backupsets to the original server with a retention, which meets the remaining retention period of the original backupset
7. Repeat this (except the first step) for all remaining backupsets
8. After all backupset has been 'migrated' the extra TSM server instance isn't needed any more and can be deleted

Scenario

To comply with your company security policies, you have installed the latest Java version. However, this Java version is not compatible with the Deployment Editor, as it requires an older version of Java. Knowing this, when you tried to go ahead and run Deployment Editor, you're facing errors, most probably because of the unsupported Java version. And you cannot change your Java version to the previous version because of security compliance.

Installing jPortable requires an internet connection, as it will download the Java directly from Oracle / Sun site. If you have internet connection, you can skip downloading the Java manually step. Otherwise, please follow the next step.

Once downloaded, move it to the same location as the jPortable installer.

Installation

Create a folder inside you USB drive, for example F:\PortableApps or you can save it on your local drive as well

Run the jPortable installation file

Select F:\PortableApps\CommonFiles\Java as the destination folder

jPortable installer should be installing jPortable by using the Java offline installer located in the same location if you have downloaded it earlier. Otherwise, it will try to download it from the internet

Most of the Bluemix or Cloud Foundry (CF) related article mentioned on how to deploy/run Wordpress⇗ on Bluemix or CF but there isn't anything specific on Joomla. So, based on my experience in PHP, MySQL and Joomla, I have done some trials and testings that can help you jumpstart on running Joomla on Bluemix.

However, please proceed with caution as I haven't got the chance to fully test this solution.

So, what is Joomla? Like Wordpress, Joomla is a content management system (CMS), which enables you to build Web sites and powerful online applications. It is one of the most popular CMS available which is running on PHP, or LAMP (Linux, Apache, MySQL, PHP). Plus, it is an open source solution, free for everyone to use.

Next, we will create the services. For Joomla, typically we will need a database service, and optionally, an email service.
Based on the existing services in Bluemix marketplace, we will use ClearDB (MySQL) for the database and Sendgrid for the email.

Now, login to Bluemix using the Cloud Foundry cli. Run the following login command:

Please enter your own username and password. By default, ORG is your email/username, and SPACE is dev. However, if you just typed cf login only, you will be prompt with the required values.

To view the list of services available in the marketplace, run the following command:

cf marketplace

You can also use cf m for short.

As you can see, there are cleardb and sendgrid services that we can use. There is also mysql but we're going to use cleardb instead.

To create cleardb service, run the following command:

cf cs cleardb spark ClearDBJoomla

cf cs is the short form for cf create-service. The above command will create a cleardb service, using spark plan, and named ClearDBJoomla. If you notice, ClearDBJoomla is mentioned in the manifest.yml file earlier. This is based on the following usage:

cf create-service SERVICE PLAN SERVICE-INSTANCE

Next, we will create the sendgrid service:

cf cs sendgrid free SendGridJoomla

If you have previously created a sendgrid service, you may have problems creating another one. In that case, you can just reuse the existing sendgrid service. To do so, you need to change the manifest.yml file accordingly.

Then, we need to deploy or push Joomla to Bluemix. But before that, just want to note that we're using a PHP 3rd party buildpack. If you run cf buildpacks you will notice that PHP is not included, hence we will import the buildpack from outside. In this case, we're using cf-php-build-pack. It is one of the community built buildpacks available that is widely used. This buildpack is using PHP 5.4, so this is compatiable with our Joomla version.

To deploy Joomla to Bluemix, make sure that you're at the same folder where you created the manifest.yml file. There's one important step that needs to be done. Create a new folder called htdocs and move all files and folders, except manifest.yml to htdocs. This is because, Joomla has a folder called libraries. When you push the files as it is, the libraries folder will be moved outside of htdocs which is needed for Joomla. In order to avoid this, all folders need to be moved into the newly created htdocs and all the files will be included accordingly.

Next, run the following command to push Joomla to Bluemix:

cf push

Once pushed, you wil receive a App started message.

Visit the urls mentioned in the message using your favorite browser to configure Joomla. For example: http://JoomlaTest.mybluemix.net.
You may notice that by default, Bluemix will change your hostname to lowercase instead.

Opps! It seems that we can't continue. In the pre-installation check, database support is listed as no. We will need to append some options to the PHP buildpack that we're using.

On the same location as the manifest.yml file, create a directory / folder named .bp-config and create a file named options.json inside it. Please note the dot before bf-config name. If you're using linux, you can use the following commands:

Once the file is create, edit it using your favorite text editor. Please note that you may not be able to see the .bp-config directory as it is hidden. Hence, you need to manually key in the folder name instead of selecting it.

In the Configuration tab, feel free to enter the fields. Make sure you remember the admin username and password. You can set your site Offline if needed. Then click Next.

In the Database Configuration tab, you will need to enter the ClearDB parameters. In order to view the needed values, we need to view the app environment on Bluemix, which has binded the ClearDB services. Please run the following command accordingly:

cf env Joomla

Note: Joomla is the name of the application
They will list out the services parameters, which includes the credentials as well. Copy the credentials from cleardb service, and use that for the Database Configuration tab.
Feel free to change the Table Prefix if you want, but for now, we'll leave is as it is. Then, click Next.

In the Overview tab, you can select to install Default English (GB) Sample Data if you want. Then click Install.

You will received Congratulations! Joomla! is now installed message. Then, you need to click Remove installation folder before you can proceed. This will literally delete the installation folder from the Joomla base directory. However, this folder will still exist in your local directory.

Post-installation tasks

Once logged in, open your Joomla application and click on Files and Logs on the left navigation bar.

Under the Files and Logs open app > htdocs and click configuration.php. This file is created once you have finished configuring Joomla.

Copy the content and create the same file under htdocs locally, paste the copied content, and save the file. This is important in case that you need to push your application again, you don't have to reconfigure it.

There is no Proviso info from above technote. IBM does not bundle any shell in TNPM . It is rely on the native shell that is installed on the platform. If you have patched the bash shell then TNPM will not reintroduce the problem. There will be no impact of this fix on Proviso.