Encore une question Borg…
Il y a 3 jours j’ai mis en place la solution BorgBackup… Donc actuellement j’ai 3 backup… Enfin 3 backup… j’ai:
auto_conf_11_04_21_00:00
auto_data_11_04_21_00:01
auto_borg_11_04_21_00:05
auto_nextcloud_11_04_21_00:08
auto_roundcube_11_04_21_00:12
auto_vpnclient_11_04_21_00:15
sur 3 jours…
Pour tester, j’ai voulu déclencher un “borg prune --keep-daily=15 …”
Seul problème, il ne m’a gardé que les 3 dernièrs “auto_vpnclient_XXXXXX”… (J’ai donc bien fait de faire un test!)
Une idée de comment faire un “borg prune”, sans killer toutes mes sauvegardes ??
Vu qu’il n’y a pas de réponse, j’ai un peu cherché, un jour il faudra bien que je nettoie mes archives aussi.
Alors, pour commencer, pour tester tu peux mettre comme arguments -v --list --dry-run
verbose, lister ce qu’il se passe, ne rien faire, juste simuler.
Ensuite, j’ai vu que si tu sauvegarde 15 applications, il considère chacune comme une sauvegarde, il ne sait pas que ce sont des choses différentes, et si tu demande d’en garder une par jour, ça en supprimera 14, et ça, on ne le veut pas !
Il y a du coup l’option --prefix='auto_nextcloud_' pour n’impacter que les sauvegardes liées à nextcloud.
Mais du coup, pour faire ça bien, il faudra faire un script qui commencera par faire un list, identifiera l’ensemble des préfix à utiliser, et finalement fera le prune pour chacun.
De mon côté, j’ai essayé ça : sudo borg prune -v --list --dry-run --keep-daily=7 --keep-weekly=4 --keep-monthly=-1 --prefix='auto_nextcloud_' /mnt/backup/borg/backup
De ce que je comprends, ça veut dire
1 par jour sur 7 jours
1 par semaine sur 4 semaines
1 par mois indéfiniment
à appliquer uniquement sur nextcloud
Mais du coup, il reste quand même le soucis de pouvoir automatiser le tout vu qu’il faut définir les applications une par une.
Lister les archives
Extraire ce qui ressemble à un prefix
Trier
Garder un de chaque
Générer une commande qui va bien
L’exécuter
Si quelqu’un qui s’y connaît un peu plus en script a un avis ou une solution pour améliorer ce bousin, je suis prenneur
(Et puis la, tel que c’est fait, ça va demander le mot de passe à chaque préfix, ça doit pouvoir s’améliorer via variable d’environnement)
Une autre solution plus propre serait sinon de modifier le fichier /etc/yunohost/hooks.d/backup_method/05-borg_app
Et de faire le prune dedans, car là on a accès au nom de l’application actuellement sauvegardée.
J’y vois cependant 2 problèmes :
Ce fichier est écrasé lors des mises à jour de l’application borg
Ça ne s’exécute que lors d’une nouvelle sauvegarde (une appli désinstallée ne sera jamais prune, ce qui est dommage)
C’est-une bonne idée cette ligne de code…
Pour le côté variable environnement, je crois que j’ai ce qu’il te faut:
export BORG_PASSPHRASE=“mot de passe borg”
J’utilise des scripts Borg et ‘prune’ pour gérer les versions depuis quasiment le début que j’utilise Yunohost si ça vous intéresse. Je m’étais basé sur les tutos trouvés sur ce forum avant que l’application était disponible. J’ai 3 scripts, un pour le système tous les jours, un pour les mails toutes les heures et un pour les applications 1 fois semaine. Comme je n’ai pas de serveur externe, je fais une copie sur mon PC perso en les synchronisant avec Nextcloud. Et comme ce PC est sur Gnu/Linux, je me suis fais des alias comme borglist pour lister, bormount pour monter, bortar pour créer une archive restaurable sur Yunohost, etc…
C’est un peu artisanal et tout en manuel sans passer par l’application, du coup il faudrait les adapter pour que ce soit automatique pour toutes les situations je pense. Mais bon, on peut en discuter en privé car ça risque d’être un peu confus le temps que je me remémore bien les scripts que j’ai mis en place il y à 2 ans… quitte à poster ici après.
Ce n’est pas un script, c’est simplement une commande que j’utilise en alias sur mon PC. Par exemple pour la sauvegarde de tous les jours qui est faite à minuit :
alias borgtar='borg export-tar borg_repo::sauvegarde_auto_du_$(date +%A-%d-%B-%Y) sauvegarde_auto_du_$(date +%A-%d-%B-%Y).tar'
pour l’archive de J-1:
alias borgtar-1='borg export-tar borg_repo::sauvegarde_auto_du_$(date --date="1 days ago" +%A-%d-%B-%Y) sauvegarde_auto_du_$(date --date="1 days ago" +%A-%d-%B-%Y).tar'
etc…
J’utilise un alias comme ça je n’ai pas besoin de retaper la commande en entier si j’en ai besoin et surtout je ne l’oublie pas! A vrai dire concernant l’export tar, j’ai eu rarement besoin de l’utiliser, et seule celle du jour a été suffisante.
Du coup je tape juste borgtar et je récupère l’archive à copier dans /home/yunohost.backup/archives du serveur.
Bien sûr, il faut adapter borg_repo à ton dépôt Borg et sauvegarde_auto_du_ à ton prefix (c’est le script qui le fait automatiquement)
Mais je suppose que tu connais déjà ces commandes, sinon comment fais-tu pour restaurer? A moins que la fonction de restauration existe dans l’application, je ne l’ai pas testée.
J’avais vu passer ça mais du coup je pense que ça ne marche pas, en tous cas chez moi le format n’est pas bon.
La ça demande comme préfix ${name}_20, ce qui pourrait aller si la date commençait par l’année sur 4 chiffres.
Mais chez moi (sauvegarde uniquement via l’app borg) ça ressemble plutôt à ça : auto_nextcloud_14_04_21_00:03 Wed, 2021-04-14 00:03:32 [f01992dca83a2c2c1234d434d3dbfbac827f435db3189ec4d930fce8b55f10b]
Je ne sais pas si on peut mettre un prefix avec une regex, ou si il faut mettre un séparateur particulier entre le prefix et la date, mais la, ça ne peut pas marcher (en tous cas pas chez moi)
C’est un peu risqué je trouve comme solution.
Je serai d’avis de juste garder le 1er prune et de virer les 2 autres, surtout celui qui vire tout ce qui a plus d’un an (j’ai des app que j’ai supprimées et que j’aimerai bien pouvoir restaurer, même dans quelques années).
Avec un point dans le README sur ce changement et une commande manuelle à passer pour ceux qui aimeraient faire un prune eux même des anciennes données.
(Ah et le commentaire sur wordpress peut être enlevé, et au passage ça s’applique à toutes les apps qui sont multiples, j’ai un borg__2 par exemple)
Y a encore des bugs…
Dans les commandes du type:
borg create “$repo::_${name}-${current_date}” ./ 2>&1 >/dev/null | log_with_timestamp
Le “2>&1 >/dev/null” ne fonctionne pas… Normalement il faut écrire “>/dev/null 2>&1”, dans cet ordre, si on veut que cela fonctionne!
Ben initialement et depuis le début l’app ne garde que les archives automatiques de moins de 12 mois. Certes depuis la nouvelle version parue il y a une semaine, ce prune ne fonctionnait plus, mais fondamentalement il fonctionnait jusque là.
Demander aux utilisateurs de faire eux même un prune des anciennes données en ligne de commande me semble risqué et compliqué (il faut savoir le faire + il faut pas faire de fausse manip). Combien vont rester avec des trés vieux backup dans le repo sans vraiment le vouloir ? Mais je t’accorde qu’il y a besoin de documentation, doc qui n’est plus à jour sur certains points.
Le premier borg prune ne s’applique pas à wordpress__2 si on met wordpress.
Le second prune s’applique, mais il y a --keep-within 2 month donc on garde toutes les versions depuis 2 mois, donc c’est moins gênant vis à vis du bug initial que la version d’il y a une semaine tentée de corriger: suppression de toutes les archives en “__X”.
Pour le 3ème prune, l’idée c’était de nettoyer le repo des trucs très vieux (qui peuvent être des essais). AU delà d’un an restaurer un backup yunohost peut créer un certains nombre de soucis (pas la même version de debian, helpers différents, …). Donc si on a les données, il faudra probablement bidouiller ou restaurer à la main.
Bien-sur… y a pas d’erreur!
Le but de la redirection vers /dev/null, c’est de ne pas afficher de messages… et notamment quand il y a un message d’erreur…
Donc, si je fais la redirection comme tu l’as fait… exemple:
$ cat FichierInexistant 2>&1 >/dev/null
cat: FichierInexistant: Aucun fichier ou dossier de ce type
$
Alors que si j’utilise la bonne méthode:
$ cat FichierInexistant >/dev/null 2>&1
$
Rien ne s’affiche… c’est normalement ce que l’on cherche à obtenir! Non ??
