Pour les besoins de mes activités pro et associatives, j’ai besoin de faire de la sauvegarde quotidienne de serveur. Les serveurs c’est déjà plutôt énergivore en électricité/climatisation (quoi que pas tant que ça si on s’auto-héberge – pas de climatisation par exemple). Je cherche à faire diminuer le coup énergétique tant que je peux, et les sauvegardes ne sont pas en reste.
Mise à jour 09/2020 : Désormais j’utilise des disque dur SSD avec le X828 Stackable Cluster Shield Expansion Board. (que je trouve très bien pensé !
Et je propose du service d’hébergement de sauvegarde à froid à prix libre : https://retzo.net/services/service-de-sauvegarde-ecologiquement-soutenable-a-froid/
Je suis donc parti sur une solution :
- Froide : c’est-à-dire qui ne serait allumée qu’au besoin (au moment de la sauvegarde) et pas allumée 24h/24 comme à l’habitude dans un datacenter.
- Faible consommation : Puisque composée d’un Raspberry Pi et d’un disque dur 2,5° = consommation ~3Wh
- Auto-hébergée : ça veut dire « à la maison », ça évite les climatiseurs des datacenters (vitaux quand la concentration de serveurs est forte) et on garde le contrôle sur les données/le matériel.
- De plus, étant autonome en électricité solaire (non raccordé), je peux assurer que l’énergie utilisée ici est full solaire.
En solution logiciel, j’utilise Dirvish, qui est une surcouche à Rsync, qui permet (en gros) de faire des sauvegardes « full » tous les jours en ne copiant que les différences. En gros il ne télécharge et enregistre que les fichiers différents de la veille et utilise l’adresse INODE sur le disque des fichiers qui n’ont pas changé. De cette façon, toute l’arborescence est complète tous les jours mais elle ne prend pas plus d’espace disque que la différence (un peu magique quand on ne connait pas le fonctionnement d’un partitionnement sous linux). De cette façon, ma sauvegarde quotidienne prend ~1h pour sauvegarder ~150Go sur 4 serveurs.
Le matériel utilisé
J’utilise donc pour mes sauvegardes à froid :
- Un Raspberry Pi (4 ici mais pas vraiment d’importance – quoi que avec un Zero j’ai essayé c’est pas terrible en perf…)
- Un disque dur 2,5° mécanique (ça serait encore plus économe en électricité avec un SSD) dans un boîtier USB 3.0
Le matériel utilisé (Raspberry PI + Disque dur SATA USB3 2,5°) Consommation constatée au Wattmètre : 3W
Consommation totale : 3Wh constaté au Wattmètre
Comparatif consommation
Pour comparaison (discutable j’en conviens) dans mon cas avec la solution choisie et une VM ou un serveur que j’aurais pu louer dans un datacenter :
| RaspberryPi + Disque | Datacenter | |
|---|---|---|
| Temps d’allumage | Le temps de la sauvegarde (ici ~1h mais variable) | 24h/24h |
| Consommation électrique (W) | 3 | 8 à 170 (1) |
| Consommation journalière (Wh/j) | 3 | 192 à 4080 |
(1) Consommation serveur nuancée entre une VM (8W) et un serveur physique dédié (170W) – chiffres de l’ADM (source). C’est tout relatif, ça dépend des cas, c’est une hypothèse de travail. Je n’ai pas non plus considéré les équipements actifs pour simplifier (chez moi juste une box, dans un datacenter beaucoup de switch/routeurs : même s’ils sont mutualisés, ça a un coût énergétique).
Avec cette méthode de sauvegarde à froid, dans mon cas, on est entre 64 et 1360 fois moins énergivore que dans le cas d’une sauvegarde ‘classique » en datacenter.
L’allumage automatique peut se faire de différente façon :
- BIOS : certain bios permette un « réveil » à heure fixe mais ce n’est pas le cas du Raspberry Pi
- WakeOnLan (fait par le serveur a sauvegarde par exemple)
- Une prise programmable avec l’heure
- PvMonit (dans mon cas) logiciel avec lequel je gère le surplus de mon énergie solaire
Dans tous les cas, le Raspberry Pi s’éteint de lui même après la sauvegarde (shutdown -h now dans le script à la fin de la sauvegarde).
Il y a quand même des désavantages à faire la sauvegarde « à la maison » :
- Débit montant limité : dans le cas ou il faut remonter le serveur en entier (toute la sauvegarde) ça peut prendre un certain temps car le débit montant d’une box est souvent faible
- Ce cas est très très rare
- Ce défaut n’est plus si on est en situation auto-hébergée : on va brancher notre disque dur avec la sauvegarde directement sur le serveur à reconstruire
- Restaurer à distance peut être problématique : si on est pas sur site et qu’on a besoin d’accéder aux sauvegardes, ça peut être problématique
- Tout dépend de la conception pour l’allumage automatique. Dans mon cas, je peux allumer à distance au besoin avec PvMonit.
Après quelques tests de débits/écritures, voici ce que je constate sur ce « nas » de sauvegarde :
root@nas(ro):/mnt/nas# curl -4 -o ./test100M http://bouygues.testdebit.info/100M.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 7145k 0 0:00:13 0:00:13 --:--:-- 7509kEn comparaison avec mon ordinateur :
david@monordinateurportable:/tmp$ curl -4 -o ./test100M http://bouygues.testdebit.info/100M.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 8424k 0 0:00:11 0:00:11 --:--:-- 8689kA ~100k de différence ça me semble pas significatif voir même plutôt bon ! (surpris même que ce soit si bon…)
Plus gros, plus redondant
Pour ceux qui ont de plus gros besoins en capacité / redondance de disque, il y a des HAT pour Raspberry Pi où il est possible de connecter plusieurs disques :
