Comment fonctionne la sauvegarde akeeba pour les tâches cron
C'est simplement une question générale sur le fonctionnement du système de sauvegarde Akeeba lorsqu'il est appelé à partir d'un travail cron.
J'ai tracé le code autant que je le pouvais et j'ai compris qu'il est appelé depuis le serveur frontal, puis lance la sauvegarde depuis le serveur principal, puis redirige le navigateur vers la fonction d'étape qui vérifie l'emplacement de la sauvegarde.
Ma question est la suivante: comment la fonction step sait-elle où elle se trouve? Comment le serveur continue-t-il à traiter la sauvegarde lorsque le navigateur a été redirigé?
J'ai exploré le Web en essayant de trouver des informations sur la façon dont cela fonctionne réellement et n'en trouve aucune. toute retenue ou explication serait grandement appréciée.
Merci
Lee
Je suis le développeur de Akeeba Backup. Deux scripts CRON différents sont fournis avec Akeeba Backup Professional.
La méthode recommandée consiste à utiliser le script CRON natif qui contourne complètement le serveur Web et exécute le processus de sauvegarde essentiellement en tant qu'application en ligne de commande autonome PHP. Mais ce n'est pas l'objet de votre question.
La méthode de sauvegarde existante utilise en effet une URL spéciale. La première adresse URL lancée démarre une sauvegarde à l'aide d'un profil spécifique et l'enregistre dans la base de données sous un ID de sauvegarde spécifique. Certains travaux de sauvegarde sont exécutés. À ce stade, l'état du moteur de sauvegarde est sérialisé et validé pour le stockage temporaire. Une redirection HTTP est émise. Lorsque vous cliquez sur la nouvelle URL, l'état du moteur de sauvegarde est lu à partir du stockage temporaire, non sérialisé et le processus de sauvegarde reprend. Cette danse de sérialisation/redirection/désérialisation se poursuit jusqu'à la fin de la sauvegarde.
Tout d’abord, cela n’arrive pas vraiment en appelant le back-end de l’application. Les contrôleurs frontaux (sauvegarde à distance héritée) et back-end implémentent une stratégie similaire. La seule différence est que le serveur frontal émet des redirections HTTP alors que le serveur principal renvoie un objet JSON à traiter par le script Javascript côté client et à décider de l'exécution de la prochaine étape de sauvegarde. La sauce pas si secrète réside dans le moteur de sauvegarde lui-même, qui est stocké dans le répertoire principal du composant, je suppose que c'est ce que vous tentiez de tracer.
Deuxièmement, le plus important est de comprendre pourquoi cela fonctionne. En raison de la sérialisation/de la désérialisation, l'état du moteur de sauvegarde interne est préservé via la redirection. L'astuce est que le moteur de sauvegarde utilise un objet Factory avec une prise en charge de la sérialisation et de la désérialisation. J'ai blogué à ce sujet en octobre 2009 sur mon site, dionysopoulos.me. Recherchez sur Google "Un modèle d'usine sérialisable PHP5" sur mon site.
Cette usine sérialisable correspond exactement à la manière dont le moteur de sauvegarde sait où en est la sauvegarde à chaque fois que vous reprenez la sauvegarde lors du chargement d'une nouvelle page. Vous êtes invités à utiliser ce code sur vos projets mettant en œuvre un processus de longue durée.