Data Held on PhixFlow

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

Backup Options

Backup options should be determined based on the RTO and RPO determined at the planning phase of the deployment.

Application server backups

Details of the solution have an impact on the needs for backup and recovery of the application server.

In most cases, the only data that must be kept for integrity of the solution is in the database. In many cases, artifacts (software, template files, image files, uploaded files) and data (imported and exported files) kept on the application server can be recovered from other sources, or are not needed for long term retention.

In some cases, on the other hand, files are generated and held on the application server that must be kept in sync with the database data.

Discuss this with your PhixFlow implementation team or PhixFlow support to determine exactly what you need to retain for the long term, and what the recovery needs are, for artifacts and data on the application server. 

It is usually important - and in some cases vital (e.g. corporate standards and/ or independent compliance frameworks may apply) to retain log files for a certain period of time. If you ingest your log files into an off-server log store, however, there may be no need to make provision for the backup and recovery of log files on the application server itself.

In many cases, a platform backup for the disk or server, of the type offered by many virtualisation solutions, will be sufficient, and this may not be needed as frequently as that for the database. Daily backup is typcial, and not usually associated with much higher cost than a less frequent backup schedule.

Database server backups

The RTO and RPO for the solution generally refer to data held in the database. This will determine whether you need a "hot" backup, or "cold".

Point-in-time recovery (PITR) is needed for some solutions to meet the RPO, but this can involve considerable extra cost and effort. Your RTO and RPO should guide you to an options that balance the cost of the backup process while meeting your requirements. 

Indicative disk partition sizings are given here: Oracle planning, that account for different backup options. Note that these are only indicative. Predicting "undo" and "redo" space is often difficult, and observing the solution at work is the best way of measuring the required amount of space. It is important to not over-specify the server and each partition to avoid unecessary cost, and grow these if needed once the solution has been established.

Some virtualisation platforms will support RPOs much shorter than standard snapshot/ backup options. For example, for running SQL Server on Azure: https://docs.microsoft.com/en-us/azure/backup/backup-azure-sql-database

Database backup volume planning

If you opt for database level backups (rather than backups on a virtualisation layer, say), you will need to plan for additional disk storage. However, for long term retention of these backups, you can use lower cost disk. These sizings are only indicative, and the exact amount you need will depend on the details of your solution.

General recommendations

• If you are working on a virtualisation platform, make use of the backup options available if you can - these are often more straightford to manage, to recover from, and to test recovery from, than traditional database backups.
• If you are using snapshot technology to take backups - that is, backing up disks that are not idle - choose application consistent snapshots/ backups if possible.