Configure repository checkpoints

Repository checkpoints represent saved images of repository files before configuration changes are made. A full checkpoint is created manually by the administrator and is a copy of the entire configuration repository including applications and connectors. Optional delta checkpoints can be 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 full checkpoint is a complete copy of the entire configuration repository. A delta checkpoint is a subset snapshot of the configuration repository made when we 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.

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.

(UNIX) 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. See Tune operating systems.

Create a full checkpoint

1. Log on to console and click...
   System administration > Extended repository service > Repository checkpoints > New

2. We are prompted for confirmation before proceeding. While the checkpoint is being created, the repository is locked. We 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 create full checkpoints with scripting use the createFullCheckpoint command in the RepositoryCheckpointCommands command group for the AdminTask object.

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.

Enable or disable automatic checkpoints

1. Enable automatic checkpoints.
   System administration > Extended repository service > Enable automatic repository checkpoints

   To disable automatic checkpoints. clear the check box.

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

3. Click Apply or OK.

To enable checkpoints with scripting use the setAutoCheckpointEnabled and setAutoCheckpointDepth commands in the RepositoryCheckpointCommands command group for the AdminTask object.

Enable audit records when saving changes to the master repository

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

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.

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

• Repository checkpoint and restore function
  
• Archive or delete checkpoints
  
• Restore checkpoints
  
• Find configuration changes in delta checkpoints
  
• RepositoryCheckpointCommands
  
• Extended repository service settings
  
• Repository checkpoint collection
  
• New repository checkpoint settings
  
• Checkpoint settings