Un prestataire qui démarre la sauvegarde chez ses clients vit une progression en trois temps. Les cinq premiers clients : tout va bien, on lit les rapports. Les vingt suivants : on les survole. Au-delà : on ne les lit plus, et on l'apprend le jour où un client demande une restauration sur une sauvegarde arrêtée depuis six semaines.
Ce n'est pas un problème de rigueur. C'est un problème de conception.
Pourquoi le rapport quotidien par mail ne tient pas
Le modèle par défaut de beaucoup de solutions : chaque sauvegarde envoie un rapport, on les reçoit tous, on regarde.
À cinquante clients et trois machines par client, cela fait cent cinquante mails par jour. Quelques réflexes apparaissent naturellement : une règle de tri les range dans un dossier, puis on les consulte « quand on a le temps », puis plus du tout.
Le vice de construction est là : le rapport quotidien signale ce qui s'est passé, pas ce qui n'a pas eu lieu. Une sauvegarde qui échoue envoie un mail d'erreur. Une sauvegarde qui ne démarre pas du tout — poste éteint, agent désinstallé lors d'un changement de machine, service arrêté — n'envoie rien. Le silence est indiscernable du calme.
L'alerte qui compte : la non-exécution
La bascule se fait quand on inverse la logique : au lieu d'attendre un signal d'erreur, on surveille l'absence de signal attendu.
Une alerte de non-démarrage utile a trois propriétés :
Elle se règle par machine, pas globalement. Un poste portable qui sauvegarde trois fois par semaine et un serveur qui sauvegarde toutes les nuits n'ont pas le même seuil. Un seuil unique produit soit du bruit, soit des angles morts.
Elle tient compte des serveurs multiples. Si vous répliquez ou si vous avez plusieurs serveurs de sauvegarde, un poste qui a sauvegardé ailleurs ne doit pas déclencher d'alerte. Une solution qui interroge les autres serveurs avant d'alerter vous évite les fausses alertes — et les fausses alertes sont ce qui tue une supervision, parce qu'on finit par les ignorer toutes.
Elle est consultable, pas seulement envoyée. Un mail se perd. Un tableau de bord qui affiche les états en cours se consulte en trente secondes le matin.
Le tableau de bord comme point de départ
L'objectif du matin n'est pas de tout vérifier : c'est de savoir en un écran s'il y a quelque chose à faire.
Concrètement, un état qui distingue les situations : erreur, avertissement, non démarrée, verrouillée, sauvegarde en cours, restauration en cours, réplication en cours, contrôle d'intégrité, sauvegarde Microsoft 365. Chacune appelle une action différente — ou aucune.
Le filtrage par périmètre compte autant que les états eux-mêmes. Un technicien qui gère dix clients ne doit pas voir les cinquante : le bruit rend la vue inutilisable.
Les droits par technicien
C'est un sujet qu'on repousse et qui devient bloquant.
Tant qu'on est seul, tout le monde est administrateur. À trois techniciens, les questions arrivent : est-ce qu'un niveau 1 doit pouvoir relancer une sauvegarde ? Oui, c'est le but. Modifier une règle de rétention ? Non, cela peut supprimer des versions. Restaurer chez un client ? Selon les cas.
Une granularité fine — de l'ordre d'une cinquantaine de droits nommés — permet de répondre à ces questions une fois, puis d'embaucher sans rouvrir le débat. La bonne question à se poser : quelle est l'action la plus destructrice que ce profil peut déclencher ?
Les rapports qui sortent chez le client
Deux réalités coexistent : ce que vous surveillez, et ce que votre client voit.
Le client n'a pas besoin des cent cinquante lignes quotidiennes. Il a besoin, à intervalle régulier, d'une page lisible qui dit ce qui est protégé, sur quelle profondeur, et si tout va bien. À votre nom, pas à celui de l'éditeur — c'est vous qui rendez le service.
C'est aussi le document que vous ressortez en réunion annuelle quand on vous demande à quoi sert la ligne « sauvegarde » de la facture.
Le test de restauration, à planifier comme une tâche
Tout ce qui précède surveille que les sauvegardes ont lieu. Rien ne garantit qu'elles sont restaurables.
Le test de restauration est la seule vérification qui compte, et c'est aussi la première qu'on abandonne faute de temps. Deux façons de tenir dans la durée :
- Le contrôle d'intégrité automatique côté serveur, qui relit les données et compare les empreintes après chaque sauvegarde ou selon une règle par machine. Il ne remplace pas une restauration, mais il détecte la corruption silencieuse sans mobiliser personne.
- Une restauration réelle par client et par an, planifiée comme une tâche de maintenance. Un fichier, un dossier, et une fois tous les deux ou trois ans un système complet chez les clients critiques.
Le second point a un bénéfice commercial souvent sous-estimé : un compte rendu de restauration daté est l'argument le plus solide dont vous disposiez face à un concurrent qui, lui, n'en produira aucun.
Une organisation qui tient
| Fréquence | Ce qu'on fait |
|---|---|
| Chaque matin | Un coup d'œil au tableau de bord, filtré sur les anomalies |
| Chaque semaine | Traitement des machines silencieuses et des avertissements récurrents |
| Chaque mois | Revue des volumes, des quotas et de l'espace disque restant |
| Chaque trimestre | Une restauration de contrôle, documentée |
| Chaque année | Revue du périmètre avec le client : ce qui a changé dans son système d'information |
La dernière ligne est celle qui rapporte. Un client qui a ajouté un serveur, une application métier ou un partage sans vous le dire a un trou dans sa protection — et c'est en le découvrant lors d'une revue, plutôt que lors d'un sinistre, qu'on reste son prestataire.
BeBackup a été conçu par un prestataire informatique pour son propre parc : console multi-clients, alertes de non-démarrage calculées par machine, droits fins et rapports en marque blanche. Voir la page prestataires ou demander une démo.