Websphere application server represents its administration configuration as XML files. You should back up the configuration on regular basis as well as before your make any big changes in the configuration. You can restore configuration from backed up file only if the WAS version is not changed i.e. WAS version at the time you backed up configuration should be same as that the time when you restored configuration.
Below steps can be followed to backup and restore the Admin configurations when required:
The backupConfig command is a simple utility to backup the configuration of your node to a file. Before executing this command make sure that your configuration is in the consistent state and then synchronize to all the nodes.
When you execute backupConfig command it will stop the node before backup is made so that partically synchronized information is not saved so you can specify -nostop command line parameter so that the backup is taken without stopping the server
cd to <WAS_INSTALLATION_ROOT>/IBM/WebSphere/AppServer/profiles/Dmgr01/bin folder
Execute below command in bin folder to start backing up:
backupConfig.sh backup_file [options]
— where backup_file specifies the file to which the backup is written. If you do not specify one, a unique name is generated.
— To check more about options go to the end of article links about backupConfig and restoreConfig Tools
Ex: backupConfig.sh DMGR_BkUp_29_02_2012.zip
command to restore the configuration of your node after backing up the configuration using the backupConfig command.By default, all servers on the node stop before the configuration restores so that a node synchronization does not occur during the restoration. If the configuration directory already exists, it is renamed before the restoration occurs. If you directly make changes to the application files in the app_server_root/installedApps directory, a process known as “hot deployment”, but do not make the same changes to the application files in the app_server_root/config directory, the changes might be overwritten if you use the restoreConfig command.
Here you can restore the previously created backup zip file using a command from bin folder like below
Few places where its in production servers and the changes to configuration files are tracked by tickets or bugs you may follow below steps which works but not a suggested method to do as you may loose data and logs but in desperate situations it’s a life saver.
Take a tar or zip of working and fully configured IBM folder which includes all files and when ever there is a corruption and there is no drive restore point just move(dont delete) the OLD not working/Corrupt IBM folder like “mv -f IBM IBM_bkup”
and Extract the zipped working IBM folder in the same place. then start all the services.
This is not at all suggested but in one of customer env. I faced a issue where rebuilding would have taken 5days as so many changes are gone in to the default installation. if I would have started from scratch , client would have lost millions of revenue as all apps were production apps and heavily used. Thank god I had a practice of creating a zip file of total IBM folder before I go for patching and after patching success. So I had a most recent backup with all patches . When the system went corrupt and they had no recent backups , my own IBM folder zip file helped and saved 5days of work and headache.