RAID1 : resync, reconstruction, durée, taille des disques

1) Y a-t-il une différence entre reconstruction et resync d'un RAID ? Pour moi, il semblerait que resync = beaucoup de lectures disque, alors que reconstruction = plus d'écritures disque.
2) La durée de reconstruction ou de resync d'un RAID dépend-elle de la taille des disques (par exemple RAID1 avec 2x2 To), ou dépend-elle uniquement des données utiles des disques (par exemple 400 Go utilisés sur les 2 To) ?

Dans tous les scénarii, c'est la capacité totale du disque qui compte, et non l'espace utilisé. Ou plus précisément la taille de la partition Raid1 qui n'est pas nécessairement tout le disque.
A ma connaissance Resync ne va pas réécrire la parité ou le duplicata si l'information s'y trouve déjà (par exexmple shutdown violent) -> resync a reboot.
Certaines cartes hardware peuvent faire un resync sur base d'un schedule.

4) La reconstruction d'un RAID pourrait-elle se faire en production (après reboot normal) au lieu qu'en rescue (pour diminuer la durée d'indisponibilité du serveur) ?

En effet, mais les performances sont dégradées et ça dépend de la priorité que tu donnes à ta reconstruction/resync.

Quand on installe un nouveau serveur OVH avec RAID1, en tout cas certains Linux, automatiquement il insère en crontab:
cron.d/raid-check:# Run system wide raid-check once a week on Sunday at 1am by default
cron.d/raid-check:0 1 * * Sun root /usr/sbin/raid-check

Selon la taille des disques et l’activité du serveur (si chargé par l'appli ça prend plus de temps) ça dure 4-7 heures le dimanche matin.

Patrick

Fais attention.
J'ai eu plusieurs cas de desynchro des RAID1, ou de panne d'un disque, donc tu ne fonctionne plus que sur un seul, puis celui-ci plante aussi et tu perds tout.
J'ai eu plusieurs fois le cas.
Donc maintenant sur tous mes serveurs, il y a resynchro tous les dimanches, et monitoring permanent du fonctionnement des 2 disques de la paire.
Avec cette sécurité, j'ai a 2 reprises appelé OVH pour changer un des 2 disques en panne, avant de tout perdre.
Patrick

raid-check est-il vraiment utile et à faire une fois par semaine

Sur un debian (6 upgradé jusque 9) j'ai ceci:

/etc/cron.d/mdadm
#
# cron.d/mdadm -- schedules periodic redundancy checks of MD devices
#
# Copyright © martin f. krafft madduck.net>
# distributed under the terms of the Artistic Licence 2.0
#

# By default, run at 00:57 on every Sunday, but do nothing unless the day of
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

Il y a aussi un check dans cron.daily.

Enfin, dans un autre cron j'ai mis ceci:

`cat /proc/mdstat |grep blocks|grep -v -q UU&& (echo raid ko|mail -s "`hostname`: check raid" adresse@ema.il)`

Le risque: tout perdre!! Plus de disques, plus de données, plus de sites, ....
C'est comme le type qui a un super mot de passe, mais a mis 123456 a la place, parce que taper 10 caractères avec des majuscule et des caractères spéciaux c'est trop contraignant.
Le risque: tout perdre.

Juste un exemple récent: L'Iran abat un drone US. Quelle est la réponse US? Alors qu'ils ont des missiles intercontinentaux, des portes-avions sur place, des bombardiers capables de mettre un tapis de bombes n'importe ou sur le globe, la réponse est Une cyberattaque!!

A part les aspects politiques ou chacun choisira son camp, cet exemple montre a quelle point la sécurité sur internet est un enjeu majeur. Et celui qui dira mais mon petit site/serveur ils n'en n'ont rien a faire. il se trompe. S'introduire sur un WP, y compris mutualisé permet d'envoyer des spams, du phishing et... de lancer des cyberattaques grace a la puissances et aux ressources de ton petit serveur.
Donc si tu ne veux pas que ton petit site soit au milieu de la 3eme guerre mondiale, il y a intérêt a le blinder.

il faut aussi des cron pour les alertes SMART

J'en ai aussi mais ceci n'était pas l'objet de la question.

Détecter 12 blocks "pending" bien à temps m'a déjà sauvé 2x un kimsufi équipé d'un seul disque, que j'ai pu répliquer ailleurs bien avant un crash complet, au cas où il manque quelque chose dans les backups, et demander un remplacement de disque bien ordonné.