|
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 !?
|