gratifiant > linux.debian.user.french

G2PC (13/10/2019, 17h10)
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 !?
Erwann Le Bras (14/10/2019, 09h30)
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 :
[..]
Daniel Caillibaud (14/10/2019, 14h00)
Le 14/10/19 à 11h33, G2PC <g2pc> a écrit :
> 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..


Dans ce cas comment est faite la compression ? Par qui ?
(si c'est une compression faite par un script php de mediawiki, y'a p'tet
un paramètre de charset qq part qui déconne).

Si tu récupères correctement ton dump.sql via https, c'est que cesource
est bon, et si tu trouves pas de moyen correct de le compresser sur le
serveur avant récupération, tu peux toujours lancer la compression dans ton
cron via une connexion ssh qui compresse sur le serveur (avec gzip ou
bzip2 ou zip), faudra "juste" autoriser sur le serveur la connexion ssh par
clé et la commande qui compresse.
Discussions similaires