Backup and Recovery of the xAPPnow Low Code Platform is an important part of the DevOps strategy. To provide a backup mechanism tailored to the client’s needs, xAPPnow offers different ways to back up the databases. These are:

 

 

Offline Backups are the standard way of backup in case of an update or server restart. All xAPPnow services need to be stopped before starting this backup.

During the usual operations, the xAPPnow services are not shutdown. But regularly backups are equally important as continuous operations. For this, xAPPnow provide Online Backups, without shutdown, using Log Shipping. Each database transaction is written inside a log file, called write ahead log (WAL), before it was executed. The archiving time, when these logs are written into the log file, can be specified. It is important to find a good trade-off between data integrity and performance, so the interval should be monitored and adjusted. After each interval, the logs should be packed and moved to an extra folder.

If no logs are written, no archiving is done. It is recommended to do a full backup regularly and incremental backups in between.

Streaming Replication will stream/duplicate all database changes (external or internal) to another postgreSQL server instance. This is called synchronous replication, which leads to a high availability. The disadvantage is that all errors in the master are directly duplicated to all slaves. The advantage is that, if one database server is not working, a direct switch to another instance can be done.

The recommended configuration is Streaming Replication with Log Shipping. It leads to high availability with low risk of data loss and better performance. The data replication here is asynchronous, which means the backup server may fall back in time behind its master. 

It is recommended to store all backups on an external physical storage for all backup mechanism.

 

 

It is important to stop xAPPnow services before execute offline backup process, and start xAPPnow services after backup is finished.

 

As an advice we propose to store backups on external media. The mechanism is designed to not interfere with custom backup policies.

 

 

If backup task finished successfully there should be created a backup file at APPOLLO_BACKUP_DIR

 

 

 

On an unexpected situation like data loss or server crash the system can be restored using a previously created backup. It is important to stop xAPPnow services before execute backup restore process, and start xAPPnow services after backup restore process finishes.

 

 

 

 

 

 

 

Example:

 

 

 

Example:

 

Example:

 

 

In this step postgresql data directory is compressed and saved, transactions during this process are saved also into the backup file. This step is a precondition to execute incremental backups.

Execute backup command

 

If backup task finished successfully there should be created a backup file at APPOLLO_BACKUP_DIR

 

In this step a backup file is created using a previously created base backup (See Create Base Backup). It saves all transactions on the database, allowing to restore the state of the database given a moment in the past, also known as point in time recovery. It also can restore the latest state of the database when backup was created.

 

Execute backup command:

 

If backup task finished successfully there should be created a backup file at APPOLLO_BACKUP_DIR