Re: sauvegarde : tables vides

Oui Bernard, j'ai eu un problème avec la base sur
la préparation " cambouis " de mise à jour spip, et c'est ce que
j'ai fait, reprendre de toute la base du site en production avec
une sauvegarde multiple détaillée table par table avec phpMyAdmin
et refait la mise à jour !

Pour les mises à jour spip, systématiquement et le faisant
manuellement, je supprime par exemple le dossier "ecrire/" pour
recharger le nouveau, ayant souvenir que lors du passage de la
v2.1.x à la v3.0.x, 2 fichiers posaient des problèmes car il
n'avaient pas été supprimés (!). Je fait la même opération sur les
tables, soit je supprime la table avant de recharger la
sauvegarde. Une méthode il semble plus sûre ...

Mais on se demande pourquoi avec spip 3.x, il a été créé une
sauvegarde sqlite, quel avantage .. et pourquoi ?!. Là est la
question.

Le 09/05/2021 à 10:12, Bernard Frit a
écrit :

Bonjour.

Avec de tels volumes (9k articles et 60k referees)
je ne comprend pas quel peut être l’intérêt de tenter de
sauvegarder ça sur SQLite.

A mon avis et dans mon expérience (>20 ans) il
y a deux moyens de sauvegarde fiables :

- la sauvegarde complète de la machine rendu
facile par l’utilisation de VMs.

- la sauvegarde des données dans le format le plus
agnostique qui soit ici : texte SQL.

Donc pourquoi ne pas faire des « mysqldump » avec
toute la base et table par table ?

Vous pouvez bien sûr utiliser phpmyadmin si vous
n’avez pas d’accès Shell au serveur.

En plus des fichiers SQL zippés ne tiennent pas
beaucoup de place et sont faciles à déplacer avec ftp.

Transférer des données d’un logiciel de base de
données vers un autre (ici mysql ver SQLite) est toujours
susceptible de poser problème et encore plus si on espère
restaurer les données sur la base d’origine.

Le sam. 8 mai 2021 à 17:13,
Gerard Colin <[email protected] > a écrit :

Oui,
j'ai le même problème !

J'ai fait une évolution d'un site (un peu moins de 9000
articles .., de mémoire 62 000 referers ..) qui était en
2.1.29, passage à la 3.0.28 en test et construction à
la racine sur une autre partie de notre espace dédié,
dossier IMG (images et documents) 30 Go. Site existant
depuis juillet 2003.

Si la mise à jour c'est effectuée correctement, quand je
veux faire un export sqlite, il me prend plus ou moins
une table sur deux !

Exemple, il me met spip_articles (environ 9 000) en
échec, il prend bien spip_auteurs (environs une
soixantaines, etc .. .

En général, je me suis arrêté au niveau de spip_referers
ou spip_referers_articles qui met très longtemps, mais
normal puisse que 60 000 sur une de ces deux dernières
tables citées, vu qu'un nombre important de tables
enregistrées avant sont en échec, j'arrête .. ! Sur mon
Mac en PHP 5.6.34 et Xampp, avec la version qui évolue
en parallèle avec la version " Cambouis " sur serveur,
même problématique.

Je fais donc deux sauvegardes par phpMyAdmin (une
globale et l'autre contenant toutes les tables
séparées), mais par précaution effectivement j'aimerais
avoir également une sauvegarde sqlite par spip, et
notamment quand je ferais la bascule sur le site en
exploitation en spip 3.2.11 !!!

Il est vrai que je n'ai pas fini la révision de tous les
squelettes, les plugins installés, mais ils sont à jour
pour la version spip (3.0.28).

Y aurait il un loup quelque part ?..

En conclusion, apparemment je ne suis pas le seul à
avoir ce même problème avec sqlite !

Squelettes à jour : sommaire, articles, auteurs,
rubriques, ecrire_auteur, page plan, c'est tout pour le
moment.

Côté plugins installés : Fulltext 1.2.0, Le Couteau
Suisse 1.10.19, Lecteur Multimédia 2.1.8 (modifié mais
fonctionnant très bien sur deux sites en version 3.2.11
- Explications et description
), Spip Bonux 3.7.2 et Vidéo accessible 0.6.10 pour la
version spip_v3.0.28.

Côté serveur web : PHP 7.4.16,
Extension PHP : mysqli https://boucan.domainepublic.net/alternc-sql/url.php?url=https%3A%2F%2Fsecure.php.net%2Fmanual%2Ffr%2Fbook.mysqli.php
curl https://boucan.domainepublic.net/alternc-sql/url.php?url=https%3A%2F%2Fsecure.php.net%2Fmanual%2Ffr%2Fbook.curl.php
mbstring https://boucan.domainepublic.net/alternc-sql/url.php?url=https%3A%2F%2Fsecure.php.net%2Fmanual%2Ffr%2Fbook.mbstring.php
- Apache/2.4.38
(Debian) - Version du client de base de données
: libmysql - mysqlnd 7.4.16.

Au loup il y a certainement .. Merci.

gC

Le 08/05/2021 à 06:38, Manu a écrit :

La discussion "sauvegarde
impossible" voisine me fait penser à un problème voisin
que je rencontre souvent (pour ne pas dire tout le
temps) : la sauvegarde proposée par SPIP échoue : de
nombreuses tables sont vides

voir copie d'écran ici : https://nimb.ws/0mTC4s

Est-ce un problème connu ?

_______________________________________________

liste spip

[email protected] -
désabonnement : envoyer un mail à [email protected]

Archives : https://www.mail-archive.com/[email protected]/maillist.html

Infos : https://listes.rezo.net/mailman/listinfo/spip

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

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

_______________________________________________

liste spip

[email protected] - désabonnement :
envoyer un mail à [email protected]

Archives : https://www.mail-archive.com/[email protected]/maillist.html

Infos : https://listes.rezo.net/mailman/listinfo/spip

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

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

--