Bonsoir,
Pour anticiper un défaut de service de notre prestataire @immae a mis en place une sauvegarde régulière via sa ligne perso, un raspberry pi et un dock avec deux gros disque 3.5" mécaniques.
Performances ok, par contre, l’alimentation du dock a grillé… sans doute trop matériel trop léger pour une utilisation 24/7.
C’est une Heden Station d’accueil USB 3 SATA.
On pense à reprendre quelque chose de plus sérieux, avec plus de logements disques, mais avec une conso mini et l’accès individuel à chaque disque.
Par exemple ceci : Terra Master
D’après la description, le D4-320 possède de bonnes caractéristiques. Mon seul reproche concerne le montage vertical des disques.
Par conséquent, si j’utilisais cet appareil, j’opterais uniquement pour des SSD. En effet, si le sol de la pièce est irrégulier, les disques durs risquent de subir une usure prématurée des plateaux dans cette configuration.
Cependant, lorsque je choisis un appareil pour un projet, plusieurs critères entrent généralement en ligne de compte :
Les contraintes budgétaires.
Les fonctionnalités requises.
Une capacité de stockage suffisante (1, 2 ou 4 disques).
La nécessité d’une connexion manuelle ou automatique.
Mon expérience et mes connaissances en la matière.
Si vous avez déjà utilisé un Raspberry Pi avec deux disques pour cette tâche et que cela vous a convenu, je vous recommande alors la configuration à deux disques. Par exemple, ce modèle : https://www.terra-master.com/fr-fr/products/f2-425
Pas trop fan des dock 3.5", même si ça s’utilise très bien en 24/7, c’est quand même plus fait pour de l’usage discontinu. Je leur préfère un adaptateur SATA/USB + une alim de PC avec un interrupteur câblé dessus pour l’allumer au besoin. Moins confortable (ça évite d’en abuser dans le temps) et plus fiable (une alim de PC VS un adaptateur secteur souvent moulé/collé irréparable).
Les boitiers USB c’est déjà un peut mieux mais pourquoi ajouter de l’USB et un adaptateur (le SATA devient pas de l’USB magiquement ), alors qu’utiliser du SATA en direct est possible.
Pour un rPi 5, utiliser un hat SATA (par exemple https://radxa.com/products/accessories/penta-sata-hat/) et une alimentation de PC (si disque 3.5") peut être pas mal aussi. Tu as toujours un contrôleur SATA, mais byebye l’USB.
Gros bénéfice c’est plus standard (et donc technologie éprouvé) et vu le prix d’un hat SATA en acheter un second pour avoir une pièce de rechange immédiatement sous la main est évidement une bonne idée.
Bonus côté performance ça sera aussi mieux (passage par l’interface PCIe).
Bien que ce soit pour de la sauvegarde (donc performance extrême pas indispensable), sauvegarder plus vite peu avoir des effets bénéfiques sur la durée de vie du matériel (sollicité moins longtemps donc rotation des disques moins longue), et sur l’encombrement du réseau (et la je pense plus en terme de flux présent qui augmente la latence pour le reste que de débit).
De façon générale le rPi c’est sympa pour apprendre (et encore vu les prix qui grimpe les concurrents sont pas loin derrière, la documentation et la communauté rattrapent le coup pour le moment), mais il y a toujours un SBC (Single Board Computer) plus adapté pour pas forcément plus chère (voir des fois même moins chère).
Dans ce cas pour du stockage, il y as moult SBC avec des ports SATA (même mon vieux routeur fait avec une SBC spécial routeur de chez PC Engines à un port SATA PC Engines apu system boards RIP les APU, certain on pu connaitre leurs cartes ALIX/WARP encore plus connues).
Et je parle même pas des défauts un peu idiot qui on mis une éternité à être corrigé sur les rPI (genre le réseau qui passait par le bus USB ce qui le bridait fort sur les anciens modèles).
Pourquoi le laisser allumer 24/24 alors qu’il n’est utilisé que quelques heures pour la sauvegarde ? 📢 wakeOnStorage : Service sobre, lowtech de stockage à froid (sauvegarde, archivage) bon oui par contre il faut du SSD pour éviter de faire subir trop de cycle… Sinon lancer un DevSleep (avec hdparm) pour arrêter les plateaux quand tu t’en sert pas à minima…
Désolé j’ai pas connaissance de bon « hat » pour du 3,5’.
David
Salut tous!
Merci pour ces réponses. En fait, la conf actuelle a été faite avec ce qui était disponible, petit Raspi3 à conso mini et ce rack de 10 ans d’âge. Et @immae s’en satisfaisait bien, jusqu’à ce que l’alimentation grille…
J’ai un peu cherché en occase, en reconditionné, mais ils nous semblent nécessaire d’investir dans du matos pro, avec comme contrainte de limiter la conso, la place sans pour autant sacrifier la facilité de remplacement de disques, en 3.5 et 2.5".
Mais si il y a un retour d’expérience positif sur un ‹ bidule › qui peut faire l’affaire, on prend!
J’ai essayé de lire la discussions ur le wakeOnStorage (qui semble intéressant), mais j’ai un doute:
Dans mon setup, j’ai un dataset (zfs) que je dois déchiffrer au démarrage. Défaut de conception d’un de mes serveurs qui fait que je ne peux pas envoyer les datasets déjà chiffrés (à l’inverse des autres serveurs de mon infra).
Le backup s’initie par le « remote » (les serveurs), le raspi ne fait qu’accepter les données.
Autrement dit, à chaque « boot » du raspi je dois entrer un mot de passe pour qu’ils soit utilisable en tant que backup.
Est-ce que c’est possible de faire du wakeOnStorage dans ces conditions ?
À noter: je ne me focalise pas sur la consommation pour l’instant. En effet, l’ajout de ce setup a été quasiment invisible dans ma consommation journalière. Plus précisément, elle est inférieure aux fluctuations quotidiennes de mes deux plus gros consommateurs dans ma maison (frigo et chauffe-eau, qui ne sont jamais éteint même quand je suis en voyage). On voit bien un surplus sur la consommation horaire pendant les backups (la nuit, quand ça tombe pas au moment où je prends la douche - surpassé par le chauffe-eau), mais une fois lissé sur une journée c’est invisible.
La seule fois où j’ai eu une consommation mesurable, c’est au démarrage: le backup a mis ~14 jours pleins à se faire et là j’ai pu voir le « surplus » d’électricité consommée (très faible).
Note: le raspi est un raspi 3B, je n’ai pas trouvé de HAT pour faire ce que tu suggères @julienth37 . À la base tout était de la recup (le aspi m’avait été offert y’a pas mal d’années, les disques durs et le dock je les avais depuis un - long - moment) J’ai aussi penché pour un appareil qui ferme car actuellement il est « à l’air libre » ce qui n’est pas top pour la poussière. C’est pas le plus gros critère mais je n’ai rien trouvé d’autre pour l’instant de toute façon
Je ne suis pas dans la même config que toi Mais comme je l’ai dit : https://forum.chatons.org/t/wa.keonstorage-service-sobre-lowtech-de-stockage-a-froid-sauvegarde-archivage/7725/4 Il semble possible déverrouiller un disque chiffré avec les 2 projets cités. Dans l’idée si tu as un Pi Zéro qui est allumé pour donner les ordres, héberger l’API local (par exemple)
Pour le lancement par le remote : le remote peut se servir directement de l’API local pour démarrer le stockage, attendre que tout soit up, puis lancer la tâche…
ça c’est un autre problème… Chez moi ça serait visible… Du coup on peut pas dire que ce soit « neutre » mais effectivement tu peux commencer par le début et revoir d’autres poste de consommation avance celui-ci.
Alors bidule je sais pas (moi ça me fait tout de suite penser a un SBC et t’aura +/- les mêmes contraintes).
Quelque chose capable de faire ça proprement et qui prend peut de place je dirait un NAS 1U du genre QNAP TS-433eU (4 baies 3.5"). J’en ai vendu un récemment (choix du client car passable sous Linux moyennant compilation du noyau), surement moyen de trouver moins chère sur d’autres marques/modèles et/ou d’occasion (ou un boitier serveur 1U mais ça sera bien plus profond dans une baie et faut monter toute la configuration donc je fort probable que bien plus couteux).
Pour plus faut passer en 2U par exemple un QNAP TS-855eU qui à 8 baies 3.5" + 2 emplacement m.2.
Le défaut est surtout de pousser des sauvegardes/données, donc la source a à priori accès à la destination en permanence (et donc toutes les sauvegardes), c’est crado, en cas de compromission de la source les sauvegardes tombent avec. Idéalement il faut tirer les sauvegardes depuis la destination (Promox Backup Server et BackupPC font ça nickel pour A-H), comme ça le serveur cible peut s’allumer (vive le wake on LAN), faire les sauvegardes/dédup/compression/whatever et s’éteindre.
Non, la source n’a les droits que pour ajouter des incréments, pas pour les supprimer. La suppression se fait côté backup régulièrement de façon automatique (et j’ai quelques jours pour réagir en cas de problème)
Dans mon cas le backup est plus facile à compromettre (voler) que les serveurs, donc il est hors de question que celui-ci ait un quelconque accès vers les serveurs
Donc elle à au moins un accès en lecture, pas ouf en cas d’attaque si il y exfiltration des données.
C’est chiant de sécuriser (physique inclus) un serveur de sauvegardes mais c’est comme un bastion, indispensable si on veux bien faire les choses.
Le backup n’a accès à aucune donnée « à froid ». À chaud, il n’a accès qu’au dataset du serveur « mal conçu » (qui est en cours de modification mais c’est pas le sujet), les autres données sont transmises chiffrées et seul moi peut les déchiffrer.
Les serveurs n’ont accès au backup qu’en lecture pour ses propres datasets et en écriture uniquement pour envoyer des nouvelles données (aucune suppression). Donc aucun serveur n’a accès à une information du backup à laquelle il n’a pas déjà accès.
Je ne vois pas où est le souci du coup ? (c’est hors sujet cependant, le fil de discussion est pour du nouveau matériel vu qu’actuellement je ne peux plus brancher les disques dur sur le backup)
), alors qu’utiliser du SATA en direct est possible.
bon oui par contre il faut du SSD pour éviter de faire subir trop de cycle… Sinon lancer un DevSleep (avec hdparm) pour arrêter les plateaux quand tu t’en sert pas à minima…