Backup and Restore
An efficient backup and restore process is essential to ensure the integrity of the Cybereason platform data in the event of a server failure. This section describes the backup and restore methodology for the Cybereason platform when Cybereason is deployed in the cloud.
Note
For details on backup and restore for on-premises environments, contact your Customer Success Manager.
Important
Backup and restore processes are performed by Cybereason Technical Support. As a result, you are not required to perform these steps. The information in this section is included in order to provide a better understanding of these processes.
In this topic:
Backup process
Cybereason’s backup and restore strategy protects organizations from both catastrophic server failure and detection data loss. The Cybereason platform automatically backs up:
Server configuration data, such as IP address, DNS, and proxy settings, allowing for a full restore of the servers should the need arise.
Detection data which is stored in the CMC Engine. Cybereason provides mechanisms for restoring this data only, if a full restore is not necessary.
Detection server backup
Cybereason automatically backs up each Detection server by:
Taking daily snapshots of the Detection server. Snapshots include detection data in the In-Memory Graph database.
Storing recordings of raw data sent from sensors to the Detection server. These recordings are stored in buffers on the sensor and are used to supplement the daily snapshot in the event of a restore.
Backing up server configuration files and database.
See retention times for each of the previous processes in the tables of the Cybereason backup archives section.
Detection server recovery
The following cases outline recovery steps for the most common scenarios:
Case 1: If the server fails unexpectedly and can be recovered, Cybereason Technical Support restarts the server. The server continues to function using the current configuration files and database:
Loading the latest snapshot to restore data up to the point when the snapshot was taken.
Loading the recordings from the snapshot creation time onwards. This restores data to the most current state.
The following image illustrates this process:
Note
The file size for the snapshot and recordings depends on the environment and on the amount of data received from sensors.
The recovery time depends on the data size and can take several hours.
Case 2: If the server fails unexpectedly and it cannot be recovered, Cybereason Technical Support reinstalls the server. After the reinstallation:
Technical Support restores detection data from the latest snapshot.
Technical Support loads recordings from the snapshot creation time onwards. This restores data to the most current state.
Technical support restores server configuration files and the database from the latest backup.
Recovery time for each phase varies, as listed in the following table:
Component |
Retention time |
|---|---|
Server re-installation |
30 min. |
Loading data |
Depends on the data size; can take several hours. |
Database restore |
30 min. |
Additional server backup
Cybereason automatically backs up server configuration files and the database for the following servers:
WebApp server
Private Threat Intel server
Registration server
Additional server recovery
The following cases outline recovery steps for the most common scenarios:
Case 1: If the server fails unexpectedly and it can be recovered, Cybereason Technical Support restarts the server and it continues to function using the current configuration files and database.
Case 2: If the server fails unexpectedly and it cannot be recovered, Cybereason Technical Support reinstalls the server. After the server reinstallation, Cybereason Technical Support restores server configuration files and database from the latest backup.
Cybereason backup archives
Cybereason Technical Support automatically backs up your data daily and generates a *.tgz file, named as follows:
<Server Name>_<Date>.tgz
The backup archive contains server configuration files and detection data files, as described in the following tables:
Server configuration data files (all servers)
Backup file |
Data description |
Estimated file size |
Retention time |
|---|---|---|---|
managment_facter.json |
Main configuration files for each server. The files exist on each Cybereason server and contain all the server settings (for example, Hostname, IP address, DNS, etc.). |
Averages ~10 kilobytes |
Indefinitely |
puppet.conf |
Configuration file containing the current version information and connection information to the Cybereason Update server. |
Averages ~5 kilobytes |
Indefinitely |
Regions_config |
Configuration related to the Registration server. The file contains logical distribution of sensors between Detections servers. |
Averages ~20 kilobytes |
Indefinitely |
MongoDB dump |
Application database for various configurations and statuses (for example, reputation lists, System user information, etc.). |
Averages ~ 15 MB* |
Indefinitely |
Detection data (Detection server only)
Backup file |
Data description |
Estimated file size |
Retention time |
|---|---|---|---|
Snapshot |
Daily backup of the data in the Memory Graph Database. This file contains all detection information up until snapshot creation. |
Averages ~36 GB* |
1 week |
Recordings |
Raw user data received from sensors assigned to the server. Recordings are generated constantly and used to supplement the Snapshot during a system restore. |
Averages ~12.5 GB* |
30 days Note: For Historical Data Lake customers, the Cybereason platform retains recordings according to the retention period configured for the Historical Data Lake instance. For example, if the Historical Data Lake instance is configured to 60 days, the Cybereason platform retains the recordings for 60 days. For Incident Response customers, the retention period is 90 days. If you would like to extend the retention period, you can purchase a backup data extension package. For more information, see Backup Data Extension Packages. |
The backup file size depends on the environment and the amount of data received from sensors.
Backup intervals and archives storage
Cybereason provides AWS S3 as a backup storage. The following table describes backup intervals, as well as how many backup archives are retained at any one time. N represents the current backup.
Server |
Recommended backup interval |
Recommended number of backup archives |
|---|---|---|
Detection server |
Daily |
N + 2 daily snapshots |
WebApp server |
Weekly |
N + 2 daily backups of server configuration files only |
Private Threat Intel server |
Weekly |
N + 2 daily backups of server configuration files only |
Registration server |
Weekly |
N + 2 daily backups of server configuration files only |
Backup script
Cybereason Technical Support executes the backup script via a cronjob on the target server. This enables control over the backup execution.
During the script execution, the script verifies the server type and creates the archive package based on the backup manifest for the specific server type.
Once the backup package is created, it is transferred to the customer’s S3 dedicated bucket.
There is full separation in S3 between customers. Backups per customer are saved in a dedicated library.
In addition, as a handshake mechanism, recovery verifies that the destination server has the same organization name as the S3 bucket library. If the organization names are different, the recovery script fails.
Backup package
The backup package is named using the following naming convention:
hostname.date.tgz
In this example, you see the following fields:
hostname: The configured host name of the Cybereason server, for example: testserver
date: The timestamp of the time when the package was created, in the format: yyyy-mm-dd, for example: 2017-06-21
file extension: *.tgz – This is a gzip compressed data format based on the Unix system.