MDH GROUP · BLOG

Disaster Recovery for self‑hosted Affilentra: Backup, Point‑in‑Time Recovery and Tested Restore Processes

Affilentra combines tracking, commission calculation and billing on a self‑hosted PHP/MySQL platform. As an operator you are responsible for data integrity, payout history and partner trust. A targeted disaster recovery plan ensures lost data can be

← All posts

Disaster Recovery for self‑hosted Affilentra: Backup, Point‑in‑Time Recovery and Tested Restore Processes

Why a Disaster Recovery Plan for Affilentra Is Indispensable

Affilentra combines tracking, commission calculation and billing on a self‑hosted PHP/MySQL platform. As an operator you are responsible for data integrity, payout history and partner trust. A targeted disaster recovery plan ensures that lost data (transactions, configurations, creatives) can be restored quickly and reproducibly — without surprises regarding roles, permissions or settlements.

Quick Overview: Goals of This Guide

  • Consistent backup of database, filesystem and configuration.
  • Setup of Point‑in‑Time Recovery (PITR) with MySQL binlogs.
  • Automation, encryption and retention policies.
  • Defined, tested restore procedures and regular audits.

1. Architecture and Prerequisites

First analyze your installation: Where are the PHP files, uploads, cron jobs, configuration files (e.g. config.php) and the MySQL database located? Separate roles: software operators (infrastructure/backups), merchants (product management) and partners (tracking links) require different recovery objectives and access rights.

Recommended prerequisites:

  • Root/administrator access to the server and the MySQL instance.
  • Reliable export storage (local + offsite e.g. object storage or external backup system).
  • Encryption tools (gpg, age) and a key management concept.

2. Backup Strategy: What Belongs Where?

The three pillars are:

  • Database (MySQL): complete dumps plus binlogs for PITR.
  • Filesystem: PHP code, uploads, media, creatives.
  • Configuration & Cron: config files, systemd units, SSL certificates.

Database Backups

Create regular consistent full backups (e.g. using mysqldump --single-transaction for InnoDB tables) or use physical backups (Percona XtraBackup) for large installations. Additionally, MySQL binlogs must be enabled so that you can reconstruct at the transaction level.

Important MySQL configuration (my.cnf):

  • log_bin = mysql-bin
  • server-id = 1 (or a unique ID)
  • binlog_format = ROW (recommended for reliable replication/PITR)
  • Optional: expire_logs_days or custom rotation via script

Point‑in‑Time Recovery (PITR)

PITR complements full backups: continuously archive binlogs and record timestamps or GTIDs at each full backup. In a recovery scenario, restore the last full backup and then apply the binlogs with mysqlbinlog --start-datetime / --stop-datetime | mysql up to the desired point before the incident.

Filesystem and configuration backups

Back up:

  • Source code directory (PHP files, libraries).
  • Uploads/Media/Assets (tracking images, promotional materials).
  • Config files, SSL certificates, cron scripts and systemd/unit files.

Create atomic archives (e.g. tar + gzip) or use file-based tools (rsync) for incremental backups. Pay attention to file permissions and SELinux/ACLs during restore.

3. Automation, storage and encryption

Automation

Use cron or systemd timers for recurring jobs:

  • Daily full DB dump (at night, outside peak hours).
  • Continuous collection and archiving of binlogs (e.g. every 5–15 minutes).
  • Daily/multiple filesystem snapshots or incremental rsync jobs.

Log each backup with a timestamp, SHA256 checksum and file size for integrity verification.

Retention policy

Define a retention policy that matches your compliance and recovery time objectives. An example structure for orientation:

  • Daily backups: 14 days
  • Weekly backups: 12 weeks
  • Monthly backups: 12 months

Store backups at least at one offsite location. Object storage (S3-compatible) or a separate backup provider reduces the risk of hardware failures.

Encryption and key management

Encrypt backups at rest with GPG/age keys. Separate storage locations from key material (e.g. keys in a dedicated HSM or a password manager with access control). Plan key rotation and document recovery access procedures.

4. Restore processes and regular tests

Recovery checklist (basic procedure)

  1. Isolate the environment to avoid data overwrites.
  2. Restore the appropriate full backup of the MySQL database.
  3. Import binlogs up to the desired stop point (PITR).
  4. Restore the filesystem backup (code & media).
  5. Check configurations, permissions and secrets.
  6. Perform integrity and functional tests (tracking, login, commission calculation).
  7. Document duration and deviations; adjust the strategy accordingly.

Regular restore tests

Test at least monthly a full restore in an isolated test environment. Practice PITR scenarios at different points in time (e.g., a failure shortly before billing day). Validate in particular:

  • Completeness of the transaction history and payout chronologies.
  • Functionality of tracking links and conversion validation.
  • Role and permission constellations (software operator vs. merchant vs. partner).

5. Example: Step-by-step restore with PITR

1) Choose the last consistent full backup (e.g., full_2026-10-01.sql.gz). 2) Decompress and import it into an empty MySQL instance. 3) Determine start/stop points of the binlogs (e.g., based on the incident timestamp). 4) Use mysqlbinlog to apply the binlogs in order. 5) Afterwards restore filesystem archives, correct paths and permissions, and start web/cron services.

If anything is unclear, keep a playbook file with exact commands, usernames and paths ready — stored separately from the server and accessible only to authorized operators.

6. Governance, roles and responsibilities

Define clear tasks:

  • Software operator: infrastructure, backups, restore tests.
  • Merchant: plausibility checks of product data and terms after restore.
  • Partner: verification of tracking links and payout history.

Communication plan: name contacts, escalation levels and communication channels for an outage.

Conclusion and next step

A reliable disaster recovery plan for your self-hosted Affilentra instance combines consistent DB backups, binlog-based PITR, encrypted offsite storage and regular restore tests. Start with a simple pilot: perform full backups, enable binlogs, automate archiving and run the first recovery test in an isolated environment.

Want to get started right away or need assistance with implementation? Choose an entry: Choose an entry

Next step

Try Affilentra yourself

A unified platform that transparently brings together product provisioning, tracking, conversion validation, commission calculation and payouts across clearly separated roles; option for a self-hosted installation with a perpetual license and no revenue sharing; merchants retain control over products, terms and creatives; partners receive personal tracking links and a traceable payout history.

Choose an entry