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

Before you begin

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

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

About this task

You can use the administrative console or wsadmin RepositoryCheckpointCommands to create, export, or delete checkpoints.

• Create a full checkpoint.

  To use the administrative console to create a full checkpoint, use the Repository checkpoints page. From this page, you 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 the AdminTask object.

• Enable or disable automatic checkpoints.

  To use the administrative 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 the AdminTask object.

• 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 that you want 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 that you want 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 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 you make a change to the configuration.

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, you 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, you can restore the entire configuration repository back to the state it was in at the time the full checkpoint was made.