CyberFr

D'après Synology soi-même : Les erreurs du système de fichiers sont généralement dues aux problèmes de disque suivants : Secteurs défectueux Installation incorrecte du disque dur Disques incompatibles Problème matériel Tu n'es pas passé par la case Présentation, pour le coup on ne sait pas quelle est ta configuration et ta version de DSM. Il existe une documentation que tu trouveras ICI. Le problème est que la tentative de réparation effectuée par DSM a échoué.

Je parlais de tests S.M.A.R.T. approfondis et ces tests durent bien plus longtemps que quelques heures. Chez moi ils prennent environ 12 heures pour deux disques.

Tu en est bien certain ? Les tests S.M.A.R.T sont au vert ? Il n'y a pas de secteurs défectueux ou d'autres problèmes signalés ? Tu pourrais effectuer un test S.M.A.R.T. approfondi pour le vérifier. Utilises-tu Scrutiny ?

À ta place je commencerais par vérifier l'état de santé de chacun des disques dans le Gestionnaire de stockage et j'aviserais en conséquence.

Ça vous intéresserait d'avoir un fichier de config docker pour JDownloader2 ? J'en ai un tout prêt.

Mais les conseilleurs ne sont pas les payeurs 😀 Tu dois faire une sauvegarde en fonction des changements intervenus dans le NAS entre deux dates. Si tu ajoutes ou modifies plein de données, il vaut mieux que les sauvegardes soient rapprochées. Mais DSM est un système fiable et il y a peu de chances que les données soient corrompues. Sauf en cas de cyber-attaque mais si tu as appliqué le tuto suivant, la sécurité de ton NAS est assurée : En ce qui me concerne (mais une fois de plus les conseilleurs ne sont pas les payeurs) j'effectue une sauvegarde une fois par semaine. Ce qui ne m'empêche pas de lancer une sauvegarde en dehors de celles programmées si j'ai apporté des modifications importantes, par exemple l'ajout d'un paquet ou d'une application en docker. Amélie, tu as un Mac et donc démonter un disque sur le NAS est équivalent à démonter un disque sur le Mac, ce n'est pas plus compliqué. Démonter un disque c'est l'éjecter. Après quoi il vaut mieux l'éteindre pour d'autres raisons. Quand tu cliques sur l’icône du disque (la première à gauche sur la partie droite) une fenêtre te propose de l'éjecter. Après il ne reste plus qu'à l'éteindre. Inversement le fait d'allumer le disque fait que cette icône apparait et tu peux commencer à sauvegarder.

Non, tu dois simplement changer l'heure à laquelle se déroule la sauvegarde. L'idée est que celle-ci se déroule à une heure où tu es réveillée de sorte que tu puisses démonter le disque de sauvegarde après que la tâche ait été effectuée. Reste à savoir si tu as vraiment besoin d'effectuer une sauvegarde tous les jours mais tu es la seule à pouvoir en juger. Sinon il existe des solutions comme Synology C2 Storage mais c'est payant.

Dans ces conditions tu n'as pas la possibilité de démonter le disque USB après la sauvegarde. Le mieux serait de modifier la planification et cela se passe dans : Hyper Backup > Paramètres de tâche > Programmer J'ai choisi 19 heures parce que j'ai la main après la sauvegarde. J'ai aussi un script qui démonte le disque de sauvegarde mais cela devient compliqué par rapport à tes besoins.

Bonjour @Arnhoo92 et bienvenue. Effectivement ton NAS commence à dater même s'il te donne entière satisfaction. Il était sans doute à la pointe en ... 2009 mais le temps a passé.

Dans ce cas il faut changer de stratégie de telle sorte que le disque externe USB soit démonté en fin de sauvegarde.

Ou la la ! Il faut vite ouvrir un sujet « Musée » sur le forum ! Et il y aura du monde pour participer 😀

C'est tout à fait normal dans ce cas. Mais il est conseillé de démonter le disque externe quand tu ne fais pas de sauvegardes car si le NAS subit une attaque, le disque est accessible ce qui pose un problème de sécurité. Ce disque est ton ultime assurance sur la vie.

J'en suis ravi. Au passage, je vois que tu as un dossier ubshare2 sur le NAS. J'espère que tu ne sauvegardes pas tes données avec HyperBackup sur un dossier partagé. Rassure-nous 😀

C'est ça, il faut simplement supprimer le contenu du dossier partagé TimeMachine sans supprimer le dossier lui-même. Exactement. Mais comme l'environnement TimeMachine existe déjà sur le NAS tu n'as pas à recommencer l'installation. Tu te contentes de faire une première sauvegarde.

Cela est du au passage à Sonoma. Même si cette sauvegarde peut être utilisée pour restaurer des données, elle ne peut plus être mise à jour. Le plus simple est de tout reprendre à zéro en accédant à DSM pour supprimer la sauvegarde TimeMachine dans le dossier partagé de même nom puis en recréant une sauvegarde complète.

Bienvenue parmi nous @Emmanuel Goldengrams, Venir sur le forum avant d'investir dans un nouveau NAS est une excellente idée 😀

Bonjour @Amelie, Est-ce que le dossier partagé sur lequel la sauvegarde Time Machine est effectuée est joignable sur le réseau ? Pour le savoir choisis "Aller > Se connecter au serveur" ou son équivalent "Command + K" sur le Mac. Dans la fenêtre d'invite tape 'smb://nom_d'utilisateur@DS220.local/. Le dossier partagé apparaît bien ?

Bonjour @Dr Jerry et bienvenue sur le forum qui est une mine d'informations.

Et tu as des NAS Synology !

« Je ne suis pas d’accord avec ce que vous dites, mais je me battrai pour que vous ayez le droit de le dire. » Voltaire. Dans le Conseiller de sécurité, prendre l'option "Personnalisé". Dans les paramètres personnalisés, décocher la case "Le compte admin est activé". Par la suite il ne devrait plus y avoir d'alerte à cause du compte admin par défaut.

Bonjour @jmb31 et bienvenue sur le forum. Passer d'un DS220J d'entrée de gamme à un DS923+, quel saut !

J'ai ajouté la variable d'environnement COLLECTOR_CRON_SCHEDULE et je me suis fait peur car il a fallu arrêter le container et le recréer. J'ai dû lancer plusieurs fois la commande sudo docker exec scrutiny scrutiny-collector-metrics run parce que, au premier lancement j'ai eu droit à une belle erreur ERROR: Post "http://localhost:8080/api/devices/register": dial tcp 127.0.0.1:8080: connect: connection refused Il m'a fallu insister et relancer la commande mais finalement, le bourrin est reparti. Ouf !!! J'ai l'impression que scrutiny est encore en construction mais Paris ne s'est pas fait en un jour.

Y'en a qui bossent 😀

Il y a des surprises. Lorsque je tape la commande : docker exec scrutiny scrutiny-collector-metrics run Un message indique : No configuration file found at /opt/scrutiny/config/collector.yaml. Using Defaults. Pour le coup j'ai dupliqué le fichier collector.yaml qui se trouve à la racine du dossier scrutiny dans la sous/dossier config. Voilà à quoi ressemble File Station. scrutiny folder config folder collector.yaml influxdb folder docker-compose.yml collector.yaml Il ne faut pas hésiter à lancer la commande "docker exec scrutiny scrutiny-collector-metrics run" - après avoir démarré le container dans Container Manager - pour que le container démarre vraiment. Le docker compose : # pouer lancer la 1ère analyse : sudo docker exec scrutiny scrutiny-collector-metrics run (merci EVOTk) services: scrutiny: container_name: scrutiny image: ghcr.io/analogj/scrutiny:master-omnibus restart: unless-stopped cap_add: - SYS_RAWIO # necessary to allow smartctl permission to query device SMART data - SYS_ADMIN # necessary for NVMe drives ports: - "6070:8080" # Web Interface # - "8801:8086" # influxDB admin volumes: - /run/udev:/run/udev:ro - ./config:/opt/scrutiny/config - ./influxdb:/opt/scrutiny/influxdb devices: # List devices with : ls /dev/ | grep '/dev/[sh]d[a-z]\|sata[0-9]\|usb[0-9]\|nvme[0-9]' # (merci MilesTEG1) - "/dev/sata1" - "/dev/sata2" # - "/dev/sata3" et ainsi de suite jusqu'au nombre de disques gérés par le NAS # - /dev/nvme0:/dev/nvme0 SSD NVMe # - /dev/nvme1:/dev/nvme1 # - /dev/nvme0n1:/dev/nvme0n1 # - /dev/nvme1n1:/dev/nvme1n1 environment: - SCRUTINY_WEB_INFLUXDB_TOKEN=STRONG_PASSPHRASE - SCRUTINY_WEB_INFLUXDB_INIT_USERNAME=lionel_a - SCRUTINY_WEB_INFLUXDB_INIT_PASSWORD=STRONG_PASSWORD - TIMEZONE=Europe/Paris Le fichier collector.yaml : version: 1 host: id: "DS220+" devices: # - device: /dev/nvme0n1 # type: 'nvme' # - device: /dev/nvme1n1 # type: 'nvme' - device: /dev/sata1 type: 'sat' - device: /dev/sata2 type: 'sat' # - device: /dev/sata3 et ainsi de suite jusqu'au nombre de disques gérés par le NAS # type: 'sat' Ça marche ainsi et je n'y touche plus ! Consolation, avec les infos qui suivent, mon NAS a pris de la valeur 😀

Je suis encore en phase de test. Avec linux il faut mettre les mains dans le cambouis, surtout quand les sources d'information sont contradictoires. Il y aura un retour d'expérience lorsque les choses seront stabilisées.