bruno78

@Juan luis je n'utilise de mon côté que HyperBackup (ça correspond à mon besoin). Le fait de sauvegarder ou pas des applis (et donc leurs données/paramétrages) ne dépend pas de la cible, mais du paquet lui-même. Certains paquets sont sauvegardables, .... d'autres non. Ma stratégie de backup est à présent la suivante avec HyperBackup (après être passé par une restauration complète qui fait bien flipper et qui instantanément met le doute sur ce que l'on a fait comme sauvegarde, jamais testée, ni jamais vraiment vérifié la complétude ou la cohérence) : j'ai 1 DD reservé aux backups dans le NAS => backup (données et appli) local en ligne des 3 autres DD toutes les 4 heures. Ce serait la source de restauration en première intention, locale donc rapide. je fais (à la main environ 1 fois par semaine, suivant les grosses évolutions ou pas ) un backup externe sur un DD USB, que je ne laisse pas en ligne. enfin je fais une fois par jour un backup en ligne externe (service Synology C2, pour les données les plus importantes) ..... en cas de scenario du pire localement .... Ces 3 backups, sur 3 supports distincts, sont faits avec HyperBackup, gèrent les versions, et permettent la sauvegardes des applis et leurs configurations ... pour celles qui y sont éligibles. Chacune de ces 3 taches est personnalisée en fonction de la capacité du support cible, mais aussi et surtout en fonction de la "valeur" des différentes données. A noter que je ne fais pas de "backup de backup" ! Chacune des 3 taches prend les données sources, initiales, comme source de la tache de backup. C'est vrai que rapidement il faut se poser 5 minutes, et faire le tour des scenarios : dd en panne, volume en panne, groupe de stockage en panne, NAS en panne, NAS détruit/volé.... . Dans chaque cas savoir et vérifier où se trouve la sauvegarde et comment je fais pour restaurer. Et pour être complet, se demander aussi comment je fais si l'un sur 3 des backups est KO/HS/inaccessible .... . Savoir si on est prêt à perdre 1 heure de boulot, 1 jour , 1 semaine ..... les dernières photos du weekend .....

@.Shad., @TuringFan je confirme !! pour avoir été confronté recemment à une restoration complète, la sauvegarde distante hors site (C2 dans mon cas) fonctionne parfaitement, .... mais les temps de restoration ne sont pas vraiment comparables avec une sauvegarde locale sur DD externe (même avec une connexion fibre) ! Je pense que les 2 sont nécessaires (en fonction de la "valeur" que l'on attribue à ses données évidemment) : sauvegarde locale sur DD externe, et sauvegarde hors site .... pour le scenario du pire !

@Jeff777 bonjour, oui c'est cela ...

@nebelnic bonjour, il serait tout de même bon de connaitre la cause de l’échec. Après, cela m'est déjà arrivé, ça peut planter un jour et passer le lendemain. Ce peut venir soit de LE, soit d'OVH, ..., des tempos ... Si tu recherches dans le log par exemple le mot clé "error", ca te dit quoi ? Pour sécuriser ton log, a minima, tu remplaces globalement ton domaine.tld par "ndd.tld", ça éliminera déjà pas mal de chose . Tu peux aussi envoyer ton log par MP. cdt, bruno78

Bonsoir, encore perdu les caches SSD (nouveaux jeux depuis le plantage précédent !!). Redémarrage du NAS au bouton (!) encore une fois. J’arrête les frais avec ces caches SSD. (modèles inclus dans la compatibility liste pourtant). Et par ailleurs, je suis revenu à 8GB de RAM avec mes barettes d'origine Syno. Je ne peux pas être plus conforme que cela aux spécifs Syno .... . Cette fois ci ils étaient montés en RO sans protection, chacun sur un volume différent. Les 2 ont planté en même temps. et les contenus ont été rincés (sans dommages puisque en Read Only). Je vais les sortir et les recycler ailleurs. Cdt, Bruno78 a priori les logs sont encore là, je vais voir si je trouve quelque chose ....

@.Shad. @oracle7 @MilesTEG1 @Jeff777, visiblement le problème speedtest apparu cette nuit est largement répandu. Une solution a été trouvée ici : https://github.com/sivel/speedtest-cli/pull/769/files Il faut donc inclure un nouveau script python "speedtest.py". Je vous propose donc une mise à jour de l'image "speedtest2". Vous trouverez dans le fichier joint 2 nouveaux fichiers : Dockerfile et speedtest.py . speedtest_fix.tar Placer ce fichier speedtest_fix.tar dans votre répertoire <speedtest>, Décompressez le (# tar xvf speedtest_fix.tar) puis relancer la procédure de création de l'image speedtest2 telle que décrite en page 22 de ce fil. Le nouveau Dockerfile va inclure dans l'image le fichier speedtest.py corrigé, et ensuite il ne doit plus y avoir de problème. Je ne relivre pas le fichier Influxdbspeedtest.py car il n'évolue pas. Testé rapidement chez moi ca semble OK, mais dites moi ce qu'il en est chez vous. bruno78

@.Shad. oui j'ai commencer à travailler avec cette image .... soit je ne l'ai pas configurée convenablement, soit elle me donne vraiment des résultats étranges .... du coup je tentais d'adapter l'image d'origine pour du influxv2. Il faut que je reprenne cette tache.

@oracle7 @Jeff777 bonjour, cela ressemble un un pb de mise à jour d'image speedtest que vous avez du subir en même temps ! Avez vous essayer de reconstruire l'image speedtest2 ? Je ne pourrai pas faire de tests avant ce soir .... bruno78

@oracle7 bonjour, de ce que je vois de ton log, le test de connectivité à influxdb est successful : Or il s'agit là de la seule modification que j'ai faite pour cette nouvelle image. L'erreur semble plutôt venir du module speedtest.py : Il faudrait aller voir ce qu'il y a en ligne 1174 de speedtest.py. Mon container speedtest n'est pas en service actuellement, je suis en train de l'adapter pour Influxdb-V2 (c'est pas gagné !). Je vais voir si je peux relancer temporairement avec influxdb-V1. Cdt, bruno78

@Spudboy, le seul conseil que je pourrais donner, c'est de mettre à jour globalement vers la dernière version DSM 6.2.4-25556-1 si je ne me trompe pas et de vérifier le comportement. Pas de comportement bizarre pour d'autres paquets Syno ? Pas de configuration "baroque" ou trop personnalisée ? Si le problème persiste (et semble systématique), faire appel à l'assistance Syno qui demandera surement à pouvoir prendre la main sur la machine.

@Spudboy heu .. non ça n'arrive pas a priori . Tu peux en dire un peu plus sur le contexte : quelle mise à jour ? de quoi ? comment ? Quels messages dans le journal après le reboot ? .... Quelle version de DSM ?

@Funroc je pense que l'erreur rencontrée est là : [Mon Apr 5 00:00:09 CEST 2021] validationUrl='eu.api.ovh.com/auth/?credentialToken=QsX7XyN26fsToATtzPxi03luZ1JMDty7957Jhcdv2BXQNlh8orcVjetMvmznY5Se' [Mon Apr 5 00:00:09 CEST 2021] consumerKey='[hidden](please add '--output-insecure' to see this value)' [Mon Apr 5 00:00:09 CEST 2021] Please open this link to do authentication: eu.api.ovh.com/auth/?credentialToken=QsX7XyN26fsToATtzPxi03luZ1JMDty7957Jhcdv2BXQNlh8orcVjetMvmznY5Se [Mon Apr 5 00:00:09 CEST 2021] Here is a guide for you: github.com/acmesh-official/acme.sh/wiki/How-to-use-OVH-domain-api [Mon Apr 5 00:00:09 CEST 2021] Please retry after the authentication is done. [Mon Apr 5 00:00:09 CEST 2021] Error add txt for domain:_acme-challenge.nnd.tld [Mon Apr 5 00:00:09 CEST 2021] _on_issue_err [Mon Apr 5 00:00:09 CEST 2021] Please check log file for more details: /volume1/Certs/Acme_renew/acmelog En général cela arrive lorsque les tokens sur le site OVH n'ont pas été créés avec une validité permanente, et donc là il y a fort à parier qu'ils ont expirés ....

Bonjour @Funroc, peux-tu stp fournir le log acmelog ? (attention à bien l'anonymiser, ou alors par MP) Cependant, avec un DS1621+, je conseillerai (sans vouloir botter en touche) d'utiliser la méthode via docker décrite ici : Cdt, bruno78

@.Shad. j'ai trouvé un palliatif, mais pas d'explication pour le moment. arrêt du docker PIHole suppression complète de tout ce qui concerne le réseau docker macvlan Depuis le paquet VPN : maintenant on peut configurer une interface dans l'onglet "Paramètres Généraux" la première valeur qui apparait furtivement : bridgemacvlan .... tiens tiens ! mais en dessous dans la liste on peut enfin sélectionner l'interface principale du NAS Dés lors, on redémarre le serveur l2tp, et dans le log auth.log les ports sont bien mappés sur l'interface du NAS. La connexion l2tp/ipsec est de suite établie sans problème. On peut alors reconfigurer notre réseau docker macvlan, puis relancer le docker PiHole. Il est "amusant" de constater qu'alors, dans les paramètres généraux, le champ "interface réseau" est redevenu vierge ..... En résumé, il a fallu configurer le l2tp/ipsec AVANT le réseau docker macvlan. Je vais chercher un peu pour voir si il y a des articles sur le sujet. Cdt, bruno78

@.Shad. OK je regarde ce que je peux faire de plus.

@.Shad., bonjour, tu as raison, il s'agit bien de l'interface virtuelle du sous réseau macvlan, et pas du Pihole lui-même. aucun changement en autorisant les ports L2TP uniquement sur l'interface eth0 (les interfaces disponibles dans le pare-feu sont global, LAN1, LAN2, PPPoE, VPN) Par contre, j'ai remarqué que dans l'interface de gestion du serveur VPN, onglet "Paramètres Généraux", le champ Interface Réseau est vide, et il est impossible d'y rentrer une quelconque valeur. Mais je ne suis pas sûr de ce qi devrait y figurer ?? bruno78

Bonjour, j'ai un problème sur lequel je butte depuis plusieurs jours ... Pour des raisons qui n'ont rien à voir avec le VPN, j'ai du entièrement ré-initialiser mon NAS. En ce qui concerne le VPN, redémarrage sans problème du serveur Openvpn. Par contre, impossible d'établir une connexion L2TP, quelle que soit l'origine (Win10, Android, Ubuntu ....). Après de multiples traces infructueuses, je finis par aller voir le log /var/log/auth.log. ... Et là ... Ça part plutôt bien : Ensuite ça se gâte ... (mais je ne sais pas si 'est normal ou pas .... mais je n'aime pas les ERROR ... Ça poursuit quand même : a priori tout va bien Et ça termine en apothéose : => il attribue les ports 500 et 4500 à l'interface macvlan utilisée pour le docker PiHole !!! ???? Ce qui est confirmé par un netstat : Et donc si pour le test je mets disable le link "bridgemacvlan", du coup il me dit qu'il n'y a plus d'interface publique : A ce stade, j'ai épuisé les idées .... et si ça se trouve l'erreur doit être grosse comme une maison, .... mais je ne vois pas .... Merci de votre aide. bruno78

Hello, @MilesTEG1 ça ne serait pas par hasard mon post du 10/février en page 29 ?? Bruno78 PS : dsl je ne suis pas très assidu, mais outre le taff, je suis toujours en train de restaurer mon DS918 après son dernier crash et la perte complète du volume1. Je me rends compte que mes sauvegardes n'était pas si parfaites que cela, loin de là. Même si au final je ne perds pas de données (ça reste encore à prouver), la remise en route est longue et fastidieuse. Je ferai à l'occasion (après) une petite synthèse là dessus, ça peut être utile.

@MilesTEG1 bonjour, j'avais donné, en page 22 de ce fil dans un post du 7/janvier une méthode pour ne pas avoir à utiliser un user admin pour la db ... parce que oui, sinon, avec cette image par defaut pour tester la connexion à la bdd il utilise un compte admin. J'avais modifié le script Python pour éviter cela, mais cela demande une modification de l'image speedtest. Cdt, bruno78

Oui, je pense que je vais un peu séparer les variables. Je viens de re-installer DSM7 (partition système). Il voit toujours le volume1 manquant. Dois-le supprimer et le recréer avant de lancer la restauration HyperBackup ?

@maxou56 bonjour, et si on pousse encore plus loin, avec 2 SSD MVNe, je pense qu'on doit pouvoir faire du cache SSD en lecture seule pour chacun des 2 volumes ? 1 SSD par volume, qu'ils soient ou non dans le même groupe de stockage ?

@.Shad., ça va finir comme ça ! Je ne suis pas sûr de les remettre en service en tant que cache SSD. Dommage. Je vais attaquer la re-installation, puis la restauration des données. Moi qui me disait "faudra quand même faire un test de restauration un de ces jours .... ", => test en grandeur réelle. Si je devais perdre toutes mes photos, je sens que ça ne me mettrait pas de bonne humeur, mais a priori toutes les précautions ont été prises, donc ... on croise les doigts. Après, ça fait réfléchir sur le fait de tout faire sur le même NAS : stockage, serveur web, serveur multimédia .... . Ce n'est pas forcement la bonne stratégie.

Bonjour, ça ne sent vraiment pas bon pour le volume1. Autant volume2 est là (il n'avait pas de cache ssd !), autant volume1 ..... root@ds918blam:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/md0 2.3G 1.9G 276M 88% / devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 100K 3.9G 1% /dev/shm tmpfs 3.9G 15M 3.8G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs 3.9G 1.7M 3.9G 1% /tmp tmpfs 781M 0 781M 0% /run/user/196791 /dev/mapper/cachedev_0 5.3T 495G 4.8T 10% /volume2 root@ds918blam:~# cd /volume1 root@ds918blam:/volume1# ls @eaDir root@ds918blam:/volume1# du 8 ./@eaDir/video2 8 ./@eaDir/FreeFileSync 8 ./@eaDir/Drive_Alain_ActiveBackup 8 ./@eaDir/homes 8 ./@eaDir/Share 8 ./@eaDir/web 8 ./@eaDir/file_history 8 ./@eaDir/Equipe 8 ./@eaDir/photo 8 ./@eaDir/web_packages 8 ./@eaDir/video 8 ./@eaDir/ActiveBackupforBusiness 8 ./@eaDir/music 8 ./@eaDir/NetBackup 8 ./@eaDir/docker 8 ./@eaDir/MailPlus 132 ./@eaDir 136 . root@ds918blam:/volume1# du -sh 136K . root@ds918blam:/volume1# du -sh @eaDir/homes 8.0K @eaDir/homes root@ds918blam:/volume1# Sauf idée géniale de dernière minute, j'attaque la ré-installation de DSM puis lance une restauration de ma dernière sauvegarde (Syno C2) de volume1. Pas beaucoup de risque puisque les données ne semblent plus être accessibles ....

Super ! cette fois, je suis dans la mouise !! Au redémarrage forcé, Il a perdu le volume 1 : Et je ne vois pas ce que je peux faire. Je ne peux même pas supprimer le cache SSD ... Demain il fera jour ! (PS : et à la question : as tu des sauvegardes, la réponse est oui .... au moins de l'essentiel !! )

Bonsoir, finalement pas si terminé que je ne le pensais !! En 8 jours, 2 plantages, avec toujours les caches SSD impliqués de près ou de loin. dans l'avant dernier plantage, il y a 8 jours, les SSD NVME étaient toujours physiquement dans la machine, mais le cache SSD désactivé. => plantage pour le dernier plantage, ce soir, avec de nouveaux SSD NVME (WD au lieu de Samsung, 500GB au lieu de 250GB), pareil, replantage de la machine qui reste dans un état très bizarre. Certains services fonctionnent, pas d'autres. Mais à chaque fois les SSD Cache disparaissent du monitoring. Du coup au niveau piste d'investigation, il ne me reste que la carte mère qui pourrait avoir des vapeurs au niveau de ses ports NVME ?? ou alors (je sais qu'on en a déjà parlé) un pb avec les 16GB de RAM ???? Ce dernier point est facile à gérer, j'ai toujours mes 2 barrettes de 4GB d'origine. Je vais les remettre en place momentanément (ce qui sera aussi plus facile lors des contacts avec le support Syno). Après je me dis qu'une ré-installation complète de DSM pourrait aussi être salutaire ? (3 plantages rapprochés avec des effets de bord bizarres même si apparemment pas de perte de données perso ....). D'ailleurs, comment faire une installation de DSM 7 Beta propre ?? Repasser par DSM6 puis upgrade ? ou alors peut’ on installer l'image DSM7 directement ? Arrrrggggg !!!! Cdt, Bruno78