WAS v8.5 > Set up the application serving environment > Administer nodes and resources

Configure checkpoints

Repository checkpoints represent saved images of the repository before configuration changes are made. Checkpoints are either full or delta images. A full checkpoint is created manually by the administrator and is a copy of the entire configuration repository. This includes applications and connectors. Delta checkpoints are optional and are not enabled by default. A delta checkpoint is created automatically when configuration changes are made and saved to the configuration repository. The delta checkpoint is formed by making a copy of the configuration documents affected by the configuration change before changes are actually applied.

New feature:

We can configure a checkpoint to back up copies of files from the master configuration repository. A full checkpoint is a complete copy of the entire configuration repository. A delta checkpoint is a subset snapshot of the configuration repository that is made when we change a product configuration. Use a checkpoint to restore the configuration repository back to a prior state.

If you are a user with either a monitor or an operator role, we can only view the repository checkpoint information. If you are a user with either a configurator or an administrator role, we have all configuration privileges for repository checkpoints.

Ensure that we have an adequate number of open file descriptors available. The default number of open files setting is 2000, which is typically sufficient for most applications. If the value set for this parameter is too low, errors might occur when opening files or establishing connections. Because this value limits the number of file descriptors that a server process might open, a value that is too low prevents optimum performance. For more information, see Tuning operating systems. We can use the dmgr console or wsadmin RepositoryCheckpointCommands to create, export, or delete checkpoints.

• Create a full checkpoint.

  To use the dmgr console to create a full checkpoint, use the Repository checkpoints page. From this page, we can create, delete, and restore checkpoints.

  1. Click System administration > Extended repository service > Repository checkpoints.

  2. Select New. You are prompted for confirmation before proceeding. While the checkpoint is being created, the repository is locked. You have read access only to configuration data while the checkpoint is being created. Any attempt to make a configuration change during this period fails.
  3. Name the checkpoint.

  4. Type a checkpoint description.

  5. Click Apply or OK.

  To use the createFullCheckpoint command, see the topic about the RepositoryCheckpointCommands command group for AdminTask.

• Enable or disable automatic checkpoints.

  To use the dmgr console to enable or disable checkpoints, use the Extended repository service page.

  1. Click System administration > Extended repository service.

  2. Select Enable automatic repository checkpoints to enable checkpoints.

     Clear the check box to disable automatic checkpoints.

  3. For Automatic checkpoint depth, specify the maximum number of checkpoints to keep.

     After the number of checkpoints reaches this checkpoint depth, the product deletes the oldest delta checkpoint when a new delta checkpoint is made.

  4. Click Apply or OK.

  To use the setAutoCheckpointEnabled and setAutoCheckpointDepth commands, see the topic about the RepositoryCheckpointCommands command group for AdminTask.

• Archive checkpoints to save product configurations.
• Delete checkpoints to free up disk space and remove unwanted checkpoints.
• Restore checkpoints.
• Find configuration changes in delta checkpoints.

• Enable audit records when saving changes to the master repository
  1. Enable automatic checkpoints.

  2. Enable security audit and ADMIN_REPOSITORY_SAVE event filter.

     1. Click Security > Security auditing > Event type filters > New.

     2. Type a name for the filter, such as repository_save_filter, enable the ADMIN_REPOSITORY_SAVE event and the SUCCESS outcome, and then click Apply or OK.

     3. Click Security > Security auditing > Audit service provider. Click on the audit service provider to use to emit the new event, such as auditServiceProviderImpl_1, enable repository_save_filter, and then click Apply or OK.

     4. Click Security > Security auditing > Audit event factory configuration. Click on the audit event configuration to use, such as auditEventFactoryImpl_1, enable repository_save_filter, and then click Apply or OK.

     WAS v8.5 generates a new audit record whenever the configuration repository changes. A new audit record resembles:

     Seq = 42 
     | Event Type = ADMIN_REPOSITORY_SAVE | Outcome = SUCCESSFUL | OutcomeReason = SUCCESS | OutcomeReasonCode = 109 
       | SessionId = null 
     | RemoteHost = null | RemoteAddr = null | RemotePort = null | ProgName = adminRepositorySave 
       | Action = createDeltaCheckpoint 
     | AppUserName = user1 | ResourceName = Delta-1328459402156 | RegistryUserName = null | AccessDecision = authzSuccess 
     | ResourceType = delta checkpoint | ResourceUniqueId = 0 | PermissionsChecked = null | PermissionsGranted = null 
     | RolesChecked = null | RolesGranted = null | CreationTime = Sun Feb 05 10:30:21 CST 2012 | GlobalInstanceId = 0 
     | EventTrailId = -1444791282 | FirstCaller = user1 | Realm = defaultWIMFileBasedRealm | RegistryType = WIMUserRegistry

     Event Type = ADMIN_REPOSITORY_SAVE indicates that only successful saves result in an audit record. ResourceName = Delta-1328459402156 indicates the name of the checkpoint.

     If the security auditing is enabled and an audit event filter is created for ADMIN_REPOSITORY_SAVE event in audit.log, disabling the automatic checkpoint causes the product to stop generating audit records for the configuration repository changes in the log file (BinaryAudit_xxx.log). Warning message XREP0022W is written to the system log about this situation.

     If the automatic checkpoint is disabled, enabling the security auditing filter for the ADMIN_REPOSITORY_SAVE event does not capture the changes to the configuration repository and corresponding audit records. A warning message SECJ7471W about this situation is written to the system log.

Results

You configured a checkpoint to back up copies of files from the master configuration repository. If you created a full checkpoint, you made a complete copy of the entire configuration repository. If you enabled delta checkpoints, subset snapshots of the configuration repository are created when we make a change to the configuration.

After creating a checkpoint, we can archive it to save the configuration files, delete it, or restore the configuration.

To undo recent changes, restore delta checkpoints in the reverse order in which they were created. If you created a full checkpoint, we can restore the entire configuration repository back to the state it was in at the time the full checkpoint was made.

Subtopics

• Repository checkpoint and restore function
  With the repository checkpoint and restore function, we can back up copies of files from the master configuration repository. We can use the backups to restore the configuration to a previous state if future configuration changes cause operational problems. By using this function, we can reduce recovery time for problems that are caused by configuration changes. Studies of unplanned outages have shown that as much as 36 percent of unplanned outages are due to operator errors. A common source of operator error is a bad configuration change. The ability to undo a bad configuration change is critical to minimizing the outage window.
• Archiving or deleting checkpoints
  To reduce clutter and free up disk space, we might need to archive or delete old checkpoints periodically. The number of checkpoints stored to disk especially adds up when automatic delta checkpoints are enabled and checkpoint depth is high. WAS v8.5 automatically deletes delta checkpoints when the number of checkpoints reaches the checkpoint depth. To preserve delta checkpoints, you must archive checkpoints before they are automatically deleted.
• Restoring checkpoints
  Use a full checkpoint to restore the entire configuration repository back to the state it was in at the time the full checkpoint was made.
• Finding configuration changes in delta checkpoints
  If automatic repository checkpoints are enabled, the product creates a delta checkpoint whenever a change is made to the configuration repository. A delta checkpoint compressed zip file contains the before and after versions of configuration files that have changed. We can extract the contents of the compressed file and then examine the extracted files to determine what has changed in the configuration.
• RepositoryCheckpointCommands command group for AdminTask using wsadmin.sh
  We can use the Jython or Jacl scripting language to create, restore, delete, and administer checkpoints with wsadmin. Repository checkpoints represent saved images of the repository before configuration changes are made. The commands in the RepositoryCheckpointCommands group support the repository checkpoint functions in wsadmin local and connected modes.
• Extended repository service settings
  Use this page to configure the repository checkpoint location and to enable automatic checkpoints. The extended repository service enables you to back up and restore the configuration repository. The configuration repository contains documents that manage the product configuration.
• Repository checkpoint page
  Use this page to create, delete, restore, and export checkpoints. Repository checkpoints represent saved images of the repository before configuration changes are made. Checkpoints can be either full or delta images. A full checkpoint is created manually by an administrator and is a copy of the entire configuration repository, including applications and connectors. A delta checkpoint is created automatically when the configuration is changed and contains copies of the affected configuration documents before the changes are made. Use checkpoints to restore the configuration repository back to a prior state.
• New repository checkpoint settings
  Use this page to create a full checkpoint of the configuration repository. A full checkpoint is a copy of the entire configuration repository, including applications and connectors. Use a full checkpoint to restore the entire configuration repository back to the state it was in at the time the full checkpoint was made.
• Checkpoint settings
  Use this page to view configurations of a checkpoint. Repository checkpoints represent saved images of the repository before configuration changes are made. Checkpoints can be either full or delta images.

Related concepts:

Repository checkpoint and restore function

Related

Tune operating systems
Restoring checkpoints

Reference:

RepositoryCheckpointCommands command group for AdminTask using wsadmin.sh

+

Search Tips   |   Advanced Search