Restauration Akeeba impossible

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • fredjouan
    a répondu
    Bonjour,
    Les backups programmés les dimanche et lundi se sont déroulés sans encombre.
    Un grand merci Robert pour ton aide, notamment sur la répartition des horaires de backups et le fonctionnement d'Akeeba.

    Laisser un commentaire:


  • fredjouan
    a répondu
    Je pense avoir compris. Les backups automatisés fonctionnent d'ailleurs bien maintenant que la restriction de l'open_basedir est désactivée.
    Pour un grand nombre de sites, les backups ne seront qu'hebdomadaires, je les ai donc répartis sur les jours de la semaine et à des horaires différents (lorsqu'il y en a plusieurs la mêmes nuit).
    Je vais donc patienter…

    Laisser un commentaire:


  • RobertG
    a répondu
    En fait, je crois que tu confonds l'erreur systématique d'Akeeba en cas d'open_basedir restreint au dossier du site et celle quand le dossier supplémentaire pour les sauvegardes est mal défini.

    Quand l'open_basedir n'est pas restreint, Akeeba est autorisé à accéder à n'importe quel dossier du serveur, donc pas d'erreur.
    Quand il est restreint au dossier du site, tu ne peux placer tes sauvegardes en dehors de ce dossier que s'il est dans un dossier autorisé en plus ("_backups"), mais comme Akeeba tente d'accéder au dossier non autorisé "monsite/.." (et qu'il n'a pas à utiliser, j'insiste) apparaît l'erreur. Il s'agit à mon avis d'une boucle mal définie sur les noms de dossiers.

    Laisser un commentaire:


  • fredjouan
    a répondu
    Bien sûr que toutes les configurations sont paramétrées pour obtenir un chemin de stockage de l'archive de type :
    /home/_backups/site/dossier
    Pour l'instant, les restrictions open_basedir ont été désactivées sur tous les sites (côté hébergeur) et les sauvegardes des sites que j'ai eu le temps de tester avec un backup manuel ont toutes fonctionné normalement et les archives des sites sauvegardés sont bien dans le dossier à la racine de l'hébergement.
    J'attends les backups automatisés pour vérifier que ça fonctionne.

    Laisser un commentaire:


  • RobertG
    a répondu
    Je veux dire qu'il n'y a strictement aucune raison pour qu'Akeeba aille chercher un dossier autre que celui du site sans que ça ait été nommément spécifié.

    Laisser un commentaire:


  • fredjouan
    a répondu
    Tu veux dire que même après désactivation de l'open_basedir, Akeeba ne trouvera pas le dossier en dehors du www ?
    Dernière édition par fredjouan à 20/07/2018, 13h21

    Laisser un commentaire:


  • RobertG
    a répondu
    La désactivation de l'open_basedir n'est pas forcément une bonne solution, car la sauvegarde Akeeba ne fait que signaler ces erreurs sans conséquences.

    Laisser un commentaire:


  • fredjouan
    a répondu
    Envoyé par RobertG Voir le message
    Attention Fred à ne pas lancer plusiuers sauvegardes à la même heure, le serveur pourrait ne pas aimer
    Ton problème avec "_backups" est strictement lié à l'open_basedir : dès qu'il est activé, Akeeba ne peut remonter d'un niveau, que tu aies ajouté ou non un dossier de niveau supérieur (sauf celui direct "site.tld" comme tu l'avais noté). C'est une erreur d'Akeeba, pas de tes paramétrages.
    Vérifie, mais ceux où tu n'as pas d'erreur Akeeba sont ceux où l'open_basedir n'est pas restreint.
    Bonjour Robert,
    J'ai pris bonne note de tes conseils :
    – Désactivation de la restriction de l'open–basedir chez PHPnet
    – Modification des horaires de backup (ils étaient tous à la même heure)
    Je verrai demain matin le résultat de ces modifications.



    Laisser un commentaire:


  • RobertG
    a répondu
    Attention Fred à ne pas lancer plusiuers sauvegardes à la même heure, le serveur pourrait ne pas aimer
    Ton problème avec "_backups" est strictement lié à l'open_basedir : dès qu'il est activé, Akeeba ne peut remonter d'un niveau, que tu aies ajouté ou non un dossier de niveau supérieur (sauf celui direct "site.tld" comme tu l'avais noté). C'est une erreur d'Akeeba, pas de tes paramétrages.
    Vérifie, mais ceux où tu n'as pas d'erreur Akeeba sont ceux où l'open_basedir n'est pas restreint.

    Edyy, à condition de disposer d'un autre hébergement qui le permet, c'est en effet très pratique lorsque certains hébergeurs n'ont pas une procédure simple pour ces tâches.

    Laisser un commentaire:


  • Eddy.vh
    a répondu
    Envoyé par Eddy.vh Voir le message

    On peut lancer un cron vers une url distante ? J'ai fait des tests infructueux depuis o2Switch… Je vais retenter pour voir, ça m'intéresserai, j'ai un site chez un hébergeur allemand qui ne propose pas la tâche cron…
    Cool.
    J'ai programmé une tâche avec l'URL Akeeba vers le site distant et BINGO, j'ai bien une sauvegarde… Merci Robert de m'avoir mis la puce à l'oreille.

    Laisser un commentaire:


  • fredjouan
    a répondu
    J'ai bien noté tes explications à propos de l'open_basedir et je t'en remercie, mais c'est quand même curieux qu'avec l'open_basedir activé et le dossier _backups mis en exception, ça marche sur certains sites et pas sur d'autres !!!
    Quant aux backups de cette nuit, ceux réglés à 01:00 ont bien fonctionné, mais pas ceux réglés à 02:00, donc je pense que c'est un problème de réseau….
    Je vois ça demain matin

    Laisser un commentaire:


  • RobertG
    a répondu
    Cette erreur, on en a déjà parlé, elle est liée à Akeeba qui cherche à remonter d'un niveau, ce qui est anormal à mon sens et interdite quand l'open_basedir est limité au dossier du site, qu'on y ajoute ou non un autre dossier, sauf bien sûr si on autorise "site.tld" comme dans ta citation, auquel cas l'open_basedir limité n'a pas d'intérêt.
    Si tu veux exclure ces erreurs, il faut que tu désactives la restriction open_basedir.

    Je n'ai actuellement pas chez PHPNET de site personnel en sauvegarde automatique pour vérifier sur une tâche planifiée, je vais en paramétrer pour vérifier, mais chez un client, même pack d'hébergement, j'ai bien eu une sauvegarde par cron cette nuit, sans erreur.

    Laisser un commentaire:


  • fredjouan
    a répondu
    Je me rends compte que tous les backups ont échoué cette nuit. Les sites, même petits, sont tronqués, avec une archive ftp sous un format J01 au lieu de JPA.
    Peut-être un problème du coté de PHPNET...

    Laisser un commentaire:


  • fredjouan
    a répondu
    Je viens de relancer une config automatique, le chemin /home/_backups/site/backups a été conservé,... mais toujours cette erreur lors du backup manuel

    Laisser un commentaire:


  • fredjouan
    a répondu
    Je vais relancer une config automatique

    Laisser un commentaire:

Annonce

Réduire
1 sur 2 < >

C'est [Réglé] et on n'en parle plus ?

A quoi ça sert ?
La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
Comment ajouter la mention [Réglé] à votre discussion ?
1 - Aller sur votre discussion et éditer votre premier message :


2 - Cliquer sur la liste déroulante Préfixe.

3 - Choisir le préfixe [Réglé].


4 - Et voilà… votre discussion est désormais identifiée comme réglée.

2 sur 2 < >

Assistance au forum - Outil de publication d'infos de votre site

Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

UTILISER À VOS PROPRES RISQUES :
L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

Problèmes connus :
FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

Installation :

1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

Archive zip : https://github.com/AFUJ/FPA/zipball/master

2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
et remplacer www. votresite .com par votre nom de domaine


Exemples:
Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
Télécharger le script fpa-fr.php dans: /public_html/
Pour executer le script: http://www..com/fpa-fr.php

Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
Télécharger le script fpa-fr.php dans: /public_html/cms/
Pour executer le script: http://www..com/cms/fpa-fr.php

En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
Voir plus
Voir moins

Partenaire de l'association

Réduire

Hébergeur Web PlanetHoster
Travaille ...
X