[SPIP Zone] problème sauvegarde sqlite

Archives Zone
1

Bonjour,

Message d'erreur : Impossible de faire une sauvegarde avec
  SQLite sur votre hébergement.
(via /?exec=sauvegarder)

sur les sites en SPIP 3.0.2 [19586]

en local (PHP version: 5.3.6-13ubuntu3.8
SQL version: MySQL: 5.1.63-0ubuntu0.11.10.1)

La base est bien en mysql comme détecté correctement par la page /?exec=admin_tech

et la sauvegarde ne se fait pas.

dd

2

Salut,

Le 25/06/2012 23:28, dd a écrit :

Bonjour,

Message d'erreur : Impossible de faire une sauvegarde avec
  SQLite sur votre hébergement.
(via /?exec=sauvegarder)

Le message n'est peut être pas assez causant, SPIP 3 nécessite SQLite sur le serveur pour pouvoir effectuer une sauvegarde (que la base soit en mysql ou en sqlite).

Cf l'article de présentation de SPIP 3 :

Dump assure la gestion des sauvegardes et restaurations. La fonctionnalité a été complètement ré-écrite pour assurer une sauvegarde complète et fiable. Le format de sauvegarde est maintenant SQLite et toutes les tables sont systématiquement conservées.

++
b_b

3

Le 26/06/2012 09:56, Bruno Bergot a écrit :

Salut,

Le 25/06/2012 23:28, dd a écrit :

Bonjour,

Message d'erreur : Impossible de faire une sauvegarde avec
  SQLite sur votre hébergement.
(via /?exec=sauvegarder)

Le message n'est peut être pas assez causant, SPIP 3 nécessite SQLite sur le serveur pour pouvoir effectuer une
sauvegarde (que la base soit en mysql ou en sqlite).
Cf l'article de présentation de SPIP 3 :
Dump assure la gestion des sauvegardes et restaurations. La fonctionnalité a été complètement ré-écrite pour assurer une
sauvegarde complète et fiable. Le format de sauvegarde est maintenant SQLite et toutes les tables sont systématiquement
conservées.
SPIP 3.0 - SPIP

La doc pourrait indiquer aussi :
En conséquence, sur un site utilisant MYSQL et dont le PHP ne dispose pas de SQLite, il vous faut sauvegarder la base de donnée indépendamment de SPIP, en utilisant mysqldump ou phpmyadmin.

JLuc

4

Hop,

Le 26/06/2012 11:31, JLuc a écrit :

La doc pourrait indiquer aussi :
En conséquence, sur un site utilisant MYSQL et dont le PHP ne dispose
pas de SQLite, il vous faut sauvegarder la base de donnée indépendamment
de SPIP, en utilisant mysqldump ou phpmyadmin.

je viens d'ajouter la mention suivant à l'article de spip.net :

Votre hébergement doit donc disposer de SQLite. Si ce n’est pas le cas, contactez votre hébergeur pour lui demander de l’activer.

++
b_b

5

Hop,

2012/6/26 Bruno Bergot <brunobergot@gmail.com>

Hop,

Le 26/06/2012 11:31, JLuc a écrit :

La doc pourrait indiquer aussi :
En conséquence, sur un site utilisant MYSQL et dont le PHP ne dispose
pas de SQLite, il vous faut sauvegarder la base de donnée indépendamment
de SPIP, en utilisant mysqldump ou phpmyadmin.

je viens d’ajouter la mention suivant à l’article de spip.net :

Votre hébergement doit donc disposer de SQLite. Si ce n’est pas le cas, contactez votre hébergeur pour lui demander de l’activer.

http://www.spip.net/fr_article5427.html?var_mode=calcul

Certains hébergeurs mutualisés font exprès de ne pas autoriser sqlite. Ils limitent le nombre de bases mysql pour plusieurs raisons. Alors fournir un nombre illimité de bases sqlite qui utiliseraient des ressources non maitrisables, je pense qu’il ne sont pas chauds.
Au hasard : Free.fr

Par rapport à ce type de situation, je propose d’utiliser la formulation suivante :
« En l’absence de sqlite, il est conseillé à l’utilisateur de réaliser ses sauvegardes via phpmyadmin ou toute autre interface de gestion de la base de données fournie par son hébergeur. »

Qu’en penses-tu ?

a+
.Gilles

++
b_b

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

6

Le 27/06/2012 18:34, Gilles Vincent a écrit :

Hop,

2012/6/26 Bruno Bergot <brunobergot@gmail.com <mailto:brunobergot@gmail.com>>

    Hop,

    Le 26/06/2012 11:31, JLuc a écrit :

        La doc pourrait indiquer aussi :
        En conséquence, sur un site utilisant MYSQL et dont le PHP ne dispose
        pas de SQLite, il vous faut sauvegarder la base de donnée indépendamment
        de SPIP, en utilisant mysqldump ou phpmyadmin.

    je viens d'ajouter la mention suivant à l'article de spip.net <http://spip.net> :

    Votre hébergement doit donc disposer de SQLite. Si ce n’est pas le cas, contactez votre hébergeur pour lui demander
    de l’activer.

    SPIP <SPIP 3.0 - SPIP;

Certains hébergeurs mutualisés font exprès de ne pas autoriser sqlite. Ils limitent le nombre de bases mysql pour
plusieurs raisons. Alors fournir un nombre illimité de bases sqlite qui utiliseraient des ressources non maitrisables,
je pense qu'il ne sont pas chauds.
Au hasard : Free.fr

Par rapport à ce type de situation, je propose d'utiliser la formulation suivante :
"/En l'absence de sqlite, il est conseillé à l'utilisateur de réaliser ses sauvegardes via phpmyadmin ou toute autre
interface de gestion de la base de données fournie par son hébergeur./"

Qu'en penses-tu ?

Je trouve ça nettement mieux.

Car demander à son hébergeur de modifier l'hébergement aura en général autant d'effet que d'aller brûler un cierge à la piscine du quartier : plouf !

Alors que se servir de phpmyadmin, mysqldump ou sauveauto marche à tous les coups...

JLuc

7

Le 02/07/2012 14:19, JLuc a écrit :

Le 27/06/2012 18:34, Gilles Vincent a écrit :

Hop,

2012/6/26 Bruno Bergot <brunobergot@gmail.com
<mailto:brunobergot@gmail.com>>

    Hop,

    Le 26/06/2012 11:31, JLuc a écrit :

        La doc pourrait indiquer aussi :
        En conséquence, sur un site utilisant MYSQL et dont le PHP ne
dispose
        pas de SQLite, il vous faut sauvegarder la base de donnée
indépendamment
        de SPIP, en utilisant mysqldump ou phpmyadmin.

    je viens d'ajouter la mention suivant à l'article de spip.net
<http://spip.net> :

    Votre hébergement doit donc disposer de SQLite. Si ce n’est pas le
cas, contactez votre hébergeur pour lui demander
    de l’activer.

    SPIP
<SPIP 3.0 - SPIP;

Certains hébergeurs mutualisés font exprès de ne pas autoriser sqlite.
Ils limitent le nombre de bases mysql pour
plusieurs raisons. Alors fournir un nombre illimité de bases sqlite
qui utiliseraient des ressources non maitrisables,
je pense qu'il ne sont pas chauds.
Au hasard : Free.fr

Par rapport à ce type de situation, je propose d'utiliser la
formulation suivante :
"/En l'absence de sqlite, il est conseillé à l'utilisateur de réaliser
ses sauvegardes via phpmyadmin ou toute autre
interface de gestion de la base de données fournie par son hébergeur./"

Qu'en penses-tu ?

Je trouve ça nettement mieux.

Car demander à son hébergeur de modifier l'hébergement aura en général
autant d'effet que d'aller brûler un cierge à la piscine du quartier :
plouf !

Alors que se servir de phpmyadmin, mysqldump ou sauveauto marche à tous
les coups...

JLuc

Oui je trouve cela plus explicite.

Un bémol : lorsque le fichier de sauvegarde fait plus de 2 mega (cela arrive même compressé) on atteint la limite PHPMyadmin de pas mal d'hébergeurs et c'est assez contraignant de séparer ses sauvegardes en plusieurs morceaux.

Si je comprend bien les plugins saveauto et consorts ne sont plus compatibles avec SPIP 3 ?

dd

8

Le 2 juil. 2012 à 23:23, dd <lemotjuste@free.fr> a écrit :

Le 02/07/2012 14:19, JLuc a écrit :

Le 27/06/2012 18:34, Gilles Vincent a écrit :

Hop,

2012/6/26 Bruno Bergot <brunobergot@gmail.com
<mailto:brunobergot@gmail.com>>

   Hop,

   Le 26/06/2012 11:31, JLuc a écrit :

       La doc pourrait indiquer aussi :
       En conséquence, sur un site utilisant MYSQL et dont le PHP ne
dispose
       pas de SQLite, il vous faut sauvegarder la base de donnée
indépendamment
       de SPIP, en utilisant mysqldump ou phpmyadmin.

   je viens d'ajouter la mention suivant à l'article de spip.net
<http://spip.net> :

   Votre hébergement doit donc disposer de SQLite. Si ce n’est pas le
cas, contactez votre hébergeur pour lui demander
   de l’activer.

   SPIP
<SPIP 3.0 - SPIP;

Certains hébergeurs mutualisés font exprès de ne pas autoriser sqlite.
Ils limitent le nombre de bases mysql pour
plusieurs raisons. Alors fournir un nombre illimité de bases sqlite
qui utiliseraient des ressources non maitrisables,
je pense qu'il ne sont pas chauds.
Au hasard : Free.fr

Par rapport à ce type de situation, je propose d'utiliser la
formulation suivante :
"/En l'absence de sqlite, il est conseillé à l'utilisateur de réaliser
ses sauvegardes via phpmyadmin ou toute autre
interface de gestion de la base de données fournie par son hébergeur./"

Qu'en penses-tu ?

Je trouve ça nettement mieux.

Car demander à son hébergeur de modifier l'hébergement aura en général
autant d'effet que d'aller brûler un cierge à la piscine du quartier :
plouf !

Alors que se servir de phpmyadmin, mysqldump ou sauveauto marche à tous
les coups...

JLuc

Oui je trouve cela plus explicite.

Un bémol : lorsque le fichier de sauvegarde fait plus de 2 mega (cela arrive même compressé) on atteint la limite PHPMyadmin de pas mal d'hébergeurs

C'est amusant que l'on présume que Spip doive réussir à se débrouiller là ou les autres outils n'y arrivent pas.
Le fait est que faire des sauvegardes volumineuses et fiables dans un gros fichier avec des limites de timeout et de dl/upload est très problématique.
Spip n'échappant pas plus aux contraintes techniques que les autres outils, le système qui était utilisé jusqu'en version 2 était très imparfait et peu fiable. Il n'a jamais été pensé comme un système de sauvegarde mais cet usage détourné conduisait à des problèmes de supports et debug incessants.
D'où le choix de passer à SQLite.

9

Save-auto en SPIP 3.0 fonctionne pour ma part (avec quelques défauts d'affichage) mais je ne suis pas un adepte du très gros fichier donc je ne peux pas te dire sur une sauvegarde de plus de 3 Mo et surtout s'il y a des failles, je viens de découvrir le message de Cédric disant que cette partie était joyeusement buggué...

Cordialement,

Pascal23

-----Message d'origine-----
De : dd [mailto:lemotjuste@free.fr]
Envoyé : lundi 2 juillet 2012 23:24
À : spip-zone@rezo.net
Cc : spip-zone@rezo.net
Objet : Re: [SPIP Zone] problème sauvegarde sqlite

Le 02/07/2012 14:19, JLuc a écrit :

Le 27/06/2012 18:34, Gilles Vincent a écrit :

Hop,

2012/6/26 Bruno Bergot <brunobergot@gmail.com
<mailto:brunobergot@gmail.com>>

    Hop,

    Le 26/06/2012 11:31, JLuc a écrit :

        La doc pourrait indiquer aussi :
        En conséquence, sur un site utilisant MYSQL et dont le PHP ne
dispose
        pas de SQLite, il vous faut sauvegarder la base de donnée
indépendamment
        de SPIP, en utilisant mysqldump ou phpmyadmin.

    je viens d'ajouter la mention suivant à l'article de spip.net
<http://spip.net> :

    Votre hébergement doit donc disposer de SQLite. Si ce n’est pas
le cas, contactez votre hébergeur pour lui demander
    de l’activer.

    SPIP
<SPIP 3.0 - SPIP;

Certains hébergeurs mutualisés font exprès de ne pas autoriser sqlite.
Ils limitent le nombre de bases mysql pour plusieurs raisons. Alors
fournir un nombre illimité de bases sqlite qui utiliseraient des
ressources non maitrisables, je pense qu'il ne sont pas chauds.
Au hasard : Free.fr

Par rapport à ce type de situation, je propose d'utiliser la
formulation suivante :
"/En l'absence de sqlite, il est conseillé à l'utilisateur de
réaliser ses sauvegardes via phpmyadmin ou toute autre interface de
gestion de la base de données fournie par son hébergeur./"

Qu'en penses-tu ?

Je trouve ça nettement mieux.

Car demander à son hébergeur de modifier l'hébergement aura en général
autant d'effet que d'aller brûler un cierge à la piscine du quartier :
plouf !

Alors que se servir de phpmyadmin, mysqldump ou sauveauto marche à
tous les coups...

JLuc

Oui je trouve cela plus explicite.

Un bémol : lorsque le fichier de sauvegarde fait plus de 2 mega (cela arrive même compressé) on atteint la limite PHPMyadmin de pas mal d'hébergeurs et c'est assez contraignant de séparer ses sauvegardes en plusieurs morceaux.

Si je comprend bien les plugins saveauto et consorts ne sont plus compatibles avec SPIP 3 ?

dd

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

10

Hop,

Le 27/06/2012 18:34, Gilles Vincent a écrit :

Par rapport à ce type de situation, je propose d'utiliser la formulation
suivante :
"*En l'absence de sqlite, il est conseillé à l'utilisateur de réaliser ses
sauvegardes via phpmyadmin ou toute autre interface de gestion de la base
de données fournie par son hébergeur.*"

Qu'en penses-tu ?

gogogo :slight_smile:

++
b_b

11

Hop

Le 03/07/2012 10:08, Bruno Bergot a écrit :

Qu'en penses-tu ?

gogogo :slight_smile:

Bon ben je l'ai fait :

++
b_b

12

Bonjour,malgré les infos ci-dessous, impossible de sauvegarder la base en SPIP3.0.3 ce qui me pose un énorme problème.

Je maitrise le serveur, j’ai fait un apt-get du dernier sqlite, que faire de plus ? message d’erreur de spip3:

Impossible de faire une sauvegarde SQLite sur votre hébergement# Rien d’interessant dans le log…merci d’avance !!!
Michel

PHP Version 5.3.2-1ubuntu4.17## sqlite3

SQLite3 support enabled
SQLite3 module version 0.7-dev
SQLite Library 3.6.22

Le 4 juil. 2012 à 22:50, Bruno Bergot a écrit :

Hop

Le 03/07/2012 10:08, Bruno Bergot a écrit :

Qu’en penses-tu ?

gogogo :slight_smile:

Bon ben je l’ai fait :

http://www.spip.net/fr_article5427.html

++
b_b

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

13

Le 25/07/2012 11:15, Michel JORDA a écrit :

malgré les infos ci-dessous, impossible de sauvegarder la base en SPIP3.0.3 ce qui me pose un énorme problème.
Je maitrise le serveur, j'ai fait un apt-get du dernier sqlite, que faire de plus ? message d'erreur de spip3:
Impossible de faire une sauvegarde SQLite sur votre hébergement

si c'est un probleme avec ton serveur que tu infogères, peut être aurais tu plus d'experts
pour te répondre sur un forum ou un chan IRC dédié à l'autohébergement ou à Ubuntu
JLuc

  Rien d'interessant dans le log...

merci d'avance !!!
Michel

  PHP Version 5.3.2-1ubuntu4.17

    sqlite3

SQLite3 support enabled
SQLite3 module version 0.7-dev
SQLite Library 3.6.22

Le 4 juil. 2012 à 22:50, Bruno Bergot a écrit :

Hop

Le 03/07/2012 10:08, Bruno Bergot a écrit :

Qu'en penses-tu ?

gogogo :slight_smile:

Bon ben je l'ai fait :

SPIP 3.0 - SPIP

++
b_b

_______________________________________________
spip-zone@rezo.net <mailto:spip-zone@rezo.net> - http://listes.rezo.net/mailman/listinfo/spip-zone

14

Bonjour,

Probablement un bug :

Sous 3.0.3 la sauvegarde ne propose que les tables spip_... même si le
site pour lequel je veux faire une sauvegarde travaille avec préfixe de
type spipabcd_...
La base de donnée comporte plusieurs collections de tables de type SPIP
(spip_..., spipabcd_..., spip2_..).

Il me semble également que la moulinette de mise à jour 'oubli' parfois
d'utiliser le bon préfixe pour ne travailler qu'avec les tables spip_...

Amicalement

--
Alain BOURDEAU

15

je me réponds a moi même.
il faut installer SQLlite et pas sqlite3, avec un utilitaire PDO
(pour les as sous Ubuntu, ca s’écrit:
sudo pecl install pdo_sqlite
)

Mes excuses pour le bruit
MJ

Le 26 juil. 2012 à 03:19, Alain BOURDEAU a écrit :

Bonjour,

Probablement un bug :

Sous 3.0.3 la sauvegarde ne propose que les tables spip_… même si le
site pour lequel je veux faire une sauvegarde travaille avec préfixe de
type spipabcd_…
La base de donnée comporte plusieurs collections de tables de type SPIP
(spip_…, spipabcd_…, spip2_…).

Il me semble également que la moulinette de mise à jour ‹ oubli › parfois
d’utiliser le bon préfixe pour ne travailler qu’avec les tables spip_…

Amicalement

–
Alain BOURDEAU

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

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

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

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