Backup before upgrade

Contribute Room Apps packaging
,
1

Une proposition, née d’une initiative de Scith avec rainloop, qui vise à faire un backup de l’application au début de l’upgrade afin d’éviter de casser l’app en cas d’échec de l’upgrade.
Si le script d’upgrade échoue, l’app est supprimée et le backup restaure l’app telle qu’elle était avant l’upgrade.

Ce mécanisme apporte une sécurité de l’upgrade en restaurant l’app dans son état précédent l’upgrade en cas d’échec de l’upgrade.
MAIS ! Il comporte plusieurs limitations

  • Le script backup ne doit pas produire d’erreur, sinon l’upgrade est annulé.
  • Le script restore doit ABSOLUMENT être parfaitement fonctionnel. Au risque de voir l’app supprimée et pas restaurée correctement.
  • Cela produit un backup par app, donc il y une consommation d’espace disque à considérer.

Pour en simplifier l’usage, j’ai réunis l’ensemble dans 2 helpers.
BACKUP_BEFORE_UPGRADE qui créer un backup différent du précédent, pour ne pas détruire le précédent backup en cas d’échec du nouveau.
Après le backup, la gestion de l’échec de l’upgrade est confié à ynh_abort_if_errors, qui lui même intègre la fonction optionnelle ynh_clean_setup, qui sera utilisée ici pour déclencher la restauration avec la fonction BACKUP_FAIL_UPGRADE

Au final, dans le script upgrade l’ensemble tiens sur 5 lignes

BACKUP_BEFORE_UPGRADE
ynh_clean_setup () {
    BACKUP_FAIL_UPGRADE
}
ynh_abort_if_errors

La question qui se pose ici est, doit-on généraliser cette pratique à l’ensemble des packages et pousser cet usage?

2 Likes
2

Le soucis c’est pour les apps avec beaucoup de données.
Pour les apps légères c’est pas un problème. On devrait même à mon avis intégrer ça dans la cli yunohost directement (comme on le fait pour déclencher un remove en cas d’erreur sur l’install)

3

Oui c’est un problème et je pense que ces apps devraient permettre, indépendamment de ce mécanisme, de ne pas faire un backup des données si l’utilisateur le souhaite.
Comme je l’ai fait pour Nextcloud.

Car si là c’est un problème dans ce cas, se peux aussi en être un pour un backup normal avec une app qui aurait plusieurs Go de données.

Je n’en suis pas convaincu dans la mesure où ce mécanisme implique d’avoir un script de restore parfaitement fonctionnel. Or, la cli ignore cela.

4

Il semble compliqué de généraliser/automatiser cette pratique à l’ensemble des packages, mais il me semble très intéressant et important de la pousser via les helpers et les applications d’exemple/modèle ! :thumbsup:

P.S. : Il faudrait modifier les liens dans le premier post pour référencer un commit “absolu”, car les lignes pointées ne correspondent plus :wink:

5

Oui c’était juste ça l’idée qui se cachait derrière ma question. D’encourager son usage.
Car comme je le disais précédemment, il faut l’utiliser seulement si le script restore fonctionne correctement. Donc surtout pas l’automatiser.

6

On this topic, do you see a way to make an error happen during upgrade (from outside the package), to automate testing that case in package_check?

Important note: you forgot one important line in your sample, the first one! :wink:

BACKUP_BEFORE_UPGRADE # Backup the current version of the app

7

You’re damn right. It’s fixed now.

And, no, for the moment I not handled this case in package check.
But, it’s possible simply by adding an exit 1 at the end of the upgrade script.