How long do I need to keep archive logs
Use the information in this section to help we plan your backup strategy.
You specify how long archive logs are kept in days, using the ARCRETN parameter in USING CSQ6ARVP or the SET SYSTEM command. After this period the data sets can be deleted by z/OS .
We can manually delete archive log data sets when they are no longer needed.
- The queue manager might need the archive logs for recovery.
The queue manager can only keep the most recent 1000 archives in the BSDS, When the archive logs are not in the BSDS they cannot be used for recovery, and are only of use for audit, analysis, or replay type purposes.
- We might want to keep the archive logs so that we can extract information from the logs. For example, extracting messages from the log, and reviewing which user ID put or got the message.
The BSDS contains information on logs and other recovery information. This data set is a fixed size. When the number of archive logs reaches the value of MAXARCH in CSQ6LOGP, or when the BSDS fills up, the oldest archive log information is overwritten.
There are utilities to remove archive log entries from the BSDS, but in general, the BSDS wraps and overlays the oldest archive log record.
When is an archive log needed
We need to back up your page sets regularly. The frequency of backups determines which archive logs are needed in the event of losing a page set.
We need to back up your CF structures regularly. The frequency of backups determines which archive logs are needed in the event of losing data in the CF structure.
The archive log might be needed for recovery. The following information explains when the archive log might be needed, where there are problems with different IBM MQ resources.
- Loss of a page set
- We must recover the system from your backup and restart the queue manager.
You need the logs from when the backup was taken, as well as up to three log data sets prior to the backup being taken.
- All LPARs lose connectivity to a CF structure, or the structure is unavailable
- Use the RECOVER CFSTRUCT command to recover the structure.
Structure recovery requires the logs from all queue managers that have accessed the structure since the last backup (back to the time when the backup was taken) plus the structure backup itself in the log of the queue manager that took the backup.
If we have been doing frequent backups of the CF structures, the data should be in active logs, and we should not need archive logs.
If there is no recent backup of the CF structure, you might need archive logs.
Note: All non persistent messages will be lost; all persistent messages will be re-created by performing the following tasks:
- Reading the last CF structure backup from the log
- Reading the logs from all queue managers that have used the structure
- Merging updates since the backup
- Administration structure rebuild
- For to rebuild the administration structure, the information is read from the last checkpoint of the log for each queue manager in the QSG.
If a queue manager is not active, another queue manager in the QSG reads the log.
We should not need archive logs.
- Loss of an SMDS data set
- If you lose an SMDS data set, or the data set gets corrupted, the data set becomes unusable and the status for it is set to FAILED. The CF structure is unchanged. In order to restore the SMDS data set, we need to:
- Redefine the SMDS data set, and
- Recover the CF structure by issuing the RECOVER CFSTRUCT command. Note: All non persistent messages on the CF structure will be lost; all persistent messages will be restored.
The requirement for queue manager logs is the same as for recovering from a structure that is unavailable.
Parent topic: Plan your logging environment