In this recipe, we look into backing up and restoring Orchestrator. To back up and restore single packages or workflows, please see the Importing and exporting Orchestrator elements and Working with packages recipes in Chapter 4, Programming Skills.
There are several things that should be backed up; we will have a look at all of them.
This is a one off job. You only need to do it when you change the Orchestrator configuration:
- Open the Orchestrator Control Center.
- Click on Export/Import Configuration and then on Export Configuration.
- Select all the checkboxes.
- Depending on your security needs, assign a Password to the export.
- Click on Export.
- Place the file in a secure location where you can easily retrieve it in the case of a restore.
The backup of an external database is done with the normal enterprise methods. The internal Orchestrator PostgreSQL DB is a different thing:
- Connect to your Orchestrator OS via SSH.
- Run the following command to backup the Orchestrator DB:
pg_dump vmware -U vmware -Fp -c | gzip -c > vRO-DB.gz
- Save the dump in a place where you can find it again. Please also see the There's more... section of this recipe.
Assuming that your Orchestrator installation died and you need to restore it, follow these steps:
- Deploy a fresh Orchestrator appliance of the same version you lost.
- Open the Orchestrator Control Center.
- Stop the Orchestrator service.
- Click on Export/Import Configuration and then on Import Configuration.
- Browse to the Orchestrator backup file.
- You may need to enter a Password.
- Click on Import.
- Click on Home and then go to Import Database.
- Browse to the exported database file.
- Click Import database.
- Select the item you want to import (for a full restore, tick everything).
- Click on Finish Import.
- Start the Orchestrator service.
The Control Center configuration export helps quite a bit with preserving your Orchestrator configurations; however, it's not perfect. The best protection against any loss is solid documentation, where you write down the Orchestrator configurations, as well as why an item is configured the way it is.
Using an external database for Orchestrator has the immense advantage that this database can be backed up using the already-existing methods of your business. The Orchestrator database contains most parts of the configuration, but more importantly, it contains all workflows and workflow executions. Having a regular database backup is important.
If one restores the database, it's important to stop the Orchestrator server first.
The continued backup of the internal Orchestrator PostgreSQL database can be done with quite a lot of methods. Here we will discuss some of them.
The idea is to use the internal Linux scheduler (called CRON) to facilitate the backup. You need access to the Orchestrator OS as well as to a shared drive. There is a nice article that goes into this in more detail:
Using Orchestrator Policies, it is possible to create re-occurring tasks. We can use this to create a workflow that will back up the Orchestrator database either to a shared drive or send the export via a mail attachment.
See the recipe Working with policies in Chapter 8, Better Workflows and Optimized Working and the recipes Working with mails and File operations in Chapter 9, Essential Plugins.
The Control Center has an API that is REST and can be accessed. We have a short look at it in the recipe Control Center titbits in this chapter and a more detailed look in the recipe Accessing the Control Center via REST plugin in Chapter 7, Interacting with Orchestrator. You could use the REST to connect to the Control Center and then export the database this way.
The recipe Working with packages in Chapter 4, Programming Skills, shows you how to back up elements in Orchestrator.