Sauvegardes - Précautions, Problèmes, solutions, conseils et Outils pratiques
Compte-rendu partagé ...
Suite au besoin de réinstallation d’un spip 3.05 nettoyé, avec des plugins propres et un squelette escal 3.69 tout fringuant, après avoir restauré la dernière sauvegarde classique proposée par SPIP j’ai constaté avec frayeur que ces sauvegardes fabriquées par spip depuis quelques mois comportaient des erreurs importantes et n’étaient pas complètes.
Je n’avais pas pris le temps de vérifier les sauvegardes au fur et à mesure de leur importation.
Les sauvegardes de SPIP 3.05 ont fait apparaitre des tables articles, rubriques, mots, vidées alors que d’autres tables étaient pleines .... Les fichiers sqlite faisaient quand même entre 4 et 12 Mo selon la date d’origine. Cela a occasionné quelques soucis et frayeurs , imaginez ...
Après vérifications sur les très anciennes sauvegardes et dans les faits, en refabriquant d’autres sauvegardes pour les tester, que cela soit sur SPIP 3 local ou sur SPIP 3 chez OVH, les sauvegardes fabriquées par SPIP 3.05 sous la forme sqlite sont incomplètes ... avec zero articles zero rubriques et zero mots clés ...
Pourquoi ? Pour l’instant c’est l’inconnu !
En allant voir depuis le manager ovh avec phpmyadmin , il apparait que les tables concernées dans la base restaurée sont effectivement vides.
En local, avec easyphp la restauration a produit le même effet de tables vides d’articles, vides de rubriques et mots cles.
J’ai donc essaye de restaurer en local un fichier.dump fourni par une sauvegarde OVH, et cela n’a pas fonctionné tout de suite avec spip en local.
Chez OVH, heureusement qu’il y a automatiquement la sauvegarde "dump" de la base de données de la semaine précédente et celle du jour d’avant qui est faite par OVH. On peut donc les télécharger sur l’ordi local , et en vérifier le fichier de tables, puis en extraire les tables "bien pleines" que l’on a besoin.
Un fichier "DUMP" chez Ovh s’ouvre avec le bloc notes, et il est facile de repérer la table concernée, en faire un copier coller de la table qui nous interresse, et sauvegarder ensuite le fichier contenant cette table en "basexemple-articles.sql" pour l’importer là où il y a besoin et remplacer la table vide.
Mais avec PhpMyAdmin, selon les fichiers et les dimensions des tables, cela bloque pour les importer.
Ma table article faisait 369 lignes, + la table rubrique, + la table mots, et d’autres tables, etc ...
Globalement le dump OVH ou les dernières sauvegardes "sqlite" de SPIP faisaient entre 10 et 13 Mo.
Avec PhpMyAdmin sur site local ou chez OVH problème de dimensions de fichiers.
Après recherche dans les forums, j’ai trouvé qu’on pouvait modifier la dimension des fichiers upload ( réglée par défaut à 2 M) en allant changer les valeurs de : "php.ini"
Sur site local avec PhpMyAdmin , on peut changer les paramètres de configuration des deux fichiers "php.ini" pour uploader des gros fichiers, et augmenter le temps d’upload, mais chez OVH on ne peut pas aller modifier ces mêmes paramètres.
Les modifications : Dans les paramètres de configuration des deux fichiers "php.ini" qui sont dans les sous-repertoires EasyPHP :
\EasyPHP-XXXX \apache\php.ini
\EasyPHP-5.3.8.1\conf_files\php.ini
Dans les fichiers "PHP.INI" changer les "limites de ressources en temps" et les valeurs des fichiers "Upload", cela se situe à ces endroits des 2 fichiers :
Dans la partie :
;;;;;;;;;;;;;;;;;;;
; {{Resource Limits ;}}
;;;;;;;;;;;;;;;;;;;
; ...
; ...
; Maximum execution time of each script, in seconds
; https://www.php.net/manual/en/info.configuration.php#ini.max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
; max_execution_time = 30
Mettre max_execution_time = 1200
Dans la partie :
;;;;;;;;;;;;;;;;
; {{File Uploads ;}}
;;;;;;;;;;;;;;;;
chercher :
; Maximum allowed size for uploaded files.
; https://www.php.net/manual/en/ini.core.php#ini.upload-max-filesize
; {{upload_max_filesize = 2M}} mettre {{20M}}
mettre : "upload_max_filesize = 20M
; Maximum number of files that can be uploaded via a single request
max_file_uploads = 20
mettre : " max_file_uploads = [**50" selon vos besoins
SQLITE MANAGER
Un autre outil bien pratique pour vérifier les tables :
En utilisant l’extension firefox SQLITE MANAGER, j’ai pu aller vérifier toutes les anciennes sauvegardes "SQLite" .
Et ensuite réimporter depuis OVH les tables extraites qui avaient été vidées par les sauvegardes de SPIP 3.05 .
En attendant que le bug de sauvegarde sqlite de spip soit réparé ...par précautions, pensez à :
- Importer par FTP sur ordi local une copie des sauvegardes que spip3 produit.
- Les vérifier en qualité des fichiers produits par SPIP.
- (chez ovh) Pensez à exporter-upload vos tables principales avec Phpmyadmin , cela sera toujours utils si une sauvegarde SQlite est imparfaite ...
Bien cordialement
Le jaseur Boreal
