en fait à chaque blocage, voire même des fois avant je supprime l ensemble des fichiers du dossier donc ça ne change rien. même en partant d un dossier vide il crée 4 sauvegardes, la 5eme coince (forcément) alors qu il aurait du faire un roulement à partir de la 4eme…c est pour ça que je poste car je ne comprends pas le problème
Doublez le quota et on verra ensuite.
Si le 5eme rempli le disque/quota, la procédure plante et jeedom ne fera jamais la sauvegarde comme @Poumi l’a dit plusieurs fois.
Non aucune relation, ce n’est pas jeedom qui a implémenté samba.
De plus vous ne seriez pas isolé avec ce problème.
2 « J'aime »
J’ai le même soucis de mon côté, mes backup s’empile alors que je demande de conserver seulement 3 jours
1 « J'aime »
je vais modifier le quota par principe mais pas convaincu dans la mesure où la consigne de suppression au delà de 3 jours n est pas respectée, je pense que ça va juste augmenter le nombre de sauvegardes stockées et répéter le problème à X+1 ou X+2
Bonsoir @temium62
Pour diagnostiquer votre problème, il faudrait ajouter des messages dans la fonction cleanBackupFolder appelée par la fonction backup_send après la sauvegarde locale. Ces 2 fonctions sont dans le fichier core/repo/samba.repo.php
Exemple de modif de la fonction :
public static function cleanBackupFolder() {
$timelimit = strtotime('-' . config::byKey('samba::keepDays') . ' days');
log::add(__CLASS__,'error', 'Timelimit: '.date('Y-m-d H:i:s',$timelimit)); // AJOUT pour avoir la date limite de rétention
foreach (self::ls(config::byKey('samba::backup::folder')) as $file) {
if($file['filename'] == '..' || $file['filename'] == '.'){
continue;
}
log::add(__CLASS__,'error', 'Backup: '.json_encode($file)); // AJOUT pour avoir les caractéristiques des fichiers présents
if ($timelimit > strtotime($file['datetime'])) {
echo 'Delete backup too old : '.json_encode($file);
$cmd = self::makeSambaCommand('cd ' . config::byKey('samba::backup::folder') . ';del ' . $file['filename']);
com_shell::execute($cmd);
}
}
}
Les résultats seront dans le log repo.samba.
Avez-vous une explication sur la taille de la sauvegarde du 22 qui fait 40Mo de moins que celles des jours précédents?
Le nettoyage étant basé sur la date des fichiers, il faut que l’heure de Jeedom et celle du NAS soient synchro.
Le quota sur le NAS ne laisse pas suffisamment de place pour les sauvegardes.
Avec mes différents essais sur la fonction, j’ai 12 backups pour une rétention de 8 jours.
2 « J'aime »
merci beaucoup JPTY
par contre, « concrètement », comment on fait tout ça? 
sauf qu’avec l’erreur d’espace disque, le code n’arrive pas jusqu’à cette étape…
2 « J'aime »
Je ne compte même plus le nombre de fois que cette info a été donnée…
1 « J'aime »
oui…
pour ma part c’est la derniere fois que je la donne, apres j’abandonne
1 « J'aime »
Je ne suis pas certain de cela.
Si le log backup contient Send backup Samba..., la copie de la sauvegarde samba s’exécute suivie du nettoyage sans test d’erreurs.
La méthode de la classe repo_samba:
public static function backup_send($_path) {
$pathinfo = pathinfo($_path);
$cmd = 'cd ' . $pathinfo['dirname'] . ';';
$cmd .= self::makeSambaCommand('cd ' . config::byKey('samba::backup::folder') . ';put ' . $pathinfo['basename']);
com_shell::execute($cmd);
self::cleanBackupFolder();
}
Difficile à déterminer ce qu’il se passe avec juste le message d’erreur sans le déroulement comme on peut le voir dans les différents messages au dessus.
Peut être que Le send raise une exception qui n’est pas catch et donc le clean ne se fait pas.
1 « J'aime »
Exact. Je n’avais pas creusé assez loin les sources.
com_shell::execute appelle com_shell::exec qui contient un throw si erreur d’exécution.
Le but de la modif de la fonction cleanBackupFolder est de voir comment sont horodatés les premiers backups sur le NAS quand ça fonctionne.
il est meme logique que le clean ne se fasse que si le backup est bien copié, sinon c’est un coup a supprimer tous ses backups 
3 « J'aime »
Bonsoir @Poumi
La contrepartie de cette logique est que s’il y a problème de sauvegarde du à l’espace disque, les copies des nouveaux backups ne se font plus. Il faut obligatoirement une intervention manuelle pour que ça reparte.
La solution de nettoyer avant permettrait de faire de la place avant de copier le nouveau backup. Ça s’auto-répare.
Que faut-il préférer?
Backups pas à jour vs Pas de backups?
Pourquoi mettre des quotas à cet endroit ?
Vrai uniquement en cas de disque full et dans tous les autres cas d’erreur cela risque de tout supprimer donc il y a toujours moyen de multiplier les scénario et coder tous les use cases mais si on veut garder le système simple il faut faire des choix et perso j’adhère à la logique actuelle.
Ça c’est la vrai question surtout qu’il y a probablement plusieurs Tera de disponible sur ce nas mais ce n’est pas @Poumi qui va pouvoir répondre 
Pour revenir à la place nécessaire, elle est de (n+2) multiplier par la taille du backup (qui va évoluer à la hausse ou à la baisse dans le temps) où n est le nombre de jour de rétention.
N+1 en permanence car n jours en arrière plus le backup du jour (jour 0)
+1 pour copier celui du jour et ensuite supprimer celui d’il y a n+1 jour
=> n+2
Donc 5 si 3 jours de rétention.
1 « J'aime »
hello
j ai mis un quota car j ai 2 synos et les sauvegardes jeedom se font sur celui qui n a plus beaucoup d espace dispo,
là j ai monté le quota à 900Mo, viré tout le dossier, passé le nombre de jours en backup à 2, on verra…
suite (et pas fin) : comme dit plus haut le nombre de sauvegardes a été modifié de 3 à 2 et aujourd hui mon dossier comporte 3 sauvegardes, correspondant à 3 jours…donc l augmentation du quota je pense ne fera que retarder l échéance…
As-tu encore une erreur dans les logs?
Si oui, envoi l’erreur
Sinon, montre nous la config sauvegarde samba et une capture du dossier
Donc c’est normal: c’est 2 jours en arrière !
Déjà dit 15 fois.
Relisez mon post ou je détaille la place nécessaire.
N+1 sauvegardes en permanence: sauvegarde du jour + n jours.
1 « J'aime »