Bonjour à tous,
Je cherche à mettre en veille mes disques dur hors temps de sauvegarde.
Les disques concernés sont en SATA et 3"1/2.
Jusqu'ici j'ai vu,
hdparm -I /dev/sda -> Infos
hdparm -C /dev/sda -> Etat disque dur
hdparm -y /dev/sda -> Commande standby mais pour disque IDE !
Est-ce que quelqu'un a déjà utilisé HDparm ?
Merci
# J'ai laissé tomber
Posté par cg . Évalué à 4.
salut,
j'ai laissé tomber l'extinction des disques durs pour deux raisons:
Peut-être qu'il est plus efficace, par ailleurs, de mettre tout ton système de sauvegarde en veille ? Certains BIOS permettent l'allumage programmé, et tu peux faire du Wake-on-LAN aussi.
[^] # Re: J'ai laissé tomber
Posté par totof2000 . Évalué à 3.
Pour des disques de sauvegarde j'éviterais de le faire …. Certains disques à une époque ont eu un bug sur cette fonctionnalité : la mise en veille du disque allait parquer les têtes de lecture et il était impossible ensuite de les débloquer => disque irrémédiablement utilisable.
Il vaut bien mieux, quitte à arrêter/redémarreer quelque chose, éteindre et rallumer le système complet. Et si ton système ne gère pas ou gère mal le wake on lan, un petit montage à base d'un arduino, rpi, ou autre, avec horloge système pourrait te permettre de démarrer automatiqueent ta machine de sauvegarde et de l'éteindre ne fois le travail effectué (mettre en parallèle le système sur le bouton power on pour fermer le circuit pour allumer l'ordi et gérer l'extinction via acpi quand la sauvegarde est terminée).
Maintenant je me pose une question : est-ce que c'est si bon que ça pour des disques les cycles power off/power on ?
[^] # Re: J'ai laissé tomber
Posté par cg . Évalué à 1.
C'est vrai que j'ai écrit veille, je voulais dire arrêt complet, désolé.
Dans mon expérience sur des serveurs, non, c'est pas bon :D. Mes disques (que ce soit SATA ou SAS, 7200rpm, 10krpm ou 15krpm) ont tendance à mourir entre 35000 et 60000 heures (entre 4 et 7 ans). La plupart sortent de production (puis sont perforés) avant de tomber en panne, car changement de serveur ! Ces serveurs (et ces disques) ne s'arrêtent que pour les déménagements de salle machine.
Mais il n'y a pas que les disques durs qui sont concernés, les ventilateurs, la carte mère, la RAM, en fait tous les composants ont tendance à casser au démarrage (comme les ampoules d'éclairage :D). J'ai encore eu la semaine dernière un système qui tournait impeccable depuis des années, et après 3 jours d'extinction, a fait une erreur matérielle à l'allumage pour me punir de l'avoir éteint.
Après c'est vrai que laisser un ordi allumé en permanence pour 2h de sauvegarde par mois, c'est un peu nul. Un cycle on/off par mois, ça me semble un risque raisonnable. Et si les disques sont en RAID (1, 10, 5 ou 6, ou équivalent ZFS), le risque de panne est carrément maîtrisé.
Pour le parquage des têtes, il me semble que tous les HDD le font automatiquement à l’extinction depuis plus de 30 ans non ? Sur l'IBM 8086 de mon grand-père, il fallait le faire (genre
park.com /i
), mais pas sur mon PS/2 ;).[^] # Re: J'ai laissé tomber
Posté par totof2000 . Évalué à 1.
Oui, mais là le bug se présentait lorsque les tetes se parquaient il me semble pour une mise en veille du disque. J'en ai perdu un comme ça :(
[^] # Re: J'ai laissé tomber
Posté par electro575 . Évalué à 1.
Une mise en veille après inactivité serait le mieux adapté à priori !?
Je mount et umount une fois la sauvegarde terminée, ça devrait passer
# hdparm -y
Posté par didg . Évalué à 5.
hdparm -y ou hdparm -Y devraient fonctionner, mais il faut unmount les partitions en premier sinon l'OS va écrire et réveiller le disque en fonction de VM writeback ou de l'écriture périodique du superblock.
Attention il y a des disques qui ne se réveillent pas après un -Y (pas toujours facile de débrancher le disque ou redémarrer la machine).
Ex:
hdparm -C /dev/sdb
/dev/sdb:
drive state is: active/idle
umount /dev/sdb1
hdparm -y /dev/sdb
/dev/sdb:
issuing standby command
hdparm -C /dev/sdb
/dev/sdb:
drive state is: standby
[^] # Re: hdparm -y
Posté par electro575 . Évalué à 1.
Avec cette commande, hdparm -y /dev/sdb
Pourquoi il est écrit : issuing standby command
Alors qu'au final, ça à l'air de fonctionner.
La commande hdparm -Y /dev/sdb ne fonctionne pas.
Le disque reste en standby, je n'ai jamais réussi à le mettre en sleep.
[^] # Re: hdparm -y
Posté par Marc Quinton . Évalué à 2. Dernière modification le 25 avril 2021 à 17:22.
peut-etre coupler :
- un démontage de la partition de manière régulière (plusieurs fois par jour, mais fréquence supérieure à 2 ou 3 heures),
- un montage automatique avec systemd,
- un mécanisme de standy sur timeout ou forcé avec hdparm.
on peut monitorer l'état des disques et ensuite injecter l'état sur une petite supervision et voir le résultat graphiquement. Pour ma part, c'est influxdb + chronograf.
expérience perso : ça n'est pas bien concluant et les disques tournent plus régulièrement que souhaité.
voici mon wrapper autour de hdparm, smartclt : https://gist.github.com/mqu/115fdc9eb471d81ac0ef1884746faefa
[^] # Re: hdparm -y
Posté par pat1423 . Évalué à 3.
De mon côté, je fais mes sauvegardes sur un disque 2,5" externe de 4Go connecté un port USB d'un raspberry. Cependant, je n'utilise ni l'option -y, ni -Y, mais l'option -S, ça marche nickel. Le plus simple est d'éditer le fichier /etc/hdparm.conf pour régler la valeur de spindown_time. Lire le man hdparm pour les unités très particulières de cette option. Par exemple: -S 24 équivaut à 120 secondes. Ci-dessous, le contenu de mon hdparm.conf
# -S standby (spindown) timeout for the drive
spindown_time = 24
# Laisser faire ?
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 26 avril 2021 à 08:34.
Y a-t-il réellement besoin de "forcer" le disque dur ?
Si tu es certain que ton système ne l'utilise pas (et un simple
umount
est parfait pour ça), le disque dur ne va-t-il pas tout seul se mettre dans un mode d'économie d'énergie ?En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.