+

Search Tips   |   Advanced Search

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.

A new feature of WAS v8.5.5, 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 you change a product configuration. Use a checkpoint to restore the configuration repository back to a prior state.

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

(V8502) When security is enabled, the user ID of the user who changes a configuration is included in a delta checkpoint in the user.id file. Including the user ID in checkpoints enables an administrator to learn who changed a configuration without needing to view the security audit log or the server SystemOut.log file.

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.

To create, export, or delete checkpoints we can use the console or wsadmin RepositoryCheckpointCommands.

To create, delete, or restore full checkpoint using the console...

When a 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.

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


Enable or disable automatic checkpoints.

To use the 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 (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.

    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.

    Click...

    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.

  3. 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.

The product 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 we created a full checkpoint, you made a complete copy of the entire configuration repository. If we enabled delta checkpoints, subset snapshots of the configuration repository are created when we make a change to the configuration.

(V8502) If the product cannot determine the user ID of a user who changes a configuration, the product does not store a user ID for the configuration change with other delta checkpoint data. The validity of the checkpoint data is not affected.


What to do next

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 we 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


Related concepts

Repository checkpoint and restore function
  • Tune operating systems
  • Restore checkpoints
  • RepositoryCheckpointCommands (AdminTask)