Data Archive collectives and backups

At a minimum, configure backups for the primary server in a Data Archive collective. A collective is not a substitute for a backup.

• Consider whether to configure backups for the secondary servers as well as the primary. There are several good reasons to back up secondary servers.

  • Not all configuration information is replicated. Non-replicated data includes tuning parameters and Data Archive message logs. In part, these files can be enumerated by the piartool -backup -identify -verbose command; the non-replicated components where the data may differ between the primary and secondary nodes include the timeout parameters, pimsgss, and pibatch components. However, non-replicated data also includes customized batch scripts, .ini files, and logs that can be backed up with the pisitebackup.bat script.

  • Database corruption can occur independently on primary and secondary nodes. The validation step at the end of the backup may, for example, detect corruption on a secondary node that did not occur on the primary node.

  • If the secondary and primary are geographically separated across a slow network, then it might be more expedient to restore the secondary from a backup rather than reinitializing from the primary.

• When setting up backup tasks on the different members of a Data Archive collective, schedule each backup task at least 30 minutes apart.

• The start and end time of archives may not be the same on primary and secondary nodes. Reinitializing a secondary typically requires manual steps to eliminate data gaps. If a secondary is restored from backup, there are no data gaps.

• If you restore a primary Data Archive server from a backup, you must reinitialize all secondary servers from the primary Data Archive server. If you restore the primary Data Archive server from a backup of a secondary Data Archive server, you must reinitialize the other secondary servers.