Mic13710

Vous parlez sans doute de dossiers synchronisés via Synology Drive. Ca concerne donc le paquet Drive. Je déplace. Les fichiers avec un fanion vert sont disponibles sur le PC et devraient donc pouvoir être ouverts. Ceux avec une croix rouge ne sont pas synchronisés. Peut-être sont ils exclus de la synchronisation. A vérifier.

Ils sont externes au NAS ? Accès à quoi, au serveur à l'hébergement, au NAS ? Ni l'un ni l'autre. Le premier sert à faire des sauvegardes mono ou multi versions vers un support externe, le second à sauvegarder un pc sur le NAS.

Tant mieux si ça fonctionne, mais c'est tout de même curieux que les valeurs évoquées dans mon précédent message se retrouvent dans les deux fichiers .conf. Chez moi, l'account.conf ne comporte aucune de ces valeurs qui sont listées dans les .conf de mes deux noms de domaine.

Je n'utilise pas de disque externe pour mes sauvegardes hyperbackup, je ne peux donc guère vous aider à résoudre votre problème. Il est possible que le fautif soit votre boîtier. Alors quitte à investir, pourquoi ne pas vous tourner vers un autre NAS, de préférence Synology pour la compatibilité avec hyperbackup vault ? On en trouve d'occasion pas trop anciens à des prix corrects. Vous pourriez ainsi programmer un jour et heure de démarrage du NAS de sauvegarde, faire vos sauvegardes et programmer une extinction à la fin de la journée. Ca vous permettrait aussi de délocaliser votre sauvegarde, de préférence dans un lieu distant. C'est en tout cas une piste à explorer.

Oui et non. Ce n'est pas sur freebox OS mais dans l'espace client Free menu Ma Freebox, Reverse DNS personnalisé.

Bonjour @phchrono, soyez le bienvenu sur ce forum. Vous pouvez poster ici : https://www.nas-forum.com/forum/forum/116-autres-nas/

A mon avis, ton problème vient du fait que tu as 2 fois les mêmes données dans les deux fichiers de conf et c'est probablement ce qui coince. Dans ton account.conf : SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.18.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='acme.toto.ovh' SAVED_SYNO_Password='PASSWORD' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='toto.ovh' et dans ton toto.ovh.conf : SAVED_SYNO_USERNAME='acme.toto.ovh' SAVED_SYNO_PASSWORD='PASSWORD' SAVED_SYNO_SCHEME='http' SAVED_SYNO_HOSTNAME='172.18.0.1' SAVED_SYNO_PORT='5000' SAVED_SYNO_CERTIFICATE='__ACME_BASE64__START<NOM DU CERTIFICAT EN BASE 64__ACME_BASE64__END_' Ce qui à mon avis a provoqué les messages : SAVED_SYNO_Username='acme.toto.ovh' has been removed. [Sun Oct 5 10:13:05 UTC 2025] Domain config new key exists, old key SAVED_SYNO_Password='Password' has been removed. [Sun Oct 5 10:13:05 UTC 2025] Domain config new key exists, old key SAVED_SYNO_Scheme='http' has been removed. [Sun Oct 5 10:13:05 UTC 2025] Domain config new key exists, old key SAVED_SYNO_Hostname='172.18.0.1' has been removed. [Sun Oct 5 10:13:05 UTC 2025] Domain config new key exists, old key SAVED_SYNO_Port='5000' has been removed. [Sun Oct 5 10:13:05 UTC 2025] Domain config new key exists, old key SAVED_SYNO_Certificate='toto.ovh' has been removed. De plus, je ne comprends pas pourquoi tu n'as pas de valeur à SAVED_SYNO_DID. Il me semble que cette donnée est devenue obligatoire pour le script acme.sh, mais je peux me tromper. Il faudrait remettre de l'ordre dans tout ça. Je te propose de sauvegarder les deux fichiers puis de commencer par supprimer toutes les lignes ci dessus de ton toto.ovh.conf puisque selon les messages ce sont elles qui mettent le souk, et de relancer le déploiement. Si ça ne fonctionne pas, tu rétablis le fichier toto.ovh.conf et tu supprimes les lignes ci-dessus du account.conf avant de relancer le déploiement. Après, je ne vois guère d'autre solution que de tout supprimer, certificat et instance docker, puis de tout recommencer pour repartir sur une base saine. P.S. : Tu as laissé ton nom de certificat en base 64 dans ton dernier message. Trop facile pour le retrouver. Je l'ai corrigé 😉

ça c'est ton account.conf. Qu'est qu'il y a dans ton toto.ovh.conf ?

C'est facile à dire, plus compliqué à réaliser. Chaque constructeur a une mise en oeuvre et une interprétation toute personnelle des tests SMART. Tu as bien vu que les valeurs affichées par Seagate ne ressemblent pas à celles de WD. Et il en est probablement de même pour les autres constructeurs. Tu ne peux pas demander au fabricant du NAS de faire une analyse de matériels tiers alors que les fabricants ne suivent pas les mêmes logiques entre eux. Ils ne vont pas se compliquer la vie à faire des évaluations variables selon les disques installés. Les tolérances des uns ne sont pas celles des autres. Dès lors, tant que DSM répond correctement, que les erreurs des disques (il y en a toujours, même sur des disques sains) sont acceptables, il ne cherche pas plus loin. On peut supposer que le côté positif des disques Synology serait de mieux analyser l'état des disques estampillés de la marque. Reste à voir si c'est le cas. Je suppose qu'ils font comme Synology. Le tout est de savoir où mettre le curseur.

@StéphanH, il est très fréquent sur des NAS synology d'avoir des disques indiqués comme étant sains et se retrouver avec un système qui rame à cause d'un des disques. C'est des situations courantes, en témoignent les nombreux messages qui vont dans ce sens. La réponse du support résume parfaitement la chose : des disques plus ou moins bons pour le NAS, donc non encore éjectés, qui ralentissent les lectures écritures et les accès aux données.

En théorie oui, mais uniquement pour le 16To. En pratique ça ne semble pas possible selon votre lien qui dit que seuls des 18To peuvent être utilisés pour augmenter la capacité du groupe. Ce n'est de toute manière pas possible de mettre un 8To car vous n'en avez pas et au mieux (s'il est accepté) il sera considéré comme un 4To.

Non, si un de vos disques tombe en panne, vous pouvez le remplacer par un disque de même capacité. Il s'agit en l’occurrence de réparer un groupe dégradé. L'article en question indique seulement le cas où vous voulez augmenter la capacité de votre groupe. Effectivement, le remplacement d'un disque par un plus gros ne peut se faire que si le disque est de capacité au moins égale au disque le plus gros du groupe. Vous dites que vous êtes en SHR2. Avec vos disques actuels, vous perdez 4To de stockage. https://www.synology.com/fr-fr/support/RAID_calculator?drives=18 TB|18 TB|16 TB|16 TB|4 TB|4 TB|4 TB|4 TB&raid=SHR_1|SHR_2 Le seul moyen de récupérer ce stockage serait de remplacer 2 disques de 4To par des 18To. https://www.synology.com/fr-fr/support/RAID_calculator?drives=18 TB|18 TB|18 TB|18 TB|16 TB|16 TB|4 TB|4 TB&raid=SHR_1|SHR_2

Il faut simplement attendre que la génération des vignettes soit terminée. Ca peut prendre plusieurs jours selon le modèle de NAS et le volume de fichiers à traiter.

Oui, vous pouvez migrer vos disques vers un autre Syno https://kb.synology.com/fr-fr/DSM/tutorial/How_to_migrate_between_Synology_NAS_DSM_6_0_and_later

Avez-vous essayé en retirant tous les disques ? Si le NAS s'allume, profitez en pour faire le test de la carte mère https://kb.synology.com/fr-fr/DSM/tutorial/Why_am_I_unable_to_install_my_Synology_NAS_and_why_is_my_power_LED_is_flashing_constantly Si le NAS s'allume sans les disques c'est que soit un des disques est HS, soit l'alim est HS.

Si vous voulez le plus de téras sur 4 volumes, c'est un NAS 4 baies qu'il vous faut avec 1 groupe et un volume par disque. Par contre, si vous montez un RAID sur 4 disques, multiplier le nombre de volumes n'a aucun intérêt dans votre cas. Dans 99% des cas 1 seul volume est suffisant et surtout plus simple à gérer puisqu'il n'y a pas besoin de se prendre la tête avec la répartition des données. Maousse quantité de téras, ça ne veut rien dire. A l'heure actuelle avec des disques de 20To montés en groupes séparés sur un nas 4 baies c'est 80To de stockage théorique. Ca n'a pas de sens car ce n'est pas le nombre de téras qui compte, uniquement votre besoin. Si vous optez pour du Synology, attention avec les modèles 2025 : ils n'acceptent que les disques Synology. Tournez vous plutôt vers des modèles 2023 ou 2024 en neuf. En occasion optez pour des modèles plus récents : 2020 maxi. Tous les modèles avant 2025 acceptent des disques d'autres marques avec une liste de disques compatibles donnée par Synology pour chaque modèle. Vu votre future utilisation, un modèle Synology J ou value (sans le +) sera largement suffisant. Inutile de mettre de la puissance pour un simple stockage. Si votre utilisation n'est que du stockage, vous pouvez regarder du côté des WD My Book, des Terramaster et autres petits NAS. Par contre, si vous voulez en demander plus à votre NAS pour faire tourner des applications multimedia, du cloud, bref, tout autre chose que du stockage, il va falloir regarder du côté des Synology, QNAP. Si vous voulez en plus faire du docker et/ou un peu de virtualisation il faudra alors viser dans les milieux/hauts de gamme, minimum série + chez Synology.

Tu as un souci au niveau de l'identification. Voici ce que mes logs donnent lors de mon dernier déploiement : [Sat Aug 30 23:29:08 UTC 2025] url='http://172.17.0.1:5000/webapi/entry.cgi?api=SYNO.API.Auth&version=7&method=login&format=sid&account=<NOM DE MON COMPTE ACME>&passwd=<MOT DE PASSE DE3 MON COMPTE>&enable_syno_token=yes&device_name=CertRenewal&device_id=<LE DEVICE ID>' [Sat Aug 30 23:29:08 UTC 2025] timeout= [Sat Aug 30 23:29:08 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sat Aug 30 23:29:10 UTC 2025] ret='0' [Sat Aug 30 23:29:10 UTC 2025] Session ID='<LE SESSION ID>' [Sat Aug 30 23:29:10 UTC 2025] SynoToken='<LE SYNO TOKEN>' [Sat Aug 30 23:29:10 UTC 2025] Getting certificates in Synology DSM... [Sat Aug 30 23:29:10 UTC 2025] POST [Sat Aug 30 23:29:10 UTC 2025] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Sat Aug 30 23:29:10 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sat Aug 30 23:29:10 UTC 2025] _ret='0' [Sat Aug 30 23:29:10 UTC 2025] escaped_certificate='<LE NOM DE MON CERTIFICAT DANS DSM' [Sat Aug 30 23:29:10 UTC 2025] Generating form POST request... [Sat Aug 30 23:29:10 UTC 2025] Upload certificate to the Synology DSM. [Sat Aug 30 23:29:10 UTC 2025] POST [Sat Aug 30 23:29:10 UTC 2025] _post_url='http://172.17.0.1:5000/webapi/entry.cgi?api=SYNO.Core.Certificate&method=import&version=1&SynoToken=<LE SYNO TOKEN>&_sid=<LE SESSION ID>' [Sat Aug 30 23:29:10 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sat Aug 30 23:31:12 UTC 2025] _ret='0' [Sat Aug 30 23:31:12 UTC 2025] Restart HTTP services succeeded. [Sat Aug 30 23:31:12 UTC 2025] GET [Sat Aug 30 23:31:12 UTC 2025] url='http://172.17.0.1:5000/webapi/entry.cgi?api=SYNO.API.Auth&version=7&method=logout&_sid=<LE SESSION ID>' [Sat Aug 30 23:31:12 UTC 2025] timeout= [Sat Aug 30 23:31:12 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sat Aug 30 23:31:13 UTC 2025] ret='0' [Sat Aug 30 23:31:13 UTC 2025] Success Comme tu peux le voir, il y a pas mal de choses plus complètes. La première ligne par exemple ne s'arrête pas "enable_syno_token=yes". Par la suite, le script récupère <LE SESSION ID> et <LE SYNO TOKEN> qui sont indispensable pour le déploiement. Comme tu n'as ni l'un ni l'autre, le déploiement s'arrête là. Tu devrais jeter un oeil dans ton fichier toto.ovh.conf. Voici ce que contient le mien : Le_Domain='ndd' Le_Alt='*.ndd' Le_Webroot='dns_ovh' Le_PreHook='' Le_PostHook='' Le_RenewHook='' Le_API='https://acme-v02.api.letsencrypt.org/directory' Le_Keylength='4096' Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/<LE FINALIZE>' Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/100631007/<LE ORDER>' Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/<LE CERT>' Le_CertCreateTime='1756596547' Le_CertCreateTimeStr='2025-08-30T23:29:07Z' Le_NextRenewTimeStr='2025-10-28T23:29:07Z' Le_NextRenewTime='1761694147' Le_DeployHook='synology_dsm,' SAVED_SYNO_DID='' SAVED_SYNO_TOTP_SECRET='' SAVED_SYNO_USE_TEMP_ADMIN='' SAVED_SYNO_USERNAME='<NOM DU COMPTE ACME>' SAVED_SYNO_PASSWORD='<MOT DE PASSE>' SAVED_SYNO_DEVICE_ID='<LE DEVICE ID>' SAVED_SYNO_DEVICE_NAME='CertRenewal' SAVED_SYNO_SCHEME='http' SAVED_SYNO_HOSTNAME='172.17.0.1' SAVED_SYNO_PORT='5000' SAVED_SYNO_CERTIFICATE='__ACME_BASE64__<NOM DU CERTIFICAT EN BASE 64>__ACME_BASE64__END_' SAVED_SYNO_SynoToken='<LE SYNO TOKEN>' Le_DNSSleep='300' Si tu n'as qu'un seul certificat, il est possible que certaines lignes soient dans le fichier account.conf. Au final, tu devrais retrouver toutes les infos entre les deux fichiers.

Cette commande ne sert qu'au déploiement d'un certificat valide sur les applications du NAS. Si le certificat n'a pas été mis à jour comme tu le dis, alors c'est lui qu'il faut aller regarder. Consulte les logs à la date supposée du renouvellement et les jours suivants. Si tu veux, tu peux aussi forcer l'obtention du certificat avec la commande suivante : docker exec Acme sh -c "acme.sh --issue --force --keylength 4096 -d 'toto.ovh' -d '*.toto.ovh' --dns dns_ovh --dnssleep 300"

C'est très insuffisant car les bots recommenceront des tentatives dès que le blocage sera levé. Certains règlent à 1 mois pour laisser le temps aux bots de se lasser. La base de la sécurité c'est de ne pas ouvrir de port http vers l'extérieur. On ne le fait qu'en connaissance de cause, pour une utilisation particulière et de préférence ponctuelle. Donc non, on n'ouvre pas le port 80 dans le routeur.

Est-ce que le NAS est trouvé par Synology Assistant ou avec http://find.synology.com ? Est-que vous arrivez à pinger le NAS ?

Le plus simple serait de changer l'adresse IP déclarée dans le routeur, de déconnecter puis reconnecter le câble RJ45 qui va vers le NAS puis joindre le NAS avec cette nouvelle IP. Vous pourrez ainsi débloquer l'IP. Mais si l'IP est déclarée dans le NAS (ce qui n'est pas la meilleure solution), deux possibilités : soit les IP bloquées sont débloquées automatiquement après quelques jours auquel cas, vous attendez que le déblocage soit effectué (si vous avez le temps d'attendre jusque là), soit le blocage est permanent ou vous êtes pressé et dans ce cas pas d'autre choix que de faire un reset de premier niveau qui va réactiver le compte admin et les paramètres par défaut de la connexion réseau. https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7#t1 Par la suite, je vous recommande de laisser le NAS en DHCP et de fixer son adresse dans le routeur. Si l'IP a été bloquée, c'est que le parefeu n'a pas été correctement paramétré. Je vous conseille vivement de consulter et surtout mettre en pratique le tuto sur la sécurisation de nos NAS. On y parle entre autre du paramétrage du parefeu pour le réseau local.

@StéphanH, pour la commande smartctl, il faut être en mode administrateur : sudo smartctl --all /dev/sda pour ton disque 1 La valeur Raw_Read_Error_Rate n'est en principe pas critique, en tout cas, elle ne l'est pas sur les disques Seagate. Voici mon smart pour mon disque 1 : === START OF INFORMATION SECTION === Model Family: Seagate IronWolf Device Model: ST4000VN008-2DR166 Serial Number: xxxxxxxxx LU WWN Device Id: 5 000c50 0c42de694 Firmware Version: SC60 User Capacity: 4,000,787,030,016 bytes [4.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5980 rpm Form Factor: 3.5 inches Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-3 T13/2161-D revision 5 SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Fri Oct 3 15:27:31 2025 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 591) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 634) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x50bd) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 074 064 044 Pre-fail Always - 24356674 3 Spin_Up_Time 0x0003 093 093 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 66 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 096 060 045 Pre-fail Always - 3787992307 9 Power_On_Hours 0x0032 045 045 000 Old_age Always - 48861 (17 164 0) 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 66 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 0 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 070 060 040 Old_age Always - 30 (Min/Max 28/31) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 133 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 195 194 Temperature_Celsius 0x0022 030 040 000 Old_age Always - 30 (0 17 0 0 0) 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 48844h+05m+11.323s 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 216817203001 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 72976696175 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 48809 - # 2 Short offline Completed without error 00% 48702 - # 3 Short offline Completed without error 00% 48534 - # 4 Short offline Completed without error 00% 48366 - # 5 Short offline Completed without error 00% 48198 - # 6 Extended offline Completed without error 00% 48088 - # 7 Short offline Completed without error 00% 48030 - # 8 Short offline Completed without error 00% 47862 - # 9 Short offline Completed without error 00% 47694 - #10 Short offline Completed without error 00% 47526 - #11 Short offline Completed without error 00% 47358 - #12 Extended offline Completed without error 00% 47345 - #13 Short offline Completed without error 00% 47190 - #14 Short offline Completed without error 00% 47022 - #15 Short offline Completed without error 00% 46854 - #16 Short offline Completed without error 00% 46686 - #17 Extended offline Completed without error 00% 46600 - #18 Short offline Completed without error 00% 46518 - #19 Short offline Completed without error 00% 46350 - #20 Short offline Completed without error 00% 46182 - #21 Short offline Completed without error 00% 46014 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Comme tu peux le voir, j'ai plus de 2.4 millions sur ce critère et mon disque se porte comme un charme. Et pire que ça, mon disque 2 n'en a pas moins de 172 millions ! ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 082 064 044 Pre-fail Always - 172056954 Tu dois avoir autre chose sur ton disque, mais pour ça il faut passer en ssh pour savoir.

Vous lisez ce que j'écris ? Je vous ai dit le cadre VOLUME par celui du groupe ! C'est en dessous sur votre capture.

Je pense qu'il est urgent d'attendre que le test soit fini et si ce n'est pas le cas, que le disque soit remplacé. Faire une mise à jour avec un disque qui n'est pas au top risque de mal se terminer. Par ailleurs, certains paquets ont été abandonnés avec 7.2. C'est le cas de Video Station. Avec la 7.2, beaucoup sont passés à Plex ou Emby. Mais là, je ne pourrai pas vous aider, je n'utilise ni l'un, ni l'autre.

Je vois que vous utilisez l'hibernation des disques. Personnellement (je ne suis pas le seul) je n'utilise pas cette fonction qui aurait plutôt tendance à flinguer les disques. Je laisse mes disque tourner h24. Sinon, je ne vois rien d'anormal dans ces valeurs. Ceci dit, si le test est bloqué à 90% c'est qu'il y a tout de même un souci. Un disque sain (pas le sain indiqué dans DSM) doit aller au bout du test. Plus d'infos dans la base de connaissance : https://kb.synology.com/fr-fr/DSM/tutorial/What_is_SMART