PPJP

Bonjour Votre IP est fixe et ... vous ne l'avez pas masquée(IPv6) dans vos copies d’écran dans vos pot précédents!

Bonjour Je n'ai pas les compétence pour exploiter les fichiers de log. ABB sur le 1815 était planifiié pour un lancement horaire. La dernière sauvegarde réussie date du 04/04/2020 à 21h15 Ci dessous un extait de /var/log/messages pour la période correspondante. 2020-04-04T21:15:24+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker_session.cpp:1155(11853,140225819868032) [Activebackup-Agent-Task-193(id: 0)] [CMD] Open: file path[PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-04_211500/0.img.tmp], last version path[PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-04_201501/0.img], resume path[] 2020-04-04T21:15:36+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker.cpp:653(11853,140225819868032) [/volume1/ActiveBackupforBusiness/@ActiveBackup] Start checkpoint 2020-04-04T21:15:37+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker_session.cpp:855(11853,140225819868032) [Activebackup-Agent-Task-193(id: 0)] checkpoint done: flush done. 2020-04-04T21:15:41+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker.cpp:245(11853,140225819868032) [/volume1/ActiveBackupforBusiness/@ActiveBackup] End checkpoint 2020-04-04T21:15:41+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker_session.cpp:1443(11853,140225819868032) [SPEED_INFO][Activebackup-Agent-Task-193(id: 0)] chunking[198.58 MB/sec], buffering[2.46 GB/sec], deduping[144.43 MB/sec], bucketing[1.15 GB/sec], composition[231.33 MB/sec], sampling[755.56 MB/sec] 2020-04-04T21:15:41+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker_session.cpp:1155(11853,140225819868032) [Activebackup-Agent-Task-193(id: 0)] [CMD] Open: file path[PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-04_211500/1.img.tmp], last version path[PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-04_201501/1.img], resume path[] 2020-04-04T21:15:55+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker.cpp:653(11853,140225819868032) [/volume1/ActiveBackupforBusiness/@ActiveBackup] Start checkpoint 2020-04-04T21:15:56+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker_session.cpp:855(11853,140225819868032) [Activebackup-Agent-Task-193(id: 0)] checkpoint done: flush done. 2020-04-04T21:15:59+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker.cpp:245(11853,140225819868032) [/volume1/ActiveBackupforBusiness/@ActiveBackup] End checkpoint 2020-04-04T21:15:59+02:00 DiskStation_02 synodedup-engine-worker: [INFO] worker_session.cpp:1443(11853,140225819868032) [SPEED_INFO][Activebackup-Agent-Task-193(id: 0)] chunking[188.70 MB/sec], buffering[2.45 GB/sec], deduping[132.77 MB/sec], bucketing[1.12 GB/sec], composition[180.79 MB/sec], sampling[903.22 MB/sec] 2020-04-05T00:00:03+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:586(18896,139625942227840) [ACTION_START:DELETE_VERSION] Delete versions start. taskId=[1], versionIds=[1453, 1454, 1455, 1456, 1457, 1458, 1459, 1460] 2020-04-05T00:00:03+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:287(18896,139625942227840) Mark delete and collect records. 2020-04-05T00:00:03+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:198(18896,139625942227840) Merge disk change block 2020-04-05T00:00:03+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:344(18896,139625942227840) Run delete. repoPath=[/volume1/ActiveBackupforBusiness/@ActiveBackup], targetDir=[PC-PC09-pjp-pc09_BareMetal], _reclaimSpace=[1] 2020-04-05T00:00:04+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:57(18896,139625942227840) dedup unlink file. filePath=[PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-03_001501/0.img] 2020-04-05T00:00:04+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:70(18896,139625942227840) normal unlink file. path=[/volume1/ActiveBackupforBusiness/@ActiveBackup/PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-03_001501/0.img.delta] 2020-04-05T00:00:04+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:57(18896,139625942227840) dedup unlink file. filePath=[PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-03_001501/1.img] 2020-04-05T00:00:04+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:70(18896,139625942227840) normal unlink file. path=[/volume1/ActiveBackupforBusiness/@ActiveBackup/PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-03_001501/1.img.delta] 2020-04-05T00:00:04+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:70(18896,139625942227840) normal unlink file. path=[/volume1/ActiveBackupforBusiness/@ActiveBackup/PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-03_001501/device_spec] 2020-04-05T00:00:04+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:70(18896,139625942227840) normal unlink file. path=[/volume1/ActiveBackupforBusiness/@ActiveBackup/PC-PC09-pjp-pc09_BareMetal/ActiveBackup_2020-04-03_001501/backup_db.sqlite] 2020-04-05T00:00:14+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:433(18896,139625942227840) Remove version folders. 2020-04-05T00:00:14+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:383(18896,139625942227840) Remove records. 2020-04-05T00:00:14+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:287(18896,139625942227840) Mark delete and collect records. 2020-04-05T00:00:14+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:198(18896,139625942227840) Merge disk change block 2020-04-05T00:00:14+02:00 DiskStation_02 synoabk-deletion: [INFO] version_deleter.cpp:344(18896,139625942227840) Run delete. repoPath=[/volume1/ActiveBackupforBusiness/@ActiveBackup], targetDir=[PC-PC09-pjp-pc09_BareMetal], _reclaimSpace=[1] Ce serait super si vous y trouviez une piste Merci

Je suis chez Orange (ADSL) ,qui, jusqu'à plus ample information, fournit des IP complètes. Et parmi ces soucis, c'est le pb ABB qui me gêne le plus, et lui est en réseau local.

ABB utilise des Ip locales, le pare est ouvert pour la totalités des ports des chaque réseau local. Le port 6281 est ouvert pour la France sur le 1815 qui reçoit les backup distants depuis le site C.

Le problème est bien là, impossible de se connecter. Mais ABB est sur le réseau local et n'utilise que des IP. Donc pas de lien avec le certificat. Je suis certain de l'IP, du nom et du mot de passe utilisés. De même HBP est en attente de vérification de l'état du serveur. L'adresse est un nom de domaine, il s'agit d'un utilisateur spécifique à cette tâche et il est propriétaire du dossier partagé et du répertoire de destination

L'agent ABB et le journal d'HBP m'indiquent seulement un problème de réseau. C'est pour cela que j'indiquais que seuls des certificats avaient été modifiés.

Bonjour, Je poste ici car je ne sais pas choisir la rubrique adéquate. J’ai des soucis depuis quelques jours, sans réussir à en trouver la cause. J ‘espère donc que l’on pourra m’aiguiller dans la bonne voie. Tout d’abord, l’implantation des matériels concernés : Site A : domicile : ds1815+ (+ds413 de backup) Site B :site distant (très loin) : ds218+ Site C :site distant : ds212j Anomalie (par ordre d’apparition) : Site B : Les sauvegardes de 4 PC par ABB avaient été mises en place et les sauvegardes initiales réalisées, mais sans planification. Lorsque j’ai voulu mettre ces planifications en fonction, leur lancement a été impossible (mème manuellement) Site A : Les sauvegardes par ABB qui tournaient régulièrement depuis plusieurs mois se sont arrêtées Site C : Les sauvegardes HyperBackup du ds212 vers le 1815 du site A qui tournaient régulièrement depuis plusieurs semaines$ se sont arrêtées Je n’arrive pas à situer une cause commune à ces différents problèmes. Les seules modifications communes faites sur ces 3 Nas sont des changements de certificats. Je ne vois pas de rapports et ces derniers sont corrects. Je suis dans le brouillard le plus complet, j’espere que l’un d’entre vous pourra me remettre dans la bonne direction. Merci d’avance

Bonjour, Bienvenue sur ce forum. Mais grave erreur dans votre présentation, la Loire-Atlantique est indéniablement en Bretagne!!!

Bonjour, La logique de cette interface graphique repose sur un cycle journalier. Pour une exécution toutes les 2 heures, le paramétrage est: Première exécution 00H 00 Répétition Toutes les 2 heures Dernière exécution 22H 00

Bonjour, Merci, je ne connaissais pas ces commandes. Bien que je n'en ai pas l'utilité actuellement je les ai testées. Elles fonctionnent correctement. Cependant un petit point à noter: Lors du démontage cela engendre un avertissement indiquant que le disque n'a pas été éjecté proprement.

Bonjour, La commande, ci-dessous, en SSH, permet d'effacer la totalité des IP bloquées, mais conserve les IP permises. sqlite3 /etc/synoautoblock.db "delete from AutoBlockIP where DENY = 1;" Attention, les IP éventuellement bloquées par le blocage auto suite à des tentatives d'intrusion seront également effacées. Bonne journée

Bonjour, C'est tout simplement ici:

Bonjour, Ma réponse est tardive mais je ne passe que très irrégulièrement sur ce forum. Vous avez parfaitement corrigé ce script, qui est bien fonctionnel, au moins sur DSM. Les ^M (retour chariot) auraient également pu être supprimés par l'option i. Il reste juste à vérifier cette correction sur SRM, @Superthx pourrait s'en charger. Pour le dernier script que j'avais posté, je n'avais pas pris le temps de rechercher l'origine des doublons et préféré les traiter au sein de SQLite. Je l'avais testé de nombreuses fois sans erreur, je viens de le relancer et il comporte maintenant une (seule) erreur. Je l'efface donc mon post. J'en profite pour vous joindre une nouvelle version du script (correction d'erreurs, ajout facultatif d'infos sur le traitement, ...) Je ne suis pas spécialiste des scripts shell que je n'utilise pas pour mes besoins personnels. Je ne suis intervenu que sur quelques scripts sur ce forum. Mais comme je suis, comme vous, têtu (mes origines!), dès que j'aurai un peu de temps libre je rechercherai l'origine de l'apparition des retours chariot intempestifs. Merci pour votre contribution autoblocksynology.sh

Bonjour, Des erreurs ne sont jamais "normales"! Dans le cas présent, ces erreurs (qui n'existaient pas à l'origine) sont dues à la non suppression des IP en doublon. Cette suppression était faite par les commandes sort -ufo qui ne fonctionnent plus actuellement (pourquoi???) Je vous joins une version du script, où cette suppression est faite au sein de SQLite en remplacement de shell. Cette version est légèrement plus lente que la précédente.

Bonjour, Il ne s’agissait que de remarques sur la forme. Il n'y a aucune conséquence sur le déroulé du script. Je n"ai pas abordé le sujet des paramètres @ et * (d'ailleurs attention avec * ) C'était juste que je m’étonnais que le nom de domaine soit contenu dans une variable fdqn dans la partie classe et zone dans la partie main. Si certains, en plus d'utiliser le script, veulent le comprendre, tout en ayant peu de connaissances des scripts, cela ne leur facilitera pas la tâche. J’arrête ici mon intrusion sur ce tutoriel. PS: Ce script n'a pas d"emplacement impératif, il pouvait rester sur le volume 1. Pour faire simple, vous auriez ainsi pu éviter la partie SSH, qui n'est pas appréciée par tous.

Pour ma part, j'ai toujours eu un réglage à 10 mn. Cela permet de ne pas arrêter le Nas lors de séquences coupure, retour, coupure, retour... assez fréquentes de l'alimentation électrique. Et je n'ai jamais atteint la fin de l'autonomie batterie. Mai, bien sûr, cela dépend de la capacité et de l'état de la batterie.

Bonjour, Je viens m'immiscer dans vos échanges pour apporter quelques éléments complémentaires. J'habite une région très exposée aux tempêtes et vents violents et avec des lignes éclectiques aériennes. J'ai donc une certaine expérience des coupures de courant! J'ai un UPS depuis fort longtemps (12 à 15 ans, je ne sais plus exactement). Mes Nas ont toujours été paramétrés pour couper l'UPS une fois le Nas passé en sécurité (donc bien avant le DSM6) et cela à toujours fonctionné. J'ai encore eu des coupures d’électricité récemment et je n'ai pas constaté un temps de coupure anormal de l'UPS (DSM 6.2.2-24922 Update3). Le problème ne viendrai t’il pas des UPS utilisés qui s’arrêteraient d'eux même au dessous d'une charge minimale? (bien que je n'y crois pas trop) Bonne journée

Bonjour, Deux remarques mineures si vous le permettez. Dans le procédure main: Pourquoi utiliser le nom de variable zone au lieu de fqdn s'agissant du nom de domaine? L'API KEY étant une info "sensible" pourquoi ne pas utiliser l'option, prévue dans le script, de la stocker dans un fichier situé à un emplacement moins accessible, plutôt que de l'indiquer en clair dans le planificateur de tâches?

Vous devriez commencer par tester votre carte mère, car il peut également s'agir d'un pb d'alimentation. Si carte HS vous pouvez tenter de faire prendre en charge votre Nas par le SAV Synology (malgré la garantie de 4 ans expirée). Comment sont formaté vos disques etx4 ou Btrf? Dans tous les cas pour récupérer les données du Raid 5, il vous faudra monter au moins 4 disques dans une tour et utiliser un système Linux. Dans ce cas c'est très simple, utilisez une de vos sauvegardes.

Bonsoir, En êtes-vous sur? Combien avez-vous de disques? Ne seriez vous pas plutôt en raid5 ou SHR? Dans l'affirmative vos donnés sont réparties sur l'ensemble des disques, donc monter un disque dans le 216J ne permettra pas de récuperer des données.

Bonsoir, Le dossier vidéo ainsi les dossiers music et photos sont créés par le serveur multimédia. Ils ne peuvent être supprimés sauf à désinstaller le serveur multimédia

Bonjour, Il serait sans doute souhaitable de revoir l'arborescence des fichiers sur votre carte SD. Le répertoire DCIM (Digital Camera IMage) devrait être réservé à vos photos et vidéos. Vos autres dossiers, Pro, Perso et Documents, devraient être dans des dossiers différents.

Bonjour, Cela n'a jamais été limité aux domaines Synologyy.

Bonjour, Je viens de faire la maj DSM 6.2.2-24922 Update 3. La mise à jour pour le protocole de Let's Encrypt to ACME V2 pouvait laisser penser que les certificats génériques étaient maintenant pris en compte. Je viens de faire l'essai de création d'un certificat générique: impossible le * n'est pas accepté. Dommage!

Bonjour Si vous avez l'intention de commencer un nouveau développement, je vous déconseille d'utiliser python 2.7 qui est maintenant déprécié (fin de vie: 01/01/2020). Partez directement sur du Python3. Je ne sais comment vous avez installé pip (il ne semble pas fonctionnel) ni s'il concerne Python2 (probable) ou Python3 Ce que vous pourriez faire: Afin d'éviter d'avoir des conflits avec plusieurs version de pip, désinstallez la version actuelle: pip uninstall pip Installer le paquet Python3 ( centre de paquets) La version de Synology ne contient pas pip, donc on l'installe: curl -k https://bootstrap.pypa.io/get-pip.py | python3 Il n'y a pas de connecteur SQL simple à installer (dont mysqldb) pour Python3. On utilise donc un équivalent comme, par exemple, PyMySQL ecrit en pur python et qui n'a pas de dépendances Installé par: python3 -m pip install PyMySQL Ensuite c'est a vous de jouer. Par exemple: import pymysql.cursors import pymysql # Connect to the database connection = pymysql.connect(host='localhost', user='user', password='passwd', db='db', charset='utf8mb4', cursorclass=pymysql.cursors.DictCursor) try: with connection.cursor() as cursor: # Create a new record sql = "INSERT INTO `users` (`email`, `password`) VALUES (%s, %s)" cursor.execute(sql, ('webmaster@python.org', 'very-secret')) # connection is not autocommit by default. So you must commit to save # your changes. connection.commit() with connection.cursor() as cursor: # Read a single record sql = "SELECT `id`, `password` FROM `users` WHERE `email`=%s" cursor.execute(sql, ('webmaster@python.org',)) result = cursor.fetchone() print(result) finally: connection.close() En espérant vous avoir mis le bon chemin...