Projet

Général

Profil

Tâche #35088

Scénario #35154: Diverses améliorations à intégrer sur la sauvegarde Bareos

Bareos : les tâches PRE et POST devraient se faire même si la sauvegarde est en erreur

Ajouté par Emmanuel GARETTE il y a plus d'un an. Mis à jour il y a 12 mois.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Début:
27/02/2023
Echéance:
% réalisé:

100%

Restant à faire (heures):
0.0

Description

J'ai parfois des erreurs étranges lors de la sauvegarde Bareos.

Par exemple :


25-nov. 22:03 amon-dir JobId 82: Fatal error: TLS read/write failure.: ERR=error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac
25-nov. 22:03 amon-dir JobId 82: Fatal error: Network error with FD during Backup: ERR=Aucune donnée disponible

Je n'ai pas identifié aujourd'hui la cause.
Mais à chaque fois qu'il y a une erreur les tâches "POST" ne sont pas faite (par exemple la mise à jour, ...).

En effet un lock est placé mais n'est pas supprimé.

Que la prochaine sauvegarde soit bloqué, cela me semble cohérent, mais les tâches PRE/POST ne devrait pas être bloquée.

Solution : en cas de présence de lock "sauvegarde", pouvoir faire les tâches PRE/POST.

Révisions associées

Révision 69e8b280 (diff)
Ajouté par Benjamin Bohard il y a environ un an

Révision des conditions d’exécution des tâches pre et post.

Ref #35088

Historique

#1 Mis à jour par Joël Cuissinat il y a plus d'un an

  • Tracker changé de Demande à Scénario
  • Début 26/11/2022 supprimé
  • Release mis à EOLE 2.8.0.1
  • Points de scénarios mis à 1.0

#2 Mis à jour par Joël Cuissinat il y a plus d'un an

  • Tâche parente mis à #35154

#3 Mis à jour par Benjamin Bohard il y a environ un an

  • Statut changé de Nouveau à En cours
  • Assigné à mis à Benjamin Bohard
  • Début mis à 27/02/2023

#4 Mis à jour par Benjamin Bohard il y a environ un an

Dans la configuration actuelle du directeur, les scripts sont déclarés avec les directives « raccourcies » qui impliquent des conditions d’exécution : https://docs.bareos.org/Configuration/Director.html#config-Dir_Job_RunScript.

Il faut remplacer ces directives par la directive générique « Run Script » pour pouvoir configurer les conditions d’exécution adaptées au cas d’usage.

#5 Mis à jour par Benjamin Bohard il y a environ un an

Liste des tâches exécutées :

  • montage du support de sauvegarde
  • démontage du support de sauvegarde
  • pose du verrou avec le numéro de job sur le directeur
  • pose du verrou avec le numéro de job sur le client
  • suppression du verrou sur le client
  • suppression du verrou sur le directeur
  • lancement des scripts sur le client pour le job pre
  • lancement des scripts sur le client pour le job post

Il semble que seules les directives concernant le lancement des scripts sur le client nécessite une réécriture pour ne plus avoir la condition à l’exécution impliquée par l’usage de la directive raccourcie.
Selon le problème rencontré durant la sauvegarde, il est possible que les scripts devant être exécutés sur le client ne puissent pas l’être malgré le changement de directive (dans le cas d’une perte de connexion par exemple).

Job {
  …
  ClientRunAfterJob = "/usr/share/eole/schedule/schedule_bareos post" 
  …
}

deviendrait :
Job {
  …
  RunScript = {                                                      
        Command = "/usr/share/eole/schedule/schedule_bareos post" 
        RunsWhen = After
        RunsOnFailure = Yes
        RunsOnClient = Yes
        }
  …
}

#6 Mis à jour par Benjamin Bohard il y a environ un an

En fait, il est plus probable que l’expression « tâche PRE/POST » fassent référence aux jobs qui encadrent le job principal de sauvegarde et qui servent de contexte à l’exécution des scripts sur le client (schedule_bareos).

La modification proposée précédemment devrait tout de même faire l’affaire : ces jobs seraient en erreur du fait de la présence d’un verrou (par exemple) mais les scripts seraient tout de même exécutés sur le client.

L’autre solution consisterait à ne pas utiliser de verrou pour ces jobs Pre et Post. De mémoire, ils avaient été mis pour avoir un ensemble de jobs atomique (que les erreurs de l’un impactent les suivants de l’ensemble) et pour signifier au système qu’un redémarrage n’est pas possible. Il semble nécessaire de revenir sur cette conception.

Quelques questions pour orienter les corrections :
  • est-ce que la condition d’exécution des tâches Pre est globale ?
  • a contrario, est-ce que certaines tâches doivent s’exécuter invariablemenent alors que d’autres sont dépendantes de l’état de sortie des jobs précédents ?
  • idem pour les tâches Post…
On pourrait :
  • conserver le système de verrous,
  • ne pas provoquer d’erreur quand il y en a déjà un pour permettre d’exécuter les scripts sur le client
  • déléguer au script client le choix de s’exécuter ou pas selon le statut du job
  • gérer le verrou indépendamment sur le client (si il est séparé du directeur) pour ne pas bloquer certaines tâches en Post comme la mise-à-jour (normalement suivie d’un reconfigure et d’un redémarrage qui seraient bloqués en la présence d’un verrou de sauvegarde).
Alternativement, on pourrait :
  • conserver le système de verrous mais limiter son utilisation à la gestion des interruptions de sauvegarde : le verrou marque seulement la sauvegarde en cours et doit être enlevé quel que soit le code de sortie du job auquel il est associé.
  • les jobs Pre et Post sont exécutés indépendamment du code de sortie du job précédent
  • une sauvegarde est tentée même si la sauvegarde précédente était en échec (sans que l’administrateur ait à enlever le verrou manuellement).
  • le verrou peut néanmoins subsister si le script n’a pas pu être exécuté (cas d’une perte de connexion avec le client distant notamment).

#7 Mis à jour par Emmanuel GARETTE il y a environ un an

Les locks ont maintenant le nom du client pour différencier les clients s'il y en a plusieurs : exemple : sauvegarde_xxxxx.id_job (xxxx étant le nom du client).

Sur le directeur, il y a deux type de lock :

  • un locks "local" permet de savoir si y a eu une erreur à la dernière sauvegarde
  • un locks "système" sur le directeur permet de savoir si un sauvegarde est en court donc :
    • ne pas interrompre la sauvegarde (maj-auto, redémarrage, reconfigure, ...)
    • ne pas relancer une sauvegarde sur ce client

S'il est distant, sur le client un y un lock "système" pour ne pas interrompre la sauvegarde.

Cinématique :

  • La tâche PRE/POST/CATALOG démarre :
    • s'il y a un lock global sur le directeur ou client, on arrête le processus avec une erreur
    • on place un lock global sur le directeur et, s'il est distant, un lock global sur le client
  • La tâche PRE/POST/CATALOG s'arrête : on supprime le lock global sur le directeur et éventuellement le client (quelque soit le status)
  • La tâche SAUVEGARDE démarre :
    • sur le directeur s'il un lock local ou global on termine le job en faisant une erreur
    • sur le client, s'il y an local global on termine le job en faisant une erreur
  • La tâche SAUVEGARDE s'arrête en erreur (mais pas lié au placement de lock) :
    • sur le directeur et éventuellement sur le client on supprime le lock global
    • sur le directeur on place un lock local
  • La tâche SAUVEGARDE s'arrête : sur le directeur et éventuellement sur le client on supprime le lock global

#8 Mis à jour par Benjamin Bohard il y a environ un an

  • Statut changé de En cours à À valider
  • % réalisé changé de 0 à 100

#9 Mis à jour par Laurent Gourvenec il y a 12 mois

  • Statut changé de À valider à Résolu

#10 Mis à jour par Joël Cuissinat il y a 12 mois

  • Statut changé de Résolu à Fermé
  • Restant à faire (heures) mis à 0.0

Modifications réalisées pour EOLE ≥ 2.8.0.

Formats disponibles : Atom PDF