Réponse courte. On écrit d'abord deux chiffres par système : combien de minutes de données on accepte de perdre, et combien de temps on accepte d'être arrêté. Pour une application de gestion, nous écrivons par défaut quinze minutes et deux heures. Puis on construit ce qui les tient : le code et la configuration dans un dépôt hors du serveur, pour recréer un serveur neuf en minutes ; la base avec une copie régulière et l'archivage continu de ses journaux vers un autre site, pour revenir à n'importe quelle minute ; les fichiers dans un stockage versionné sur un second site, avec une période pendant laquelle rien ne peut être effacé, même par un administrateur ; les secrets dans un gestionnaire, les comptes et le domaine au nom de l'entreprise, deux personnes qui savent ; et un exercice de restauration complet chaque mois, sur un serveur vide chez un autre hébergeur, chronométré, consigné, lu par le gérant. Une sauvegarde jamais restaurée n'est pas une sauvegarde.
Ce guide s'adresse au gérant qui a déjà perdu une journée de ventes, au fondateur installé en France qui ne saura qu'au téléphone que le serveur est mort, et au responsable informatique qui doit répondre à « et si… ». Il ne redit pas où placer les serveurs, décrit dans le guide sur l'hébergement, ni comment reprendre une application dont le prestataire a disparu, décrit dans le guide dédié ; il décrit ce qui se construit pour que la panne soit un mardi matin ordinaire, et il prolonge notre page sur le cloud et l'infrastructure.
Ce que les documentations disent
La base de données peut revenir à la minute près, mais pas avec n'importe quelle sauvegarde. La documentation de PostgreSQL décrit l'archivage continu des journaux de transactions combiné à une copie de base : « cette technique permet la récupération à un instant donné : il est possible de restaurer la base dans l'état où elle était à n'importe quel moment depuis la copie de base ». Elle prévient aussi que les sauvegardes logiques, celles qu'on fait chaque nuit avec un export, « ne produisent pas de sauvegardes au niveau du système de fichiers et ne peuvent pas faire partie d'une solution d'archivage continu », qu'il faut « une séquence continue de journaux archivés » remontant au moins au début de la copie, et qu'on est « invité à surveiller le processus d'archivage ». Ce que cela impose : l'export nocturne garde sa place, mais ce qui tient un objectif de quinze minutes, c'est l'archivage continu, vers un autre site, surveillé par une alerte quand il s'arrête.
Les fichiers peuvent devenir impossibles à effacer, même par vous. La documentation du stockage d'objets d'un grand fournisseur décrit un verrouillage « écrire une fois, lire plusieurs fois » : en mode conformité, « une version d'objet protégée ne peut être ni écrasée ni supprimée par aucun utilisateur, y compris l'utilisateur racine du compte », pendant une période de rétention qui ne peut être raccourcie ; et elle cite comme usage « une fenêtre de récupération configurable contre les rançongiciels ou la suppression accidentelle ». Ce que cela impose : les copies de fichiers et de base sont versionnées et verrouillées pour une durée écrite, trente jours par exemple, et un attaquant qui a pris le serveur ne peut pas les effacer ; ni un administrateur pressé.
La règle que les agences de sécurité répètent tient en trois chiffres : trois copies, sur deux supports, dont une ailleurs ; nous y ajoutons un quatrième mot, inaltérable, et un cinquième, restaurée. Ce que nous n'avons pas trouvé : une statistique publique des pertes de données subies par les entreprises en Algérie, ni du temps moyen de reprise ; ce que nous voyons sur les applications que nous reprenons, c'est une sauvegarde nocturne sur le même serveur dans la majorité des cas, et une restauration jamais essayée dans presque tous, et nous le disons comme une observation.
Le jour où le serveur meurt, sur l’horloge
La reprise ne se comprend pas sur un principe mais sur une matinée, minute par minute.
9 h 14, le disque du serveur de production meurt. 9 h 16, l'alerte arrive sur deux téléphones, pas un. 9 h 20, la décision est prise et le document de reprise ouvert : il dit qui fait quoi, dans quel ordre, et où sont les copies. 9 h 25, un serveur neuf existe chez l'hébergeur de secours, créé depuis le dépôt de code qui décrit le serveur ; personne n'installe rien à la main. 9 h 40, la base est restaurée au point de 9 h 13 : la dernière copie de base plus les journaux archivés en continu jusqu'à la minute qui précède la panne. Une minute de données perdue, pour un objectif écrit de quinze.
10 h 05, les fichiers, photos, documents, exports, sont revenus depuis la copie versionnée du second site ; c'est l'étape la plus longue, et c'est pour cela qu'on la mesure chaque mois. 10 h 20, le nom de domaine pointe vers le nouveau serveur. 10 h 30, douze vérifications métier sont passées : une commande, une facture, un paiement, un export, une connexion. 10 h 35, les clients travaillent à nouveau. Une heure vingt et une d'indisponibilité pour un objectif de deux heures. Rien n'a été improvisé : chaque étape avait été jouée lors de l'exercice du mois précédent, et le fondateur, à Lyon, a suivi la matinée sur le même document que l'équipe. L'exemple est construit à partir de cas réels ; les deux objectifs sont ceux que nous écrivons par défaut.
«Une sauvegarde jamais restaurée n'est pas une sauvegarde ; c'est l'exercice qui la rend réelle, et le rapport qui la rend vérifiable.»
Ce qu’il faut pour survivre à son serveur, en cinq couches
Derrière cette matinée, cinq couches, et une seule qui prouve que les quatre autres existent.
Le code et la configuration : le code de l'application, la description du serveur, les réglages et les scripts de déploiement vivent dans un dépôt hors du serveur ; un serveur neuf se recrée depuis ce dépôt en minutes, et rien n'est « installé à la main » une fois, comme le guide sur la livraison le décrit. La base de données : une copie de base régulière et l'archivage continu des journaux vers un autre site, pour revenir à n'importe quelle minute ; un réplica si l'activité exige de ne pas s'arrêter du tout. Les fichiers : photos, documents et exports dans un stockage d'objets versionné sur un second site, avec une période pendant laquelle rien ne peut être effacé.
Les secrets et les accès : mots de passe, clés et certificats dans un gestionnaire de secrets, jamais sur le serveur ni dans le code ; les comptes hébergeur et le domaine au nom de l'entreprise, avec deux personnes qui savent, pour que ni le serveur mort ni le prestataire disparu n'emportent quoi que ce soit ; c'est la discipline décrite dans le guide sur les droits. L'exercice et la supervision : une restauration complète chaque mois sur un serveur vide, chronométrée et consignée, et des alertes si une sauvegarde manque ou si l'archivage s'arrête. C'est la seule couche qui prouve l'existence des quatre autres : une sauvegarde qu'on n'a jamais restaurée est une hypothèse.
Six façons de sauvegarder, et ce qu’on perd vraiment
« On a des sauvegardes » recouvre six réalités très différentes, et le serveur qui meurt à quinze heures les départage.
La copie logique nocturne sur le même serveur meurt avec le disque : on perd tout, et on revient d'une vieille copie retrouvée par hasard, ou jamais. La copie logique nocturne envoyée ailleurs perd la journée, les ventes depuis deux heures du matin, et revient en quelques heures si quelqu'un sait restaurer et si la copie est lisible ; c'est la plus répandue des méthodes honnêtes. La copie de base plus les journaux archivés en continu perd quelques minutes au plus et revient en moins d'une heure si l'exercice a été fait ; c'est la seule ligne qui tienne un objectif de quinze minutes.
L'instantané de l'hébergeur seul ne perd rien tant que l'hébergeur existe et que le compte est ouvert, et c'est précisément ce qui n'existe plus dans deux des six pannes du guide. Les fichiers copiés sans versions perdent chaque fichier supprimé ou chiffré avant la copie suivante, et la copie de la veille peut elle-même avoir été chiffrée. Tout cela sans exercice : la perte est inconnue, le délai est inconnu, et c'est le jour de la panne qu'on l'apprend ; c'est la ligne la plus fréquente de toutes, et la raison de ce guide.
L’exercice de restauration du mois, chronométré et consigné
L'exercice est la pièce qui transforme les sauvegardes en reprise, et il se lit en huit lignes.
Le premier mardi du mois, sur un serveur vide chez un autre hébergeur, la personne qui n'a pas écrit la procédure la joue. Serveur créé depuis le dépôt, quatre minutes. Secrets récupérés par la seconde personne, trois : aucun mot de passe n'était sur le serveur mort. Base restaurée au point choisi, dix-huit : copie de base plus journaux jusqu'à 14 h 02 la veille, le point est arbitraire et change chaque mois. Fichiers restaurés depuis le second site, vingt-deux : deux fois plus long que le mois dernier, et l'écart est ouvert. Application démarrée, trois. Douze vérifications métier, neuf. Nom de domaine basculé en test puis remis, deux. Rapport écrit et signé, cinq.
Soixante-six minutes pour un objectif de cent vingt : tenu. Mais le rapport dit aussi ce qui a doublé, et pourquoi on le saura avant le prochain exercice ; c'est ainsi qu'on apprend que les fichiers ont grossi, que le second site a changé de débit, ou qu'une étape manuelle s'est glissée dans la procédure. Le gérant lit le verdict sans comprendre une seule des huit lignes, et c'est voulu ; le fondateur en France le reçoit par e-mail le même jour. C'est le même principe que la recette à distance : on ne croit pas ce qu'on n'a pas vu se faire.
Six pannes, et ce qui rend la reprise possible
Six pannes que nous avons vues ou reprises, et pour chacune ce qui a rendu, ou aurait rendu, la reprise possible.
Le disque meurt : serveur recréé depuis le dépôt, base restaurée au point de la panne, fichiers depuis le second site ; c'est la matinée de la première figure. La mauvaise requête : un script efface trois mille clients à 15 h 12, personne ne le voit avant 17 h ; on restaure la base au point 15 h 11 sur un serveur à côté, on réinjecte les clients, et le journal d'audit dit exactement quoi ; c'est le cas où l'archivage continu vaut le plus, parce que la copie nocturne aurait déjà perdu la journée. Le rançongiciel : le serveur et les sauvegardes qui lui sont attachées sont chiffrés la même nuit ; les copies du second site, versionnées et verrouillées pour trente jours, ne peuvent pas l'être, et le serveur se recrée propre depuis le dépôt.
Le prestataire disparu : il avait les accès, les mots de passe et le dépôt ; si le dépôt, les comptes et le domaine sont au nom de l'entreprise, que les secrets sont dans un gestionnaire et que deux personnes savent, la reprise est un désagrément, pas une catastrophe ; sinon c'est le guide dédié qui commence. Le compte hébergeur fermé : carte refusée au renouvellement, compte suspendu, instantanés inaccessibles ; les copies vivent chez un second fournisseur, et la reprise se joue là, exactement comme à l'exercice. Le fichier supprimé : un employé supprime le dossier des contrats partagé et la synchronisation propage la suppression ; les versions sont conservées, et le dossier revient à la date de la veille en quelques minutes. Deux des six pannes n'ont rien de technique, et ce sont celles qui coûtent le plus.
«Deux des six pannes n'ont rien de technique, le prestataire et le compte ; ce sont celles qui coûtent le plus.»
Vu ailleurs : les documentations de référence, et ce qui se transpose
Deux sources disent l'essentiel. La documentation de PostgreSQL dit que l'archivage continu des journaux permet de revenir à n'importe quel instant depuis la copie de base, que l'export logique n'y suffit pas, et que l'archivage se surveille ; ce qui se transpose, c'est l'objectif de quinze minutes et l'alerte quand l'archivage s'arrête. La documentation du verrouillage d'objets dit qu'en mode conformité personne, pas même le compte racine, ne peut effacer une version pendant sa rétention, et nomme le rançongiciel comme cas d'usage ; ce qui se transpose, c'est la copie inaltérable pour trente jours, chez un second fournisseur.
Ce que ces sources ne disent pas : combien de minutes votre entreprise accepte de perdre, et combien d'heures elle accepte d'attendre ; ces deux chiffres sont les vôtres, ils se décident la première semaine, et ils décident de tout le reste.
Les règles d'une application qui survit à son serveur
Six règles, écrites la première semaine. Deux chiffres par système, perte maximale et délai de reprise, signés par le gérant. Trois copies, deux supports, une ailleurs, et la copie ailleurs est versionnée et inaltérable pour une durée écrite. La base s'archive en continu vers un autre site, et une alerte sonne quand l'archivage s'arrête. Le serveur se recrée depuis le dépôt ; rien n'est installé à la main. Les secrets, les comptes et le domaine sont hors du serveur, au nom de l'entreprise, connus de deux personnes. Un exercice complet chaque mois, chronométré, consigné, joué par quelqu'un d'autre.
Une septième règle porte sur le devis : « sauvegardes quotidiennes » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « perte maximale et délai de reprise écrits par système ; copie de base et archivage continu des journaux vers un second site avec alerte ; fichiers dans un stockage versionné sur un second site avec verrouillage de trente jours ; serveur recréable depuis le dépôt ; secrets dans un gestionnaire, comptes et domaine au nom du client, deux détenteurs ; document de reprise ; exercice de restauration complet mensuel sur serveur vide chez un autre hébergeur, chronométré, rapport remis », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui écrit « sauvegarde automatique incluse » sans un chiffre de perte ni de délai a écrit la sixième ligne du tableau.
Six entreprises, et le chiffre qu’elles ont écrit
Six entreprises que nous équipons souvent, et pour chacune les deux chiffres écrits et ce qui les tient.
- Le commerce piloté depuis la France, décrit dans le guide dédié. Quinze minutes et deux heures ; le fondateur reçoit le rapport d'exercice chaque mois et sait, depuis Lyon, que la caisse d'Alger repartira.
- La caisse en magasin, décrite dans le guide dédié. Elle continue d'encaisser sans serveur grâce au mode hors ligne du guide sur la synchronisation ; la reprise du serveur a donc quatre heures, mais zéro minute de ventes perdues.
- Le promoteur immobilier, décrit dans le guide dédié. Les contrats et les reçus des acquéreurs sont dans le stockage versionné et verrouillé pour un an ; aucun fichier signé ne peut disparaître.
- Le cabinet dentaire, décrit dans le guide dédié. Cinq minutes et une heure pour les dossiers patients ; l'exercice est joué un samedi, quand le cabinet est fermé.
- La plateforme SaaS, décrite dans le guide dédié. Un objectif par client écrit dans le contrat, et l'exercice restaure un client à la fois pour prouver l'isolation.
- L'entreprise qui migre, décrite dans le guide sur la reprise de données. Le premier exercice de restauration est joué avant la bascule, parce que la semaine de la bascule est la pire pour découvrir qu'on ne sait pas restaurer.
Le calendrier 2027
Le calendrier est celui d'une application rendue capable de survivre à son serveur en huit semaines, dont la première sans un octet copié.
La semaine 0 à 1 fait l'inventaire et écrit les deux chiffres : ce qui existe et où, la perte maximale et le délai de reprise par système, signés par le gérant. Les semaines 1 à 3 traitent la base : copie de base et archivage continu des journaux vers un autre site, et une première restauration à la minute vérifiée. La semaine 3 à 4 traite les fichiers : stockage d'objets versionné sur un second site, période d'inaltérabilité, test de restauration d'un dossier. La semaine 4 à 5 rend le serveur recréable depuis le dépôt, met les secrets dans un gestionnaire, et passe les comptes et le domaine au nom de l'entreprise, avec deux détenteurs.
La semaine 5 à 6 joue le premier exercice complet sur un serveur vide chez un autre hébergeur, chronométré, et corrige la procédure. Les semaines 6 à 8 installent l'exercice mensuel, le premier mardi, les alertes si une sauvegarde manque, et le rapport lu par le gérant. Le coût de ces copies et de l'exercice entre dans le budget annuel décrit dans le guide sur la vie d'une application ; et quand un modèle d'IA tourne sur vos serveurs, le guide sur le déploiement privé ajoute ses propres copies au même exercice.
Ce qui fait échouer une reprise
Les reprises que nous avons vues échouer l'ont presque toujours été pour l'une de ces raisons.
- La sauvegarde sur le même serveur. Elle meurt avec le disque, et on le découvre ce matin-là.
- Jamais restaurée. La copie existe, elle est illisible, incomplète ou chiffrée, et personne ne le savait.
- Les mots de passe sur le serveur mort. La base est restaurée, et personne ne peut s'y connecter.
- Un seul détenteur. Il est en congé, ou c'est le prestataire disparu.
- Les copies effaçables. Le rançongiciel les a chiffrées en même temps que le serveur.
- Le serveur installé à la main. Trois jours pour le refaire, et personne ne se souvient de tout.
- Pas de chiffre écrit. Chacun avait un objectif différent en tête, et la reprise a duré ce qu'elle a duré.
Questions fréquentes
Les questions que nous recevons de gérants, de fondateurs et de responsables informatiques.
- Nous avons une sauvegarde chaque nuit, n’est-ce pas suffisant ?
- Cela dépend de deux chiffres que vous seuls pouvez écrire : combien de minutes de données vous acceptez de perdre, et combien d'heures d'arrêt. Une copie nocturne perd jusqu'à une journée et revient en quelques heures, si elle est ailleurs que sur le serveur et si quelqu'un l'a déjà restaurée. Pour tenir quinze minutes, il faut l'archivage continu des journaux de la base ; pour tenir deux heures, il faut un exercice qui l'a déjà fait.
- À quoi sert l’exercice de restauration si les sauvegardes sont automatiques ?
- À prouver qu'elles se restaurent, et en combien de temps. La plupart des échecs de reprise que nous voyons viennent de copies illisibles, incomplètes, chiffrées ou de mots de passe perdus, et aucune automatisation ne le détecte : seule une restauration complète, sur un serveur vide, par quelqu'un qui n'a pas écrit la procédure, le montre. Le rapport chronométré est aussi ce qui permet au gérant de lire un verdict sans comprendre la technique.
- Comment se protéger d’un rançongiciel qui chiffre aussi les sauvegardes ?
- Par des copies qu'il ne peut pas atteindre : sur un second site, chez un autre fournisseur, versionnées, et verrouillées pour une durée écrite pendant laquelle personne, pas même le compte administrateur, ne peut les effacer ou les écraser. Le serveur compromis est alors recréé propre depuis le dépôt de code, et la base et les fichiers reviennent des copies verrouillées.
- Que se passe-t-il si le prestataire disparaît avec les accès ?
- Si le dépôt de code, les comptes hébergeur, le domaine et les copies sont au nom de votre entreprise, que les secrets sont dans un gestionnaire et que deux personnes de chez vous savent, la disparition est un désagrément : un autre prestataire reprend depuis le dépôt et les copies. Si tout était au nom du prestataire, c'est une autre histoire, et c'est le guide sur l'application bloquée qui s'applique.
- Combien de données perd-on vraiment ?
- Avec l'archivage continu des journaux de la base, quelques minutes au plus : on revient au point juste avant la panne. Avec une copie nocturne, jusqu'à une journée. Pour les fichiers, les versions conservées permettent de revenir à la veille, ou à l'heure qui précède si le stockage le permet. Les deux chiffres sont écrits par système, parce qu'une caisse et un catalogue n'ont pas la même tolérance.
- Combien de temps pour mettre tout cela en place ?
- Huit semaines : une pour l'inventaire et les deux chiffres, deux pour la base et sa première restauration à la minute, une pour les fichiers, une pour le serveur recréable, les secrets et les comptes, une pour le premier exercice complet, deux pour installer l'exercice mensuel et les alertes. Sur une application existante, les trois premières semaines suffisent souvent à passer de « on a des sauvegardes » à « on a restauré ».