Backup HS vers synology depuis (mise a jour rclone ?)

Bonjour,

Un petit carnage chez moi cette dernière mise à jour.
Plus aucun backup n’est fonctionnel vers mon syno en sftp/

0000|2026/01/08 08:26:53 ERROR : backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: Failed to calculate dst hash: failed to calculate md5 hash: failed to run "md5sum /Backup/Jeedom/Prod/backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial": md5sum: /Backup/Jeedom/Prod/backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: No such file or directory: Process exited with status 1
0001|2026/01/08 08:26:53 ERROR : backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: corrupted on transfer: md5 hashes differ src(Local file system at /var/www/html/backup) "85e6704c6e5444861c3f01d9af41be2f" vs dst(sftp://jeedom@xpenology1-int.lan:22//Backup/Jeedom/Prod) ""
0002|2026/01/08 08:26:53 INFO  : backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: Removing failed copy
0003|2026/01/08 08:26:53 ERROR : Attempt 1/3 failed with 2 errors and: corrupted on transfer: md5 hashes differ src(Local file system at /var/www/html/backup) "85e6704c6e5444861c3f01d9af41be2f" vs dst(sftp://jeedom@xpenology1-int.lan:22//Backup/Jeedom/Prod) ""
0004|2026/01/08 08:26:54 ERROR : backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: Failed to calculate dst hash: failed to calculate md5 hash: failed to run "md5sum /Backup/Jeedom/Prod/backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial": md5sum: /Backup/Jeedom/Prod/backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: No such file or directory: Process exited with status 1
0005|2026/01/08 08:26:54 ERROR : backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: corrupted on transfer: md5 hashes differ src(Local file system at /var/www/html/backup) "85e6704c6e5444861c3f01d9af41be2f" vs dst(sftp://jeedom@xpenology1-int.lan:22//Backup/Jeedom/Prod) ""
0006|2026/01/08 08:26:54 INFO  : backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: Removing failed copy
0007|2026/01/08 08:26:54 ERROR : Attempt 2/3 failed with 2 errors and: corrupted on transfer: md5 hashes differ src(Local file system at /var/www/html/backup) "85e6704c6e5444861c3f01d9af41be2f" vs dst(sftp://jeedom@xpenology1-int.lan:22//Backup/Jeedom/Prod) ""
0008|2026/01/08 08:26:54 ERROR : backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: Failed to calculate dst hash: failed to calculate md5 hash: failed to run "md5sum /Backup/Jeedom/Prod/backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial": md5sum: /Backup/Jeedom/Prod/backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: No such file or directory: Process exited with status 1
0009|2026/01/08 08:26:54 ERROR : backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: corrupted on transfer: md5 hashes differ src(Local file system at /var/www/html/backup) "85e6704c6e5444861c3f01d9af41be2f" vs dst(sftp://jeedom@xpenology1-int.lan:22//Backup/Jeedom/Prod) ""
0010|2026/01/08 08:26:54 INFO  : backup-jeedom-4.5.2-2026-01-08-02h27.tar.gz.35ca6fcb.partial: Removing failed copy
0011|2026/01/08 08:26:54 ERROR : Attempt 3/3 failed with 2 errors and: corrupted on transfer: md5 hashes differ src(Local file system at /var/www/html/backup) "85e6704c6e5444861c3f01d9af41be2f" vs dst(sftp://jeedom@xpenology1-int.lan:22//Backup/Jeedom/Prod) ""
0012|2026/01/08 08:26:54 INFO  :
0013|Transferred:   	  371.802 MiB / 371.802 MiB, 100%, 0 B/s, ETA -
0014|Errors:                 2 (retrying may help)
0015|Checks:                 0 / 0, -, Listed 3
0016|Elapsed time:         1.2s
0017|2026/01/08 08:26:54 NOTICE: Failed to copy with 2 errors: last error was: corrupted on transfer: md5 hashes differ src(Local file system at /var/www/html/backup) "85e6704c6e5444861c3f01d9af41be2f" vs dst(sftp://jeedom@xpenology1-int.lan:22//Backup/Jeedom/Prod) ""

OK coté dependance

evidemment ca tournait depuis des années sans soucis, j’ai tenté de donner tous les droits cote syno pour voir si c’etait un problème de droit mais pareil.

Gemini est assez clair dans la réponse : La mise à jour a probablement installé une version plus récente de Rclone. Les versions récentes sont plus strictes sur la vérification src vs dst. Comme votre destination (dst) renvoie un hash vide, Rclone compare « 85e6704… » avec «  » et conclut logiquement que les fichiers sont différents.

Résumé des actions à tester

Action Impact
Ajouter --ignore-checksum Recommandé. Ignore l’erreur de hash et valide le transfert.
Ajouter --sftp-disable-hashcheck Empêche Rclone de demander le hash au serveur SFTP.

En restaurant l’ancien dossier du plugin de ma precedente sauvegarde c’est OK (donc ancienne version rclone)

Bon n’ayant pas de retour, tu m’as donné l’occasion de me passer du plugin avec des scripts ssh de purge/copie qui ne dépendront plus de mise à jour.

Merci en tout cas pour ces longues années d’utilisation du plugin.

le post initial a juste 2j, fallait peut être laisser plus de temps au dev pour regarder non ?

et puis on ne sait meme pas la version utilisée, ca se trouve en beta ca fonctionne et c deja corrigé ?

La stable du 2026-01-02 (j’avais attendu 1 semaine avant de l’appliquer). Et la beta si tu regardais tu verrais qu’elle n’implemente que le stockage webdav donc rien à voir. Donc ça sert a rien de m’envoyer un pouce en bas …

J’avais pour objectif (et ça n’a rien a voir directement avec ce plugin ou j’étais super satisfait) de supprimer le max de plugin de mon jeedom (trop de surprises a chaque maj de plugin, d’os …), l’occasion était trop belle.

Malgré tout s’il faut debug, le plugin est encore en dormance sur mon jeedom jusqu’à la fin du mois si je peux aider.

Heu tu serais pas un peu gonflé ?

Tu utilises un plugin gratuit mais maintenu et sur lequel le développeur interagit souvent sur ce forum et propose régulièrement des corrections et des améliorations.

Et la parce que tu n’a pas de réponse samedi sur un thread ouvert jeudi, tu te comporte comme si t’étais client d’un outil avec une licence couteuse.

Il serait bon de redescendre un peu …

Sur cet aspect je peux tout à fait comprendre mais bon clairement tout envoyer bouler après 2 jours d’attente ça fait quand même un peu enfant gâté …

2 « J'aime »

le pouce c pour je pose une question et 2 jours apres car le dev réponds pas j’envoies tout bouler…

le dev a une vie et son plugin est gratuit et maintenu !

Je parlais d’une opportunité de basculer, pas de critiquer mais tu dois voir le mal dans chaque post. Je m’en suis pas aperçu de suite donc je voulais pas restaurer mon snapshot. Mais bref a la base je suis sur ce topic pour parler au dev.

Action=>Reaction :grin:

Enfant gâté, j’insiste encore sur le fait de tester le bug rencontré même si j’utilise plus le plugin…

Bonsoir.

Et pourquoi ne pas se passer aussi du plugin script ?
L’envoi d’une sauvegarde vers un NAS, via smb, est native dans le core de Jeedom.
Ou alors le NAS n’est pas sur le même site.

2 « J'aime »

Car c’est un plugin officiel (trèeeees largement utilisé) et j’aurai vraiment beaucoup de mal à faire sans.
Et ce n’est pas que pour la sauvegarde du backup jeedom, je préfère de loin sauvegarder en ssh niveau sécurité que smb. Et oui j’ai aussi des scripts qui envoient sur des nas distants.

absolument pas !

1 « J'aime »

Je vais aller chez l’ophtalmo :laughing:

le tag du post est cloudsyncpro…
et lui n’est pas officiel

enfin bref je laisse tomber…
continues tu es en bonne voie tu as raison.

Je répondais a @Fabrice pour le plugin script.
Bref si mon sujet dérange (apparemment), les modos peuvent le supprimer, l’affaire sera classée.

Bonne soirée.

sambav3

Chiffrement de bout en bout. Les données envoyées entre noeuds SMB 3.0 sont chiffrées par défaut assurant une sécurité optimale des données.

de plus ce genre de sauvegarde est sur le lan, donc le risque…

bref si demain y a un bug core et que sous 2j tu as pas de réponse tu iras sur HA…

1 « J'aime »

Pour ma part, je n’ai aucun souci en SFTP sur un serveur tiers (hors Synology)

Au vu du log d’erreurs, il y a 2 options possibles :
1/ absence du programme md5sum dans l’environnement SSH du Synology
2/ différence au niveau du chemin d’accès entre le SFTP et l’environnement SSH

Pour le prermier cas, il y a l’option « disable_hashcheck » : SFTP - sftp-disable-hashcheck
Pour le deuxième cas, il y a l’option « sftp-path-override » : SFTP - sftp-path-override

Dans tous les cas, il faut toujours vérifier que le checksum à la source est équivalent à la destination

La documentation rclone indique clairement les limitations de ce type de stockage secondaire sur un Synology :
SFTP - Limitations

Merci de ton retour.

Je ne dois pas etre le seul à transferer sur un syno je pense et l’ancienne version de rclone faisait bien le travail mais elle devait peut etre commencer à dater.
Ne pourrait on pas prevoir une option avec genre une case à cocher « synology » qui active une pseudo compatibilité (avec les 2 options que tu as listé) ?

Je peux tester s’il y a quelque chose de faisable.

Merci à toi.

Bon ne t’embetes pas en creusant cette histoire de rclone coté synology, il s’avere qu’il existe un package sur SynoCommunity. (actuellement rclone 1.71 côté syno, tu es en 1.72 ca ne pose pas de soucis)

Installer la source de paquet de la communauté syno :

Chercher le plugin rclone :

Une fois installé le plugin arrive sans problème à executer les commandes telles quelles :-).

Peut etre à ajouter dans la doc si ca peut servir à d’autres.

Merci.

C’est très intéressant, mais pour ma part je ne prendrais pas le risque d’installer ce type de package non officiel sur mon NAS.
Je ne pense donc pas l’ajouter à la documentation, d’autant plus qu’il n’y a plus vraiment d’intérêt puisque tout est désormais géré en dehors du plugin Jeedom :wink:

1 « J'aime »

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.