Sauvegarde et plan de reprise d'activité d'un ERP : le guide essentiel

Votre ERP contient vos factures, vos stocks, votre comptabilité et l'historique de vos clients. Perdre une journée de données, c'est au mieux ressaisir une journée de travail. Au pire, c'est ne plus pouvoir facturer, expédier ou clôturer pendant que l'on reconstruit.

Pourtant, l'objectif n'est pas d'avoir des sauvegardes : c'est de pouvoir restaurer, vite et proprement. Ce guide pose les notions essentielles, les erreurs à éviter et une liste de contrôle pour faire le point sur votre situation.

Sauvegarde, réplication, PRA : trois choses différentes

Ces trois mots sont souvent confondus. Ils ne protègent pas contre les mêmes risques.

• La sauvegarde est une copie de vos données à un instant donné, conservée pendant une certaine durée. Elle permet de revenir en arrière après une suppression, une corruption ou une attaque.
• La réplication maintient une seconde copie à jour en continu, sur un autre serveur. Elle protège contre la panne d'une machine, mais elle recopie aussi les erreurs : une table supprimée par mégarde l'est aussitôt sur la réplique. La réplication ne remplace pas la sauvegarde.
• Le plan de reprise d'activité (PRA) décrit comment redémarrer le service après un incident majeur : qui décide, dans quel ordre on relance les systèmes, à partir de quelles copies, et comment on vérifie que les données sont saines.

Un dispositif solide combine les trois : la réplication pour les pannes, les sauvegardes pour revenir en arrière, le PRA pour savoir quoi faire le jour J.

RPO et RTO : fixer ses objectifs avant la technique

Deux indicateurs structurent toute stratégie de reprise :

• Le RPO (Recovery Point Objective) est la quantité maximale de données que vous acceptez de perdre, exprimée en temps. Avec une sauvegarde par nuit et sans autre mécanisme, un incident en fin de journée peut coûter jusqu'à une journée de saisie.
• Le RTO (Recovery Time Objective) est la durée maximale d'interruption acceptable avant que le service ne soit rétabli.

Ces objectifs ne se décident pas au service informatique, mais avec les métiers. Posez des questions concrètes : combien d'heures de saisie pouvons-nous refaire ? Combien de temps pouvons-nous facturer, expédier ou payer sans l'ERP ? La réponse change souvent selon la période : une panne en pleine clôture mensuelle n'a pas le même coût qu'un mardi ordinaire.

Plus les objectifs sont ambitieux, plus le dispositif coûte cher. Les fixer d'abord évite de surpayer une protection inutile, ou de découvrir trop tard qu'elle était insuffisante.

La règle 3-2-1, adaptée à un ERP

La règle 3-2-1 reste la base d'une stratégie de sauvegarde :

• 3 copies de vos données : la production et deux sauvegardes.
• 2 supports ou systèmes de stockage différents, pour qu'une même panne ne les emporte pas ensemble.
• 1 copie hors site, à l'abri d'un incident sur le lieu principal.

Face aux rançongiciels, on y ajoute souvent une copie isolée ou immuable, que les attaquants ne peuvent ni chiffrer ni effacer, même avec des identifiants volés.

Pour un ERP, une précaution de plus : la sauvegarde doit être cohérente. Copier les fichiers d'une base de données en cours d'écriture peut produire une sauvegarde inutilisable. Il faut passer par les outils de la base, ou par des instantanés pris au bon moment.

Ce qu'il faut sauvegarder, et qu'on oublie souvent

La base de données ne suffit pas. Pour redémarrer un ERP complet, il faut aussi :

• les pièces jointes et documents : factures scannées, bons de livraison, fichiers stockés hors de la base ;
• les développements spécifiques et modules complémentaires, dans la version exacte en production ;
• la configuration : paramètres, utilisateurs et droits, tâches planifiées, modèles d'impression ;
• les intégrations : connecteurs, clés d'API, correspondances EDI, certificats et licences.

Une base restaurée sans sa configuration ni ses intégrations, c'est un ERP qui démarre mais qui ne fonctionne pas.

Un PRA qui fonctionne le jour J

Un PRA utile est écrit, connu et testé.

Écrit. Pour chaque scénario (panne de serveur, corruption de données, rançongiciel, erreur humaine, perte d'un site), il précise qui décide, les étapes, l'ordre de redémarrage (base de données, application, puis intégrations), les contrôles d'intégrité et la manière d'informer les utilisateurs.

Testé. Seule une restauration réelle prouve qu'une sauvegarde fonctionne. Des tests réguliers, par exemple chaque trimestre, permettent aussi de mesurer votre RTO réel, souvent plus long que prévu.

Pensé pour les rançongiciels. Gardez des copies isolées, protégées par des identifiants distincts de ceux de la production, et conservées assez longtemps pour revenir à une date antérieure à l'infection, qui est souvent découverte avec retard.

Les erreurs les plus fréquentes

• Stocker les sauvegardes au même endroit que la production, sur le même serveur ou avec les mêmes accès.
• Ne jamais tester de restauration, et découvrir le jour de l'incident qu'une sauvegarde est incomplète.
• Sauvegarder uniquement la base de données, sans les fichiers, la configuration ni les intégrations.
• Prendre la réplication pour une sauvegarde.
• Ne pas surveiller les tâches de sauvegarde : un échec silencieux peut durer des semaines.
• Une durée de conservation trop courte pour revenir avant une corruption détectée tardivement.

Ce que nous faisons chez BigBang Cloud

Chez BigBang Cloud, la continuité d'activité fait partie du service, pas d'une option :

• Des plans de sauvegarde automatisés, la réplication et un plan de reprise d'activité géré sont inclus pour chaque environnement.
• Une surveillance 24/7 de votre environnement, de jour comme de nuit.
• Une sécurité en plusieurs couches : ZTNA, WAF, VPN, segmentation du réseau et chiffrement SSL.
• Vos données vous appartiennent : la réversibilité est totale et contractuelle, et vous pouvez obtenir à tout moment une sauvegarde complète et exportable de votre base.

Chaque projet commence par un audit de votre ERP, de ses personnalisations et des applications qui y sont connectées : c'est le bon moment pour parler de vos objectifs de reprise.

Liste de contrôle

Faites le point en cinq minutes :

1. Vos objectifs de RPO et de RTO sont-ils définis avec les métiers ?
2. Avez-vous au moins une copie hors site et une copie isolée ?
3. Vos sauvegardes couvrent-elles la base, les fichiers, la configuration et les intégrations ?
4. Quand avez-vous restauré une sauvegarde pour la dernière fois ?
5. Votre PRA est-il écrit, et l'équipe sait-elle où le trouver ?
6. Quelqu'un est-il alerté quand une sauvegarde échoue ?

Si l'une de ces réponses vous fait hésiter, parlons-en.