Délai de 72 heures

Ce que fait le délai de 72 heures

Un changement qui retire de la protection ne prend pas effet tout de suite. La plateforme l'enregistre comme une action différée, et elle l'applique 72 heures après la demande. Pendant ces 72 heures, l'état actuel reste en vigueur.

Ce délai protège les sauvegardes de vos clients contre une erreur de manipulation et contre un compte volé. Une personne qui prend la main sur un compte du portail ne détruit donc pas les sauvegardes tout de suite. Vous avez trois jours pour voir l'action et pour l'annuler.

Le délai est fixe. Il vaut 72 heures pour tous les MSP et pour toutes les machines. Personne ne le raccourcit : ni un administrateur de votre MSP, ni une clé API, ni un assistant IA relié par MCP.

Prérequis

• N'importe quel rôle du MSP pour lire les actions qui attendent.
• Le rôle Technicien ou Administrateur pour annuler une action. Voir Rôles et droits.
• Aucun réglage. Le délai est actif dès le départ, et vous ne le désactivez pas.

Quelles actions attendent 72 heures

Huit changements attendent. Ils portent tous sur un endpoint ou sur une politique de sauvegarde.

Changement	Ce qu'il retire	Page de la fonction
Suppression d'endpoint	La machine et, après la purge, ses points de restauration.	Supprimer un endpoint ou un client
Suppression de politique	La politique. Ses points de restauration gardent sa dernière rétention.	Politique de sauvegarde de fichiers
Désactivation de politique	Les exécutions planifiées de la politique.	Planification et rétention
Réduction de rétention	L'historique gardé par les règles calendaires.	Planification et rétention
Retrait de chemins sources	Les dossiers retirés de la politique.	Politique de sauvegarde de fichiers
Modification des filtres	Les fichiers que les nouvelles exclusions laissent de côté.	Politique de sauvegarde de fichiers
Modification du script avant la sauvegarde	Les données que l'ancien script mettait dans la sauvegarde.	Scripts avant et après une sauvegarde
Retrait de bases SQL Server	Les bases retirées de la politique.	Sauvegarder SQL Server

La sélection des VM d'un hôte suit la règle des filtres. Décocher une VM attend donc 72 heures. Voir Sauvegarder les VM d'un hôte Hyper-V et Sauvegarder les VM et conteneurs d'un nœud Proxmox VE.

Ce qui s'applique tout de suite

Un changement qui ajoute de la protection ne passe pas par le délai :

• un chemin source de plus ;
• une exclusion ordinaire retirée ;
• une rétention plus longue ;
• une base SQL Server de plus, ou une VM cochée ;
• une politique réactivée ;
• un nouveau script avant la sauvegarde, une durée maximale plus longue, ou le passage à Ne pas sauvegarder ;
• le script après la sauvegarde, dans tous les cas.

Les réglages qui ne changent pas ce qui est sauvegardé s'appliquent aussi tout de suite : les horaires, la fenêtre d'exécution et la limite de débit.

Une sauvegarde lancée à la main reste possible pendant le délai, même sur une politique que vous venez de désactiver.

Ce que le délai ne couvre pas

Le délai protège les sauvegardes. Il ne protège pas les accès. Ces changements ne l'attendent pas :

• L'accès de l'agent est coupé dès la demande de suppression. La machine ne sauvegarde plus, et elle ne restaure plus, avant la fin des 72 heures. Une annulation ne rend pas cet accès : rattachez l'agent. Voir Rattacher un agent.
• Les comptes et les accès changent tout de suite : un rôle modifié, un utilisateur retiré, une clé API révoquée, un accès MCP retiré, un jeton d'enrôlement révoqué.
• Une nouvelle version d'un script part sans délai. Elle s'exécute à la prochaine sauvegarde des machines qui l'utilisent. Voir Scripts avant et après une sauvegarde.
• Une restauration écrit sur la machine tout de suite. Le délai ne porte pas sur les restaurations. Voir Restaurer des fichiers depuis le portail.
• La suppression d'un client n'est pas une seule action. La demande crée une suppression d'endpoint par endpoint du client. Vous les annulez une par une.
• Un tag supprimé part tout de suite, sur toutes les machines qui le portaient. Voir Tags et actions sur une sélection.

L'autre effet du délai : les points récents

Le même délai de 72 heures protège les points de restauration récents. Un point de moins de 72 heures n'est jamais retiré par la rétention. Il ne pousse pas non plus un point plus ancien hors de la rétention.

Vous gardez donc jusqu'à 72 heures de points en plus du calcul de la rétention. Voir Planification et rétention.

Lire les actions qui attendent sur votre MSP

Faites ce contrôle une fois par semaine, et après chaque incident sur un compte du portail.

1. Ouvrez le portail.
2. Dans le menu Administration, cliquez Actions différées.
3. Gardez le filtre En attente.
4. Lisez la colonne Changement de chaque ligne.
5. Lisez la colonne Objet. Elle donne le nom de l'endpoint et celui de son client.
6. Lisez la colonne Prévue le. Elle donne la date de l'application, puis le temps qui reste.
7. Lisez la colonne Demandée. Elle donne le temps passé depuis la demande.

Un bandeau orange en haut des pages du portail rappelle la prochaine action. Le tableau de bord porte aussi un bloc Actions différées avec les trois actions les plus proches.

Annuler une action pendant le délai

1. Ouvrez Administration, puis Actions différées.
2. Trouvez la ligne du changement.
3. Dans la colonne Actions, cliquez Annuler.

L'annulation garde l'état actuel. Elle ne remet rien en arrière, car rien n'a encore changé.

La page Annuler une action différée donne les autres chemins d'annulation : la page de l'endpoint, l'onglet Politiques, le tableau de bord et le lien d'un ancien email d'annulation.

Vérifier qu'une action a été demandée, annulée ou appliquée

Le journal d'audit garde les trois étapes d'une action différée. Une entrée du journal ne peut être ni modifiée ni supprimée.

1. Dans le menu Administration, cliquez Journal d'audit.
2. Ouvrez la liste Action.
3. Choisissez Action différée demandée pour la demande, Action différée annulée pour une annulation, ou Action différée appliquée pour l'application.
4. Cliquez une entrée pour ouvrir son panneau.
5. Lisez l'auteur, la date, l'objet et le changement.
6. Pour une annulation, lisez le chemin utilisé : le portail, une clé API ou le lien d'un email.

L'entrée d'une application porte Système comme auteur : la plateforme l'applique sans personne devant l'écran. Voir Journal d'audit.

Limites et précautions

• Une action ne s'annule plus à partir de sa date d'application. Surveillez la colonne Prévue le et annulez avant cette date.
• La plateforme applique une action peu après sa date, et non à la seconde exacte. Ne comptez pas sur cet écart.
• Le délai ne remplace pas la surveillance. Lisez les actions qui attendent et le journal d'audit. Le portail n'envoie pas d'email pour une action différée.
• Le délai ne protège pas contre un administrateur de la machine du client. Root sur Linux, ou un administrateur local sur Windows, désinstalle l'agent sans délai. Voir Isolation de l'agent.
• Après les 72 heures, la suppression d'un endpoint devient effective. Les données du dépôt sont purgées 7 jours plus tard. Il n'y a plus rien à annuler. Voir Supprimer un endpoint ou un client.
• Une nouvelle politique de sauvegarde peut annuler un changement différé par elle-même. Si la politique enregistrée ne demande plus ce changement, la plateforme l'annule à l'enregistrement.
• Le portail n'annule pas plusieurs actions en une seule fois.
• Une clé API avec la portée operate annule une action différée. Elle ne raccourcit jamais le délai. Voir Rôles et droits.

Référence

• API : Backups, routes GET /pending-actions et POST /pending-actions/{id}/cancel.
• API : Endpoints, route DELETE /endpoints/{id}. Sa réponse donne effective_at et purge_at.
• Outils MCP : list_pending_actions et cancel_pending_action.