64Fermer66
flankerLe 25/05/2016 à 23:43
Prenons un exemple : j'ai www.yaronet.com et ns.yaronet.com à sauvegarder.
Je veux les fichiers uploadés et les bases MySQL pour les deux sites : J'ai deux sites à sauvegarder, et deux systèmes de sauvegarde : je ne veux donc pas plus de 4 fichiers de conf' au total : deux .local (www.local et ns.local) et deux .remote (git.remote et tar-curl.remote) .

Pour chacun des deux sites, j'ai donc les opérations suivantes à effectuerLa collecte des données (A et D) ne doit se faire qu'une fois, on est d'accord pour mettre ça dans le fichier .local de chaque site, avec une section du fichier de conf pour décrire où je collecte et à quelle fréquence, et une section par source (MySQL, fichiers, Postgres…).

Actuellement on n'a que des couples (B, C) et (E, F), sans possibilité de choisir (B, F) ou (E, C) et le couple (B, C) est décrit dans un fichier git.remote, le couple (E, F) étant dans tar-curl.remote.

Si je comprends bien ce que tu veux dire, tu proposes de décrire B et E dans les fichiers www.local et ns.local, pour obtenir www-identite.local, www-targz.local, ns-identite.local, ns-targz.local. Seul C serait dans git.remote, et enfin seul F serait dans curl.remote. Ça double donc les fichiers de conf -> inacceptable.
L'autre possibilité pour découpler (B, C) et (E, F) est de ne garder que www.local et ns.local, et de décrire les étapes B et E dans chacun de ces deux fichiers. Mais comment C et F sauraient qu'ils ne doivent s'appliquer qu'à B et E respectivement ?



En revanche, une solution, peu coûteuse, serait de découper les .remote en deux sections : [format] et [transport].
Dans la section [format], qui serait optionnelle, on décrirait la transformation à appliquer aux fichiers avant de les envoyer (donc B et E).
Dans la section [transport], obligatoire, on décrirait la méthode d'envoi (donc C et F).