Domain Backups

Now that you have created a domain, it is important to understand how to back up critical domain data in case of a failure. You can archive domain configurations in various ways by using periodic backups to tape or fault-tolerant disks, or by manually copying files to another machine. Having a backup allows you to restart the Administration Server on a different machine in case of failure, or restart a Managed Server in the absence of the Administration Server.

The three resources to back up are the configuration data for the domain, the security data for the domain, and, of course, any deployed applications.

13.4.1 Configuration Data

The most critical aspect of a domain configuration is the config.xml file that holds the configuration for the entire domain. The config.xml file usually is stored in the root directory of the domain. Although you can start a Managed Server without it in certain circumstances, it is necessary for the overall administration of the domain.

The file usually is accompanied by a useful secondary backup, config.xml.booted. This file is created only after the Administration Server has successfully started up. So, for instance, if you have made severe changes to the configuration for a domain, and the Administration Server no longer starts up, you can overwrite the config.xml file with the config.xml.booted file, and thereby restore the domain to its last known successful startup configuration. This is very useful while you are experimenting with the various domain options. We recommend that you back up both versions of the config.xml file.

WebLogic 8.1 also maintains a number of backups of the config.xml.booted file. For example, whenever you make a change to the domain, the current config.xml.booted file is archived to config.xml#2. When you make another change, the same thing happens after renaming config.xml#2 to config.xml#3, and so on. You can use the Administration Console to set the maximum number of archived versions to keep. Select the domain node in the left pane, and change the value of the Archive Configuration Count parameter in the Configuration/General tab. By default, WebLogic maintains five archived versions, all kept in the configArchive subdirectory of your domain.

WebLogic 8.1 also creates a config.xml.original file. Whereas the config.xml.booted file is created after the server has successfully started up, the config.xml.original file represents the config.xml file before the system has fully started. Some subsystems add information to the configuration file (for example, the security system adds serialized security information) when the Administration Server starts up, and the config.xml.original file captures the state before any of these changes take place.

13.4.2 Security Data

The Administration Server holds all of the security data for a domain. The domain's security data is spread across WebLogic's LDAP repository, the config.xml file, the SerializedSystemIni.dat file, the Security Configuration Data, and the keystores for the servers' identity and trusted certificate authority (CA) certificates. It also includes the boot.properties file, if it is being used to store the username and password for server startup.

Security data is as crucial as the domain's configuration file. Without a running Administration Server, the domain's security data cannot even be modified; without security data, you cannot start the Administration Server. For these reasons, it is important to maintain backups of the security data. Having a backup copy of the domain's configuration and security data allows you to restart the Administration Server on another machine, and subsequently regain control of the Managed Servers in case the Administration Server fails.

13.4.2.1 The LDAP repository

If you are using the default security realm and settings of WebLogic Server, the configuration data is stored in the embedded LDAP server within WebLogic Server. Chapter 17 explains more about how WebLogic uses an internal LDAP repository to persist its security settings. For a domain called mydomain, the Administration Server adminServer serializes this data into the mydomainadminServerldap folder. Note that WebLogic makes a backup of this data once a day, and then places the backup in the mydomainadminServerldapackup directory in the form of a ZIP file. Any changes to the security data made after the backup is created are reflected only on the next day's backup so, be aware that the ZIP may not always contain the latest security information.

Take care when backing up the ldap directory yourself. If anybody is modifying the security data during the time of the backup, the files may be copied while still in an inconsistent state. The ZIP backups created by WebLogic, albeit not always up to date, are always consistent.

The LDAP data is also replicated to all Managed Servers whenever changes are made to security settings using the Administration Console. Thus, it is not necessary to back up this data on the Managed Servers. You need to back up only the master LDAP data on the Administration Server.

Every server needs access to the security realm before it can start. If your WebLogic servers use the default security realm, all the necessary information will be stored in the LDAP repository, which gets replicated automatically to all Managed Servers. If, however, the domain uses a custom security realm, ensure that all of the servers can access the necessary information for this realm. Its configuration and repository should be added to your backup list as well.

13.4.2.2 The serialized security datafile

The SerialiazedSystemIni.dat file is located in the root directory of each server and contains encrypted security data necessary to start the server. This file also should be backed up.

13.4.2.3 Certificates

If the server has been configured to use SSL, the security certificates, keys, and keystores also need to be backed up. See Chapter 16 for more details on SSL configuration.

13.4.2.4 Security configuration data in WebLogic 7.0

For WebLogic 7.0, you also must back up the security configuration data, stored in the domain_nameuserConfigSecurity directory. WebLogic persists the security provider information here, and this data is used as the basis of a runtime cache.[2]

[2] WebLogic 8.1 stores this information in the domain's config.xml file.

Note that you can manipulate this security data in several ways. WebLogic lets you dump the security configuration data into an XML file. The data is actually a serialization of the security provider MBeans. You then can make changes to the contents of this XML document and reload the XML data into the MBean repository. WebLogic provides tools to do this mapping, which we describe later in Chapter 20. The following command maps the security information to an XML output file:

java weblogic.management.commo.WebLogicMBeanDumper -includeDefaults -name Security:* XML-file

This command will map the XML file back into WebLogic:

java weblogic.management.commo.WebLogicMBeanLoader XML-file