Follow Us on Twitter

A small and clean WebLogic cold backup

by Laurens van der Starre on March 7, 2013 · 1 comment

In one of my projects we have to be able to set up a (cold) backup Oracle Service Bus domain in a different data center from a domain backup. One of the requirements was that this data center is -for security reasons- completely independent of the “main” data center. In this particular case, just syncing the middleware home and domain directories wasn’t an option.

Fair enough, and not that difficult at all. Setting up this cold backup domain is just using the pack & unpack tools from WebLogic, and “cloning” your domain. Keeping you cold backup domain up to date can be done by just syncing the configuration backups the “main” domain can automatically create for you:

<YOUR DOMAIN> -> Configuration -> General -> Advanced.


Config Archive in WebLogic

Config Archive in WebLogic


With this option enabled, every time an configuration change is activated in your domain, the complete config directory is JAR’ed, and stored in DOMAIN_HOME/configArchive. Getting the latest configuration state in your cold backup domain is just deleting the contents of the config directory and “un-tar” the config backup jar from your main domain in the config directory.

However, if you have set up your cold backup domain using pack and unpack, WebLogic’s “salt” and security configuration such as DefaultAuthenticatorInit.ldif and XACMLRoleMapperInit.ldif are automatically generated. This makes your config archives from your main domain incompatible with your backup domain. Not only isn’t WebLogic able to decrypt the encrypted passwords from the config.xml, the deployed applications in your domain aren’t allowed to run. Although your weblogic-user’s password is set up correctly, nice error messages such as

<Critical> <WebLogicServer> <BEA-000386> <Server 
subsystem failed. Reason: 
Authentication for user weblogic denied

will fill the logs.

The solution is straightforward: when using the tool, make sure that you add/inject the files DefaultAuthenticatorInit.ldif and XACMLRoleMapperInit.ldif from the DOMAIN_HOME/security directory into the created JAR file. For example:

# Pack -domain=<YOUR DOMAIN HOME> -template=./backup.jar -template_name=backupDomain

# Inject
jar ufv backup.jar <YOUR DOMAIN HOME>/security/DefaultAuthenticatorInit.ldift

jar ufv backup.jar <YOUR DOMAIN HOME>/security/XACMLRoleMapperInit.ldift

Also, backup the <YOUR DOMAIN HOME>/security/SerializedSystemIni.dat from your main domain separately. This is the “salt / seed” of the encrypted passwords in your configuration. ¬†Now, when using unpack to create your cold backup domain, the¬†DefaultAuthenticatorInit.ldif and XACMLRoleMapperInit.ldif are already present. Copy the SerializedSystemIni.dat to your new domain in the security directory, and your cold backup domain should be compatible with your “main”-domain’s config archives.

Using this method my backups for the cold backup domain consists of of the packed domain, the latest configuration archive from the main domain, the SerializedSystemIni.dat, and some misc config files (such as the Basically, I only have to make sure that the configuration archive is up to date in the backup. Nice, clean, small and simple. This backup allows me to quickly setup an new production domain in case of an emergency, using this backup and readily available OSB en WebLogic binaries and deployments from SVN.

A small and clean WebLogic cold backup, 4.0 out of 5 based on 6 ratings
VN:D [1.9.22_1171]
Rating: 4.0/5 (6 votes cast)

{ 1 comment… read it below or add one }

kumar madduri June 23, 2015 at 11:23 am

Instead of pack and unpack, would tar ball of the entire oracle home and domain home be more fool proof.
From what I understood only creates jar file of config directory.


Leave a Comment


Previous post:

Next post:

About Whitehorses
Company profile

Whitehorses website

Home page

Follow us
Blog post RSS
Comment RSS