Quelques réflexions :
1/ Pour le load_cycle_count, 82 en 5 ans, c'est la preuve que le NAS est bien configuré pour les disques. Bien vérifier que le nouveau disque soit compatible avec un NAS qui n'hiberne jamais.
2/ Il est possible de faire un test "bas" niveau supplémentaire que je fais sur tous mes NAS (enfin sauf pour le dernier car c'est un AMD et que le package qui contient la commande screen n'est pas porté sur Synology).
Il s'agit de lancer la commande badblocks qui se trouve habituellement dans /usr/local/diskutils/sbin/. Celle-ci écrit successivement des 0x55 (010101010), des 0xaa (10101010), des 0xff (11111111) et enfin des 0x00 depuis le premier byte du disque jusqu'au dernier, le tout en 4 passes, intercalées de 4 passes de vérification. Cela prend "en gros" 1j / TB.
Evidemment, il faut être à l'aise avec ce genre de commande. Voici par exemple une commande pour tester le disque /dev/sdc :
sudo ./screen /bin/sh -c '/usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096 /dev/sdc > /root/badblocks_sdc.log 2>&1'
(le tout en étant ici dans la directory où screen est installée, typiquement /volume1/@appstore/diskutils/bin/ )
Voici un output pour 2 disques de 3TB :
Temps Disk 1 Disk 2
Début 05/11/2017 16:52 05/11/2017 16:54
Write 0xaa 06/11/2017 00:24 06/11/2017 00:18
Read 0xaa 06/11/2017 07:51 06/11/2017 07:38
Write 0x55 06/11/2017 15:22 06/11/2017 15:01
Read 0x55 06/11/2017 22:49 06/11/2017 22:20
Write 0xff 07/11/2017 06:19 07/11/2017 05:43
Read 0xff 07/11/2017 13:46 07/11/2017 13:02
Write 0x00 07/11/2017 21:17 07/11/2017 20:25
Read 0x00 08/11/2017 04:43 08/11/2017 03:45
(à éviter sur le disque root ... puisque la procédure crashe l'ensemble des données)
1/ Pour le load_cycle_count, 82 en 5 ans, c'est la preuve que le NAS est bien configuré pour les disques. Bien vérifier que le nouveau disque soit compatible avec un NAS qui n'hiberne jamais.
2/ Il est possible de faire un test "bas" niveau supplémentaire que je fais sur tous mes NAS (enfin sauf pour le dernier car c'est un AMD et que le package qui contient la commande screen n'est pas porté sur Synology).
Il s'agit de lancer la commande badblocks qui se trouve habituellement dans /usr/local/diskutils/sbin/. Celle-ci écrit successivement des 0x55 (010101010), des 0xaa (10101010), des 0xff (11111111) et enfin des 0x00 depuis le premier byte du disque jusqu'au dernier, le tout en 4 passes, intercalées de 4 passes de vérification. Cela prend "en gros" 1j / TB.
Evidemment, il faut être à l'aise avec ce genre de commande. Voici par exemple une commande pour tester le disque /dev/sdc :
sudo ./screen /bin/sh -c '/usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096 /dev/sdc > /root/badblocks_sdc.log 2>&1'
(le tout en étant ici dans la directory où screen est installée, typiquement /volume1/@appstore/diskutils/bin/ )
Voici un output pour 2 disques de 3TB :
Temps Disk 1 Disk 2
Début 05/11/2017 16:52 05/11/2017 16:54
Write 0xaa 06/11/2017 00:24 06/11/2017 00:18
Read 0xaa 06/11/2017 07:51 06/11/2017 07:38
Write 0x55 06/11/2017 15:22 06/11/2017 15:01
Read 0x55 06/11/2017 22:49 06/11/2017 22:20
Write 0xff 07/11/2017 06:19 07/11/2017 05:43
Read 0xff 07/11/2017 13:46 07/11/2017 13:02
Write 0x00 07/11/2017 21:17 07/11/2017 20:25
Read 0x00 08/11/2017 04:43 08/11/2017 03:45
(à éviter sur le disque root ... puisque la procédure crashe l'ensemble des données)