Sauvegarde incomplète de la base ?

Général
1

Bonjour à tous,

Depuis quelques mois, peut-être même depuis SPIP 3, je suis confronté à un phénomène étrange :

Lors des sauvegardes de la base et alors que la case « Sauvegarder toutes les tables » est bien cochée et qu’il n’y a aucun message d’erreur en cours de sauvegarde,
à la restauration, j’ai le message d’erreur suivant qui s’affiche :

  • Table spip_mots, données manquantes
  • Table spip_auteurs, données manquantes
    Bizarrement, aussi, ce problème semble inexistant en local sous MAMP.

C’est vraiment contraignant, car, pour « rapatrier » la dernière version de la base vers la version de sauvegarde et de dev en local, je suis obligé de passer par phpmyadmin et la sauvegarde SQL.

J’aurais besoin de piste pour diagnostiquer ce qui provoque cette sauvegarde incomplète chez l’hébergeur et poser les bonnes questions à leurs techniciens.

Merci d’avance,

Hervé Le Dantec / Fennec72
herve.ledantec@gmail.com

2

Bonjour J

Je pense que cela ressemble au bug que j’ai signaler ici :

http://core.spip.org/issues/3164

Par contre, il serait bon de savoir la version de php que tu as ?

Savoir si avant tu étais, sous spip 2.1 ou 2.0 ou alors tu as fait le site directement en spip 3.0 ?

Si la première fois que tu as installer le site, tu avais choisi un prefix de table « particulier » ou alors si tu avais laisser celui natif (spip_xxx) ?

Cordialement

De : Hervé Le Dantec [mailto:herve.ledantec@gmail.com]
Envoyé : vendredi 14 février 2014 09:06
À : spip rezo rezo
Objet : [Spip] Sauvegarde incomplète de la base ?

Bonjour à tous,

Depuis quelques mois, peut-être même depuis SPIP 3, je suis confronté à un phénomène étrange :

Lors des sauvegardes de la base et alors que la case « Sauvegarder toutes les tables » est bien cochée et qu’il n’y a aucun message d’erreur en cours de sauvegarde,

à la restauration, j’ai le message d’erreur suivant qui s’affiche :

  • Table spip_mots, données manquantes
  • Table spip_auteurs, données manquantes

Bizarrement, aussi, ce problème semble inexistant en local sous MAMP.

C’est vraiment contraignant, car, pour « rapatrier » la dernière version de la base vers la version de sauvegarde et de dev en local, je suis obligé de passer par phpmyadmin et la sauvegarde SQL.

J’aurais besoin de piste pour diagnostiquer ce qui provoque cette sauvegarde incomplète chez l’hébergeur et poser les bonnes questions à leurs techniciens.

Merci d’avance,

Hervé Le Dantec / Fennec72

herve.ledantec@gmail.com

3

Bonjour J

Je pense que cela ressemble au bug que j’ai signaler ici :

http://core.spip.org/issues/3164

Par contre, il serait bon de savoir la version de php que tu as ?

Savoir si avant tu étais, sous spip 2.1 ou 2.0 ou alors tu as fait le site directement en spip 3.0 ?

Si la première fois que tu as installer le site, tu avais choisi un prefix de table « particulier » ou alors si tu avais laisser celui natif (spip_xxx) ?

Cordialement

4

Je suis heureux de voir que je ne suis pas le seul!

Par contre, ça n'explique toujours pas d'où ça vient et comment le régler.

Envoyé de mon iPhone

Le 14 févr. 2014 à 14:11, Zapilou <csi@zapilou.com> a écrit :

Bonjour,

Je cite ci-dessous mon propre message à cette liste sans réponse. Donc
pour ma part, je vote "bug" et non pas pbm d'hébergement.

Bonjour,

Je viens de transférer une installation spip d’un hébergeur à un autre
en me faisant une petite frayeur …

Il s’avère que chez l’ancien hébergeur on avait, suite au travail d’un
hacker (le site était en 1.8 … et géré par personne), mis un préfixe de
base particulier histoire de ne pas faciliter le travail des méchants.
J’avais oublié ce fait lors du transfert et donc j’ai créé la nouvelle
base avec le prefixe standard « spip" et là je me suis rendu compte que
quelque chose n’allait pas … mais sur le moment j’ai pensé que c’était
juste le fait que les préfixes étaient différents.

Bref, j’ai refait l’installation destinataire avec le bon prefixe … mais
je me suis aperçu que ça n’allait toujours pas: sauvegarde et
restauration semblait ok sauf par ex pour les articles (0/33), les
rubriques (0/14), … J’ai fait plusieurs tests avant de me rendre compte
qu’en fait la restauration marche, c’est la sauvegarde qui ne semble pas
bien se faire avec ce prefixe spécial.

Pour régler le pbm, je suis finalement passé par phpMyAdmin , mais j’ai
l’impression que la sauvegarde SQLite ne marche pas avec des prefixes
spécifiques ...

--
Pierre.

Le 14/02/2014 09:06, Hervé Le Dantec a écrit :

Bonjour à tous,

*Depuis quelques mois, peut-être même depuis SPIP 3, je suis confronté à
un phénomène étrange :*

Lors des sauvegardes de la base et alors que la case « Sauvegarder
toutes les tables » est bien cochée et qu’il n’y a aucun
message d’erreur en cours de sauvegarde,
à la restauration, j’ai le message d’erreur suivant qui s’affiche :

* Table *spip_mots*, données manquantes
* Table *spip_auteurs*, données manquantes

Bizarrement, aussi, ce problème semble inexistant en local sous MAMP.

C’est vraiment contraignant, car, pour « rapatrier » la dernière version
de la base vers la version de sauvegarde et de dev en local, je suis
obligé de passer par phpmyadmin et la sauvegarde SQL.

*J’aurais besoin de piste pour diagnostiquer ce qui provoque cette
sauvegarde incomplète chez l’hébergeur et poser les bonnes questions à
leurs techniciens.*

Merci d’avance,

Hervé Le Dantec / Fennec72
herve.ledantec@gmail.com <mailto:herve.ledantec@gmail.com>

--
Pierre

5

Bonjour,

Ahah, j'en rajoute car cela fait longtemps (mois, 1 année ?) que j'ai aussi ce problème de non-récupération de tables lors des sauvegardes SPIP puis réinjection en local.

Et je viens justement ce soir d'avoir ce problème avec la table spip_documents qui ne s'est pas sauvegardée.

Mais sur d'autres sites c'est la table spip_documents_liens, (et sans doute d'autres mais je n'ai pas tout noté) qui foiraient.

Mes tables ne sont pas préfixées et le site du jour date d'au moins SPIP 1.9 mais il est maintenant en SPIP 3

De toute façon maintenant je fais systématiquement mes sauvegardes via phpmyadmin ce qui évite aussi les problèmes d'UTF-8 dans le cas de sqlite.

dd

Le 14/02/2014 14:16, Hervé Le Dantec a écrit :

Je suis heureux de voir que je ne suis pas le seul!

Par contre, ça n'explique toujours pas d'où ça vient et comment le régler.

Envoyé de mon iPhone

Le 14 févr. 2014 à 14:11, Zapilou <csi@zapilou.com> a écrit :

Bonjour,

Je cite ci-dessous mon propre message à cette liste sans réponse. Donc
pour ma part, je vote "bug" et non pas pbm d'hébergement.

Bonjour,

Je viens de transférer une installation spip d’un hébergeur à un autre
en me faisant une petite frayeur …

Il s’avère que chez l’ancien hébergeur on avait, suite au travail d’un
hacker (le site était en 1.8 … et géré par personne), mis un préfixe de
base particulier histoire de ne pas faciliter le travail des méchants.
J’avais oublié ce fait lors du transfert et donc j’ai créé la nouvelle
base avec le prefixe standard « spip" et là je me suis rendu compte que
quelque chose n’allait pas … mais sur le moment j’ai pensé que c’était
juste le fait que les préfixes étaient différents.

Bref, j’ai refait l’installation destinataire avec le bon prefixe … mais
je me suis aperçu que ça n’allait toujours pas: sauvegarde et
restauration semblait ok sauf par ex pour les articles (0/33), les
rubriques (0/14), … J’ai fait plusieurs tests avant de me rendre compte
qu’en fait la restauration marche, c’est la sauvegarde qui ne semble pas
bien se faire avec ce prefixe spécial.

Pour régler le pbm, je suis finalement passé par phpMyAdmin , mais j’ai
l’impression que la sauvegarde SQLite ne marche pas avec des prefixes
spécifiques ...

--
Pierre.

Le 14/02/2014 09:06, Hervé Le Dantec a écrit :

Bonjour à tous,

*Depuis quelques mois, peut-être même depuis SPIP 3, je suis confronté à
un phénomène étrange :*

Lors des sauvegardes de la base et alors que la case « Sauvegarder
toutes les tables » est bien cochée et qu’il n’y a aucun
message d’erreur en cours de sauvegarde,
à la restauration, j’ai le message d’erreur suivant qui s’affiche :

  * Table *spip_mots*, données manquantes
  * Table *spip_auteurs*, données manquantes

Bizarrement, aussi, ce problème semble inexistant en local sous MAMP.

C’est vraiment contraignant, car, pour « rapatrier » la dernière version
de la base vers la version de sauvegarde et de dev en local, je suis
obligé de passer par phpmyadmin et la sauvegarde SQL.

*J’aurais besoin de piste pour diagnostiquer ce qui provoque cette
sauvegarde incomplète chez l’hébergeur et poser les bonnes questions à
leurs techniciens.*

Merci d’avance,

Hervé Le Dantec / Fennec72
herve.ledantec@gmail.com <mailto:herve.ledantec@gmail.com>

--
Pierre

_______________________________________________

6

Je confirme qu'une fois les tables au préfix personnalisé transférées sur une autre base de mon serveur dédié et le préfix repassé à spip_xxx, tout est rentré dans l'ordre.

Il y a donc un problème lorsque le préfix de table est personnalisé, problème qui n'existait pas, à ma connaissance avant la version 3 de Spip.

Hervé

Envoyé de mon iPad

Le 15 févr. 2014 à 01:57, dd <lemotjuste@free.fr> a écrit :

Bonjour,

Ahah, j'en rajoute car cela fait longtemps (mois, 1 année ?) que j'ai aussi ce problème de non-récupération de tables lors des sauvegardes SPIP puis réinjection en local.

Et je viens justement ce soir d'avoir ce problème avec la table spip_documents qui ne s'est pas sauvegardée.

Mais sur d'autres sites c'est la table spip_documents_liens, (et sans doute d'autres mais je n'ai pas tout noté) qui foiraient.

Mes tables ne sont pas préfixées et le site du jour date d'au moins SPIP 1.9 mais il est maintenant en SPIP 3

De toute façon maintenant je fais systématiquement mes sauvegardes via phpmyadmin ce qui évite aussi les problèmes d'UTF-8 dans le cas de sqlite.

dd

Le 14/02/2014 14:16, Hervé Le Dantec a écrit :

Je suis heureux de voir que je ne suis pas le seul!

Par contre, ça n'explique toujours pas d'où ça vient et comment le régler.

Envoyé de mon iPhone

Le 14 févr. 2014 à 14:11, Zapilou <csi@zapilou.com> a écrit :

Bonjour,

Je cite ci-dessous mon propre message à cette liste sans réponse. Donc
pour ma part, je vote "bug" et non pas pbm d'hébergement.

Bonjour,

Je viens de transférer une installation spip d’un hébergeur à un autre
en me faisant une petite frayeur …

Il s’avère que chez l’ancien hébergeur on avait, suite au travail d’un
hacker (le site était en 1.8 … et géré par personne), mis un préfixe de
base particulier histoire de ne pas faciliter le travail des méchants.
J’avais oublié ce fait lors du transfert et donc j’ai créé la nouvelle
base avec le prefixe standard « spip" et là je me suis rendu compte que
quelque chose n’allait pas … mais sur le moment j’ai pensé que c’était
juste le fait que les préfixes étaient différents.

Bref, j’ai refait l’installation destinataire avec le bon prefixe … mais
je me suis aperçu que ça n’allait toujours pas: sauvegarde et
restauration semblait ok sauf par ex pour les articles (0/33), les
rubriques (0/14), … J’ai fait plusieurs tests avant de me rendre compte
qu’en fait la restauration marche, c’est la sauvegarde qui ne semble pas
bien se faire avec ce prefixe spécial.

Pour régler le pbm, je suis finalement passé par phpMyAdmin , mais j’ai
l’impression que la sauvegarde SQLite ne marche pas avec des prefixes
spécifiques ...

--
Pierre.

Le 14/02/2014 09:06, Hervé Le Dantec a écrit :

Bonjour à tous,

*Depuis quelques mois, peut-être même depuis SPIP 3, je suis confronté à
un phénomène étrange :*

Lors des sauvegardes de la base et alors que la case « Sauvegarder
toutes les tables » est bien cochée et qu’il n’y a aucun
message d’erreur en cours de sauvegarde,
à la restauration, j’ai le message d’erreur suivant qui s’affiche :

* Table *spip_mots*, données manquantes
* Table *spip_auteurs*, données manquantes

Bizarrement, aussi, ce problème semble inexistant en local sous MAMP.

C’est vraiment contraignant, car, pour « rapatrier » la dernière version
de la base vers la version de sauvegarde et de dev en local, je suis
obligé de passer par phpmyadmin et la sauvegarde SQL.

*J’aurais besoin de piste pour diagnostiquer ce qui provoque cette
sauvegarde incomplète chez l’hébergeur et poser les bonnes questions à
leurs techniciens.*

Merci d’avance,

Hervé Le Dantec / Fennec72
herve.ledantec@gmail.com <mailto:herve.ledantec@gmail.com>

--
Pierre

_______________________________________________

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Discuter chez rezo.net

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

7

Bsr,

C'est quand même un réel problème, cela veut dire qu'on ne peut pas
utiliser de prefixes spéciaux, pas plusieurs spip sur une seule base ...

Le 15/02/2014 14:08, Hervé Le Dantec a écrit :

Je confirme qu'une fois les tables au préfix personnalisé transférées sur une autre base de mon serveur dédié et le préfix repassé à spip_xxx, tout est rentré dans l'ordre.

Il y a donc un problème lorsque le préfix de table est personnalisé, problème qui n'existait pas, à ma connaissance avant la version 3 de Spip.

Hervé

Envoyé de mon iPad

Le 15 févr. 2014 à 01:57, dd <lemotjuste@free.fr> a écrit :

Bonjour,

Ahah, j'en rajoute car cela fait longtemps (mois, 1 année ?) que j'ai aussi ce problème de non-récupération de tables lors des sauvegardes SPIP puis réinjection en local.

Et je viens justement ce soir d'avoir ce problème avec la table spip_documents qui ne s'est pas sauvegardée.

Mais sur d'autres sites c'est la table spip_documents_liens, (et sans doute d'autres mais je n'ai pas tout noté) qui foiraient.

Mes tables ne sont pas préfixées et le site du jour date d'au moins SPIP 1.9 mais il est maintenant en SPIP 3

De toute façon maintenant je fais systématiquement mes sauvegardes via phpmyadmin ce qui évite aussi les problèmes d'UTF-8 dans le cas de sqlite.

dd

Le 14/02/2014 14:16, Hervé Le Dantec a écrit :

Je suis heureux de voir que je ne suis pas le seul!

Par contre, ça n'explique toujours pas d'où ça vient et comment le régler.

Envoyé de mon iPhone

Le 14 févr. 2014 à 14:11, Zapilou <csi@zapilou.com> a écrit :

Bonjour,

Je cite ci-dessous mon propre message à cette liste sans réponse. Donc
pour ma part, je vote "bug" et non pas pbm d'hébergement.

Bonjour,

Je viens de transférer une installation spip d’un hébergeur à un autre
en me faisant une petite frayeur …

Il s’avère que chez l’ancien hébergeur on avait, suite au travail d’un
hacker (le site était en 1.8 … et géré par personne), mis un préfixe de
base particulier histoire de ne pas faciliter le travail des méchants.
J’avais oublié ce fait lors du transfert et donc j’ai créé la nouvelle
base avec le prefixe standard « spip" et là je me suis rendu compte que
quelque chose n’allait pas … mais sur le moment j’ai pensé que c’était
juste le fait que les préfixes étaient différents.

Bref, j’ai refait l’installation destinataire avec le bon prefixe … mais
je me suis aperçu que ça n’allait toujours pas: sauvegarde et
restauration semblait ok sauf par ex pour les articles (0/33), les
rubriques (0/14), … J’ai fait plusieurs tests avant de me rendre compte
qu’en fait la restauration marche, c’est la sauvegarde qui ne semble pas
bien se faire avec ce prefixe spécial.

Pour régler le pbm, je suis finalement passé par phpMyAdmin , mais j’ai
l’impression que la sauvegarde SQLite ne marche pas avec des prefixes
spécifiques ...

--
Pierre.

Le 14/02/2014 09:06, Hervé Le Dantec a écrit :

Bonjour à tous,

*Depuis quelques mois, peut-être même depuis SPIP 3, je suis confronté à
un phénomène étrange :*

Lors des sauvegardes de la base et alors que la case « Sauvegarder
toutes les tables » est bien cochée et qu’il n’y a aucun
message d’erreur en cours de sauvegarde,
à la restauration, j’ai le message d’erreur suivant qui s’affiche :

* Table *spip_mots*, données manquantes
* Table *spip_auteurs*, données manquantes

Bizarrement, aussi, ce problème semble inexistant en local sous MAMP.

C’est vraiment contraignant, car, pour « rapatrier » la dernière version
de la base vers la version de sauvegarde et de dev en local, je suis
obligé de passer par phpmyadmin et la sauvegarde SQL.

*J’aurais besoin de piste pour diagnostiquer ce qui provoque cette
sauvegarde incomplète chez l’hébergeur et poser les bonnes questions à
leurs techniciens.*

Merci d’avance,

Hervé Le Dantec / Fennec72
herve.ledantec@gmail.com <mailto:herve.ledantec@gmail.com>

--
Pierre

_______________________________________________

--
Pierre