La sauvegarde de mon Jeedom se passe bien, il envoie ensuite le fichier sur mon share Samba mais juste après il le supprime car il pense que la sauvegarde est trop vieille.
Voici la log de la sauvegarde :
[START BACKUP] Start of Jeedom backup at 2020-01-16 00:35:45
Envoi l’évènement de début de sauvegarde…OK
Vérification des droits sur les fichiers…OK
Vérification de la base de données…OK
Sauvegarde la base de données…OK
Persistance du cache :
OK
Création de l’archive…
OK
Nettoyage de l’ancienne sauvegarde…OK
Limitation de la taille des sauvegardes à 3000 Mo…
OK
Send backup Samba…Delete backup too old : {« filename »:« backup-TiToDom-4.0.38-2020-01-16-00h35.tar.gz »,« size »:« Thu »,« datetime »:« 1970-01-01 01:00:00 »}OK
Nom de la sauvegarde : /var/www/html/core/php/…/…/backup/backup-TiToDom-4.0.38-2020-01-16-00h35.tar.gz
Vérification des droits sur les fichiers…OK
Envoi l’évènement de fin de sauvegarde…OK
Durée de la sauvegarde : 20s Fin de la sauvegarde de Jeedom
[END BACKUP SUCCESS]
Dans la partie :
Send backup Samba…Delete backup too old : {« filename »:« backup-TiToDom-4.0.38-2020-01-16-00h35.tar.gz »,« size »:« Thu »,« datetime »:« 1970-01-01 01:00:00 »}OK
On voit bien qu’il « Delete backup too old » car la valeur de « datetime » est : « 1970-01-01 01:00:00 »
Le problème à mon avis c’est qu’il n’arrive pas à récupérer la date du jour. Il prend par défaut toujours la même valeur :« 1970-01-01 01:00:00 »
Le nom de la sauvegarde est correcte. La date est correcte.
Sauriez-vous me dire pourquoi il trouve la dernière sauvegarde « trop vieille » ?
D’où vient la date : « 1970-01-01 01:00:00 » ?
Le système est à l’heure aussi et à la bonne date également : (Raspbian)
xxx@xxxx:~ $ timedatectl
Local time: jeu. 2020-01-16 10:39:50 CET
Universal time: jeu. 2020-01-16 09:39:50 UTC
RTC time: n/a
Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
Si vous voulez ajouter des messages dans le déroulement de la sauvegarde pour essayer de comprendre, tout est dans le fichier /var/www/html/core/repo/samba.repo.php
Et plus particulièrement cette ligne dans la fonction ls:
C’est là que la date du fichier de la sauvegarde que vous venez de faire est calculé.
Il n’y a pas que la date qui est fausse, il y a aussi la taille qui est fausse ‹ Thu › au lieu d’une taille en octets.
La commande smbclient ls retourne des lignes avec ce format:
[0] [1] [2] [3] [4][5] [6] [7]
backup-JeedomJpty-4.0.38-2020-01-13-02h44.tar.gz A 159163653 Mon Jan 13 02:45:48 2020
Chez vous, ca semble différent: la taille du fichier est en [1] comme si le type de fichier (A) était absent ?
Pouvez-vous SVP fournir un exemple de ce que retourne la commande ls (après connexion en smbclient)
Oui, c’est un format différent, pour que ça soit décalé comme ça il manque le type de fichier dans la réponse de ls (le A en [1])
Le [0] nom du fichier est correct et le [2] la taille du fichier ne l’est pas.
Je ne trouve pas de description du format de la commande dir (=ls) dans samba ni comment changer ce format
Je pense également que le soucis vient de mon serveur SAMBA.
C’est en fait le serveur SAMBA disponible sur la Nvidia Shield TV. Elle est à jour et à l’heure mais de mémoire c’est une vielle version de Samba qui pourrait expliquer qu’elle retourne une date fausse.
Pour que ça fonctionne avec cette vieille version de samba surement modifiée par Nvidia, il n’y aurait que 2 lignes à modifier dans la la fonction ls du fichier /var/www/html/core/samba.repo.php
C’est les lignes 154 et 155.
Remplacer :
Depuis deux trois jours je n’ai plus d’archive sur mon Nas
Je viens d’en lancer un manuellement dans le Moteur de tâche mais celuici ne s’arrête jamais
La création de l’archive à l’air de ne pas se faire, au bout de dix minutes rien ne change.
Avez vous une Idée ? Merci
Bonjour,
Cela n’a pas de rapport avec le problème de ce post ni avec un nas puisque l’archive ne se crée même pas en local.
Je vous invite à créer un nouveau sujet avec plus d’information.
