The following article explains the general configuration for all backup policies configured and operated by Infrastructure Services. These policies may be slightly tailored to fit various different use cases but all policies will have generally the same configuration guidelines.

Backup Policies

The following article explains the general configuration for all backup policies that are configured and managed by Infrastructure Services. These policies may be occasionally tailored to support different use cases, though all policies will have generally the same configuration guidelines.

All policies are documented with the following information:

• Frequency: Schedule

• Type: The type of backup being taken

  • Full: Full Backup of All Defined Data

  • Incremental: Only data that has been added or changed since the last Full.

• Retention: The amount of time that the backup data set is kept before being deleted

• Recovery Time Object (RTO): The amount of time required to restore the first 100GB of data, measured from the time when the restore job has been launched

• Recovery Point Object (RPO): The maximum amount of data – as measured by time – that can be lost after a recovery from a disaster, failure, or comparable event before data loss will exceed what is acceptable.

Non-Production Systems

Non-production systems are not backed up by default. A request for an exception to this guideline may be submitted to Infrastructure Services via a TDX service request. Please be specific with your justification and include details such as the restoration requirements as well as the size of the data.

System State Backups

A snapshot of each production virtual machine is taken daily, and these snapshots are retained for 60 days. A VM snapshot may be used to restore specific files, directories, or the entier VM to the time when the snapshot was taken.

RTO: 2 Hours

Production Systems

All designated backup data, including file systems, databases, and application configurations.

RPO: 24 Hours

RTO: 2 Hours

Wasabi Replicated Data

Data is replicated to Wasabi Cloud Storage via the backup system. Additional fees may be applied.

RPO: 24 Hours

RTO: Restore times vary depending on the size of data and network transmission speeds.

Data Security

All communications with Rubrik UI and APIs are encrypted via industry-standard HTTPS/TLS (TLS 1.2+) over public networks. This ensures that all traffic between customer environments and the backup platform is secure during transit. Our product offerings also support AES-256 key at-rest encryption.

Data At Rest - On-Premises with Rubrik

R528: FIPS 140-2 LEVEL 2 SELF-ENCRYPTING DRIVES

Rubrik encrypts user and application data at rest with FIPS 140-2 Level 2 certified self-encrypting drives (SED) as its HDDs and SSDs with our r528 appliance. Self-encrypting drives provide the additional functionality of automatic data protection without additional intervention. The data-at-rest encryption solution is turnkey – all SEDs ship completely configured. In order to bootup or power cycle, Rubrik retrieves the cryptographic keys protecting its SEDs via its TPMs. These keys are then used to unlock and mount the drives. Furthermore, these security keys can then be used to instantly and securely delete data on a SED. Rubrik Encryption at Rest enables compliance with the requirements of HIPAA, SOX, PCI  DSS, FIPS 140-2, NIST 800-88, and Common Criteria.

SOFTWARE-BASED DATA-AT-REST ENCRYPTION

Software-based encryption at-rest is available on the r300s appliance series, which ships with a Trusted Platform Module (TPM). Rubrik’s file system is protected via AES-256 encryption. Key management is done internally, providing an additional layer of security and enabling secure cluster erasure. Rubrik also supports the detection of data tampering even when the system is powered off. Lastly, Rubrik’s software-based encryption solution is designed for scale to meet the needs of high data growth. 

Data At Rest - Wasabi Cloud Storage

Wasabi is secure by default and all data stored in Wasabi hot cloud storage is always encrypted at rest (even if the data is already encrypted by the storage application prior to sending it to Wasabi).   Wasabi follows industry-best security models and security design practices. Examples of Wasabi security features include:

• HTTPS is supported for the secure upload/download of data
• Buckets are only accessible to the bucket and object creators
• Wasabi supports user authentication to control access to data
• Access control mechanisms such as bucket policies and Access Control Lists (ACLs) can be used to selectively grant permissions to users and groups of users

Wasabi system software always encrypts object data before it is written to a disk drive.  Encryption is done using an AES256-bit key that can be provided in two different methods:

• If the S3 client app provides an encryption key in the S3 PUT Object Data REST request (the SSE-C approach described here), that key is used to encrypt the object data before writing to disk.  After the PUT Object operation is completed, the key is discarded.  The S3 client app must provide the same encryption key in an S3 GET Object REST request to access the data.  The Wasabi system software does not keep a copy of the encryption key and it is only stored temporarily in memory while the object is being encrypted. The working of SSE-C with Wasabi is also demonstrated in this document.
• If no key is provided by the S3 client app (meaning SSE-C is not used), then a random AES256-bit key is generated using a  cryptographic random routine in Wasabi's software.  A different encryption key is generated for each object stored in the system. This AES-256 bit key is stored in the meta-data secure layer of the Wasabi system (until you delete that object) and is used again for decryption when you make a GET call for your object(s), and that way you get the same data back in your native format. 

Additional general info on Wasabi and security can be found here.