Bonjour Erwann, merci de ta réponse. Le hic, c'est que j'ai le même problème avec une archive compressée. C'est étonnant non ? L'archive que je récupère par DropBox ( et tâche cron ) est bien compressée. Idem, j'ai testé via FTP, avec une archive compressée. En décompressant, j'ai un fichier utf8 non valide.
Pour le moment, seul la méthode de transfert en https semble avoir fonctionnée. C'est très embêtant. J'en ai profité pour réviser les alternatives de sauvegardes, pour Mediawiki : Sauvegarder Mediawiki : https://wiki.visionduweb.fr/index.php?title=Accueil_Utiliser_MediaWiki#Sauvegarder_la_base_de_donn.C3.A9es_de_MediaWiki Source : https://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki/fr La méthode avec mysqldump ou Automysqlbackup aboutit bien, et, comme dit, si je charge par https, le fichier est fonctionnel, mais, pas si je le récupère via une archive compressée sous DropBox ou FTP. C'est ce qu'il me faut, pour pouvoir continuer d'utiliser ma tâche cron pour exporter automatiquement ma sauvegarde. Le 14/10/2019 à 09:24, Erwann Le Bras a écrit : > > bonjour > > Il doit s'agir d'un pb d'encodage lors du transfert du fichier. > Le fichier de "dump" mysql est un fichier texte contenant des > commandes SQL pour regénérer la base complète si besoin. > Lors du transfert, le caractère "ascii" (texte) du fichier n'est pas > respecté et il est transféré en "binaire". > il en résulte une conversion unix/dos du fichier, en trop ou > manquante, ce qui fait que le fichier n'a pas les retours chariots. > > Veillez à transférer le fichier en forçant le caractère "ascii" dans > les paramètres FTP pour l'extension ".sql" > ou compressez votre sauvegarde avant transfert pour écarter tout pb > d'encodage. > > Erwann > > Le 13/10/2019 à 17:02, G2PC a écrit : >> >> Drôle de problème que je rencontre : >> >> J'ai une sauvegarde automatique vers DropBox, qui syncronise mes >> fichiers, via cron. >> Je test de rapatrier un des fichiers SQL, vers ma VM locale, l'import >> plante, et, lorsque j'ouvre le fichier.sql, cela me dit qu'il y a un >> problème d'encodage. >> >> Idem, j'exporte le fichier directement en sql, depuis le serveur, et, >> je le met dans le dossier de mon FTP, je charge sans soucis, >> j'importe ça plante, et, si je l'ouvre, même constat : un problème >> d'encodage ! >> >> >> La ou je suis rassuré, c'est que si je déplace le même fichier sql >> vers le répertoire de mon site, je peux charger le même fichier >> depuis https, et, la, pas de soucis, l'import se fera sur la VM, et, >> le fichier peut être ouvert également !!! >> >> En gros, mon fichier se voit, semble t'il, être détérioré, quand il >> est récupéré depuis dropbox ? Idem, quand il est récupéré depuis >> proFTPd ? :/ >> Mais, le même fichier est fonctionnel quand je le charge depuis https:// >> >> Je n'y comprend rien :s >> >> >> Seule remarque que je peux ajouter, ( les deux prochaines >> configurations sont également appliquées à ma VM ) >> J'ai récemment modifié mariadb pour utiliser la collation >> utf8mb4_unicode_ci par défaut au lieu de utf8mb4_general_ci >> J'ai également ajouté les lignes suivantes à la configuration de >> MariaDB : >> >> [mariadb-10.3] >> innodb_file_format = Barracuda >> innodb_file_per_table = 1 >> innodb_default_row_format = dynamic >> innodb_large_prefix = 1 >> >> Cela pourrait expliquer le problème de corruption de fichier lors de >> l'export / récupération ? ( Sauf que par https, le fichier n'est PAS >> corrompu. ) >> >> >> Du coup, je suis embêté, comment puis je faire pour m'assurer que ma >> sauvegarde automatique qui se fait sur DropBox puisse être >> fonctionnelle !? >>
