[mOved] [F] Solution de sauvegarde générique - Page 4

OK en effet ça a l'air de fonctionner déjà mieux

Bon du coup il m'a fait un backup sans aucune erreur, visiblement il arrive à le retrouver puisque si je relance il me dit qu'il est up to date, en revanche j'ai pas l'impression qu'il ait sauvegardé grand chose. Sur le remote j'ai un fichier .tar vide (enfin il contient seulement un fichier ".last_backup" qui n'est pas à moi, je ne sais pas trop ce qu'il fabrique là). Dans le dossier de backup local que j'ai choisi il n'y a que des metadata mais le dossier "backups" est vide

[edit] J'ai compris, c'est parce que j'utilisais l'ancienne syntaxe au lieu de celle du post ./77 du coup il a ignoré mes sections. Un message d'erreur serait le bienvenu dans ce cas (et même plus généralement dès qu'il y a quoi que ce soit de non reconnu dans un fichier de config), au lieu de me dire que c'est bon, tout est sauvegardé

Ok, je note ça, ça devrait être rapide à faire ^^

Bon, j'ai encore un problème avec mes remote et la récupération de la date de la dernière sauvegarde.
Je sais que le problème a l'air idiot, mais il n'est pas si facile que ça à résoudre

Mettons que les sauvegardes soient envoyées vers l'URL http://example.org(fqdn)s-%(Y)s-%(m)s/backup.tar.gz . Super pratique : polyarchiv envoie directement vers le bon dossier et change de dossier tout seul chaque mois, avec un dossier différent par serveur sauvegardé.

Maintenant, le serveur est mort et on réinstalle une nouvelle machine. Impossible de retrouver le dernier backup (le fqdn a changé et polyarchiv ne peut pas deviner que Y = 2016 et m = 06 lors du dernier backup).
Je distingue trois possibilités :

• copier la dernière sauvegarde à l'URL choisie ET à une URL dont les variables sont mises à des valeurs fixes (fqdn == localhost, Y=1970, m=01, d=01, etc.) : peu viable car on n'a pas envie de dupliquer la sauvegarde
• on reprend l'URL fixe et on n'y envoie qu'un fichier contenant la date de dernière sauvegarde et son URL
• chaque remote repository a en plus un paramètre supplémentaire de type http://file://, scp:// ou http:// vers lequel on envoie le fichier en question, qui ne prendrait aucun paramètre variable dans le temps ou l'espace.

je penche de plus en plus vers la dernière. Des avis ?

Les trois solutions sont un peu dommage je trouve, c'est une sacré contrainte que tu ajoutes là. Ça ne serait pas possible de conserver sur le remote un fichier les informations qui te permettent de reconstruire la dernière URL utilisée ?

Oui, mais où sur le remote, justement ?

Je ne peux pas conserver en local, étant donné que l'information peut disparaître.

Ah pardon j'avais mal compris ta troisième suggestion, ça serait effectivement celle-là que je prendrais. Tu pourrais par exemple imposer de configurer l'URL en deux parties : une racine fixe dans laquelle les variables ne sont pas autorisées, puis un template pour le sous-chemin dans lequel on place les fichiers sauvegardés. Le fichier spécial "emplacement de la dernière sauvegarde" serait conservé dans la racine uniquement.

Je suis donc parti, sans surprise, sur la 3ème solution. Ça m'a demandé pas mal de développement, afin de faire une classe de transport générique (avec une sous-classe SSH, une sous-classe HTTP/webdav et une pour les fichiers). C'est pénible de n'avoir aucun logiciel permettant de faire l'équivalent de rsync, mais via HTTP ou FTP…
Cette classe dispose de seulement 4 méthodes (copier un dossier, récupérer un fichier et récupérer un dossier, récupérer un fichier — ça a l'air bête, mais ce n'est parfois pas le même code)

L'URL pourra utiliser les variables, en sachant que les paramètres de date et de hostname sont remplacés par des constantes. Ça me permet de stocker un bête JSON avec la date de la dernière sauvegarde ainsi que les variables correspondantes (dates et hostname). Ainsi, je peux procéder à la restauration sans trop de souci.

Je peux maintenant travailler à la restauration des fichiers sauvegardés (d'abord récupérer les fichiers depuis le remote, appliquer les filtres dans l'ordre inverse, puis restaurer les fichiers localement).

Ensuite, j'aimerais réutiliser la classe de transport générique pour refaire mes types de RemoteRepository.

Ça a l'air d'avancer de façon intéressante

Merci

Avoir fait un code générique pour envoyer ou récupèrer des fichiers depuis une URL précise (ssh/http/file) m'a permis de bien simplifier le code des remote.
Maintenant, je dois me relancer dans l'écriture des tests pour valider l'ensemble. Mais c'est franchement pénible à mettre en place (il faut un serveur webdav, un serveur SSH, etc…).

Bon, les tests avancent (j'installe apache, gitlab et ssh dans Vagrant, c'est bien pratique pour ça ^^), j'ai déjà pu corriger quelques problèmes

Au passage, y a-t-il des solutions de tests d'intégration continue un peu comme tox ou Gitlab-CI qui permettent de mettre en place un environnement complet (comme une bdd, un webdav, ... ) le temps d'un test ?

pendant que j'avance tranquillement dans mes tests (c'est l'avantage par rapport à un bête script bash : je peux tester indépendamment chaque type de source et chaque type de dépôt, ainsi que chaque backend de transport (ssh/webdav/file)), je suis tombé sur dovecot-adm qui permet de faire des backups facilement

Bon je viens de refaire un essai mais entre la syntaxe des fichiers qui a changé, le nom des moteurs qui n'est visiblement plus le même et le fait que j'ai oublié le peu que j'avais réussi à comprendre, je crois que je vais retourner à une solution plus basique pour le moment

Je reviendrai à polyarchiv quand tu l'auras stabilisé, pour l'instant je trouve que tu as réussi à inventer une solution de sauvegarde très usine-à-gazesque, je n'ai jamais eu autant de mal à faire fonctionner quelque chose que je pensais pourtant être un problème simple

(tu veux dire que tu n'as jamais essayé aucun programme dans ma pléthore de releases ? )

Bon, avec des explications en live hier et en croisant la doc + les posts sur yAronet, ça marche nettement mieux ! J'ai une configuration qui fonctionne \o/

Je n'ai plus que deux commentaires mineurs, avec une configuration qui ressemble à ça :Avec ça, quand j'exécute polyarchiv backup :

- J'ai un message d'erreur ValueError: Unable to create the /sandstone directory, alors qu'en réalité c'est la connexion SSH qui a échoué (je ne sais pas pourquoi d'ailleurs, mais rien à voir avec polyarchiv). Ça mériterait un message un peu moins trompeur
- J'ai un message d'erreur /home/polyarchiv/httpd__fr_mirari_www is not a valid directory. C'est vrai, il semblerait que polyarchiv crée automatiquement tous les destination_path si besoin mais pas le local_path. Je comprends l'idée, mais ça veut dire que dans mon cas il faudrait que je retire le suffixe /httpd__fr_mirari_www dans local_path et que je l'ajoute comme préfixe au destination_path de toutes les sources. Ça introduit un tout petit peu de redondance dans la configuration, pas dramatique, et peut-être que c'est un petit prix à payer pour avoir la sécurité au niveau de la vérification du local_path, j'hésite encore ^^

[edit] Ah j'ai peut-être parlé un peu vite, maintenant j'ai une erreur quand un backup a tenté de s'exécuter via la crontab :

Traceback (most recent call last):
  File "/usr/bin/polyarchiv", line 8, in <module>
    from polyarchiv.cli import main
  File "/opt/polyarchiv/polyarchiv/cli.py", line 17, in <module>
    from polyarchiv.check import check_local_repository, check_remote_local_repository
  File "/opt/polyarchiv/polyarchiv/check.py", line 7, in <module>
    from polyarchiv.locals import LocalRepository
  File "/opt/polyarchiv/polyarchiv/locals.py", line 15, in <module>
    from polyarchiv.conf import Parameter, strip_split, check_directory, check_executable
  File "/opt/polyarchiv/polyarchiv/conf.py", line 8, in <module>
    from polyarchiv.utils import text_type
  File "/opt/polyarchiv/polyarchiv/utils.py", line 10, in <module>
    from pip._vendor.distlib.compat import raw_input
ImportError: No module named pip._vendor.distlib.compat

Il ne me semble pas avoir eu le même problème quand j'ai lancé l'outil à la main, c'est curieux, je creuserai un peu.

[edit] Hum, je crois que j'ai une idée du coupable

!slap Flanker
• Zeph slaps Flanker around a bit with a large trout !

Bon, j'aimerais changer la source « rsync » en « local_files ».
Je pense que c'est mieux de ne pas citer la techno sous-jacente, rien n'interdirait de faire un truc en pur Python, après tout.

En échange, j'ai ajouté une source « remote_files »

Au passage, j'ai commencé une doc version HTML : http://polyarchiv.readthedocs.io/en/latest/index.html
Je suis preneur de tout commentaire sur le sujet, sachant qu'il me reste les exemples à écrire ^^

Avant de lire plus en détail j'ai toujours le même commentaire sur le choix malheureux des noms : il y a des local repositories, des remote repositories, et parmi les sources on trouve local_files et remote_files, tout ça n'ayant rien à voir. À mon avis pour ne pas perdre les utilisateurs ça serait une bonne chose de ne jamais donner le même nom (ou un nom proche) à des concepts différents (et inversement d'ailleurs)

C'est le bon moment pour changer la nomenclature
Je suis preneur d'autres idées, si tu en as ^^

Peut-être renommer "local_files" en "filesystem" et "remote_files" en "download", "mirror" ou "synchronize", pour éviter de réutiliser les mots "local" et "remote" qui sont déjà très largement utilisés dans la documentation ? (et qui sont des concepts à vraiment comprendre pour pouvoir se servir de l'application)

J'aime bien « filesystem », un peu moins « download » ou « synchronize ». Peut-être « mirror ».

Après, je peux également changer les termes « local repository » et « remote repository » ; simplement si je change ça sera définitif ^^
« collect_point » pour le premier, « backup_destination » pour le second ?

Ah oui, c'est bien ça

On va finir par tomber d'accord

Du coup, si je supprime la notion de remote/local repos, pourquoi ne pas conserver remote_files pour la source récupérant des fichiers distants ?
Et pour les fichiers de conf', .collect et .dest ?

Oui bien sûr, le but était de ne pas réutiliser les termes pour des choses différentes, si les ex-repos ne s'appellent plus local et remote aucun problème pour appeler les sources de cette façon

C'est bon, refactoring entamé.

Je remplace donc local repository par « collect point ». Par contre, pour les remote, j'hésite encore entre « backup_destination », « push_destination » et « push_point ». Le premier me convient moyennement car au final, le « collect point » peut tout à fait suffire (s'il est sur un NFS et que c'est un dépôt git, par exemple). Le dernier permettrait de conserver une certaine symétrie entre les deux types.

Et backup_point, pour avoir la symétrie sans sous-entendre qu'on "push" forcément quelque part ?

Pourquoi pas (mais ça veut dire que le collect_point n'est pas un backup, mais bon, je peux l'accepter quand même)

(bon, je te déteste, c'est super pénible de tout changer, ainsi que la documentation)

(il faut faire comme Folco, des softs dont tu es le seul utilisateur : comme ça, plus de soucis )

'foiray xD

./116 : il te faut une IDE qui permet de faire du refactoring de doc

(./118 : si ça peut te consoler, c'est même pas vrai : même pour tes programmes persos, tu te poses des questions existentielles )