Fonctionnalité #224

GLB: Nouveau projet de backup

Added by David THENON 610 days ago. Updated 234 days ago.

Status :Annulé Start :06/05/2010
Priority :Normal Due date :
Assigned to :David THENON % Done :

60%
Category :GLB
Target version :-

Description

Mon premier projet de backup "Nanoo" a bien vieilli, j'ai accumulé une liste d'améliorations intéressantes à faire dessus et en parallèle je n'ai toujours pas trouvé d'utilitaire de backup rassemblant tout ce que je veux. Il est temps de faire évoluer le projet, mais surement dans un Fork de façon à revoir totalement le code depuis zéro et changer le nom.

Ce que fait Nanoo actuellement :

  • Les règles de backup sont stockés dans un fichier XML;
  • Les règles de backup peuvent concernés la création d'un tarball ou d'un dump Mysql (devenu obsolète);
  • Un fichier de log donnant un résumé des actions qui ont été faites ainsi que les erreurs survenues (comme lorsqu'un fichier à backuper n'existe pas);
  • Une interface CLI minimale qui permet juste de lancer un backup avec quelques options mineures;

Ce que je souhaiterais ajouter :

  • Nouvelle règle de backup "syncs" pour synchroniser des répertoires et fichiers via Rsync, cela se fera probablement en utilisant directement la commande shell de Rsync, le code python se chargerait juste de construire la commande selon les options puis de la lancer en controlant sa sortie de debug;
  • Nouvelle règle de backup ou une nouvelle option supplémentaire commune à tout les types de règles, qui permettrait de lancer une commande shell (par exemple pour utiliser un utilitaire pour faire un dump BDD qui pourrait être backupé directement après dans une règle de tarball);
  • Séparer fonctionnellement la lecture d'une config de backup qui passerait un backend interne à l'outil. Comme cela, on pourrait imaginer ajouter la possibilité d'utiliser des règles dans autre chose qu'un XML (BDD, fichier plat, etc..);
  • Récupérer le principe du projet "Noé" qui était une interface de commande en ligne plus élaborée (permet de créer les règles de backups, éditer une config existante, etc..) que celle de Nanoo;
  • Une option de test des règles d'une config de façon à pouvoir tout vérifier et corriger les erreurs AVANT de faire le backup (avec Nanoo il faut lancer le backup et corriger selon les erreurs archivés dans les logs);
  • Supprimer la partie "dump" qui est trop limité et demande un support trop grand alors que les outils fournis avec les serveurs de BDD (mysqldump, psql, etc..) sont largements suffisant.
  • Option de l'interface CLI qui permette de ne séléctionner qu'une règle d'un fichier de config de backup;
  • La base de frontend ne doit rien afficher dans le terminal mais seulement renvoyer les infos que le frontend final utilisera comme il lui convient;
  • Les backends et la base du frontend remonte des exceptions trop générique à eux mêmes. Ils doivent remonter des exceptions explicites qui permettent de juger du problème, et les frontend doivent les surveiller pour remonter proprement une erreur à leur façons propre;
  • Terminer le frontend CLI, soit solutionner la complexité des arguments de manipulation du backend, soit les retirer;
  • La partie BackendManipulatorBase du backend de base doit implémenter des méthode de suppression de config, directive et action. De même pour les backend existants.
  • Frontend de type "curse" avec une interactivité de prompt suffisante pour régler le problème du frontend CLI;
  • Backend humainement manipulable avec un simple éditeur de fichier tel que XML ou JSON;
  • Implémenter la capacité de désactiver des actions de directives de commandes (voir le docstring du module).

History

06/05/2010 11:04 AM - David THENON

En attendant mieux (ou pas), je vais prendre un nom temporaire pour le projet qui sera GLB aka "Geek Life Backup".

06/26/2010 11:44 AM - David THENON

  • Subject changed from Nouveau projet de backup to GLB: Nouveau projet de backup
  • Category set to GLB
  • % Done changed from 0 to 30
  • Projet dénommé GLB, acronyme valable pour Geek Like Backup ou Geek Life Bank, au choix;
  • Nouveau projet ajouté, pour l'instant dans bordel/sveetch/glb/ (peut être bientôt dans son propre repository à part);
  • Système composé de trois parties : modules pour les directives d'actions (tarball, commandes shell, synchronisation Rsync, etc..), backends qui contiendra les différents types de backends possibles (xml, sqlite, fichiers plats, etc..) pour l'instant seulement dummy (backend bidon qui ne fait que démontrer ce que doit retourner un backend) et frontends qui contiendra les différentes interfaces (cli, curse, Qt, etc..) pour manipuler et utiliser GLB
  • Les Backends seront prévus pour lire et manipuler (création/édition) une config de backup;
  • Directive Tarball qui reprends le système de "tarball-isation" utilisé dans Nanoo;
  • Directive Sync qui permet de faire des synchronisations de fichiers/répertoires via Rsync (local ou SSH);
  • Directive Command qui permet d'effectuer des commandes Shell;
  • Un backend qui renvoi une config de backup sous forme d'une liste Python contenant les objets des directives et leur actions sous forme d'objets déja initialisés, prêt à l'emploi;
  • Les directives possèdent deux méthodes publiques importantes: cleanup qui sert à valider la config, execute qui éxécute la directive (à n'utiliser qu'après avoir fait un cleanup).

Il reste à s'occuper de l'interface de base cli. Puis ce sera les backends (ou tout au moins un pour le support xml).

06/30/2010 12:48 PM - David THENON

  • % Done changed from 30 to 50

Une première partie de frontend CLI est en place, mais qui ne fait pas grand chose actuellement, il fallait d'abord qu'un backend réel (pas dummy) existe pour pouvoir mettre en place les options de manipulation du frontend.

Pour ce faire j'ai fait le backend sqlite, qui pour l'instant n'implémente que la partie lecture, la partie écritude est en cours. Ensuite je repasserais sur le frontend cli.

07/25/2010 04:25 AM - David THENON

  • % Done changed from 50 to 60

Un petit bilan, globalement GLB fonctionne, il peut exécuter sans soucis les directives d'une config de backup. Cependant il n'y a pour l'instant qu'un seul type de backend disponible qui est sqlite3 (qui n'est pas des plus aisés à manipuler manuellement).

L'outil CLI est assez sommaire, mais fait ce travail d'éxécution d'une config de backup. Cependant pour la manipulation du backend c'est plus problématique car la diversité des directives et action rend l'outil CLI tel quel, trop cryptique à utiliser (vis à vis de la diversité des arguments possibles pour une meme commande d'ajout de directive ou d'action).

Une première solution serait d'ajouter "dynamiquement" les options de commandes pour chaque modules de directives possibles mais les modules devront publiés ce qu'ils ont besoin mais de façon assez générique pour que ce ne soit pas utilisable uniquement par l'outil CLI.

Une seconde solution résidera dans un frontend de type "curse" qui permettra un peu d'intéractivité qui permettra une plus grande aisance à utiliser la diversité des directives et actions.

07/25/2010 07:05 PM - David THENON

En fait il y a un gros soucis "d'inconsistance" dans le backend et le frontend. Actuellement le backend de base accepte des identifiant clés d'objets en "string" alors que le backend sqlite n'utilise que des integer. De plus le backend en interne, utilise des index de position de liste comme identifiant d'objets au lieu de leur vrai ID, et le frontend suit ce comportement.

Il faut repartir sur une base saine sur le backend, en utilisant que des identifiants de type integer, plus de keycode, l'argument "keycode" des sous objets (attr, content) doit être renommé (parce qu'il sert de nom d'attributs/éléments et non de réel identifiant). Le backend sqlite doit suivre cela, puis après seulement s'occuper de reporter ça sur le frontend.

Et aussi, le backend doit utiliser les identifiants pour localiser un objet et non plus les index de positions. De même cela doit etre reporté après sur le backend sqlite et le frontend. D'ailleurs le backend doit aussi présenter une méthode pour accéder directement à une directive en utilisant son ID.

C'est LA tâche à faire avant tout pour continuer.

06/16/2011 04:06 PM - David THENON

  • Status changed from Assigné to Annulé

C'était un projet sympa mais un peu trop vaste (multiplicité des backends d'entrées, de modules et formats de sorties) pour moi seul (mon disciple m'a lachement abandonné), donc on je clos le sujet, l'avenir à mes yeux maintenant c'est le projet Bump, mon outil en PyQT.

Also available in: Atom PDF