Borg: Marquer les archives pour « pruneau » ?
Actuellement, borg prune ne peut restreindre les archives à élaguer que par un préfixe commun. Cela fonctionne pour les schémas de nommage où la partie "pertinente pour le pruneau" des noms d'archives est au premier plan, par exemple system-<hostname>-<date> et userdata-<hostname>-<date> , mais ne fonctionne vraiment pour rien d'autre.
L'ajout de balises, c'est-à-dire une liste de chaînes arbitraires (à l'exception de "," qui serait le séparateur de balises) aiderait. "prune" et d'autres commandes utilisant "--prefix" obtiendraient une option "--tags", et seules les archives qui ont _all_ (ou _any_, discussion) listées seraient affectées (et elles devraient être immuables pour cette raison).
EDIT : approche différente peut-être, pas de champs de métadonnées supplémentaires, applicable en amont .
Les noms sont déjà là. Nous pourrions simplement ajouter quelque chose comme --tags some,tags (utilisez toujours , comme délimiteur ici ?) et --tag-delim - (quel délimiteur par défaut ?).
tags = set(args.tags.split(args.tag_delim))
for archive in ...:
if set(archive.name.split(args.tag_delim)) <= tags:
... # prune
enkore
Tous les 5 commentaires
Mélanger les noms et les tags est impur. Les balises peuvent être des métadonnées d'archive distinctes.
ThomasWaldmann
le 6 avr. 2016
Bon point, mais je ne sais pas si ce n'est pas bien ici (en tant que décision de conception). #866 m'a fait penser "Hm, à quoi _est_ vraiment le nom de l'archive ?". Le "recycler" pour le taguer n'est pas une chose vraiment propre à faire, mais cela me semble assez pratique (si c'est un opt-in 100% explicite). D'une certaine manière, les « tags » seraient simplement une façon différente de regarder le champ « nom ».
enkore
le 9 avr. 2016
J'aimerais supprimer cette demande de fonctionnalité pour les balises/alias.
Après avoir passé tant de temps dans l'univers git, je me retrouve à souhaiter pouvoir appliquer des balises supplémentaires à des archives borg spécifiques.
L'intégration de balises dans le nom de l'archive est actuellement possible, mais c'est assez indiscipliné lorsque vous souhaitez utiliser plusieurs balises pour une archive. Par exemple, j'utilise déjà le nom de l'archive pour intégrer le nom d'hôte, l'horodatage et un ou deux autres champs. Je souhaite également ajouter des balises supplémentaires telles que "@latest" et "@release-1". Cela devient vite désordonné. Pire, j'ai parfois envie de déplacer une balise telle que @latest d'une archive à une autre.
Si vous utilisez simplement borg pour sauvegarder des fichiers (d'accord, sa mission d'origine), il n'y a probablement pas beaucoup besoin de balises. Mais si, comme moi, vous avez trouvé la déduplication de borg extrêmement utile dans d'autres situations, comme l'archivage de très gros fichiers utilisés dans un pipeline d'analyse de données :-) alors la possibilité d'attribuer plusieurs balises à une archive existante devient vraiment importante.
Actuellement, ma solution consiste à créer l'archive d'origine avec le schéma de nommage que j'ai conçu, puis à créer immédiatement plusieurs archives supplémentaires avec des noms commençant par "@" -- @latest , @v1.0, @beta2 , etc. Chacune de ces archives supplémentaires prend quelques minutes à analyser/créer, et n'ajoute que quelques centaines d'octets au référentiel puisque le contenu est complètement identique à l'archive d'origine. (Eh bien, tant que les fichiers n'ont pas changé au cours de ces quelques minutes.)
Ce serait vraiment bien d'éliminer ce ralentissement en ajoutant des métadonnées de balise.
J'imagine que l'interface utilisateur est quelque chose comme ceci :
Créez une nouvelle balise et pointez-la vers une archive existante :
borg tag [repo::archive-name] [tag1] [tag2] ...Répertoriez toutes les balises et les archives vers lesquelles elles pointent
borg tag --list [repo]La suppression de balises peut réutiliser la commande
borg deleteexistante ou peut également être une option de commande :
borg tag -d [repo] [tagname]
Merci d'avoir pensé à ça !
billyc
le 10 mars 2017
J'ai seulement commencé à essayer borg récemment, mais je voulais donner +1 à l'idée de marquage. Je peux voir un cas d'utilisation pertinent pour les sauvegardes dans lequel des balises sont utilisées pour définir sur lequel des multiples services cloud une archive est sauvegardée. J'imagine (sur la base d'autres discussions) que la sauvegarde dans le cloud se ferait très probablement via un outil séparé qui récupère les balises et, par exemple, gère la création d'un fichier *.tgz à télécharger. (Vous pouvez même ajouter une fréquence de sauvegarde en tant que balise détectable distincte, mais ce genre de chose relèverait de la portée de l'outil de sauvegarde plutôt que de borg lui-même.)
ChrisDowning
le 10 mars 2017
Voir le problème #2300 pour une possible implémentation de balise. Il s'agit actuellement plus de git tag que d'étiquettes Gmail - en d'autres termes, des alias supplémentaires peuvent exister pour une archive, mais ils doivent être uniques. Il n'est peut-être pas difficile de fusionner cette idée avec ce qui est discuté ici - les étiquettes appliquées à plusieurs archives.
billyc
le 14 mars 2017
Questions connexes
ThomasWaldmann
·
6Commentaires
auanasgheps
·
5Commentaires
ypid
·
6Commentaires
verygreen
·
4Commentaires
htho
·
5Commentaires
Commentaire le plus utile
J'aimerais supprimer cette demande de fonctionnalité pour les balises/alias.
Après avoir passé tant de temps dans l'univers git, je me retrouve à souhaiter pouvoir appliquer des balises supplémentaires à des archives borg spécifiques.
L'intégration de balises dans le nom de l'archive est actuellement possible, mais c'est assez indiscipliné lorsque vous souhaitez utiliser plusieurs balises pour une archive. Par exemple, j'utilise déjà le nom de l'archive pour intégrer le nom d'hôte, l'horodatage et un ou deux autres champs. Je souhaite également ajouter des balises supplémentaires telles que "@latest" et "@release-1". Cela devient vite désordonné. Pire, j'ai parfois envie de déplacer une balise telle que @latest d'une archive à une autre.
Si vous utilisez simplement borg pour sauvegarder des fichiers (d'accord, sa mission d'origine), il n'y a probablement pas beaucoup besoin de balises. Mais si, comme moi, vous avez trouvé la déduplication de borg extrêmement utile dans d'autres situations, comme l'archivage de très gros fichiers utilisés dans un pipeline d'analyse de données :-) alors la possibilité d'attribuer plusieurs balises à une archive existante devient vraiment importante.
Actuellement, ma solution consiste à créer l'archive d'origine avec le schéma de nommage que j'ai conçu, puis à créer immédiatement plusieurs archives supplémentaires avec des noms commençant par "@" -- @latest , @v1.0, @beta2 , etc. Chacune de ces archives supplémentaires prend quelques minutes à analyser/créer, et n'ajoute que quelques centaines d'octets au référentiel puisque le contenu est complètement identique à l'archive d'origine. (Eh bien, tant que les fichiers n'ont pas changé au cours de ces quelques minutes.)
Ce serait vraiment bien d'éliminer ce ralentissement en ajoutant des métadonnées de balise.
J'imagine que l'interface utilisateur est quelque chose comme ceci :
Créez une nouvelle balise et pointez-la vers une archive existante :
borg tag [repo::archive-name] [tag1] [tag2] ...Répertoriez toutes les balises et les archives vers lesquelles elles pointent
borg tag --list [repo]La suppression de balises peut réutiliser la commande
borg deleteexistante ou peut également être une option de commande :borg tag -d [repo] [tagname]Merci d'avoir pensé à ça !