Scripts avant et après une sauvegarde
Ce que font les scripts avant et après une sauvegarde
Une politique de sauvegarde peut lancer un script sur la machine juste avant la sauvegarde, et un autre juste après. Le script avant prépare les données, par exemple il exporte une base ou il arrête un service. Le script après remet la machine en service.
Les scripts vivent dans une bibliothèque qui appartient à votre MSP. Les politiques de tous vos clients y puisent. Chaque enregistrement d'un nouveau contenu crée une version, avec son numéro, son empreinte SHA-256, son auteur et sa date.
Un script s'exécute avec les droits les plus élevés de la machine : en root sur Linux, en SYSTEM sur Windows. Traitez-le comme du code de production.
Aucun script ne s'exécute autour d'une restauration.
Prérequis
- Une politique de sauvegarde sur une machine Linux ou Windows. Voir Quel type de sauvegarde choisir.
- Pour lire les scripts : le rôle Technicien ou Administrateur.
- Pour écrire un script, ou pour changer les scripts d'une politique : le rôle Administrateur. Voir Rôles et droits.
- La vérification en deux étapes activée sur votre compte. Chaque écriture demande un code de moins de 10 minutes. Voir Connexion et vérification en deux étapes.
- Un agent qui sait exécuter les scripts. Voir Versions d'agent minimales par fonction.
L'ordre d'exécution
- Le script avant la sauvegarde s'exécute. Sur Windows, il s'exécute avant l'instantané du disque.
- La sauvegarde s'exécute.
- Le script après la sauvegarde s'exécute.
Le code de sortie 0 veut dire « réussi ». Tout autre code veut dire « échoué ».
La politique dit ce qui se passe quand le script avant la sauvegarde échoue, et quand le script après la sauvegarde s'exécute. Par défaut, un échec avant la sauvegarde annule la sauvegarde, et le script après la sauvegarde s'exécute toujours, même après une sauvegarde échouée.
Ce que l'agent donne au script
L'agent écrit le contenu du script dans un fichier temporaire privé, puis il le lance avec son interpréteur. Il retire le fichier après l'exécution.
| Variable | Valeur |
|---|---|
BAASTIDE_POLICY_ID | L'identifiant de la politique. Vide pour une sauvegarde d'image, et pour une sauvegarde sans politique. |
BAASTIDE_RUN_ID | L'identifiant de la tâche. |
BAASTIDE_PHASE | pre avant la sauvegarde, post après. |
BAASTIDE_STATUS | Après la sauvegarde seulement : success, partial, failed ou cancelled. |
BAASTIDE_SNAPSHOT_ID | Après la sauvegarde seulement : le point de restauration créé. Vide quand il n'y en a pas. |
L'agent passe aussi les Arguments de la politique au script, dans l'ordre.
L'environnement du script est celui du service de l'agent, sans les variables internes de BaaStide
et de son moteur de sauvegarde. Le dossier de travail est celui du service : / sur Linux,
System32 sur Windows.
Écrire un script dans la bibliothèque
- Ouvrez le portail.
- Ouvrez Administration, puis Scripts.
- Cliquez Créer un script.
- Choisissez le Système, Linux ou Windows. Ce choix ne pourra plus changer.
- Saisissez un Nom, de 1 à 100 caractères, par exemple
Export de la base CRM. - Saisissez une Description. Elle dit à un autre technicien quand utiliser ce script.
- Choisissez l'Interpréteur :
shou Bash sur Linux, PowerShell ou cmd sur Windows. - Saisissez le Contenu, 64 Kio au plus. Le compteur sous le champ donne la taille utilisée.
- Cliquez Créer le script.
- Saisissez le code de vérification de votre application quand le portail le demande.
Le portail ouvre la page du script. Elle porte le système et le numéro de version.
Pour changer un script, ouvrez-le depuis la liste, modifiez le contenu, puis cliquez Enregistrer. Un nouveau contenu ou un nouvel interpréteur crée la version suivante. Un changement du nom ou de la description seul ne crée pas de version.
Rattacher un script à une politique
- Ouvrez Parc, puis la machine.
- Ouvrez l'onglet Politiques.
- Cliquez Modifier sur la politique.
- Allez dans la partie Scripts.
- Dans Avant la sauvegarde, choisissez un Script dans la liste. La liste ne contient que les scripts du système de la machine.
- Réglez la Durée maximale, en secondes, de 1 à 14 400. La valeur d'une nouvelle politique est 600.
- Choisissez Si le script échoue ou dure trop longtemps : Ne pas sauvegarder. La sauvegarde échoue, ou Sauvegarder quand même.
- Saisissez les Arguments, un par ligne, 16 au plus.
- Faites de même dans Après la sauvegarde. Choisissez Quand l'exécuter : Toujours, même après une sauvegarde échouée, ou Seulement après une sauvegarde réussie.
- Cliquez Enregistrer.
- Saisissez le code de vérification quand le portail le demande.
Chaque politique porte un script avant et un script après, au plus. Choisissez Aucun script pour en retirer un.
La machine reçoit la version actuelle du script à sa prochaine sauvegarde.
Lire le résultat d'un script
- Ouvrez Parc, puis la machine.
- Ouvrez l'onglet Activité.
- Ouvrez la tâche de sauvegarde.
- Allez à la carte Scripts. Elle donne, pour chaque phase, l'état, le script et sa version, le code de sortie, la durée et la sortie du script.
La Sortie réunit la sortie standard et la sortie d'erreur, dans l'ordre. L'agent en garde les 64 derniers Kio. Au-delà, le portail écrit « La sortie dépassait 64 Kio : seule sa fin est gardée. »
| État | Ce qu'il veut dire |
|---|---|
| Réussi | Le script s'est terminé avec le code de sortie 0. |
| Échoué | Le script s'est terminé avec un code de sortie autre que 0. |
| Durée maximale atteinte | L'agent a arrêté le script à la durée maximale de la politique. |
| Refusé | L'agent n'a pas lancé le script : son contenu ou son interpréteur n'a pas passé les contrôles. |
| Scripts désactivés | L'agent n'a pas lancé le script : les scripts sont coupés sur cette machine. |
| Ignoré | L'agent n'a pas lancé le script après la sauvegarde : il ne s'exécute qu'après une sauvegarde réussie. |
La carte n'apparaît que sur une tâche qui portait un script.
Quand le script avant la sauvegarde échoue et que la politique dit Ne pas sauvegarder, la tâche
échoue avec la cause pre_hook_failed et aucune sauvegarde n'a lieu. Voir
Codes de cause d'une tâche.
Comparer deux versions et revenir en arrière
- Ouvrez Administration, puis Scripts.
- Ouvrez le script.
- Allez à la carte Versions. Les versions les plus récentes sont en haut.
- Cliquez Afficher la version N pour lire son contenu.
- Cliquez Comparer avec la version actuelle, ou choisissez les versions De et À sous le
tableau. Les lignes qui commencent par
+sont ajoutées, celles qui commencent par-sont retirées. - Pour revenir en arrière, cliquez Revenir à la version N, puis confirmez.
- Saisissez le code de vérification quand le portail le demande.
Un retour en arrière ne supprime rien : il crée une version de plus, avec le contenu de l'ancienne. Les machines la reçoivent à leur prochaine sauvegarde.
Supprimer un script
- Ouvrez le script.
- Ouvrez le menu de la page, puis cliquez Supprimer le script.
- Confirmez.
Le script et toutes ses versions quittent la bibliothèque. La colonne Politiques de la liste donne le nombre de politiques qui exécutent un script : retirez-le d'abord de chacune.
Couper les scripts sur une machine
L'administrateur de la machine garde le dernier mot. Il coupe les scripts sur la machine, en ligne de commande, et le portail ne peut pas les rallumer.
- Ouvrez une session sur la machine en root, ou une invite de commandes en tant qu'administrateur sur Windows.
- Exécutez
baastide agent scripts off. - Pour lire l'état en vigueur, exécutez
baastide agent scripts. - Pour les rallumer, exécutez
baastide agent scripts on.
L'agent lit ce choix à chaque tâche. Aucun redémarrage du service n'est nécessaire.
Pour couper les scripts dès l'installation, ajoutez --no-scripts à install.sh, ou -NoScripts
à install.ps1. Voir Installer l'agent sur Linux et
Installer l'agent sur Windows. Sans cette option,
l'installation garde le choix en vigueur sur la machine.
Avec les scripts coupés, chaque script porte l'état Scripts désactivés dans la tâche. La politique applique quand même sa règle Si le script échoue : avec Ne pas sauvegarder, la sauvegarde n'a pas lieu.
Limites et précautions
- Un script s'exécute en root ou en SYSTEM sur la machine du client. Relisez chaque version avant de l'enregistrer. Le journal d'audit garde qui a changé quoi, et quand.
- Ne mettez jamais un mot de passe dans les Arguments d'une politique : le journal d'audit les garde.
- Une nouvelle version d'un script part sur les machines à leur prochaine sauvegarde, sans délai. Les administrateurs du MSP reçoivent un email quand la version d'un script déjà utilisé par une politique change.
- Retirer ou affaiblir le script avant la sauvegarde prend effet 72 heures plus tard, car un script différent peut exclure des données de la sauvegarde. Comptent comme un affaiblissement : le retrait du script, un autre script, d'autres arguments, une durée maximale plus courte, et le passage de Ne pas sauvegarder à Sauvegarder quand même. D'ici là, le script actuel continue de s'exécuter, et vous pouvez annuler le changement. Voir Annuler une action différée.
- Un nouveau script avant la sauvegarde, une durée maximale plus longue et le passage à Ne pas sauvegarder s'appliquent tout de suite. Le script après la sauvegarde change toujours tout de suite.
- Le système d'un script ne peut pas changer après sa création. Créez un deuxième script pour l'autre système.
- Une politique de VM Hyper-V ou Proxmox VE n'exécute aucun script.
- Quand l'agent n'a pas déclaré qu'il sait exécuter les scripts, la sauvegarde échoue avec la cause
agent_unsupported. Mettez l'agent à jour. Voir Mettre un agent à jour à la main. - À la durée maximale, ou quand vous annulez la tâche, l'agent arrête le script et ses processus fils. Un processus fils encore actif à la fin normale du script n'est pas arrêté : un script après la sauvegarde peut donc relancer un service.
- Un argument d'un script cmd ne peut pas contenir de guillemet droit, de signe pour cent, ni de retour à la ligne. L'agent refuse le script.
- La suppression d'un script est refusée tant qu'une politique l'utilise, ou qu'une action différée va l'utiliser. Une politique supprimée compte aussi : retirez le script de la politique avant de supprimer la politique.
- La copie d'une politique copie aussi ses scripts. Elle demande alors le rôle Administrateur et un code de vérification récent. La copie d'une politique sans script ne les demande pas, sauf quand elle remplace sur la machine cible une politique qui porte des scripts. Voir Copier une politique sur d'autres machines.
Référence
- Commande de l'agent :
baastide agent scripts. - Causes d'une tâche :
pre_hook_failedetagent_unsupported.