Backup & Redundancy

Backup & Restore

Records365 has technical and operational controls in place to ensure that customer data is backed up in a secure and redundant manner.

All Records365 customer data is backed up at the following frequency:

  • Full backups are taken once a week
  • Differential backups are taken twice a day
  • Transaction log backups are taken every 5 minutes

Backups are stored in a geographically redundant manner which ensures that backups are available even in the event of a data center level failure.

Backups are encrypted at rest using AES-256 bit encryption.

Backups are retained for up to 7 days.

These technical controls have been put in place to ensure that Records365 customers incur minimal data loss in the event of a disaster or service outage.

Service Continuity & Disaster Recovery

Records365 uses a variety of technical controls as well as a distributed service architecture to maximize service availability.

Using a distributed service architecture, Records365 is able to spread processing tasks across clusters of compute nodes thereby eliminating service availability impacts of individual compute nodes failing.

In addition, the following technical controls are in place to maximize service availability:

  • Service load balancing across compute clusters
  • Persistent message queuing to enable service components to pass durable messages to each other
  • Cloud-scale domain name systems (DNS)
  • Segmentation of compute clusters into separate availability sets and update domains
    • Availability sets ensure that compute nodes within the same availability set are serviced by the same physical hosts, storage units and network switches
    • Update domains ensure that updates are applied in a rolling fashion (one-by-one) across a single compute cluster
  • Storage redundancy to ensure that critical service data, such as customer data, is stored across multiple data centers

RecordPoint tests service continuity and disaster recovery automation and procedures on an annual basis to ensure that these are in line with the RPO and RTO below.

Recovery Point Objective

The Recovery Point Objective (RPO) represents the maximum amount of time for which data loss may occur in the event of the service outage.

RecordPoint currently offers an RPO of twelve (12) hours for Records365.

Recovery Time Objective

The Recovery Time Objective (RTO) represents the maximum amount of time before the service will become operational again after a service outage.

RecordPoint currently offers an RTO of forty-eight (48) hours for Records365.


The above RTO commitment are not applicable in circumstances where the underlying base Azure platform is experiencing a complete outage in any of the Azure regions that Records365 is hosted in. In such scenarios, the RTO commitment only becomes effective once the impacted Azure region has recovered from the outage. The Records365 service has been designed to minimize data loss in the event of a service disruption by ensuring that connectors can track their progress of synchronizing changes from a connected content source in a durable way. This allows connectors to simply resume operation from where they left off prior to a service disruption.