To Back Up Your Existing Sun Aduva OnStage Installation

This procedure will back up the data from the Sun Aduva OnStage installation except for the following:

• The credentials you entered to access software directly from a vendor, such as for the Solaris patches

  Add these credentials after the upgrade is complete by using the Sun Update Connection – Enterprise Authentication window.

• The cached public components that were downloaded with Sun Aduva OnStage

  Download the cached public components after the upgrade is complete.

To perform the upgrade from Sun Aduva OnStage 439 to Sun Update Connection – Enterprise 1.0.x, see To Upgrade From Sun Aduva OnStage to Sun Update Connection – Enterprise.

1. Log in as superuser on your Sun Update Connection – Enterprise system dependency server.

2. Back up the Sun Aduva OnStage product.

   The script is a tar file of your existing Sun Aduva OnStage installation.

   # cd /usr/local/aduva/install # ./backup.sh

   The backup.sh script performs the following steps:

   • Stops the Sun Aduva OnStage services.

   • Verifies that the local system is the SDS.

   • Saves the data in the following directories and files under backup names:

     • /usr/local/aduva/director_server/public/* – Universal rules and components

     • /usr/local/aduva/director_server/private/* – Local rules and components

     • /usr/local/aduva/director_engine/*/bin – Settings files and encryption keys

     • /usr/local/aduva/install/* – Application installers, restore scripts, and support scripts

     The databases are backed up.

     All backup files created by the script are stored in one archive and saved in /usr/local/OnStage_backup/backup-yyyy-mm-dd-hh-mm.tar.gz.

   Save a copy of this archive file for possible future use.

3. Check the names of the categories that you created under Local.

   Make sure that all names are unique.

   For example, say that you use the following categories:

   • Local/Configuration files/test

   • Local/Macros/test

   • Local/Probes/test

   • Local/Post-Actions/test

   • Local/Pre-Actions/test

   Change the test categories to the following:

   • test_files

   • test_macros

   • test_probes

   • test_postactions

   • test_preactions

4. Complete the following checklist for jobs in the Status window:

   1. Decide whether to stop any incomplete jobs or to run any incomplete jobs to completion.

   2. For running running jobs that have a schedule, ensure that the next time it is scheduled to run is after the upgrade completes.

   3. Make sure that idle scheduled jobs are set to next run after the upgrade.

   4. Stop the jobs that are waiting for offline hosts.

   5. Run remaining active jobs to completion.

5. Complete the following checklist for the Consoles, APIs, CLIs and Agents:

   1. Exit all the Consoles.

   2. If a host is running the CLI or API commands, wait for the job to complete.

   3. Check that the Agent application on the managed hosts is not busy with any task.

   4. Check that the Agent application on the managed hosts is up and running.

6. Verify that you have no running jobs before you start the upgrade.

   See the jobs listed in Step 4.