Pourquoi un plan de reprise après sinistre pour Affilentra est indispensable
Affilentra combine le suivi, le calcul des commissions et la facturation sur une plateforme PHP/MySQL auto‑hébergée. En tant qu’exploitant, vous assumez la responsabilité de l’intégrité des données, de l’historique des paiements et de la confiance des partenaires. Un plan de reprise après sinistre ciblé garantit que les données perdues (transactions, configurations, supports publicitaires) peuvent être restaurées rapidement et de façon reproductible — sans surprises concernant les rôles, les permissions ou les calculs de facturation.
Aperçu : objectifs de ce guide
- Sauvegarde cohérente de la base de données, du système de fichiers et de la configuration.
- Mise en place du Point‑in‑Time‑Recovery (PITR) avec les binlogs MySQL.
- Automatisation, chiffrement et règles de conservation.
- Procédés de restauration définis, testés et contrôlés régulièrement.
1. Architecture et prérequis
Analysez d’abord votre installation : où se trouvent les fichiers PHP, les uploads, les tâches cron, les fichiers de configuration (par ex. config.php) et la base de données MySQL ? Séparez les rôles : opérateur logiciel (infrastructure/sauvegardes), commerçant (gestion des produits) et partenaire (liens de tracking) ont des objectifs de restauration et des droits d’accès différents.
Prérequis recommandés :
- Accès root/administrateur au serveur et à l’instance MySQL.
- Stockage d’export fiable (local + hors site, par ex. objet‑storage ou système de sauvegarde externe).
- Outils de chiffrement (gpg, age) et un concept de gestion des clés.
2. Stratégie de sauvegarde : quoi sauvegarder et où ?
Les trois piliers sont :
- Base de données (MySQL) : dumps complets plus binlogs pour le PITR.
- Système de fichiers : code PHP, uploads, médias, supports publicitaires.
- Configuration & Cron : fichiers de config, unités systemd, certificats SSL.
Sauvegardes de la base de données
Réalisez des sauvegardes complètes cohérentes régulières (par ex. via mysqldump --single-transaction pour les tables InnoDB) ou utilisez des sauvegardes physiques (Percona XtraBackup) pour les grandes installations. De plus, les binlogs MySQL doivent être activés afin de pouvoir reconstruire au niveau des transactions.
Configuration MySQL importante (my.cnf) :
log_bin = mysql-binserver-id = 1(ou un ID unique)binlog_format = ROW(recommandé pour une réplication/PITR fiable)- Optionnel :
expire_logs_daysou rotation personnalisée via script
Point‑in‑Time‑Recovery (PITR)
PITR complète les sauvegardes complètes : sauvegardez en continu les binlogs et notez les horodatages ou GTID à chaque sauvegarde complète. En cas de restauration, remettez la dernière sauvegarde complète puis réappliquez les binlogs avec mysqlbinlog --start-datetime / --stop-datetime | mysql jusqu’au moment souhaité avant l’incident.
Sauvegardes du système de fichiers et de la configuration
Sauvegardez :
- Le répertoire du code source (fichiers PHP, bibliothèques).
- Uploads/Media/Assets (images de suivi, éléments publicitaires).
- Fichiers de config, certificats SSL, scripts Cron et fichiers systemd/Unit.
Créez des archives atomiques (par ex. tar + gzip) ou utilisez des outils basés sur les fichiers (rsync) pour des sauvegardes incrémentielles. Faites attention aux permissions de fichiers et aux contextes SELinux/ACL lors de la restauration.
3. Automatisation, stockage et chiffrement
Automatisation
Utilisez Cron ou les timers systemd pour les tâches récurrentes :
- Dump complet de la base de données quotidien (la nuit, en dehors des heures de pointe).
- Collecte continue et archivage des binlogs (par ex. toutes les 5–15 minutes).
- Snapshots du système de fichiers quotidiens/multiples ou tâches Rsync incrémentielles.
Consignez chaque sauvegarde avec horodatage, somme de contrôle SHA256 et taille de fichier pour la vérification d’intégrité.
Politique de rétention
Définissez une politique de rétention adaptée à vos exigences de conformité et à vos objectifs de temps de récupération. Une structure d’exemple pour orientation :
- Sauvegardes quotidiennes : 14 jours
- Sauvegardes hebdomadaires : 12 semaines
- Sauvegardes mensuelles : 12 mois
Conservez les sauvegardes au moins à un emplacement externe (offsite). Le stockage objet (compatible S3) ou un fournisseur de sauvegarde séparé réduit les risques liés aux défaillances matérielles.
Chiffrement et gestion des clés
Chiffrez les sauvegardes au repos avec des clés GPG/age. Séparez les emplacements de stockage du matériel de clés (par ex. clés dans un HSM dédié ou gestionnaire de mots de passe avec contrôle d’accès). Planifiez la rotation des clés et documentez les accès de récupération.
4. Processus de restauration et tests réguliers
Checklist de restauration (flux de base)
- Isolez l’environnement pour éviter l’écrasement des données.
- Restaurez la sauvegarde complète appropriée de la base de données MySQL.
- Importez les binlogs jusqu’au point d’arrêt désiré (PITR).
- Restaurez la sauvegarde du système de fichiers (code et médias).
- Vérifiez les configurations, permissions et secrets.
- Effectuez des tests d’intégrité et de fonctionnement (tracking, connexion, calcul des commissions).
- Documentez la durée et les écarts ; adaptez la stratégie en conséquence.
Tests réguliers de restauration
Testez au moins une restauration complète chaque mois dans un environnement de test isolé. Entraînez des scénarios PITR à différents instants (p. ex. une erreur juste avant le jour de facturation). Validez notamment :
- Intégralité de l'historique des transactions et des chroniques de paiements.
- Fonctionnalité des liens de tracking et validation des conversions.
- Constitution des rôles et des droits (opérateur du logiciel vs. commerçant vs. partenaire).
5. Exemple : restauration pas à pas avec PITR
1) Choisissez la dernière sauvegarde complète cohérente (p. ex. full_2026-10-01.sql.gz). 2) Décompressez-la et importez‑la dans une instance MySQL vide. 3) Déterminez les points de départ/arrêt des binlogs (p. ex. d'après le moment de l'incident). 4) Utilisez mysqlbinlog pour appliquer les binlogs dans l'ordre. 5) Restaurez ensuite les archives du système de fichiers, corrigez les chemins et les permissions, et démarrez les services Web/Cron.
En cas d'incertitude, tenez un fichier playbook avec les commandes exactes, les noms d'utilisateurs et les chemins — séparé du serveur et accessible uniquement aux opérateurs autorisés.
6. Gouvernance, rôles et responsabilités
Définissez des tâches claires :
- Opérateur du logiciel : infrastructure, sauvegardes, tests de restauration.
- Commerçant : vérification de plausibilité des données produits et des conditions après restauration.
- Partenaire : vérification des liens de tracking et de l'historique des paiements.
Plan de communication : nommez des interlocuteurs, des niveaux d'escalade et des canaux de communication pour un incident.
Conclusion et prochaine étape
Un plan de reprise après sinistre fiable pour votre instance Affilentra self‑hosted combine des sauvegardes DB cohérentes, un PITR basé sur les binlogs, le stockage hors site chiffré et des tests de restauration réguliers. Commencez par un pilote simple : mettez en place des sauvegardes complètes, activez les binlogs, automatisez l'archivage et réalisez le premier test de restauration dans un environnement isolé.
Vous souhaitez démarrer immédiatement ou avez besoin d'aide pour la mise en œuvre ? Choisissez un point d'entrée : Einstieg wählen
Prochaine étape
Essayer Affilentra soi‑même
Plateforme unifiée qui centralise de manière transparente la mise à disposition des produits, le tracking, la validation des conversions, le calcul des commissions et les paiements selon des rôles clairement séparés ; option d'installation self‑hosted avec licence perpétuelle sans partage du chiffre d'affaires ; les commerçants conservent le contrôle sur les produits, les conditions et les supports publicitaires ; les partenaires reçoivent des liens de tracking personnels et un historique des paiements traçable.