Data Held on PhixFlow

The PhixFlow system comprises various types of data / is comprised of a database and systems files stored as follows:

Backup Options

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

Application server backups

:

• Recovery Time Objective (RTO): how long the recovery will take? (5 minutes / 1 hour?)
• Recovery Point Objective (RPO): for example, point-in-time recovery (PITR) or recovery to the overnight backup. For the latter, are you OK with losing data input entered today for example?

For more details on this topic see: https://en.wikipedia.org/wiki/Disaster_recovery_and_business_continuity_auditing

Application server backups

• Perform an application backup each time PhixFlow is upgraded

• Or weekly application server backups to simplify the process. Deleting old backups after N weeks.

Details of the solution have an impact on the needs need for backup and recovery of the application server.In  In most cases, the only data that must be kept for the 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 typcialtypical, and not usually associated with much higher cost than a less frequent backup schedule.

Database server backups

The Define the backup requirements for your RTO and RPO for the solution generally refer to data held in the database. This will determine whether you need so that your Database Administrator (DBA) can best advise on a suitable backup strategy for your setup. For example, your requirements will influence the need for a "hot" backup (PITR)), 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. (Full backup daily).

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, unnecessary costs and grow these if needed once the solution has been established.

...

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 a lower cost disk. These sizings are only indicative, and the exact amount you need will depend on the details of your solution.

...

• If you are working on a virtualisation platform, make use of the backup options available if you can - these are often more straightford straightforward 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.

...