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

Ce sujet est issu d'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d'origine, suivez ce lien.

Bon, bah voilà, j'ai bien entamé le projet. Mais gros problème : va falloir que je trouve un nom sympa

Il se structure en dépôts locaux (chacun composé de plusieurs sources de données) et en dépôt distants, avec dans l'idée d'avoir plus ou moins un dépôt local par projet à sauvegarder.
Quand on lance le script, il scanne tous les fichiers de conf (un par dépôt local et un par dépôt distant), et exécute les bonnes commandes :

• récupération des différentes sources (mysqldump, copie des fichiers, pg_dump, …)
• sauvegarde locale éventuelle
• envoi vers les différents dépôts distants

On peut préciser une fréquence maximale (du coup, ça ne fait rien si la dernière sauvegarde est assez récente), limiter les associations locaux-distants, afficher les commandes bash exécutées, les confirmer une à une ou les simuler. Accessoirement, il peut se comporter en check nagios pour être intégré à une sup’ assez facilement.
Un dépôt local peut être des fichiers standards ou un dépôt git. Pour les distants, il y a git, .tar.gz envoyé par cURL, duplicity ou rsync.

Par exemple, avec en local : [global] engine=GitRepository local_path=/tmp/local frequency=daily [source_1] engine=PostgresSQL host=localhost user=test password=testtest database=testdb destination_path=./postgres.sql [source_2] engine=MySQL user=test password=testtest database=testdb destination_path=./mysql.sql [source_3] engine=RSync source_path=/tmp/source/files destination_path=./filesEt en distant :[global] engine=TarArchive remote_url=file:///tmp/remote/archives/on peut avoir
python run.py backup --show-commands --force --dry PGPASSWORD=testtest pg_dump --username=test --host=localhost --port=5432 testdb > /tmp/local/./postgres.sql mysqldump --user=test --password=testtest --host=localhost --port=3306 testdb > /tmp/local/./mysql.sql rsync -a --delete -S /tmp/source/files/ /tmp/local/./files/ echo '2016-05-05T13:56:32' > /tmp/local/.last-backup cd /tmp/local git init git add . git commit -am 'Backup 2016/05/05 13:56' # register this backup state cd /tmp/local tar -cjf /tmp/local/archive-2016-05-05_13-56.tar.bz2 .last-backup files mysql.sql postgres.sql cp /tmp/local/archive-2016-05-05_13-56.tar.bz2 /tmp/remote/archives/
Faut encore faire l'opération de restauration des backups, et surtout faire les tests pour chaque type d'opération

Pas mal

Du coup ça mérite d'être forké côté projets, non ?

Plusieurs questions, parce que je serais bien utilisateur d'un système pareil : dans le fichier de configuration, "global" ça veut dire "paramètres par défaut qu'on peut overrider dans la définition des sources" ? Si oui, je trouve dommage d'avoir un conflit potentiel entre cette définition et la définition des sources (c'est trompeur, et puis impossible d'avoir une source qui s'appelle "global" j'imagine), mais ça ne vaut peut-être pas le coup de changer. Par contre si j'ai bien compris la définition, je me serais attendu à un nom genre "default" plutôt que "global" dont le sens est plus ambigu.

Pour que ça fonctionne il faut au moins un fichier local et au moins un fichier distant ? Comment est-ce qu'il choisit lesquels il utilise ? (je ne vois pas de référence à l'un ou à l'autre dans ton exemple) Il faut les placer où ?

La fréquence, il y a moyen de mettre des choses plus précises que "daily" (ou "hourly", etc. j'imagine) ? Par exemple toutes les 12h ?

Ah et le PascalCase pour le nom des moteurs, c'est une faute de goût presque impardonnable (sérieusement, "RSync" et "GitRepository" quoi !)

[edit] Encore une : le fichier distant semble porter deux notions différentes, celle de format de fichier pour la sauvegarde (avec ce fabuleux "TarArchive" qui pourrait s'appeler "tar" ) mais également celle de type de transport ("file:///" qui pourrait j'imagine être aussi "ftp://", "ssh://", "webdav://" ou autre) ; comment ça marche ?

fork done ^^

Pour les sources : https://github.com/d9pouces/PolyArchiv . Of course, c'est du Python (2.7 et 3.4+), sans aucune dépendance.
Alors, pour répondre :

1) la section « global » correspond aux paramètres pour le dépôt local. Effectivement, ça empêche d'avoir une source nommée « global » dans ce dépôt. L'autre possibilité aurait été de faire un fichier de conf' supplémentaire, ça aurait été plus pénible qu'autre chose. J'aurais pu la nommer en « repository », effectivement.
2) par défaut, il essaie de sauvegarder tous les dépôts locaux, puis sur chaque dépôt local, il applique tous les dépôts distants. Les fichiers de conf' illisibles sont ignorés. Mais tu peux changer ça avec des « tags ».
Chaque dépôt local ou distant peut avoir des tags (par exemple « large » ou « small »), et inclure ou exclure des tags de l'autre type de dépôt. Tu peux mettre le tag « large » sur un dépôt avec beaucoup de données, et sur certains dépôts distants tu exclues le tag « large ».
3) tu peux préciser l'heure de chaque jour, le jour de chaque semaine ou de chaque mois, ou une fréquence (en secondes pour l'instant).
4) en fait ce sont des classes, et il faut mettre le chemin complet (par exemple polyarchiv.locals.GitRepository) : c'est le chemin Python complet pour importer la classe. L'idée est de pouvoir ajouter ses propres plugins.
5) pas bien compris

flanker (./2) :
Mais gros problème : va falloir que je trouve un nom sympa

"Flanker Backup" -> Flankup

1) repository ? je trouve ça encore moins explicite, mais OK je vois l'idée ^^ (un repository pour moi c'est un conteneur dans lequel on met des fichiers, du coup c'est curieux comme nom pour la section qui contient les paramètres par défaut, non ?)
2) OK mais comment trouve-t-il les fichiers ? Il faut qu'ils soient tous dans un dossier particulier (genre /etc/tonsoft), ou bien les spécifier en ligne de commande, ou encore il y a un index qui les référence tous ?
3) OK
4) je me doutais que c'était quelque chose dans le genre, mais ça reste vraiment atroce (blague à part, c'est assez contre-intuitif, je ne connais pas un seul soft qui demande à mettre des options en PascalCase pour que ça fonctionne, surtout quand les options disponibles ressemblent à des commandes unix qui s'écrivent toujours en minuscule)
5) hmm oui c'est super mal formulé désolé, et entre temps je pense avoir compris : j'avais regardé le dernier exemple où on voit une option "engine" (tiens, encore un nom que je trouve peu explicite) et une autre "remote_url", or les deux me semblaient potentiellement incompatibles (par exemple "engine=git" avec "remote_url=webdav://machin" ça n'aurait pas beaucoup de sens). Mais en fait j'imagine que "remote_url" n'est valable que pour certaines valeurs de "engine" ; j'ai encore été trompé par le fait qu'on a deux paramètres au même niveau mais que l'un dépend de l'autre.

Zerosquare (./5) :
"Flanker Backup" -> Flankup

"Flanker Backup" -> F*ckup?

./5 : ou bien tu contractes encore plus : Flup

Ah très sympa, Flup !

Zeph (./6) :
1) repository ? je trouve ça encore moins explicite, mais OK je vois l'idée ^^ (un repository pour moi c'est un conteneur dans lequel on met des fichiers, du coup c'est curieux comme nom pour la section qui contient les paramètres par défaut, non ?)

En pratique, c'est exactement ça : si tu reprends l'exemple du premier post, le dépôt local correspond à /tmp/local/, dans lequel on va faire les dumps MySQL et PostgreSQL et copier les fichiers à sauvegarder depuis /tmp/source/files/.
Si ton dépôt local est de type polyarchiv.locals.FileRepository, ça s'arrête là.
S'il est de type polyarchiv.locals.GitRepository, il fait en plus un commit local.

2) OK mais comment trouve-t-il les fichiers ? Il faut qu'ils soient tous dans un dossier particulier (genre /etc/tonsoft), ou bien les spécifier en ligne de commande, ou encore il y a un index qui les référence tous ?

Il prend tous les fichiers dans le dossier /etc/polyarch (ou l'équivalent dans un virtualenv s'il n'est pas installé globalement), mais tu peux spécifier bien sûr un autre dossier.

3) OK
4) je me doutais que c'était quelque chose dans le genre, mais ça reste vraiment atroce (blague à part, c'est assez contre-intuitif, je ne connais pas un seul soft qui demande à mettre des options en PascalCase pour que ça fonctionne, surtout quand les options disponibles ressemblent à des commandes unix qui s'écrivent toujours en minuscule)

L'autre option serait d'utiliser les « entry_points » de Python. Ça pourrait permettre de déclarer n'importe quel alias pour les classes Python (et faire quelque chose d'insensible à la casse)

5) hmm oui c'est super mal formulé désolé, et entre temps je pense avoir compris : j'avais regardé le dernier exemple où on voit une option "engine" (tiens, encore un nom que je trouve peu explicite) et une autre "remote_url", or les deux me semblaient potentiellement incompatibles (par exemple "engine=git" avec "remote_url=webdav://machin" ça n'aurait pas beaucoup de sens). Mais en fait j'imagine que "remote_url" n'est valable que pour certaines valeurs de "engine" ; j'ai encore été trompé par le fait qu'on a deux paramètres au même niveau mais que l'un dépend de l'autre.

Oui, en effet ; heureusement qu'il y a une commande qui affiche toutes les options pour chaque "engine".

merci pour ces remarques

flup est pas mal, en effet

édit : mais déjà pris

OK, ça s'annonce pas mal tout ça, merci pour les réponses

J'attends ton go pour tester (malgré un nom qui sera surement beaucoup moins cool que flup )

À la rigueur, tu peux déjà tester (au pire avec l'option --dry --show-commands pour voir ce que ça donne).
C'est dispo sur Github https://github.com/d9pouces/PolyArchiv avec un README minimal
Je te conseille de créer un virtualenv python et d'installer via pip install polyarchiv.

Pour le backup, je n'ai pas encore tout testé (pour de bêtes raisons techniques : il faudrait des serveurs OpenLDAP, MySQL, PostgreSQL, git+http, git+ssh, webdav, smb, ftp, ftps, https, etc…).
D'ailleurs, si tu connais des solutions permettant ça, je suis preneur J'aimerais un truc pour les tests de non régression, avec un simple fichier de conf dans lequel tu précises que tu veux du MySQL, du LDAP, du Postgres, et en échange la plate-forme te créerait une base et te fournirait les infos correspondantes.


Pour la restauration des archives, ce n'est pas encore fini et donc non fonctionnel : il faut essentiellement que je fasse la partie qui interroge les différents dépôts distants pour récupérer les données depuis le plus récent.

Tu as prévu de crypter le stockage sur le dépôts distants ?

PpHd (./14) :
Tu as prévu de crypter le stockage sur le dépôts distants ?

Si tu utilises duplicity comme type de dépôt distant, c'est automatiquement chiffré.
(note : celui-ci n'est pas encore testé)

Je trouve que l'un des principaux avantages de ton soft c'est d'être standalone. S'il faut utiliser duplicity ça diminue pas mal l'intérêt, et cumuler ces deux softs ne me semble pas très intéressant vu le nombre de redondances entre eux et les dépendances que traine duplicity (dont paramiko ). Je rejoins PpHd, ça serait cool d'avoir le cryptage géré directement

Je pensais me contenter d'utiliser duplicity de façon indirecte (comme ça, on ne voit pas trop ce que ça traîne comme dépendances).

Ça m'embête un peu de faire un système de chiffrement, j'ai toujours peur d'introduire plus de failles qu'autre chose
Cela dit, une méthode assez simple serait de chiffrer le dépôt local, mais ça veut dire que chaque fichier est chiffré individuellement : ce n'est pas la meilleure solution.

Il me semble que duplicity repose entièrement sur gnupg pour la partie chiffrement, du coup pas trop de risque de se louper a priori ? (et pour le coup c'est un utilitaire disponible par défaut donc c'est beaucoup moins gênant comme dépendance)

Enfin on est déjà en train de parler de fonctionnalités avancées, il est peut-être un peu tôt

Oui, simplement il y a moyen de faire plus subtil (regrouper les fichiers avant de chiffrer pour plus de sécurité), et là ça commence à être compliqué ^^ je vous laisse faire l'ajouter sur le compte Github

Mais en soi, c'est tout à fait faisable de rajouter un type de dépôt local qui soit chiffré (et du coup immédiatement compatible avec les dépôts distants)

Ce qui serait bien, ce serait une sauvegarde différentielle et chiffrée.
Ton outil permet-il de gérer le nombre ou l'ancienneté maximale des sauvegardes ? Il existe des systèmes qui permettent pas exemple de garder une version par heure sur la dernière journée, puis toutes les 24 heures sur le dernier mois et après une par semaine jusqu'à l'ancienneté maximale choisie. Ce serait bien que ton outil puisse le faire

Pour la sauvegarde différentielle chiffrée, ça devrait être possible de le faire via git, en chiffrant les commit (peut-être https://gist.github.com/shadowhand/873637 ? ).

j'ai hésité à le faire pour le type « archive tar », qui fait un .tar.gz puis l'expédie au loin avec cURL.
Malheureusement, ce n'est pas systématiquement possible car cURL ne permet pas de parcourir un dossier pour récupérer la liste de fichiers.

Je pourrais probablement le faire avec un nombre limité de transports (ssh ou cp, par exemple). Mais à vrai dire vrai, j'aimerais me passer de ssh (je souhaiterais n'utiliser ssh que pour les tâches d'admin et éviter les connexions depuis n'importe où), ce qui signifie passer par du ftp (pénible avec plein de ports à ouvrir) ou mieux du http+webdav.

Bon j'ai voulu essayer mais on dirait qu'il y a quand même au moins une dépendance $ python run.py Traceback (most recent call last): File "run.py", line 5, in <module> from polyarchiv.cli import main File "/home/vagrant/document/work/repository/PolyArchiv/polyarchiv/cli.py", line 16, in <module> from pkg_resources import iter_entry_points ImportError: No module named pkg_resourcesNote que je ne suis pas sûr d'avoir lancé le bon fichier : je n'ai pas utilisé pip pour l'installation (je n'ai pas pip et je préfère éviter de l'installer juste pour un projet), donc j'ai simplement cloné le repo et tenté d'exécuter run.py. Petite correction au passage : les fichiers .py et .sh n'ont ni shebang ni permission en exécution par défaut

[edit] Pour pouvoir aller plus loin j'ai installé pip temporairement. Je viens d'essayer de lister les plugins avec polyarchiv plugins -v, mais ça lui plait moyennement $ polyarchiv plugins -v configuration directory: /etc available local repository engines: * engine=files Traceback (most recent call last): File "/usr/local/bin/polyarchiv", line 9, in <module> load_entry_point('polyarchiv==0.7.1', 'console_scripts', 'polyarchiv')() File "/usr/local/lib/python2.7/dist-packages/polyarchiv/cli.py", line 107, in main display_classes('polyarchiv.locals', verbose=verbose, width=width) File "/usr/local/lib/python2.7/dist-packages/polyarchiv/cli.py", line 123, in display_classes cprint(' ' + engine_cls.__doc__.strip(), GREY, BOLD) File "/usr/local/lib/python2.7/dist-packages/polyarchiv/termcolor.py", line 108, in cprint print((colored(text, color, on_color, attrs)), **kwargs) UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2018' in position 58: ordinal not in range(256)[edit 2] De même, il a tendance à crasher dès qu'on utilise une commande qu'il ne connait pas. Par exemple polyarchiv backup (avec un "s" manquant) sort du programme avec une stack trace au lieu d'afficher un message d'erreur.

[edit 3] Bon je m'arrête là, sans documentation et sans possibilité de lister les plugins c'est un peu trop chaud de savoir ce qu'il faut mettre dans les fichiers de configuration J'ai essayé de faire deux fichiers /etc/polyarchiv/test.local et /etc/polyarchiv/test.remote puis d'exécuter polyarchiv backups, mais ça sort avec un code d'erreur 0 sans rien afficher

Ça vient de l'absence de l'utilisation de pip ^^ Je pensais que pip était fourni de base, à vrai dire (et pkg_resources doit venir avec).

Quand tu utilises pip (ou python setup.py develop, ou encore python setup.py install), run.py est ignoré et un joli fichier est installé dans ton $PATH (qui a sensiblement le même contenu que le run.py), avec les bons shebang et permissions.

OK entre temps j'ai mis à jour mon post avec les tentatives suivantes, mais je n'ai pas réussi à m'en sortir.

J'avais prévu le bug que tu remontes, mais je pensais qu'il n'arriverait qu'avec un pipe (python run.py | more, par exemple).
Quelle était ta configuration ?

Lequel, celui que j'obtiens avec polyarchiv plugins -v ? Je l'ai eu en tapant uniquement cette commande depuis mon shell (TTY, pas de pipe) ; c'était sous Ubuntu et j'utilise zsh, mais je ne pense pas que ce soit significatif.

(c'est là qu'on voit à quel point l'informatique a progressé : avant, installer un programme c'était tout un bazar, mais ça s'est nettement simplifié depuis ! )

Au passage, j'ai corrigé les bugs et passé pas mal de temps pour avoir des erreurs nettement plus claires ; là je vais consacrer un peu plus de temps à faire des tests dans Vagrant pour installer des bases de données et les recréer

Alors je viens d'essayer à nouveau :

- polyarchiv plugins -v ne fonctionne toujours pas (même erreur qu'en ./22), mais si je fais polyarchiv plugins -v | cat ça fonctionne donc je suppose qu'il n'arrive pas bien à gérer un TTY UTF-8, ça n'a pas l'air bien grave
- L'aide a l'air bien fournie, mais je vois deux catégories "local repository engine", "remote repository engines" (qui sont mentionnés dans la doc) et une troisième "source engines" (dont la signification m'échappe) ; à quoi ça correspond ? (en fait je suis d'autant plus perdu que jusqu'ici je comprenais "local repository" = "source" et "remote repository" = "destination", mais du coup c'est peut-être pas du tout ça)
- Si j'essaie polyarchiv config -v | cat il me dit configuration directory: /etc : je m'attendais à ce que ce soit plutôt /etc/polyarchiv par défaut ? (je peux changer avec -C, mais c'est moins pratique)
- J'ai préparé un fichier /etc/polyarchiv/my-local.local avec seulement ce contenu :[test] engine=files local_path=/tmpMais il me dit qu'il faut une section globale avec au moins un paramètre "engine". Je peux le faire, mais du coup j'ai l'impression de ne toujours pas avoir compris la signification de cette section particulière : je pensais qu'il s'agissait uniquement de paramètres globaux éventuellement écrasés par les sections déclarées ensuite, mais si elle est obligatoire ça doit vouloir dire que j'ai faux ?
- J'ai renommé la section "test" de mon fichier précédent en "global", puis j'ai créé un fichier /etc/polyarchiv/my-remote.remote comme ça :[global] engine=tar frequency=1 remote_url=file:///user/vagrant/backups/En exécutant je m'attendais à ce que je ça me fasse un backup au format tar de /tmp dans /user/vagrant/backups/. La sortie standard termine par "[OK] remote repository my-remote on local repository my-local" ce qui a l'air d'être bon signe, mais mon dossier /user/vagrant/backups/ reste vide. Comment est-ce que je peux savoir si ça a marché, et où mes fichiers ont été copiés ?

Je suis allé un petit peu plus loin cette fois, ça avance ^^

J'ai l'impression que la doc du README ( https://github.com/d9pouces/Polyarchiv ) n'explique pas assez… J'ai essayé de corriger cela, est-ce mieux ?

Sinon, je ne comprends vraiment pas ton erreur, chez moi ça marche© (avec un terminal UTF-8), je vais tenter sur une Ubuntu toute neuve.

Merci encore pour ces retours !