[RÉGLÉ] Déclencher par code dans un plugin une sauvegarde Akeeba et attendre ?

[RobertG]

Bonjour,

Pour le plugin de purge que j'ai créé pour supprimer d'anciennes données d'Event Booking et surtout des fichiers joints, je voudrais lancer une sauvegarde Akeeba backup avant de démarrer la purge, mais je ne sais pas si, spontanément, le code attendra que la sauvegarde soit terminée, ni dans le cas contraire comment faire pour y arriver.

Le principe actuel est de vérifier si le moment de purger est arrivé, sinon, on sort, puis de récupérer les infos événements, inscrits et les fichiers qu'ils ont transmis pour les supprimer. Il me faudrait donc, avant cette récupération, déclencher une sauvegarde et ne pas aller plus loin tant qu'elle est en cours.

Les sauvegardes actuelles pèsent plus de 500 Mo, elles se réduiront drastiquement, je pense, une fois les anciens fichiers joints supprimés.

Merci de vos conseils !
Robert

[dolmenhir]

Tu peut tester la présence du fichier de sauvegarde via un "if file_exist()".
Lors de la sauvegarde, le fichier en cours de traitement a un nom temporaire et ce n'est qu'à la fin que le nom final est donné au fichier de sauvegarde.

[RobertG]

Cette méthode de test d'existence, je l'utilise déjà pour effacer le fichier trace du plugin.

Ce serait une solution pour boucler tant qu'on n'a pas celui de sauvegarde, mais on n'a pas son nom, et dans le cas présent, le fichier est transféré sur un serveur distant et supprimé de celui du site.
Il faut donc interroger la table des sauvegardes d'Akeeba pour s'assurer que la dernière date bien d'après l'heure de son lancement par le plugin (et pas seulement du jour actuel). Mais hélas, la ligne est ajoutée par Akeeba dès le lancement de la sauvegarde.
Il faudrait donc boucler jusqu'à ce que la dernière ligne ait dans le champ "status" la valeur "complete".

Il serait beaucoup plus simple que le code ne puisse continuer tant que l'ordre de lancement de la sauvegarde n'ait pas eu en retour une info attestant que celle-ci est terminée. Mais je n'ai pas trouvé comment le faire de manière simple en PHP.

En fait, ma question est double : si je lance la sauvegarde depuis le plugin, est-ce que le code qui suit va immédiatement s'exécuter ? Et si c'est le cas, comment puis-je de manière "propre" et simple attendre de savoir que c'est terminé ?

[RobertG]

Bonjour,

Je nage !
Je n'arrive même pas à déclencher la sauvegarde !!!
Le code :

 if ($bkp_url !="") {
$return = $this->backupSite($bkp_url);
if($return = false) {
fclose($LogFile);
return;
}

La fonction :

 function backupSite($value)
{
if (fopen($value,'r')) {
return true;
} else {
return false;
}
}

Alors que l'adresse est correcte et peut être ouverte directement dans le navigateur, la fonction renvoie "false" ! (je teste en local)

[lomart]

Bonjour Robert,

Quelle version de PHP ?

Tente avec ce test

if (!empty($bkp_url)) {

[RobertG]

Merci Loïc,

La version de PHP est 7.4, et $bkp_url a la bonne valeur, je l'ai vérifié en l'enregistrant dans le fichier trace.
Donc fopen utilise bien l'adresse que donne Akeeba backup et qui a été ajoutée dans le paramétrage du plugin.

[RobertG]

Logiquement, la fonction de sauvegarde eb_backupSite($value) devrait renvoyer true ou false, mais la valeur revient vide, la sauvegarde est bien lancée par Akeeba mais n'aboutit pas, il semble donc que que le code passe bien par cette fonction, mais l'ajout de ceci juste avant la ligne fopen n'ajoute pas les infos attendues dans le fichier trace

fputs($LogFile, 'url value : ' . $value . "\n" );

J'ai modifié la fonction ainsi, en ajoutant un sleep(180) pour voir si laisser le temps à la sauvegarde serait une solution. Le seule effet est de bloquer l'affichage de la page qui déclenche le plugin pendant une trentaine de secondes.

 function eb_backupSite($value)
{
fputs($LogFile, 'url value : ' . $value . "\n" );
if (fopen($value,'r')) {
sleep(180);
return true;
} else {
return false;
}
}

Dans la table Akeeba, le dernier backup conserve un statut "run" tant qu'un autre n'est pas lancé, et il passe alors à "fail". La sauvegarde manuelle complète pèse un peu plus de 540 Mo, les sauvegardes automatisées s'arrêtent à environ 54 Mo.
J'ai défini un découpage des sauvegardes à 100 Mo, augmenté memory_limit à 1 Go, et le dernier fichier, j01, pèse 60 Mo !

[RobertG]

Bonjour,

Malgré tous mes essais, rien à faire, la sauvegarde n'aboutit pas. Pire, j'ai créé un profil n'embarquant que la base de données et le dossier des pièces jointes, pour alléger un peu, mais ce matin, la sauvegarde ne se lance même plus !

Pensez-vous que lancer deux tâches cron successives, la sauvegarde Akeeba puis celle de la purge 5 minutes plus tard, serait la solution ? sachant que sur les serveurs mutualisés, j'ai souvent constaté des décalages entre l'heure définie et celle du lancement de la tâche.

[dolmenhir]

Robert,
Et si tu faisais les choses autrement.
Tu utilises les tâches Cron, exemple :

1. tu lances ta sauvegarde Akeeba à 00:00
2. tu lances la purge à 00:30

Et tu peux programmer la sauvegarde et la purge plusieurs fois par jour, par semaine, par mois...

Et dans ton script de purge, tu peux vérifier que la sauvegarde est bien là, puisque là tu connais le nom (tu peux créer un profil Akkeba avec un nom de fichier explicite + un "quota count" pour ne garder qu'un seul exemplaire de cette sauvegarde (chaque sauvegarde supprime la précédente avant de lancer le nouveau process).
Avec le "file_exist", la classe "SplFileInfo" te permettra même de vérifier l'heure de cette sauvegarde.

Le script de purge se lançant à une heure fixe, toujours après la sauvegarde, + le "file_exist", tu réduis drastiquement les risques d'avoir un problème.

En plus, rien de t'interdit d'avoir un autre profil de sauvegarde Akeeba, pour une sauvegarde "classique" qui, elle, se sera pas supprimée par le lancement de ta sauvegarde "spéciale purge".

... j'ai été assez clair ? j'ai pas encore pris mon café...

[RobertG]

Merci !

Tu es très clair !

Disons que pour moi, réussir à le faire avec le plugin aurait l'avantage de la simplicité en cas de besoin de modifications de certains paramètres, plus facile en ouvrant la page du plugin qu'en se connectant au serveur en passant éventuellement par la gestion du compte client chez l'hébergeur (ce n'est pas le cas ici, chez PlanetHoster où je peux accéder directement au cPanel).

A l'inverse, utiliser des tâches cron permet de les lancer à date et heure précises, hors des moments où le site est habituellement visité.

[dolmenhir]

Et si tu lances le script de sauvegarde d'akeeba depuis ton plugin, en utilisant l'url du cron liée au profil Akeeba spécialement créé, ce qui te permet de connaître le nom exact du fichier de sauvegarde ?
Toujours grâce au file_exist tu ne lances la purge que quand la sauvegarde est terminée (file_exist="true").
Le problème, c'est que tant que le file_exist renvoie "false", ton script devra boucler pour t'assurer de lancer la purge une fois la sauvegarde terminée.
Et le boucler pendant 5 minutes, ça risque de poser un sérieux problème, dans la mesure où le code du plugin s'exécute.

A moins que cette fonction de purge ne se lance que via un bouton dans les paramètres du plugin qui ne s'active que si la sauvegarde est terminée.
Donc en fait, faudrait avoir 2 boutons :
1 pour lancer la sauvegarde et un 2nd pour lancer la purge.
Le second bouton ne s'active qu'une fois la sauvegarde terminée, grâce à un petit script en ajax qui "check" si la sauvegarde est faite et alors rend le 2nd bouton opérationnel.

Mais qui aura la patience d'attendre 5mn devant son écran, sous réserve que la sauvegarde ne prenne que 5mn... ?

Sinon tu utilises un simple "switch" via le plugin qui, je présume, se déclenche à chaque passage d'un utilisateur sur une page du composant Event Booking.
Si la sauvegarde n'est pas là, tu la lances.
Si elle est là, tu lances la purge et tu efface la sauvegarde pour réactive le switch.

[dolmenhir]

En me relisant, je me dis que le switch risque de lancer de nombreuses sauvegardes et purge.
Donc faut que ton script de purge génère aussi un fichier pour savoir de quand date la dernière purge pour éviter qu'elles ne se succèdent trop (à moins que tu check le volume à purger et ne fais la purge que si le volume est important...)

[RobertG]

Le problème depuis le plugin est que la tâche de sauvegarde échoue et ne me renvoie ni vrai ni faux, dans la fonction eb_backupSite(), et le code de purge s'exécute. C'est pour ça que j'ai tenté d'utiliser sleep(180), mais ça n'a rien changé, la sauvegarde s'arrête.
Si elle fonctionnait, il me suffirait d'une boucle sur la dernière ligne de la table des backups pour savoir si le champ "status" est à "complete", ce qui veut dire que la sauvegarde est terminée (run pour sauvegarde en cours, et fail en cas d'échec).

Actuellement, avec le nombre de fichiers non supprimés depuis le début du fonctionnement d'Event Booking sur ce site, les sauvegardes pèsent 540 Mo environ, et sans aucun fichier joint, on descend à 100 Mo environ, et quand ça se déclenche avec le plugin, il n'y a qu'un peu plus de 50 Mo avant l'arrêt (et pas de log Akeeba).
Chez PlanetHoster, en sauvegarde manuelle complète, le temps de traitement varie de 3 à un peu plus de 5 minutes. C'est long !

Actuellement, le fonctionnement du plugin est déclenché par l'affichage en frontend d'un événement (onEventDisplay) : récupération des paramètres du plugin, vérification de la date de la dernière exécution et si le délai entre deux exécutions n'est pas atteint, on abandonne. Sinon, on inscrit la nouvelle date et on lance la purge : la liste des utilisateurs dans la table des événements antérieurs à une date fixée, récupération du n° de champ dans lequel les noms des fichiers à supprimer sont enregistrés, puis boucle (lecture des données des champs personnalisés de l'inscrit, suppression du fichier de l'inscrit, suppression de tous les champs personnalisés de l'inscrit, suppression de l'inscrit) et enfin suppression des événements.
A priori, il n'y a pas de risque d'erreur et d'effacement de données plus récentes que les 14 ou 21 jours antérieurs à la date du jour, donc on pourrait oublier la sauvegarde, d'autant qu'on a une sauvegarde complète hebdomadaire du site, journalière de la base et que les fichiers joints sont aussi reçus par mail... Mais je préfèrerais par prudence avoir cette sauvegarde (au moins les fichiers en question et les tables Event Booking) juste avant la purge.

Donc ce qu'il faut, c'est que j'arrive avec deux tâches cron lancées dans la nuit tous les x jours faire une sauvegarde puis quelques minutes plus tard la purge.
Mais si je comprends bien, je ne pourrai pas utiliser pour la purge les fonctionnalités d'accès à la base qu'offre Joomla!, mais un accès classique, est-ce que je me trompe ?

[RobertG]

En me relisant, je me dis que le switch risque de lancer de nombreuses sauvegardes et purge.
Donc faut que ton script de purge génère aussi un fichier pour savoir de quand date la dernière purge pour éviter qu'elles ne se succèdent trop (à moins que tu check le volume à purger et ne fais la purge que si le volume est important...)

En fait, comme je le dis ci-dessus, la purge ne se déclenche que selon un délai défini : toutes les 2, 3 ou 4 semaines (pas encore décidé, mais probablement 2), ma date de la dernière étant inscrite dans les paramétrages du plugin à chaque exécution complète.

[RobertG]

Bonjour,

N'ayant toujours pas trouvé comment obtenir que la sauvegarde aboutisse ( l'instant, sur le site de production, une sauvegarde par tâche cron "wget" a pris plus de 6 minutes pour 565 Mo), j'ai créé un script à lancer par tâche cron quelques instants après la tâche cron de sauvegarde, qui d'une part nettoie les événements et leurs données liées, d'autre part permet de supprimer les inscrits orphelins, dont les événements ont été effacés, mais aussi les fichiers orphelins (ceux qui notamment pourraient avoir été envoyés depuis le formulaire d'inscription sans que ce dernier soit finalement validé).
Il me reste à optimiser ce script et à choisir entre lui et le plugin débarrassé de son rôle de déclencheur de sauvegarde (il pourrait se contenter de s'assurer qu'une sauvegarde a été effectuée quelques heures plus tôt). A débattre avec ma cliente.