Tests de restauration

Une sauvegarde qui existe n’est pas une sauvegarde qui se restaure. Un test de restauration myPBS restaure l’une de vos VM sur un serveur de Forget About IT, la démarre sans aucun réseau, constate qu’elle a démarré, puis vous remet un rapport que vous pouvez transmettre à un auditeur, à un assureur ou à vos propres clients.

Vous le demandez vous-même depuis l’onglet Tests de restauration du datastore, dans l’espace client. Chaque test est une demande manuelle : il n’y a pas de test planifié.

Pour voir le document remis à la fin du test, consultez l’exemple commenté de rapport.

Ce qui est testé, et ce qui ne l’est pas

Ce que le test prouve :

• la sauvegarde choisie se lit en entier et se restaure ;
• la VM restaurée démarre, avec sa configuration d’origine (processeur, machine, UEFI, disques) ;
• une preuve positive de démarrage a été constatée : l’agent invité répond, ou une invite de connexion apparaît sur la console.

Ce que le test ne prouve pas :

• que vos applications et vos données fonctionnent : la VM n’a pas de réseau et personne ne s’y connecte ;
• que la VM se comportera de la même façon sur votre propre matériel ou dans votre réseau ;
• que les sauvegardes plus récentes ou plus anciennes se restaurent : le rapport ne vaut que pour la sauvegarde testée.

L’absence d’erreur n’est jamais prise pour une preuve : sans signe net de démarrage, le test n’est pas déclaré réussi.

Conditions

Le portail vérifie l’éligibilité avant la demande et indique la raison d’un refus.

• Datastore actif : ni essai gratuit, ni impayé, ni résiliation en cours.
• Sauvegarde d’une VM (type vm). Les conteneurs et les serveurs Linux sauvegardés par fichiers ne sont pas pris en charge.
• Système Linux. Les VM Windows et les autres systèmes ne sont pas pris en charge pour le moment.
• Sauvegarde non chiffrée : une sauvegarde chiffrée côté client ne peut pas être démarrée sans votre clé, que nous ne détenons jamais.
• Aucun matériel transmis à la VM (carte PCI, périphérique USB).
• Taille totale des disques de la VM dans la limite d’un serveur de test. Cette limite est affichée dans le formulaire de demande. Ni la mémoire ni le nombre de vCPU ne sont des motifs de refus : une VM qui en demande plus que le serveur de test n’en accorde démarre avec moins pour le test, et le rapport le précise.
• Un crédit disponible, ou l’acceptation du prix (voir plus bas).

Déroulé

1. Vous choisissez la VM. Par défaut, la dernière sauvegarde est testée ; une plus ancienne peut l’être aussi.
2. Vous lisez le rappel de ce qui est prouvé et de ce qui ne l’est pas, puis vous confirmez. Une seule demande à la fois par datastore : tant qu’un test est en cours (y compris en vérification), une nouvelle demande est refusée ; attendez la fin du test en cours pour en demander un autre.
3. La demande passe à l’état en attente jusqu’à ce qu’un serveur de test soit disponible. Vous pouvez l’annuler tant qu’elle est en attente.
4. En cours : la sauvegarde est restaurée, les cartes réseau de la VM sont isolées (un contrôle refuse tout démarrage si une seule carte ne l’est pas), puis la VM démarre et on observe son démarrage pendant quelques minutes.
5. Le verdict tombe, généralement en quelques minutes selon la taille de la VM. La copie restaurée est alors détruite.

Si la sauvegarde choisie disparaît avant le début du test (rétention), le test est annulé et son crédit rendu.

États et verdicts

• Réussi : au moins une preuve positive nette a été constatée.
• Échoué : la restauration a abouti mais la VM ne démarre pas, s’arrête, ou montre un signe net d’échec (panique du noyau, mode de secours, aucun disque amorçable).
• En cours de vérification : la preuve n’est pas assez nette pour conclure. Un administrateur regarde la VM, qui reste en place jusque-là, puis confirme réussi ou échoué avec un commentaire repris dans votre rapport.

Un incident de notre côté (serveur injoignable, erreur de lecture, disque plein) n’est jamais compté comme un échec de votre VM : le test est relancé automatiquement, puis passe en vérification si l’incident persiste.

Lire le rapport

Le rapport est consultable dans l’espace client et téléchargeable en PDF. Il est conservé 13 mois, soit un cycle d’audit annuel. Il contient :

• le client, le datastore, la VM (numéro et nom), la sauvegarde testée (date) et la taille restaurée ;
• la date du test, les durées (restauration, délai jusqu’à la preuve) ;
• le verdict et les preuves retenues : capture de l’écran au moment de la preuve (invite de connexion) ou, à défaut, la dernière, extrait de la console série, réponse de l’agent invité ;
• le commentaire de l’administrateur, le cas échéant ;
• ce que le test prouve et ne prouve pas ;
• l’identifiant du rapport et l’adresse de la page de vérification.

Si le nombre de vCPU ou la mémoire de la VM dépasse ce que le serveur de test accorde, la copie démarre avec moins pour le test et le rapport l’indique.

Vous recevez un e-mail à la fin du test (réussi, échoué, ou passage en vérification) avec le lien vers le rapport. Le PDF n’est pas joint à l’e-mail.

Exemple de rapport

Rapport de démonstration : toutes les données sont fictives. Cet exemple présente le format du PDF remis après un test de restauration. Les noms, dates, durées, éléments de configuration et preuves illustrent sa lecture ; ils ne proviennent pas d’une restauration réelle.

Télécharger l’exemple complet (PDF, 4 pages)

Comment lire cet exemple

1. Identifier la sauvegarde concernée. La première page associe le verdict à une machine, un datastore et une date de sauvegarde. Ici, il s’agit de la VM fictive 104 (srv-compta) et de sa sauvegarde du 28 octobre 2026 à 22:56. Un rapport ne valide que la sauvegarde qui y est désignée.
2. Distinguer restauration et démarrage. Dans cet exemple, la restauration dure 12 min 34 s, puis une preuve est obtenue 1 min 2 s après le démarrage. Ce sont deux mesures distinctes. Ces durées fictives ne sont ni une estimation pour votre VM ni un délai garanti de reprise de votre service.
3. Regarder les preuves du verdict. Le bloc Preuves indique ici une réponse de l’agent invité et une invite de connexion. Le PDF contient aussi un extrait fictif de console série. Dans un rapport réel, ces éléments permettent de comprendre pourquoi le test a été déclaré réussi.
4. Lire les ajustements et les limites. La VM de démonstration démarre avec moins de mémoire et de vCPU ; l’adaptation apparaît dans le déroulé. La configuration sauvegardée est détaillée en annexe. Un démarrage réussi sans réseau ne valide pas le fonctionnement des applications : cette limite est rappelée dans le rapport.

Cet exemple n’est pas enregistré dans le service de vérification des rapports. Son identifiant ne permet donc pas d’y valider une restauration. Pour un rapport issu de votre espace client, utilisez la procédure ci-dessous.

Vérifier l’empreinte d’un rapport

Un PDF ne peut pas contenir sa propre empreinte. L’empreinte SHA-256 du PDF figure donc sur la page du rapport dans l’espace client, à laquelle mène le lien de l’e-mail, et le PDF porte l’identifiant du rapport.

Pour vérifier un rapport reçu, ouvrez la page publique de vérification du portail et saisissez l’identifiant du rapport et l’empreinte. La page confirme seulement que ce rapport existe, sa date et son verdict, sans aucune autre donnée du client.

Pour calculer l’empreinte du PDF reçu :

# Linux et macOS
sha256sum rapport-test-restauration.pdf

# Windows
Get-FileHash rapport-test-restauration.pdf -Algorithm SHA256

Si l’empreinte calculée diffère de celle publiée, le document a été modifié : ne vous y fiez pas.

Prix et crédits

• Premium : 2 tests de restauration par mois inclus, par datastore, remis à chaque renouvellement mensuel de votre abonnement (sans report).
• Standard : aucun test inclus, 5 € HT par test réussi, ajouté à la prochaine facture de l’abonnement du datastore. Le prix est affiché avant que vous ne confirmiez.
• Au-delà des tests inclus, un test Premium coûte aussi 5 € HT s’il réussit.

Les tests inclus se comptent sur le mois d’abonnement en cours, qui commence chaque mois à la date anniversaire de votre abonnement (la date de la commande, ou la fin de l’essai gratuit) ; ils ne sont pas reportés. L’espace client indique la date de leur remise à zéro. Un administrateur peut accorder des crédits supplémentaires à un datastore : ils n’expirent pas. Les crédits sont consommés dans l’ordre suivant : tests inclus, crédits accordés, puis paiement à l’unité.

Un crédit est réservé à la demande et consommé seulement si le test réussit. Un test échoué, annulé ou encore en vérification ne consomme aucun crédit et n’est pas facturé.

Choisir l’offre adaptée à vos tests

Les offres Standard et Premium détaillent les tests facturés à l’unité et ceux inclus en Premium. Comparez aussi le prix du stockage, forfait et quota compris. Pour effectuer vos propres contrôles, consultez le guide Restaurer une VM ou des fichiers Proxmox.