Backup

Data Held on PhixFlow

The PhixFlow system comprises various types of data / systems files stored as follows:

Backup Options

Backup requirements depend on the level of risk that is acceptable and the role that PhixFlow fulfils:

Snapshot

In a “standalone” role in which PhixFlow does not update other business systems then a simple daily snapshot backup of the database may be sufficient. The risk associated with this approach is that in the case of a catastrophic machine failure PhixFlow will lose all new configuration data entered that day plus state information and any new analysis results. To recover from this case after a database restore, the new configuration data would need to be re-entered manually and the analysis tasks re-rerun (this is possible provided source data is still available and import files are still in their import directories).

Hot Backup

More typically PhixFlow is used to update other business systems either directly (e.g. by calling APIs or updating / inserting data via SQL) or indirectly (e.g. by passing files or creating jobs on external work queues). In this case the impact of losing a day’s worth of data would require remedial action on other systems and the risk of a simple backup is too great, PhixFlow recommend that in this case a hot backup mechanism is put in place and redo logs and archived redo logs are maintained for sufficient time to recover completely from a catastrophic machine failure. When doing a hot backup, remember to place the database into backup mode to ensure complete blocks are written to redo.

Backup Volumes

The total backup storage requirements for one week for the hot backup approach on a standard sized system (i.e. tablespace size is 100 GB) is given below:

A recommended backup strategy is to retain data as follows:

This strategy enables the administrator to reset the database to any point within at least the last week and provide restore points for the previous 4 weeks. For larger systems, these values should be provided by the sizing process.