Bonjour a tous
J’ai installé un system Debian 9 Lite + jeedom 3.3.34 sur un rpi3 pour tester la V4 tranquillement
Quand j’ai voulu restaurer ma sauvegarde de prod (3.3.34) le rpi se plante au bout d’une minute (meme plus acces en ssh) mais j’ai eu le temps de voir le message suivant:
Citation
[2019-10-25 13:29:05][ERROR] : Erreur sur la fonction cron15 du plugin : [MySQL] Error code : 42S02 (1146). Table ‹ jeedom.object › doesn’t exist : SELECT el.id, el.name, el.logicalId, el.generic_type, el.object_id, el.eqType_name, el.eqReal_id, el.isVisible, el.isEnable, el.configuration, el.timeout, el.category, el.display, el.order, el.comment, el.tags FROM eqLogic el
J’arrive a empecher le plantage en desactivant le plus rapidement possible les plugins Monitoring, Monitoring2, geotrav, Heliotrope, ecodevices,suivi conso,Network… car j’ai remarqué que ce message d’erreur etait remonté dans plusieurs de ses plugins… et je pense que l’accumulation fait que le rpi se bloque
Je dois preciser que la restauration sur un rpi secours que je fait regulierement depuis x mois
fonctionne sans probleme…mais pas sur un system « neuf » (???)
Si quelqu’un a une idée ??
Salut,
A priori tu as un souci avec ta base de données, il en manque une partie (la table object)…
Es-tu certain du contenu de ta sauvegarde ?
Tu peux aussi regarder le contenu du fichier BD_backup.sql qui doit contenir ce genre d’info
LOCK TABLES `note` WRITE;
/*!40000 ALTER TABLE `note` DISABLE KEYS */;
/*!40000 ALTER TABLE `note` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `object`
--
DROP TABLE IF EXISTS `object`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `object` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(45) COLLATE utf8_unicode_ci NOT NULL,
`father_id` int(11) DEFAULT NULL,
`isVisible` tinyint(1) DEFAULT NULL,
`position` int(11) DEFAULT NULL,
`configuration` text COLLATE utf8_unicode_ci DEFAULT NULL,
`display` text COLLATE utf8_unicode_ci DEFAULT NULL,
`image` mediumtext COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name_UNIQUE` (`name`),
KEY `fk_object_object1_idx1` (`father_id`),
KEY `position` (`position`)
) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `object`
--
LOCK TABLES `object` WRITE;
/*!40000 ALTER TABLE `object` DISABLE KEYS */;
INSERT INTO `object` VALUES (1,'La maison',NULL,1,1,
Merci de ta reponse
J’ai recuperé d’un backup BD_backup.sql et quand j’ai voulu l’editer j’ai un message d’erreur:
impossible d’ouvrir : le fichier depasse la taille maximale allouée (il fait 701 Mo)
Ca voudrait dire que mes sauvegardes ne sont pas bonnes a cause de la taille de ce fichier !!!
Pourtant je n’ai eu aucun message d’erreur
Ma sauvegarde fait 210 Mo (compressée)
Tu peux essayer de changer la limite (Réglages => Système => Sauvegarde)
Et aussi voir si une partie de l’historique est nettoyable (Outils => Historique => Configuration), il faudra attendre la purge nocturne et voir après si tu as réduits un peu la taille de tes backup
Dans config des sauvegardes la taille est a 1050 Mo mais la on parle bien de la taille totale des backups (compressées) ?? J’ai lu il n’y a pas longtemps dans le forum quelqu’un qui disait que sql bloquait la taille de la base a 1 Go , si c’est vrai je n’en suis pas tres loin
Bon c’est vrai que j’ai pas mal d’historique… j’ai crée mon jeedom en fevrier 2016 je vais faire du nettoyage et voir le resultat demain
Au pire du pire, il y a toujours moyen de faire le dump soi-même… Mais ça rends l’opération de restauration bien plus complexe.
J’ai continué mes essais et recherche et je me suis rendu compte que c’etait le plugin Monitoring qui me plantait tout…
Je l’ai desinstallé puis reinstallé…et depuis tout semblerait OK… mais j’attend un peu avant de crier victoire
Je posterai peut etre dans la categorie Plugins voir si peut etre quelq’un aurait une idée…
Ce qui m’inquiete le plus c’est que je ne peux pas totalement faire confiance a une sauvegarde.
Merci a toi quand meme.
OK.
Je l’ai aussi ce plugin, et j’ai pas de souci pour autant
En fouillant un peu j’avais pas fait attention lors d’une sauvegarde j’ai ce message:
Citation
Début de la restauration de Jeedom 2019-10-26 19:54:10
Envoie l’événement de début de restauration…OK
Vérifiez les droits…
OK
Fichier utilisé pour la restauration : /var/www/html/install/…/backup/backup-Jeedom-3.3.34-2019-10-26-02h38.tar.gz
Backup database access configuration…Can not copy /var/www/html/install/…/core/config/common.config.php
C’est quoi common.config.php ??
C’est juste un des fichiers de jeedom.
Tu dois avoir un souci des droits.
Essaye de les rétablir (Réglages => Système => Configuration => _OS/BD)
Je viens de retablir les droits sur le rpi sur lequel je restaure mon backup… j’ai relancé une restaur…et j’ai toujours le message.
Il faudrait peut etre restaurer les droits sur le rpi source avant de faire un backup ??
Oui, le tar conserve les permissions
Et je continue les essais …J’ai remis les droits sur jeedom sources , refait un backup (ceci dit dans les logs du backup je n’ai jamais vu un message d’erreur quelconque) puis une restaur …et toujours le meme message Can not copy …
Mystere mystere !!!
Tu es sur une carte SD lors de la restauration ?
ça vaut peut-être le coup de tester avec une autre, et même de repartir d’une version vierge de l’os
Non je n’utilise pas de carte Sd mais des SSD
Et justement mon rpi de restauration etait vierge a l’origine… et le probleme avec le plugin Monitoring s’est presenté a la 1° restaur…
Je viens penser que dans Monitoring j’avais crée 3 objets:
- mon NAS deporté sur IP
-mon Jeedom prod local
-mon rpi sauve deporté sur IP
Mais apres une restaur sur mon 3° rpi test le jeedom prod devient le rpi test (local)
les 2 autres objets ne changent pas
J’ai fait la manip suivante: juste apres une restaur sur le 3° rpi , juste avant qu’il ne se bloque j’ai supprimé tous les objets crée dans monitoring… et plus de blocage du rpi (je n’ai pas eu a réinstaller le plugin) et il fonctionne bien
Par contre je ne m’explique toujours le message Can not copy …alors que tout est normal END
Ouf c’est compliqué mon affaire
Pas de souci de copie sur le 3ème ? parce que si tu as aussi le problème, il vaut mieux chercher du coté de la source
J’ai toujours le message en restauration Can not copy …que se soit sur le 3° et le 2° rpi
Sur le prod la derniere restaur que j’ai faite date du 1 Avril 2019 et j’avais aussi ce message
Voila le Log complet d’une restaur
Il y a OK partout !!!
Citation
[START RESTORE]
Début de la restauration de Jeedom 2019-04-01 19:40:49
Envoie l’événement de début de restauration…OK
Vérifiez les droits…
OK
Fichier utilisé pour la restauration : /var/www/html/install/…/backup/backup-Jeedom-3.2.16-2019-04-01-18h29.tar.gz
Backup database access configuration…Can not copy /var/www/html/install/…/core/config/common.config.php
OK
Disable all task
…
… OK
Disable all scenario…
…
… OK
Décompression de la sauvegarde…
OK
Supprimer la table de la sauvegardeDésactive les contraintes…OK
Supprimer la table : cache …OK
Supprimer la table : calendar_event …OK
Supprimer la table : cmd …OK
Supprimer la table : config …OK
Supprimer la table : conso_abo …OK
Supprimer la table : conso_current …OK
Supprimer la table : conso_groupe …OK
Supprimer la table : conso_jour …OK
Supprimer la table : conso_periode …OK
Supprimer la table : conso_periode_groupe …OK
Supprimer la table : conso_price …OK
Supprimer la table : conso_taxe …OK
Supprimer la table : conso_teleinfo …OK
Supprimer la table : conso_teleinfo_save …OK
Supprimer la table : conso_tmp …OK
Supprimer la table : conso_tva …OK
Supprimer la table : cron …OK
Supprimer la table : dataStore …OK
Supprimer la table : eqLogic …OK
Supprimer la table : eqReal …OK
Supprimer la table : history …OK
Supprimer la table : historyArch …OK
Supprimer la table : interactDef …OK
Supprimer la table : interactQuery …OK
Supprimer la table : listener …OK
Supprimer la table : message …OK
Supprimer la table : object …OK
Supprimer la table : plan …OK
Supprimer la table : planHeader …OK
Supprimer la table : scenario …OK
Supprimer la table : scenarioElement …OK
Supprimer la table : scenarioExpression …OK
Supprimer la table : scenarioSubElement …OK
Supprimer la table : update …OK
Supprimer la table : user …OK
Supprimer la table : view …OK
Supprimer la table : viewData …OK
Supprimer la table : viewZone …OK
Restauration de la base de données…
OK
Active les contraintes…OK
Restauration du cache…OK
Plugin restoration : calendar…
OK
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
Check jeedom consistency…[START CONSISTENCY]
Vérifiez les droits sur les fichiers…
OK
[END CONSISTENCY]
OK
Enable scenario : OK
Enable task : OK
Envoie l’événement de la fin de la sauvegarde…OK
Temps de la restauration : 1560s
Fin de la restauration de Jeedom
[END RESTORE SUCCESS]
Petite rectification
La ligne : Verifier les droits sur les fichiers n’apparait plus sur les restaurations actuelles…
Les OK, il faut quand même pas trop s’y fier, ça veut dire que c’est pas bloquant…
Tu es pas le seul
https://www.jeedom.com/forum/viewtopic.php?t=40700
Donc la question , c’est de voir si ton backup est complet avec ce fichier
Et tu as quoi là coté source ?
Avec Jeexplorer j’ai decompresse un backup dans un nouveau repertoire et j’ai bien le fichier common.config.sample.php mais PAS le common.config.php…
Coté source voila ma config:
