Junari/Recycly - Disaster Recovery Plan – Production Environment

1. Likely Causes of Production Downtime

• Server hardware failure
• Software bug or security issue resulting in data loss or system unavailability

2. Mitigations and Preventative Measures

• Redundant hardware components including power supply units (PSUs) and RAID storage
• Nightly backups of both system images and customer databases
• AWS-based infrastructure providing high availability and rapid restoration options
• Ansible-driven configuration management for consistent and repeatable environment builds

3. Backup Strategy

Backups are performed automatically every night shortly after midnight and include two distinct types:

• Server Disk Image Backup: A complete image of all server disks, including file attachments and software components.
• Database Backup: A separate nightly backup of each customer database.

All server disks are fully imaged via AWS Backup, allowing restoration within minutes.

For safety and transparency, maximum potential downtime is advertised as 4 hours.

4. Recovery Objectives

• Recovery Time Objective (RTO): 4 hours
• Recovery Point Objective (RPO): 24 hours

These values represent the maximum targeted time to restore service and the maximum acceptable period of potential data loss respectively.

5. Restoration Process Overview

In the event of a production-level outage:

1. Commission new server infrastructure where required.
2. Deploy Recycly systems using the recycly_infra Ansible configurations from GitHub to rebuild environments and Nginx configurations.
3. Restore all backups, including Odoo databases, version 7 databases, and associated filestores.
4. Update DNS records to direct domain traffic (based on Nginx server_name definitions) to the newly restored environment.

The restoration process is currently semi-manual and requires oversight by a senior developer or infrastructure engineer, but all necessary resources and configurations are documented and maintained for immediate access.