Project

General

Profile

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

Added by Emmanuel GARETTE over 1 year ago. Updated about 1 year ago.

Status:
Fermé
Priority:
Normal
Assigned To:
Start date:
02/27/2023
Due date:
% Done:

100%

Remaining (hours):
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.

Associated revisions

Revision 69e8b280 (diff)
Added by Benjamin Bohard about 1 year ago

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

Ref #35088

History

#1 Updated by Joël Cuissinat over 1 year ago

  • Tracker changed from Demande to Scénario
  • Start date deleted (11/26/2022)
  • Release set to EOLE 2.8.0.1
  • Story points set to 1.0

#2 Updated by Joël Cuissinat over 1 year ago

  • Parent task set to #35154

#3 Updated by Benjamin Bohard about 1 year ago

  • Status changed from Nouveau to En cours
  • Assigned To set to Benjamin Bohard
  • Start date set to 02/27/2023

#4 Updated by Benjamin Bohard about 1 year ago

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 Updated by Benjamin Bohard about 1 year ago

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 Updated by Benjamin Bohard about 1 year ago

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 Updated by Emmanuel GARETTE about 1 year ago

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 Updated by Benjamin Bohard about 1 year ago

  • Status changed from En cours to À valider
  • % Done changed from 0 to 100

#9 Updated by Laurent Gourvenec about 1 year ago

  • Status changed from À valider to Résolu

#10 Updated by Joël Cuissinat about 1 year ago

  • Status changed from Résolu to Fermé
  • Remaining (hours) set to 0.0

Modifications réalisées pour EOLE ≥ 2.8.0.

Also available in: Atom PDF