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
You 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 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.
About this task
You can use the administrative console or wsadmin RepositoryCheckpointCommands to create, export,
or delete checkpoints.
Procedure
- 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.
- Click .
- 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.
- Name the checkpoint.
- Type a checkpoint description.
- 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.
- Click .
- Select Enable automatic repository checkpoints to enable
checkpoints.
Clear the check box to disable automatic checkpoints.
- 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.
- 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
- Enable automatic
checkpoints.
- Enable security audit and
ADMIN_REPOSITORY_SAVE
event filter.
- Click .
- 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 that you want to use to emit the new event, such
as
auditServiceProviderImpl_1
, enable repository_save_filter
, and
then click Apply or OK.
- Click . 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.