PB Sauvegarde SAMBA

[ktn]

@iznogood

jeedompi@FreePiJDom:~$ sudo su
root@FreePiJDom:/home/jeedompi#cd
root@FreePiJDom:~#ssh [jeedompi@192.168.0.9]
j’obtiens :
[jeedompi@NASF62441 ~]$

Ceci montre que les clés ssh sont bien déployées. Il a été possible de se connecter sur le 192.168.0.9, compte jeedompi depuis le compte root de FreePiJDom sans avoir besoin de saisir le password.

Maintenant, il faut un répertoire existant pour accueillir les copies de backup. Je propose de simplement créer un répertoire dans le HOMEDIR de jeedompi sur 192.168.0.9

Depuis le compte rootsur FreeOiJDom, faire un ssh jeedompi@192.168.0.9
Ensuite, lancer le commande mkdir backup_jeedom

 [jeedompi@NASF62441 ~]$ mkdir backup_jeedom
 [jeedompi@NASF62441 ~]$ exit

On peut enfin configurer les sauvegardes jeedom

[Backup] IP :             192.168.0.9
[Backup] Utilisateur :    jeedompi
[Backup] Chemin:          /share/homes/jeedompi/backup_jeedom

Un test devrait être concluant

[iznogood]

@ktn

On peut enfin configurer les sauvegardes jeedom

[Backup] IP :             192.168.0.9
[Backup] Utilisateur :    jeedompi
[Backup] Chemin:          /share/homes/jeedompi/backup_jeedom

Un test devrait être concluant

Le test à été concluant.
Du coup j’ai lancé une sauvegarde pour aller jusqu’au bout
retour d’erreur :

Erreur sur sudo ssh jeedompi@192.168.0.9 rm /share/homes/jeedompi/backups_jeedom/ 2>&1 valeur retournée : 1. Détails : rm: '/share/homes/jeedompi/backups_jeedom' is a directory

Information de la sauvegarde :

[START BACKUP]
***************Start of Jeedom backup at 2021-03-30 09:29:50***************
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...
tar: .: file changed as we read it
OK
Nettoyage de l'ancienne sauvegarde...OK
Send backup Ssh...
Delete backup too old :
{"filename":"backup-FreePiJDom-4.1.20-2021-03-30-09h29.tar.gz","size":"151879090","datetime":"2021-03-30 09:34:00"}
Delete backup too old :
{"filename":null,"size":null,"datetime":"2021-03-30 09:32:31"}[2021-03-30 09:32:32][ERROR] : Erreur sur sudo ssh jeedompi@192.168.0.9 rm /share/homes/jeedompi/backups_jeedom// 2>&1 valeur retournée : 1. Détails : rm: '/share/homes/jeedompi/backups_jeedom' is a directory
/!\ Erreur sur sudo ssh jeedompi@192.168.0.9 rm /share/homes/jeedompi/backups_jeedom// 2>&1 valeur retournée : 1. Détails : rm: '/share/homes/jeedompi/backups_jeedom' is a directory /!\OK
Limitation de la taille des sauvegardes à 500 Mo...
OK
Nom de la sauvegarde : /var/www/html/core/php/../../backup/backup-FreePiJDom-4.1.20-2021-03-30-09h29.tar.gz
Vérification des droits sur les fichiers...
OK
Envoi l'évènement de fin de sauvegarde...OK
Durée de la sauvegarde : 164s
***************Fin de la sauvegarde de Jeedom***************
[END BACKUP SUCCESS]

[legeantvert]

Bonjour,
Je suis en Jeedom 4.1.20.
Depuis quelques temps, j’avais également des erreurs timeout et mon backup sur nas (Syno) ne faisait que 50 à 100Mo alors que le complet fait environ 230Mo.
Après avoir modifié le fichier /core/repo/samba.repo.php ligne 134 pour forcer le timeout à 120s :

	public static function makeSambaCommand($_cmd, $_type = 'backup') {
		return system::getCmdSudo() . 'smbclient -t 120 ' . config::byKey('samba::' . $_type . '::share') . ' -U "' . config::byKey('samba::' . $_type . '::username') . '%' . config::byKey('samba::' . $_type . '::password') . '" -I ' . config::byKey('samba::' . $_type . '::ip') . ' -c "' . $_cmd . '"';
	}

et avoir redémarré… Les backup semblent maintenant passer l’etape de copie pour moi… Reste à vérifier sur le long terme.
Ce que je ne comprend pas c’est qu’en reprenant la ligne de commande de copie en echec dans le log et en l’exécutant en ssh cela passait toujours sans problème…
Bon courage.

[ktn]

Si le timeout de 120 résoud ton problème ( il semble que ce ne soit pas le cas pour @iznogood ) je te suggère d’utiliser la méthode de @oozean:

Sauvegarde SAMBA Timeout client SMB

Bonjour, Je suis partiellement d’accord avec toi. En effet, le problème peut venir de chacun des équipements entre Jeedom et le NAS. J’ai pu notamment remarquer de grosses latences lorsque je suis en Wifi depuis que j’ai installé en Raspbian Buster. Je suis depuis passé en RJ45 mais la configuration de ma maison m’impose de passer par un CPL dont la connexion est moyenne également. Cependant, je suis d’accord sur le fait qu’il serait bien de pouvoir rendre ce paramètre configurable, c’est u…

Le paramètre -t 120 dans la configuration résistera bien mieux à une mise à jour que si tu modifies le code qui sera écrasé lorsque tu passeras à une version supérieur du core.

[ktn]

Je ne comprend pas d’où vient l’erreur. J’ai l’impression que c’est parce que le répertoire est encore vide mais je n’ai pas réussi à le reproduire chez moi.
J’ai un NAS Synology DS415play et toi?

Après ton backup, est-ce que tu a quelques chose dans la liste Sauvegardes disponibles

Si oui, refait un backup pour vérifier si tu as toujours le message d’erreur.

[iznogood]

J’ai un Snap TS-453A
Après le backup la liste des sauvegardes reste vide.
J’ai même essayé de faire 2 sauvegardes à la suite.
Demain matin je vais essayer de mettre une sauvegarde que j’ai avant tout ces soucis et lancer une sauvegarde avec un dossier non vide.

[ktn]

Il serai intéressant d’avoir le résultat de la commande ls -l /share/homes/jeedompi/baclup_jeedom pour que je le compare avec le résultat de la commande équivalente sur mon Synology.
Les formats sont probablement différents et, si ça se confirme, il faudra que je trouve le moyen d’adapter mon code.

[iznogood]

J’espère que c’est ce que tu voulais

09H12 j’ai relancé une sauvegarde et en même temps j’ai scruté mon dossier de destination je me suis rendu compte que pendant le « send backup ssh… » le transfert ce faisait et qu’à la fin il supprime le fichier de sauvegarde qu’il est en train d’envoyer…
Le fichier doit faire au final à peut prés 152Mo alors que la limite par défaut et de 500Mo.
Jai même changé le dossier de destination et même soucis.

[ktn]

Le format de sortie de ta commande ls -l me semble plus conforme à ce que l’on a l’habitude de voir sous Unix/Linux que le format de la même commande mon Synology.

Je vais voir ce soir si j’arrive à adapter mon code pour qu’il puisse fonctionner avec les deux formats.

Il y a tout de même une bonne nouvelle: ton transfert fonctionne

[iznogood]

Oui le transfert fonctionne jusqu’au bout dommage qu’il le supprime à la fin bizarre

[ktn]

En attendant une solution définitive, je te propose de mettre le contenu de la fonction cleanBackupFolder comme ceci:

public static function cleanBackupFolder() {
//    $timelimit = strtotime('-' . config::byKey('ssh::keepDays') . ' days');
//    foreach (self::ls(config::byKey('ssh::backup::folder')) as $file) {
//        if($file['filename'] == '..' || $file['filename'] == '.'){
//            continue;
//        }
//        if ($timelimit > strtotime($file['datetime'])) {
//            echo 'Delete backup too old : '.json_encode($file);
//            $cmd = self::makeSshCommand('rm ' . config::byKey('ssh::backup::folder') . '/' . $file['filename']);
//            com_shell::execute($cmd);
//        }
//    }
}   

[ktn]

Peux-tu me retourner le résultat de ls -l --time-style="+%s" /share/homes/jeedompi/ ?

J’aimerai vérifier que le ls de ton NAS accepte l’option --time-style

[iznogood]

Bonjour,

[jeedompi@NASF62441 ~]$ ls -l --time-style="+%s" /share/homes/jeedompi
total 8
drwxrwx--- 2 admin everyone       4096 1617253426 backups_jeedom/
lrwxrwxrwx 1 admin administrators   30 1616840576 @Recycle -> /share/homes/@Recycle/jeedompi/
[jeedompi@NASF62441 ~]$

J’ai fait la modification du fichier comme indiqué tout à fonctionné. Archive crée et sauvegardée dans le dossier voulu.

[ktn]

Super, j’ai une modif du script qui utilise l’option --time-style. Je la poste ce soir.

[iznogood]

Super merci

[ktn]

ssh.repo.php.txt (5,3 Ko)

Voilà la nouvelle version qui devrait aussi fonctionner avec ton NAS. J’en ai profité pour finalisé la fonction de rapatriement des fichiers qui ne fonctionnait pas correctement.

Il y a une petite différence dans la fonction de rapatriement par rapport à celle pour le repos samba:

• Le rapatriement du repos ssh rapatrie le fichier.
• Le rapatriement du repos samba rapatrie le fichier puis lance un « restore »
• Le rapatriement du repos market (cloud) rapatrie le fichier

Il y a juste un petit soucis: l’icône tournante affichée sur le bouton de rapatriement ne disparaît pas en fin de rapatriement.

[iznogood]

Bonjour,

Merci pour tout, la fonction de sauvegarde s’exécute bien.

@ktn

Il y a juste un petit soucis: l’icône tournante affichée sur le bouton de rapatriement ne disparaît pas en fin de rapatriement.

Je rafraichi ma page tout simplement ce qui me permet aussi de rafraichir la liste des sauvegardes disponibles dans la combo des sauvegardes locales.