General Documents

Application and database backups should be scheduled at certain frequencies, based on your specific business requirements. Generally, the higher the transaction volume, the more frequent backups should take place. Taking a backup should be possible online, parallel to normal database update activities to save a transaction-consistent state of the database.

You can take data backups using the following backup concepts:

Backups can be done monthly, weekly, daily, hourly, by the minute, or more likely a combination of some or all of them. A simple backup plan includes a rotating monthly and weekly backup combined with several hourly backups every day. A more complex scenario includes retaining 12 monthly backups.

To know more about the backup and recovery processes, refer to the respective database documentation.

In addition to taking backups, it is important to restore backups regularly to validate the back up procedures. The best practice is to restore every backup of the production environment to an alternate server and then validate the integrity of the restored databases. This practice provides the following advantages:

The backup strategies described in this document preserve the physical structure of the database. A clean integrity check of the restored copy ensures that the integrity of the production database was sound at the time of the backup. However, an integrity error detected on the restored copy of a database does not necessarily imply that there are integrity problems on the production database. For example, there could be errors in the backup media. If you discover an integrity error in the restored database, immediately run an integrity check on the production database to verify the integrity of the production system.

Work metrics provide top-level health insights into the infrastructure. These metrics provide an estimate of how much work resources are being produced and whether to raise an alert when specific thresholds are reached or when system failures occur. Some examples of work metrics include request rates and response times.

Resource metrics provide deep-level insights into the system’s current state. These metrics are useful for investigative purposes whenever a system fails to operate normally. Some examples of resource metrics include disk space utilization, memory usage, and network availability.

Cyware recommends that self-hosted customers monitor primary metrics that are important for user experience, application, and infrastructure health. Following are some examples to implement the resource metrics monitoring:

To facilitate Cyware’s ability to assist, a self-hosted customer is encouraged to follow the system specification recommendations for the self-hosted installation found in the respective software product deployment guide.

To facilitate Cyware’s ability to assist, a self-hosted customer must provide Cyware with remote access to the software installation, including via a desktop-sharing application.

Cyware provides general guidance for the customer support activities for the self-hosted software. This does not include performing the following services and are the responsibilities of the customer: