Disaster Recovery
Disaster Recovery: Backup and Securing the Relution Server
Introduction
This guide describes the backup and security concept for a Relution Server that uses a database (PostgreSQL or MariaDB) and optionally integrates an on-premises S3-compatible storage system (such as MinIO).
The goal is to ensure data integrity, minimize downtime (RTO), and guarantee reliable restorability in an emergency.
Note: The configuration of backup automation, monitoring, and ensuring the backups are performed is the responsibility of the customer.
System Overview
The Relution infrastructure typically consists of the following components that need to be backed up:
- Application Server: Hosts the Relution application and services.
- Database (On-Premises): MariaDB or PostgreSQL.
- S3 Storage (On-Premises): Object-based storage system (optional) for storing files, backups, and persistent data.
Important: All applications can also be operated together on a single machine. The use of S3 Storage is optional, but if used, operation of the Relution Server is impossible without the contents of the S3 Bucket.
Backup Goals
- Minimizing data loss (RPO – Recovery Point Objective)
- Fast restoration of services (RTO – Recovery Time Objective)
- Protection against hardware failure, software errors, and human errors
- Protection against data manipulation and ransomware
Backup Components and Strategies
1. Database Backup
| Strategy | Details |
|---|---|
| Frequency | Daily full dumps (e.g., via mariadb-dump or pg-dump) |
| Incremental | Hourly incremental backups (depending on necessity) |
| Management | Automated rotation and retention rules |
| Security | Encryption of backup files (AES256 or GPG) depending on necessity |
| Consistency | During the backup, the Relution service should be temporarily stopped to avoid inconsistencies! |
2. S3 Storage Backup (Optional)
| Strategy | Details |
|---|---|
| Method | Replication to a second S3 target or regular syncing (s3cmd sync, rclone sync) |
| Scope | Backup of critical buckets at defined intervals |
| Consistency | During the backup, the Relution service should be temporarily stopped to avoid inconsistencies! |
3. Server Configuration Backup
All relevant configuration files must be backed up:
/opt/relution(Directory of the Relution Server)compose.yml(or comparable startup scripts)application.yml(Relution configuration)- NginX configuration file, if applicable
- SSL certificate and key
Backup Storage Locations
Adherence to the 3-2-1 backup principle is recommended:
- 3 copies of the data
- 2 different systems/media
- 1 copy external/offsite
Backup Processes
Time Schedule
| Interval | Backup |
|---|---|
| Daily | Full database backup |
| Hourly | Incremental DB backup (depending on necessity) |
| Daily | S3 sync of critical buckets |
| Weekly | Full server configuration backup |
Further Aspects
| Area | Details |
|---|---|
| Automation | Cron jobs or systemd timers; Logging all processes; Notifications on errors |
| Encryption | Encryption of all backups; TLS/HTTPS/SSH for transport |
| Integrity Check | Monthly test restore |
Recovery Procedures
1. Database Recovery
- Select the correct backup file.
- Prepare the target system (stop the database service).
- Perform the data import (e.g., via
psqlormysql). - Functional test of the Relution application.
2. S3 Storage Recovery
- Select the objects/buckets.
- Restore via
rclone,s3cmd, or API. - Integrity check (verify files are available in Relution).
3. Full System Recovery
- Restoration of configurations (from the server configuration backups).
- Restart of all services.
- Functional test of the complete application.
Monitoring & Alerting
- Monitoring of all backup processes (e.g., with tools like Grafana + Prometheus).
- Alerting for:
- Backup errors
- Low disk space
- Integrity errors
- Test-restore failures
Security and Documentation
Security
- Access restrictions (Least Privilege principle).
- Secure storage of keys and credentials.
- Regular updates of the software used.
Documentation
- Documentation of all process changes (configuration, schedules).
- Clear responsibilities for backup and restore.
- Log data retention for at least 90 days.
Conclusion
This security concept ensures that both the database and the on-premises S3 storage system are reliably protected and can be quickly restored in an emergency. Through automation and regular checks, operational security is guaranteed long-term.