Ce que couvre le PRA
- Identification des services critiques.
- Réplication des environnements éligibles.
- Définition des priorités de reprise.
- Procédure de bascule et de retour en fonctionnement normal.
- Tests périodiques et comptes rendus.
PRA et Disaster Recovery
PRA informatique : prévoir la panne avant qu'elle ne devienne une crise.
Un plan de reprise d'activité ne consiste pas seulement à avoir une sauvegarde. Il faut savoir quels services redémarrer, dans quel ordre, avec quelles données, et comment vérifier que la reprise fonctionne.
La vraie question
Si le serveur principal tombe demain matin, qui fait quoi, combien de temps cela prend, quelles données sont perdues, et comment les utilisateurs continuent à travailler ?
Ce que je documente
- Périmètre protégé.
- Dépendances réseau, système et applicatives.
- Points de contrôle avant et après bascule.
- Rôles et actions à mener en cas d'incident.
- Limites connues et pistes d'amélioration.
Le PRA s'appuie sur des sauvegardes et une réplication maîtrisées et peut être intégré à des serveurs cloud managés, un stockage en ligne managé et un suivi technique via une offre d'infogérance cloud complète.
Sauvegarde et PRA
Sauvegarde et PRA : deux choses différentes.
La sauvegarde protège les données
Elle garantit qu'une copie existe encore après un incident, à une date donnée. Elle ne dit ni où redémarrer, ni dans quel ordre, ni en combien de temps. Sa mise en place est détaillée sur la page sauvegarde, réplication et restauration.
Le PRA organise la reprise
Il définit les services prioritaires, l'infrastructure de secours, l'ordre de redémarrage, les rôles de chacun et les contrôles à faire avant de rouvrir le service. C'est un plan testé, pas une copie de fichiers.
Scénarios de panne
Les situations qu'un PRA doit couvrir.
Panne matérielle
Disque, contrôleur ou serveur hors service. La reprise passe par une réplication ou une restauration sur un autre hôte, dans le délai fixé par le RTO.
Rançongiciel
Données chiffrées et comptes potentiellement compromis. Il faut une copie immuable ou hors ligne, des identifiants distincts et une reconstruction sur un système sain avant toute restauration.
Perte du site
Incendie, dégât des eaux ou coupure prolongée. Seules des sauvegardes hors site et une infrastructure de reprise située ailleurs permettent de repartir.
Erreur humaine
Suppression, mauvaise mise à jour ou configuration écrasée. Une rétention suffisante et des restaurations ciblées évitent de tout remettre en cause pour un seul fichier ou une seule machine.
RPO et RTO
Deux chiffres à fixer avant de choisir une solution.
RPO : la perte de données acceptable
Le Recovery Point Objective indique jusqu'à quel moment les données doivent pouvoir être restaurées. Une sauvegarde nocturne implique jusqu'à une journée de travail perdue. Une réplication fréquente réduit cette fenêtre mais augmente le coût et la complexité.
RTO : la durée d'interruption acceptable
Le Recovery Time Objective fixe le délai maximal pour rendre le service de nouveau utilisable. Il détermine s'il suffit de restaurer une sauvegarde, ou s'il faut un environnement secondaire prêt à prendre le relais.
Ces objectifs sont définis service par service : une messagerie, un ERP et un site vitrine n'ont pas la même criticité.
Méthode
De l'analyse au test de bascule.
1
Inventaire et criticité
Recensement des services, des données, des dépendances et de l'impact métier d'une interruption.
2
Objectifs et architecture
Choix du RPO, du RTO, du site de reprise, de la fréquence de réplication et de la rétention des sauvegardes.
3
Mise en place
Configuration des sauvegardes hors site, de la réplication, des accès d'urgence et de la supervision des tâches.
4
Test et documentation
Restauration réelle ou bascule contrôlée, mesure des temps obtenus, compte rendu et procédure mise à jour.
Ordre de redémarrage
Redémarrer dans le bon ordre, dépendances comprises.
Une application ne redémarre pas si le réseau, la résolution DNS, l'annuaire ou la base de données dont elle dépend ne sont pas déjà disponibles. Le PRA cartographie ces dépendances et en déduit un ordre de reprise écrit, avec un point de contrôle à chaque étape.
Ordre type
- Réseau, pare-feu et accès d'urgence.
- DNS, annuaire et identités.
- Stockage et bases de données.
- Applications métier.
- Accès des utilisateurs et vérifications finales.
Cas pratique
Exemple de PRA : le serveur du logiciel métier ne répond plus.
Que se passe-t-il si le serveur qui héberge votre logiciel métier devient indisponible ? Voici le déroulé type d'une reprise pour une PME d'une vingtaine de personnes.
Le point de départ
Le logiciel de gestion, sa base de données et les fichiers partagés tournent sur un seul serveur. Une sauvegarde part chaque nuit vers un stockage hors site. L'entreprise accepte de perdre au plus une journée de saisie (RPO) et veut retravailler dans la demi-journée (RTO).
Les dépendances à remettre en route
- Le réseau et l'accès VPN des utilisateurs à distance.
- La résolution DNS et l'annuaire, pour l'authentification.
- La base de données, avant le logiciel qui l'utilise.
- Les licences du logiciel, parfois liées à la machine.
- Les postes, imprimantes et échanges avec les partenaires.
La reprise prévue
Le PRA prévoit une restauration sur un serveur de secours dans le cloud, à partir de la dernière copie hors site. La procédure suit l'ordre écrit : réseau, DNS, base de données, logiciel, puis accès des utilisateurs. Chaque étape a son point de contrôle, et le dernier test a mesuré la durée réelle de la reprise.
Les limites à anticiper
- Les saisies faites depuis la dernière sauvegarde sont à refaire.
- Une licence liée au matériel peut exiger l'éditeur pour être réactivée.
- Après un rançongiciel, un système sain est reconstruit avant toute restauration, ce qui allonge le délai.
- Le retour sur le serveur principal se planifie, avec ses propres contrôles.
Exemple type. Pour réduire la perte de données, une réplication plus fréquente complète la sauvegarde nocturne. Sur une plateforme Proxmox, la réplication entre nœuds raccourcit aussi la reprise. Selon l'offre retenue, un test annuel ou des tests périodiques vérifient que ce scénario tient toujours.
Tests et documentation
Un PRA non testé reste une hypothèse.
Le test mesure le temps réel de reprise, le compare au RTO et révèle ce que la documentation a oublié.
Tests périodiques
Restaurations partielles régulières, et bascule complète au moins une fois par an ou après un changement important. Selon l'offre, le test est annuel avec compte rendu, ou périodique avec une procédure renforcée.
Documentation exploitable
Procédure pas à pas, contacts, accès de secours stockés hors de l'infrastructure protégée, et limites connues. Elle doit pouvoir être suivie par quelqu'un d'autre que son auteur, en pleine crise.
Tarifs indicatifs
Offres PRA.
| Offre | Inclus | Prix indicatif | Mise en service |
|---|---|---|---|
| PRA Essentiel | Configuration et vérification. | 99 € par environnement par mois | 790 € |
| PRA Pro | Test annuel et compte rendu. | 199 € par environnement par mois | 1 500 € |
| PRA Sécurité | Tests périodiques et procédure renforcée. | 390 € par environnement par mois | 2 500 € |
Les coûts de réplication, stockage, serveurs secondaires et consommations sont calculés selon le périmètre protégé. TVA non applicable, article 293 B du CGI.
Questions fréquentes
PRA, PCA et sauvegardes.
Quelle différence entre un PRA et un PCA ?
Le plan de reprise d'activité organise le redémarrage après une interruption. Le plan de continuité d'activité vise à éviter l'interruption elle-même, par exemple avec des services redondés. Beaucoup de TPE et PME commencent par un PRA réaliste, puis renforcent la continuité sur les services les plus critiques.
Mes sauvegardes suffisent-elles ?
Une sauvegarde qui n'a jamais été restaurée reste une hypothèse. Le PRA vérifie qu'elle est complète, isolée d'une compromission du système principal, et que la reprise tient dans le délai attendu.
Un PRA protège-t-il contre un rançongiciel ?
Il limite fortement l'impact si les sauvegardes sont hors ligne ou immuables et si les accès d'administration sont séparés. Il doit être complété par la sécurisation des systèmes pour réduire le risque d'infection.
À quelle fréquence tester un PRA ?
Au moins une fois par an pour une bascule complète, et après chaque changement important de l'infrastructure. Des restaurations partielles plus fréquentes vérifient entre-temps que les sauvegardes restent exploitables.
Faut-il un second site ?
Pas nécessairement. La reprise peut se faire sur une plateforme cloud à partir de copies hors site, si le RTO le permet. Un environnement secondaire prêt à démarrer n'est utile que lorsque le délai d'interruption acceptable est court.
Le PRA peut-il être mis en place à distance ?
Oui. L'analyse, la configuration, les tests et la documentation sont réalisés à distance, avec des accès temporaires et contrôlés.