Data Backup and Recovery

Ridgeback ensures robust network security by relying on three critical components: a MySQL-compatible database for historical data retention and forensics, a collection of service containers for extensibility, and Rcores for managing network traffic at the segment level. Protecting the data and configurations within this architecture is vital for continuity and operational integrity.

This chapter outlines comprehensive procedures for backing up and recovering Ridgeback’s key elements across various deployment scenarios. It provides guidance for environments using local MySQL, local MariaDB, MySQL in Azure, MySQL in AWS, and MariaDB in a container.

1. Backing Up and Restoring the Database

The MySQL-compatible database used by Ridgeback stores crucial information about IT infrastructure and network activity. Backups are essential to preserve this data for forensic analysis and long-term compliance with organizational retention policies.

Backup Procedures

Local MySQL/MariaDB

1. Stop Ridgeback services to ensure no active connections to the database:

   docker-compose down
   

2. Create a database dump using mysqldump:

   mysqldump -u <username> -p --all-databases > ridgeback_backup.sql
   

3. Validate the dump by restoring it to a test database.
4. Secure the backup file in encrypted storage or a secure offsite location.

MySQL in Azure

1. Use Azure’s automated backup feature via the Azure Portal for routine backups.
2. For manual backups, export the database using mysqldump:

   mysqldump -h <azure_server>.mysql.database.azure.com -u <username>@<servername> -p <database> > ridgeback_backup.sql
   

3. Save backups to Azure Blob Storage or another secure repository.

MySQL in AWS

1. Enable Amazon RDS automated backups or take manual snapshots via the AWS Management Console.
2. To create a manual backup, use:

   mysqldump -h <rds_endpoint> -P 3306 -u <username> -p <database> > ridgeback_backup.sql
   

3. Store the backup securely in S3 buckets or other encrypted storage solutions.

MariaDB in a Container

1. Stop the container to avoid corrupting data during backup:

   docker stop <container_name>
   

2. Use docker exec to run mysqldump inside the container:

   docker exec <container_name> mysqldump -u <username> -p <database> > ridgeback_backup.sql
   

3. Copy the .sql file out of the container for safe storage:

   docker cp <container_name>:/ridgeback_backup.sql .
   

Restore Procedures

1. Stop Ridgeback services to ensure data integrity.
2. Prepare the database:
   • For local databases, create an empty database if necessary.
   • For cloud services, use the provider’s portal to create a new instance or restore a snapshot.
3. Import the backup:
   • For local databases:

     mysql -u <username> -p < ridgeback_backup.sql
     

   • For containers, use docker exec:

     docker cp ridgeback_backup.sql <container_name>:/restore.sql
     docker exec <container_name> mysql -u <username> -p <database> < /restore.sql
     

4. Restart Ridgeback services to resume normal operations:

   docker-compose up -d
   

2. Recovering from Deleted Service Images or Containers

The Ridgeback service containers host critical functionality. If images or containers are deleted, you can recover them using the steps below:

1. Rebuild the containers:
   • Use the docker-compose.yml file and .env to pull the required images:

     docker-compose up -d
     

2. Reattach the database volume (if you are using an external volume) to restore data continuity:

   docker run -v <volume_name>:/var/lib/mysql -d <image_name>
   

3. Recovering from Deleted Rcores

Rcores are essential for capturing and analyzing network traffic. If an Rcore is accidentally deleted:

1. Reinstall the Rcore:
   • Download and re-deploy the Rcore executable on the appropriate system.
   • Refer to the system requirements for Windows, macOS, or Linux installations.
2. Reconfigure network connectivity:
   • Ensure the Rcore has an IP route to the Ridgeback service containers.
3. Validate the setup:
   • Use Ridgeback’s admin interface to verify the Rcore is operational.

Best Practices for Backup and Recovery

• Automate Backups: Schedule regular database and configuration backups.
• Test Restorations: Periodically restore backups to verify their integrity.
• Secure Backup Storage: Use encryption and secure offsite locations for backup files.
• Document Recovery Plans: Maintain up-to-date recovery documentation accessible to authorized personnel.
• Monitor Logs: Regularly monitor logs from containers and Rcores to detect anomalies early.