Introduction
Self‑hosted means control — but also responsibility. For Affilentra installations (PHP/MySQL), reliable backups, reproducible migration paths and tested rollback procedures are indispensable to ensure tracking, commission calculation and payouts without interruption. This article provides practical recommendations you can implement immediately to minimize downtime and make recovery times predictable.
Fundamental Principles of a Robust Strategy
- Separate roles: Software operators perform infrastructure tasks (backups, upgrades), merchants coordinate campaigns and partners verify tracking integrity.
- Separation of code and data: Back up the filesystem (webroot, media, creatives) separately from the database.
- Automate, document, test: Every backup and migration step must be automatable and reproducible in a test environment.
- Minimally invasive migrations: Design schema changes so that old and new code paths can temporarily coexist.
Backup Strategy: Intervals and Retention
A practical combination of full backups, incremental backups and continuous transaction logging reduces recovery windows.
- Database:
- Full backup (physical or logical) at least once daily for active systems.
- For low RTO/RPO: enable and regularly archive binary logs (MySQL binary logs) to allow point‑in‑time recovery.
- For large databases: use physical backups (e.g., Percona XtraBackup) or consistent snapshots via replication to avoid locking.
- Filesystem / Application Files:
- Full backup once daily; for frequent changes (creatives, uploads) add hourly incremental backups.
- Always create an immediate snapshot backup before any upgrade.
- Retention: Minimum: daily backups for the last 7 days; weekly backups for 8 weeks; monthly backups for 12 months. Adjust retention to regulatory requirements and business needs.
- Offsite & Verification: Store backups encrypted and at least one external location. Test restorations regularly (e.g., monthly).
DB Snapshots and Tools
Choose the tool based on the size and availability requirements of your installation.
- smaller installations: mysqldump is suitable for logical backups and simple restores.
- medium to large installations: Percona XtraBackup or physical snapshots (LVM, ZFS) provide consistent, faster backups without long locks.
- replication as a backup source: A read‑only replica can be used for backups and for test environments to avoid impacting production load.
- before the upgrade: Always create a consistent snapshot including active binary logs and record the binlog position.
Migration paths between versions
Plan migrations so that data integrity is preserved and rollbacks are possible.
- versioned migrations: Use a migration framework (e.g. Doctrine Migrations, Phinx or an in‑house tool) with clearly definable up and down scripts.
- prefer additive changes: Add new columns as nullable, create indexes in separate steps, perform migration backfills asynchronously.
- backward compatibility: Deploy code that works with both the old and new schema first. Only after a successful deploy and backfill switch to the new schema and remove legacy functionality later.
- avoid schema blockers: Long ALTER TABLE operations should be prepared on replicas and then executed using controlled procedures (pt‑online‑schema‑change, gh‑ost).
Test environments & CI/CD
A test environment that mirrors production is mandatory.
- full staging copy: Regularly generate from production snapshots, including filesystem and DB (provide masking of sensitive data).
- automated migration runs: Execute every migration in CI against staging and automate integration and smoke tests (tracking flow, conversion, commission calculation, payout history).
- canary / blue‑green: For larger releases consider a canary rollout (small traffic percentage) or blue‑green deployment to quickly revert to the stable environment in case of errors.
Rollback processes: step by step
A tested rollback plan minimizes operational risks.
- Preparation: Complete backup + binlog position before the release; define release checklist and responsibilities.
- Prioritize rollback options:
- Rollback of the application (fastest option) — if migrations were reversible and not already destructive.
- Restore the database from a snapshot — necessary if migrations contained irreversible changes or data corruption occurred.
- Steps on error:
- Lock writes or enter maintenance mode.
- Roll the application back to the previous version.
- If necessary, restore the DB from a snapshot and replay the binlog up to just before the faulty change.
- Run smoke tests and, after validation, re-enable writes.
- Communication: Proactively inform merchants and partners about possible impacts on tracking and payouts.
Practical upgrade procedure (example)
Concrete procedure for a typical release window:
- 72–48 hours beforehand: Publish release notes, test plan, and designate responsible persons.
- 24 hours beforehand: Full DB backup, archive the binlogs, snapshot the webroot files.
- Before deploy: Restore staging from the snapshot and run automated tests.
- Deploy in canary/blue‑green: Gradually increase traffic, monitor for 30–60 minutes.
- After approval: Perform asynchronous backfills and index builds; remove deprecated fields only after an observation period.
Monitoring, validation and governance
Systematic checks are required after every upgrade:
- Smoke tests: Generate a tracking link, simulate a conversion, verify commission calculation, check payout entries.
- Logs and metrics: Watch error rates, latencies, queue lengths and DB slow queries.
- Audit and change log: Document every migration and every rollback, including backup reference and binlog position.
Role‑based responsibilities
Clear task allocation reduces friction:
- Software operators: Ensure backup automation, snapshot management, applying upgrades and rollbacks.
- Merchants: Plan campaigns around maintenance windows; check campaign metrics and creatives after the release.
- Partners/publishers: Verify tracking links and payout histories after a release and report discrepancies immediately.
Conclusion and next steps
Planning pays off for Affilentra installations: consistent backups, a staged migration strategy and tested rollback procedures reduce downtime risks and protect revenue. Start with three simple measures: daily DB backups + binlog archiving, a staging restore before each release, and a written rollback checklist.
Ready for the next step? Choose your starting option and get advice on suitable license options and support packages: Choose a starting option.
Next step
Try Affilentra yourself
A unified platform that transparently brings together product provisioning, tracking, conversion validation, commission calculation and payout across clearly separated roles; option for a self‑hosted installation with a perpetual license and no revenue share; merchants retain control over products, terms and promotional materials; partners receive personal tracking links and a transparent payout history.