PRA informatique : méthode et cas réel d'un site perdu

1. PRA, PCA : la différence

Le PRA : repartir après l'arrêt

Le plan de reprise d'activité accepte une interruption. Il fixe sa durée maximale, la quantité de données qu'on accepte de perdre, et la suite d'actions qui ramène le service : où restaurer, dans quel ordre, qui décide.

Le PCA : ne pas s'arrêter

Le plan de continuité d'activité cherche à éviter l'arrêt, par une architecture qui bascule d'elle-même sur un second site ou un second nœud. C'est le terrain de la haute disponibilité, et son budget n'est pas le même.

Le PCA ne dispense pas du PRA. Une réplication recopie aussi ce qui abîme : une suppression, une mauvaise migration, des fichiers chiffrés par un rançongiciel. Même avec une continuité parfaite, il faut savoir revenir à un état sain. C'est pourquoi la suite de cette page parle du PRA.

2. RTO et RPO : fixer ce qu'on accepte de perdre

Deux chiffres, fixés par le métier et non par l'informatique, dimensionnent tout le reste.

RTO : combien de temps sans le service ?

Le Recovery Time Objective est la durée d'arrêt maximale acceptée. Il décide de la méthode : en heures, une restauration depuis la sauvegarde peut suffire ; en minutes, il faut une infrastructure prête à reprendre la charge.

RPO : combien de données perdues ?

Le Recovery Point Objective se mesure en temps : un RPO de 24 heures accepte de perdre la dernière journée. Il décide de la fréquence des sauvegardes, ou de la réplication quand une sauvegarde quotidienne ne suffit pas.

Fixez-les par application, pas pour toute l'infrastructure : la comptabilité, la messagerie et le site public n'ont ni le même coût d'arrêt ni la même valeur de la dernière heure. Plus les deux chiffres sont courts, plus l'architecture coûte cher ; le calculateur RPO / RTO aide à mettre ce coût en regard de celui d'une heure d'arrêt.

Un RTO reste un objectif. Seule la durée mesurée lors d'une restauration réelle (section 5) dit s'il est tenable.

3. Cartographier ses dépendances : qui peut vous couper ?

Un service ne tombe pas seulement quand son serveur tombe. Listez, pour chaque application, tout ce dont elle a besoin pour fonctionner, et repérez ce qui n'existe qu'en un seul exemplaire.

L'énergie

Onduleur, groupe électrogène, climatisation : quelle autonomie réelle, et quand a-t-elle été vérifiée pour la dernière fois ?

Le réseau et les opérateurs

Liens Internet, interconnexion des sites, DNS. Deux liens chez deux opérateurs ne font pas une redondance s'ils empruntent le même fourreau ou le même point de collecte.

L'hébergeur et le site

Un seul datacenter, un seul bâtiment, un seul compte chez l'hébergeur : chacun est un point de rupture. Une sauvegarde rangée chez le même hébergeur que la production disparaît avec lui.

Une seule personne

Celle qui connaît les mots de passe, l'ordre de redémarrage ou le contact chez l'opérateur. Si elle est en congé le jour du sinistre, le plan doit fonctionner sans elle.

Un fournisseur « redondant » dépend souvent d'un autre

Votre hébergeur a deux arrivées électriques, mais un seul fournisseur d'énergie. Votre opérateur vous vend deux liens, mais les loue au même réseau de collecte. Votre outil en ligne est « multi-zone », mais repose sur un seul fournisseur d'identité. Pour chaque dépendance, posez la question un cran plus loin : de qui dépend-il, lui ? Nous l'avons fait pour notre réseau : voir la diversité réelle de nos propres transitaires. Et vérifiez que la documentation du PRA, les accès et les clés de chiffrement ne sont pas stockés sur le système qu'ils servent à restaurer.

L'arbitre d'un cluster, le witness qui tranche le quorum, est une dépendance comme une autre : si l'arbitre et le lien entre les deux moitiés du cluster dépendent du même bâtiment, le cluster les perd ensemble. C'est ce qu'a montré l'incendie d'un site cœur de réseau municipal, en 2023 (section 6).

4. Les scénarios à couvrir

Un PRA ne se rédige pas contre « le sinistre » en général. Chaque scénario appelle une réponse différente, et un plan qui n'en couvre qu'un laisse les autres sans réponse.

La perte d'un site : incendie, dégât des eaux

Le bâtiment et tout ce qu'il contient sont perdus, sauvegardes locales comprises. Il faut une copie des données ailleurs, un endroit où les restaurer, et un réseau capable de contourner le site disparu. C'est le scénario du cas réel de la section 6.

La panne de l'hébergeur

Les données sont souvent intactes mais inaccessibles, pour une durée que vous ne maîtrisez pas. Le plan doit dire à partir de quand on attend, et à partir de quand on restaure ailleurs : voir que faire pendant une panne d'hébergeur.

Le rançongiciel

L'attaquant vise aussi les sauvegardes qu'il peut atteindre. Il faut une copie qu'il ne peut ni effacer ni chiffrer, hors ligne ou immuable, avec des accès séparés de ceux de la production, et une restauration qui ne réinstalle pas la porte d'entrée de l'attaque. Le guide de la sauvegarde externalisée détaille ces options.

L'erreur humaine

Le scénario le plus fréquent et le moins spectaculaire : une table vidée, un dossier supprimé, une mise à jour qui casse l'application. Il demande des versions anciennes conservées assez longtemps, et une restauration fine, d'un fichier ou d'une base, sans tout écraser.

5. Tester son PRA : sinon, ce n'est qu'une hypothèse

Un PRA jamais testé n'est qu'une hypothèse. Un journal de sauvegarde « OK » prouve qu'une copie a été écrite, pas qu'elle se restaure, ni en combien de temps.

Une restauration réelle, sur une machine qui n'est pas la production, jusqu'à un service qui répond, pas seulement des fichiers présents.
Chronométrée : c'est la seule source honnête du RTO que vous pouvez tenir.
Datée et écrite : ce qui a été restauré, la durée, le résultat, et ce qui a manqué.
Refaite après chaque changement d'hébergeur, d'application ou de méthode de sauvegarde.

Le test révèle presque toujours autre chose que la sauvegarde : un mot de passe introuvable, une clé de chiffrement restée sur le serveur perdu, un ordre de démarrage que personne n'a noté. Pour une plateforme de virtualisation, la mise en œuvre concrète est décrite dans le PRA d'une infrastructure Proxmox.

6. Cas réel : la perte d'un site cœur

Le 28 juin 2023, à Mantes-la-Jolie, un incendie a détruit l'un des quatre sites cœur du réseau municipal, qui relie environ 80 sites. RDEM Systems assurait alors la conception et le support de ce réseau, de 2016 à 2024. Ce site hébergeait aussi le witness du cluster de virtualisation, et les deux brins de la boucle de fibre passaient par le bâtiment. Redéployer le witness ailleurs a rendu un arbitre au cluster, mais pas sa seconde moitié : il a fallu regrouper les nœuds de l'autre site là où le witness avait été redéployé, et remonter le cluster.

Personne ne pense à l'arbitre d'un cluster tant que le site qui l'héberge est debout. Le récit complet, et ce qu'il dit d'un PRA : incendie d'un site cœur : le retour d'expérience.

7. Ce que RDEM prend en charge

Le PRA reste le vôtre : c'est vous qui fixez le RTO et le RPO de chaque application. Nous tenons ce qui le rend exécutable le jour où il sert.

Une sauvegarde hors de votre hébergeur : un volume NimbusBackup est inclus dans les formules d'infogérance (Proxmox VE ou client PBS) ; sinon, la sauvegarde n'est pas incluse.
Des tests de restauration pour les clients éligibles : une machine virtuelle tirée au hasard, une par semestre jusqu'à cinq machines, une par trimestre au-delà, avec un rapport qui donne la durée mesurée.
Quelqu'un qui décroche : supervision 24/7 sur toutes les formules, et une astreinte avec une GTI de 4h en formule Pro ou de 1h en formule Critique, 24/7.

Ce que nous n'écrivons pas : un délai de reprise garanti. Nous engageons le délai d'intervention, pas celui du rétablissement, que personne ne peut promettre avant le diagnostic. Le chiffre que nous vous donnons est la durée mesurée lors du dernier test. Le détail, côté exploitation au quotidien : ce que l'infogérance tient d'un PRA.

Demander un devis

8. Questions fréquentes

Quelle est la différence entre un PRA et un PCA ?

Le PRA, plan de reprise d'activité, organise le redémarrage après un sinistre : il accepte une interruption et fixe sa durée maximale et la quantité de données qu'on accepte de perdre. Le PCA, plan de continuité d'activité, cherche à éviter l'arrêt, par une architecture redondante qui bascule d'elle-même. Le PCA coûte plus cher et ne dispense pas du PRA : une réplication recopie aussi une suppression ou un chiffrement par rançongiciel.

Un PRA est-il obligatoire ?

Aucun texte ne l'impose à toutes les entreprises. La directive NIS2 demande aux entités qu'elle couvre des mesures de continuité d'activité, dont la gestion des sauvegardes et la reprise après sinistre, et le règlement DORA fait de même pour le secteur financier. Pour les autres, la question est économique : combien coûte une journée d'arrêt, et combien de temps faudrait-il pour repartir sans plan.

La haute disponibilité remplace-t-elle un PRA ?

Non. Un cluster ou un stockage répliqué protège contre le matériel qui casse : il recopie fidèlement tout ce qu'on lui écrit, y compris une table vidée par erreur ou des fichiers chiffrés. Et si les deux nœuds sont dans le même bâtiment, un incendie les emporte ensemble. Le PRA couvre ce que la haute disponibilité ne couvre pas : la perte du site, la donnée abîmée, le retour à un état sain.

Une sauvegarde suffit-elle comme PRA ?

Non : la sauvegarde est la matière première du PRA, pas le plan. Le plan dit où l'on restaure si le site est perdu, dans quel ordre, avec quels accès et qui décide. Sans ces réponses écrites à l'avance, une sauvegarde intacte peut rester inutilisable pendant des jours, faute de machine pour la recevoir ou de clé pour la déchiffrer.

À quelle fréquence tester un PRA ?

À une fréquence fixée à l'avance et tenue, et après chaque changement d'architecture : nouvel hébergeur, nouvelle application, nouvelle méthode de sauvegarde. Le test qui compte est une restauration réelle, chronométrée et datée, pas la lecture d'un journal de sauvegarde. Chez nos clients éligibles, nous restaurons une machine virtuelle tirée au hasard, une par semestre jusqu'à cinq machines et une par trimestre au-delà, avec un rapport.

RDEM garantit-il un délai de reprise ?

Non. Nous engageons un délai d'intervention, la GTI : 4h en formule Pro, 1h en formule Critique, 24/7. Nous n'engageons pas de délai de rétablissement, car tant que le diagnostic n'est pas posé, aucune durée de réparation ne peut être promise honnêtement. Le chiffre que nous communiquons est la durée de restauration mesurée lors du dernier test, pas une garantie.

Plan de reprise d'activité (PRA) informatique : la méthode, et ce qu'un vrai sinistre en dit

Sommaire