Le 10 mars 2021, un incendie a détruit l’un des bâtiments du datacenter d’OVHcloud à Strasbourg. Des milliers de sites se sont arrêtés, et une partie des clients a découvert ce jour-là que leurs sauvegardes se trouvaient dans le même datacenter, parfois sur le même serveur. Sur une machine dédiée, la sécurité des données repose entièrement sur les choix de celui qui la loue, et ce sont presque toujours les mêmes erreurs qui coûtent cher.
Prendre le RAID pour une sauvegarde
Le RAID protège contre une seule chose : la panne d’un ou plusieurs disques. Un RAID 1 copie les données en miroir sur deux disques, un RAID 5 répartit des informations de parité qui permettent de survivre à la perte d’un disque, un RAID 6 à celle de deux. Dans tous les cas, la grappe reproduit fidèlement chaque écriture. Si un administrateur supprime un dossier, si un rançongiciel chiffre les fichiers ou si une mise à jour corrompt une base de données, le RAID applique l’erreur sur tous les disques à la fois.
Une sauvegarde est une copie séparée et datée, qu’on peut restaurer à un état antérieur. Les deux se complètent, sans jamais se remplacer.
Garder les copies au même endroit que l’original
La règle dite 3-2-1 reste la référence la plus simple :
- trois copies des données, l’original compris ;
- sur deux supports ou systèmes différents ;
- dont une hors du site principal.
Pour un serveur dédié, cela veut dire au minimum une sauvegarde vers un stockage situé dans un autre datacenter, idéalement chez un autre fournisseur. Ajoutez-y une copie protégée contre l’effacement, par exemple un stockage objet avec verrouillage des versions : un attaquant qui prend la main sur le serveur ne doit pas pouvoir supprimer aussi les sauvegardes.
Choisir un niveau de RAID sans calculer la capacité réelle
Prenons une machine équipée de quatre disques de 4 To. En RAID 5, la capacité utile tombe à 12 To. En RAID 6 comme en RAID 10, elle descend à 8 To. Le système affichera ensuite moins que ces valeurs, parce qu’il compte en puissances de 2 : un disque vendu 4 To apparaît comme environ 3,6 Tio.
Le choix ne se résume pas à la capacité. Le RAID 10 se reconstruit plus vite et encaisse mieux les écritures d’une base de données, tandis qu’un RAID 5 sur de gros disques mécaniques laisse une longue fenêtre de reconstruction, pendant laquelle une seconde panne fait tout perdre. Avant de commander, un comparatif de serveurs dédiés qui détaille le stockage de chaque offre permet de vérifier le nombre de disques, leur type et leur capacité, donc les niveaux de RAID réellement possibles. Avec deux disques, la seule option redondante reste le miroir.
Reste à savoir qui gère la grappe. Un contrôleur RAID matériel décharge le processeur, mais si la carte meurt, il faut en général un modèle compatible pour relire les disques. Un RAID logiciel géré par mdadm se remonte sur n’importe quelle machine Linux. Sur un serveur loué, c’est souvent le choix le plus prudent.
Laisser une grappe dégradée tourner sans le savoir
Un RAID logiciel sous Linux continue de fonctionner quand un disque tombe en panne. C’est son rôle, et c’est aussi son piège : sans alerte, personne ne s’en aperçoit, et le serveur tourne des semaines sans aucune redondance. Configurez l’envoi d’un courriel par mdadm en cas d’incident, installez smartmontools pour suivre l’état des disques, et surveillez le nombre de secteurs réalloués, dont la hausse précède souvent une panne.
Autre détail : des disques achetés ensemble, issus du même lot et soumis à la même charge, ont tendance à vieillir ensemble. La reconstruction, qui sollicite fortement les disques restants, est justement le moment où un deuxième peut lâcher. Demandez le remplacement à l’hébergeur dès la première alerte, sans attendre le week-end suivant.
Ne jamais tester la restauration
Une sauvegarde qui n’a jamais été restaurée reste une hypothèse. Les scripts échouent en silence, les identifiants du stockage distant expirent, une base de données copiée à chaud se révèle incohérente. Sans test, on l’apprend le jour où l’on en a besoin.
Les bases de données méritent un traitement à part. Copier les fichiers de MariaDB ou de PostgreSQL pendant qu’ils sont en cours d’écriture peut donner une sauvegarde inutilisable. Passez par les outils prévus pour cela, comme mysqldump avec l’option –single-transaction pour des tables InnoDB, ou pg_dump, et vérifiez que le fichier obtenu se recharge réellement dans une base vide.
Programmez une restauration complète chaque trimestre sur une machine de test, chronométrez-la et notez le résultat : c’est cette durée, bien plus que le niveau de RAID, qui dira combien de temps votre activité restera à l’arrêt après un incident sérieux.