- Même après l’arrêt du Time Capsule, installer Linux sur une petite machine basse consommation permet de fabriquer soi-même, à bas coût, un appareil de sauvegarde toujours disponible pour macOS
- Le HP t520 à 25 $ livraison comprise embarque un AMD G-Series double cœur, 4 Go de RAM, un SSD M.2 SATA de 16 Go, de l’Ethernet 1 Gbit/s et des ports USB 3.0, ce qui suffit pour un serveur dédié à une seule tâche
- Pour le stockage, on peut choisir entre le SSD M.2 SATA interne et un disque USB3 externe ; avec un SSD M.2 SATA 2280 de 2 To, le coût total reste autour de 94 $
- Sur Bodhi Linux, l’installation de
netatalk et avahi-daemon permet de configurer un partage Time Machine basé sur AFP, mais après publication, une note a été ajoutée indiquant d’utiliser Samba, AFP étant deprecated
- La première sauvegarde de 460 Go aurait pris 21 jours à 2 Mbit/s, mais Power Nap,
debug.lowpri_throttle_enabled=0 et le rapprochement du point d’accès Wi‑Fi ont permis de monter à 120 Mbit/s, ramenant la durée à 8 heures
Concevoir un ThinMachine pour remplacer Time Capsule
- Apple Time Machine a été l’un des déclencheurs du passage au Mac en 2007, puis les sauvegardes sans fil ont été utilisées via Time Capsule
- L’ancien Time Capsule a fonctionné pendant plus de 10 ans avant de tomber en panne, et macOS affichait sans cesse des alertes indiquant que les sauvegardes étaient trop anciennes
- Même après l’arrêt du Time Capsule par Apple, configurer un serveur Linux permet de fabriquer soi-même un appareil de sauvegarde similaire
- Pour un appareil dédié qui reste allumé en permanence, un matériel petit, basse consommation et capable de tenir dans un placard réseau est adapté
- Un Raspberry Pi aurait aussi été possible, mais il était alors difficile à trouver, coûtait plus de 80 $, et le boîtier ainsi que l’alimentation étaient à acheter séparément, ce qui le rendait moins intéressant financièrement
- L’alternative retenue a été un PC client léger d’occasion, avec un HP t520 acheté 25 $ livraison comprise sur eBay
Matériel et consommation du HP t520
- La configuration de base du HP t520 à 25 $ suffit pour un simple serveur de sauvegarde
- CPU double cœur AMD G-Series GX-212JC à 1,2 GHz et Radeon R2E
- 4 Go DDR3-1600
- SSD M.2 SATA de 16 Go
- Ethernet 1 Gbit/s
- 2 ports USB 3.0, 4 ports USB 2.0
- 2 DisplayPort, 1 VGA
- Support vertical
- Adaptateur secteur 18,5 V et câble
- Il n’a pas de Wi‑Fi, mais ce n’était pas un problème puisqu’il était prévu de le placer dans le placard réseau à côté du routeur ; au besoin, il est possible d’utiliser l’emplacement mini PCIe libre
- L’ajout du Wi‑Fi n’a pas été testé directement, donc son bon fonctionnement à 100 % n’est pas confirmé
- Le t520 consomme 6 W au repos et 10 W dans les autres cas
- En prenant un prix moyen de l’électricité de 0,35 $ par kWh, un fonctionnement permanent à 6 W coûte environ 19 $ par an
- D’autres clients légers comme le HP t610 peuvent consommer plus de 10 W au repos à cause de chipsets plus anciens
- Le Raspberry Pi 4 a été mesuré à environ 4 W
- L’OS par défaut est HP Thin Pro, une distribution personnalisée basée sur Tiny Core Linux
- HP Thin Pro inclut des clients Citrix et VMWare
- Tiny Core Linux d’origine a aussi été essayé, mais le nombre de paquets disponibles était trop limité
Choisir le stockage de sauvegarde : SSD interne ou USB3 externe
- La capacité officiellement prise en charge pour le SSD interne du t520 est de 64 Go, mais cette spécification date d’une époque où les SSD M.2 plus grands n’existaient pas
- L’emplacement M.2 interne prend en charge les formats 2242 et 2260, tandis qu’un SSD 2280 interfère par défaut avec le haut-parleur
- Le haut-parleur peut être retiré en soulevant la carte mère puis en dévissant deux vis
- Avant d’installer un SSD 2280, il faut couvrir avec du ruban adhésif les pastilles et pistes en cuivre exposées au dos du SSD
- En l’absence de vis de fixation, le SSD pourrait sortir de son connecteur, mais dans cette configuration réelle, cela n’a pas été considéré comme une grande inquiétude
- L’emplacement interne du t520 ne prend en charge que les SSD M.2 SATA
- Les SSD de grande capacité sont souvent en NVMe, mais cet emplacement n’est pas destiné au PCIe/NVMe
- HP a choisi le mauvais connecteur, ce qui permet physiquement d’insérer un SSD NVMe
- Insérer un SSD NVMe peut endommager le SSD, la carte mère, ou les deux
- Au moment de choisir le stockage interne, les écarts de prix et de formats étaient importants
- Un SSD M.2 SATA 2260 de 2 To coûtait 149 $ sur Amazon
- Les SSD M.2 SATA 2280 de 2 To commençaient à 69 $
- Un SSD SATA 2280 de 4 To montait à 260 $
- Le SSD M.2 SATA 2280 de 2 To choisi a fonctionné correctement, portant le coût total du ThinMachine 2 To à 94 $
- Un disque USB3 externe est une alternative qui simplifie l’installation
- Les SSD 2,5 pouces de 4 To commencent à 150 $, et de plus grandes capacités sont possibles
- Il est facile de débrancher le disque pour le stocker ou le connecter à un autre PC
- Il n’est pas nécessaire d’ouvrir le t520
- Les inconvénients sont la nécessité d’un boîtier USB3 et une apparence moins propre
Installation de Bodhi Linux et partitionnement
- En cherchant une distribution basée sur Ubuntu avec une image d’installation légère, le choix s’est porté sur Bodhi Linux
- La version HWE faisait 837 Mo, soit 5 Mo de plus que la version standard, et prenait en charge du matériel plus récent
- Le téléchargement de l’ISO Ubuntu était lent, mais celui de l’ISO Bodhi Linux était rapide
- Le déroulé de l’installation est celui d’un démarrage USB classique
- Préparer une clé USB d’au moins 1 Go
- Écrire l’image ISO sur la clé USB avec Balena Etcher
- Brancher la clé USB au t520 et démarrer
- Suivre l’installateur pour installer Bodhi Linux sur le SSD du t520
- Les partitions du SSD interne séparent l’OS et les données de sauvegarde
/dev/sda1 : efi, 1 Go, partition de démarrage, doit être la première partition/dev/sda2 : ext4, 16 Go, destinée à l’installation de Bodhi Linux/dev/sda3 : ext4, tout le reste, partition des données de sauvegarde
- Les points de montage sont aussi clairement séparés
/dev/sda2 est montée sur le répertoire racine //dev/sda3 est montée sur /mnt/timemachine
- Après installation, Bodhi Linux utilise un peu plus de 5 Go sur le SSD ; allouer 16 Go laisse donc de la marge pour installer des outils supplémentaires
Compte du serveur Time Machine et configuration AFP
- Commencer par mettre les paquets à jour
sudo apt update && sudo apt dist-upgrade
- Installer les paquets nécessaires au fonctionnement de Time Machine
sudo apt install procinfo netatalk avahi-daemon
- Avahi est une implémentation open source des fonctions de réseau zéro configuration d’Apple Bonjour ; elle permet au Mac de voir le serveur thinmachine sur le réseau
- Netatalk est une implémentation open source de l’Apple Filing Protocol, avec prise en charge d’Apple Time Machine
- Créer un compte dédié
timemachine
- Ce compte n’a pas les droits
root ou sudo et ne crée pas non plus de répertoire /home
- Ce nom d’utilisateur et ce mot de passe sont utilisés lors de la connexion au serveur depuis le Mac
- Ce mot de passe n’est pas celui qui sert au chiffrement des données de sauvegarde
sudo useradd --no-create-home timemachine
sudo passwd timemachine
sudo chown timemachine:timemachine /mnt/timemachine/
- Modifier
/etc/netatalk/afp.conf pour configurer le partage Time Machine
vol size limit permet de limiter, en Mo, l’espace disque utilisable par les sauvegardes Time Machine- Ici, comme tout le disque est consacré à Time Machine, aucune limite de capacité n’est définie
hostname n’a pas besoin d’être identique au nom d’hôte Unix, mais il sert de nom visible sur le réseau Bonjour
;
; Netatalk 3.x configuration file
;
[Global]
hostname = thinmachine
[ThinMachine]
path = /mnt/timemachine
time machine = yes
valid users = timemachine
;vol size limit = 500000
- Activer et démarrer les démons nécessaires
sudo systemctl enable avahi-daemon
sudo systemctl start avahi-daemon
sudo systemctl enable netatalk
sudo systemctl start netatalk
- Ouvrir les ports nécessaires dans le pare-feu puis redémarrer Netatalk
sudo ufw allow 548
sudo ufw allow 427
sudo ufw allow 4700
sudo systemctl restart netatalk
- Cette configuration est basée sur AFP ; après publication, une note a été ajoutée indiquant qu’AFP avait été deprecated et qu’il fallait utiliser Samba
Rétablissement de l’alimentation et connexion du Mac
- Comme l’appliance de sauvegarde doit se rallumer automatiquement après le retour du courant, modifier les paramètres du BIOS
- Appuyer sur F10 au début du démarrage pour entrer dans les paramètres du BIOS
- Aller dans
Advanced → Power-On Options
- Régler
After Power Loss sur On
- Dans les réglages Time Machine du Mac, cliquer sur
Select Disk fait apparaître ThinMachine parmi les options
- Le chiffrement des données de sauvegarde est effectué sur le Mac ; le client léger n’intervient ni dans le chiffrement ni dans le déchiffrement
- En cas de perte du mot de passe de sauvegarde, il n’existe aucun moyen de récupérer les données
- La première sauvegarde peut prendre longtemps
Améliorer la vitesse de la première sauvegarde
- Le MacBook contenait 460 Go de données, et les sauvegardes Time Machine étant atomiques, si elles ne se terminent pas, il faut recommencer depuis le début
- La vitesse initiale de sauvegarde était d’environ 2 Mbit/s, soit environ 21 jours pour une sauvegarde complète
- Pendant ce temps, éteindre et rallumer le serveur ou sortir le portable de la portée du Wi‑Fi obligeait à recommencer la sauvegarde depuis le début
- Activer Power Nap même sur batterie
- Lorsque Power Nap est activé, la sauvegarde Time Machine continue même si l’ordinateur portable est fermé ou fonctionne sur batterie
- Si Power Nap est désactivé, la sauvegarde s’interrompt puis redémarre
- Désactiver la limitation des processus en arrière-plan pendant la première sauvegarde complète
sudo sysctl debug.lowpri_throttle_enabled=0
- Ce réglage a fait passer la vitesse de sauvegarde de 2 Mbit/s à 20 Mbit/s
- Après la sauvegarde initiale, il faut réactiver la limitation
sudo sysctl debug.lowpri_throttle_enabled=1
- En rapprochant l’ordinateur portable d’un point d’accès du réseau Wi‑Fi mesh Eero, la vitesse est passée de 20 Mbit/s à 120 Mbit/s
- Grâce au changement de priorité et au rapprochement du point d’accès, le temps de sauvegarde des 460 Go est passé de 21 jours à 8 heures
Résultat d’utilisation et possibilités supplémentaires
- Après quelques jours d’utilisation, les alertes de sauvegarde ancienne du MacBook ont disparu, et les sauvegardes fonctionnent correctement en arrière-plan
- Il serait aussi possible d’ajouter des disques au t520 pour en faire un NAS, mais le besoin ne s’en est pas fait sentir
- Pour se prémunir d’une panne du disque interne, il est également possible de créer périodiquement une copie complète sur un disque externe
- Backblaze étant déjà utilisé comme service de sauvegarde hors site, le niveau de redondance a été jugé suffisant
1 commentaires
Commentaires sur Hacker News
Je ne fais plus confiance à Time Machine. Il y a quelques années, j’ai créé un script shell qui automatisait presque entièrement la configuration de tout mon système avec
brewet d’autres outils, et de temps en temps j’efface complètement le système puis je le restaure avec ce scriptPour la sauvegarde des données, j’utilise restic. Le gros avantage, c’est qu’on peut lire les sauvegardes même sans machine macOS. Quand mon unique appareil macOS a eu un problème matériel, ma sauvegarde Time Machine était en pratique inutile jusqu’à ce que je puisse obtenir un nouveau Mac
Ce n’est pas une approche adaptée à tout le monde, mais comme Time Machine a corrompu mes sauvegardes plus de cinq fois et reste bien trop lent par rapport à restic, je n’ai aucune envie de réessayer, même à la sortie d’une nouvelle version de macOS
Je suis juste un utilisateur satisfait depuis 9 ans, sans aucun lien avec eux
[1] https://www.arqbackup.com
J’utilise maintenant Carbon Copy Cloner, Syncthing et Arq. Résultat, les sauvegardes familiales sont plus rapides, plus naturelles et bien plus faciles à administrer
Mais il y a deux comptes utilisateurs sur macOS, le mien et celui de mon épouse, et je n’ai pas réussi à permettre à Restic d’accéder aux données de l’autre compte. Je suis administrateur, je l’ai exécuté en root, et j’ai même accordé l’« accès complet au disque », mais ça ne marche toujours pas. Je suis preneur d’astuces
Même avec
brewetbrew cask, il y a beaucoup d’apps GUI qui nécessitent une installation manuelle, et leurs réglages sont dispersés à plusieurs endroits. Si on ajoute les outils CLI ou services de fond installés manuellement, ainsi que les réglages système, je ne vois pas très bien comment automatiser raisonnablement la restauration de tout cela sans une sauvegarde de type Time Machine, autrement dit sans image disqueJe me demande aussi si vous avez rencontré la même corruption avec la version APFS
Je fais tourner Pi-hole et Time Machine sur un Raspberry Pi, et c’est peut-être bien le produit tech au meilleur rapport qualité-prix que j’aie jamais acheté. J’ai suivi https://saschaeggi.medium.com/use-a-raspberry-pi-4-for-time-...
C’est plus cher, il faut un boîtier et une alimentation séparés, et on ne peut pas utiliser de SSD M.2 sans boîtier USB3 supplémentaire. Il y a aussi l’historique de corruption des cartes flash, et la consommation au repos n’est que légèrement plus basse
Je l’ai donné à ma fille quand elle est partie à l’université, mais je doute fortement qu’elle l’ait vraiment utilisé, et je n’y aurais même pas repensé si je n’avais pas vu cet article
Pour préserver votre santé mentale, je recommande d’arrêter d’utiliser Time Machine et de passer à Carbon Copy Cloner [0]. Ça fonctionne correctement, ça continue de fonctionner, la documentation sur les scénarios possibles de sauvegarde et de restauration est excellente, et l’outil montre de manière transparente ce qu’il fait.
Time Machine marche bien puis, à un moment, ne marche plus. Il ne vous dit même pas que la sauvegarde est corrompue avant que vous tentiez une restauration. Les erreurs sont obscures, il n’y a pas de support, les forums n’aident pas, et une sauvegarde cassée ne peut pas être réparée. Time Machine adopte une approche du type « va te faire voir, utilisateur », sans donner la moindre information sur ce qu’il fait, ne fait pas, ou essaie de faire.
Si vos données méritent d’être sauvegardées, vous ne devriez pas utiliser Time Machine.
[0] https://bombich.com
Avec iCloud aussi, les seules réponses qu’on entend partout sont « vos données sont en cours de synchronisation », « essayez d’éteindre et de rallumer », ou « redémarrez ». Quand on voit Apple Support recommander avec assurance de réinitialiser iOS ou de réinstaller entièrement macOS au moindre petit problème de synchronisation, on a l’impression de parler à un bot sadique kafkaïen.
C’est la méthode Apple. Les critiquer publiquement sur les réseaux sociaux ne sert à rien, les e-mails restent sans réponse, et les demandes des clients sont bloquées. Par moments, j’ai l’impression que c’est moi qui devrais être payé pour utiliser des produits Apple.
Quand mon ancien manager disait que la première chose qu’il faisait en recevant un Mac, pour usage personnel ou pro, c’était d’y installer Linux, les nouvelles recrues le prenaient pour une sorte de fanatique bizarre du GNU/FOSS. Il riait et disait qu’avec le temps on comprendrait ; maintenant, je comprends à quel point l’écosystème Apple est impuissant et hostile. À force de buter contre des murs et de subir des limitations irritantes, on finit dans une situation d’otage où cela semble être la seule façon de faire.
À ce stade, dire que Time Machine ou une fonctionnalité Apple engageant l’intégrité et la fiabilité des données « fonctionne bien » ou est « suffisamment correcte », ou dépendre de quelque chose comme iCloud pour la sauvegarde et l’intégrité des données, me paraît proche de l’autodestruction.
J’attends le jour où l’accès aux fichiers sous autorisation explicite deviendra plus simple sur iOS, ou où Android sera moins mauvais. Au bout du compte, il faudra simplement forcer l’ouverture des plateformes dans ce glorieux duopole ; ils ne le feront pas d’eux-mêmes.
Time Machine est gratuit et, pour la plupart des gens, c’est « suffisamment correct » pour des sauvegardes locales ou sur réseau local. Pour la sauvegarde distante, BorgBase, Vorta — dont l’interface GUI borg est affreuse — ainsi que Backblaze sont des options plus ou moins supportables.
Et il semble aussi que CCC n’ait pas, comme Borg, de sauvegardes immuables en écriture seule côté client après création, et sa liste de fonctionnalités ne montre ni chiffrement ni déduplication. https://bombich.com/features
Aujourd’hui, je sauvegarde avec Time Machine à la fois vers un serveur TrueNAS et vers un disque local, mais seulement quand je pense à le brancher. Mon répertoire personnel est sauvegardé vers B2 avec Arq.
Pour ma famille, je leur fais utiliser Backblaze. C’était vraiment la seule méthode qu’on pouvait configurer puis oublier. Les membres de ma famille oublient toujours de brancher leur disque Time Machine local, et si on configure Time Machine sur un disque réseau, il finit par se dérégler tous les quelques mois ; ils ignorent alors simplement les messages de Time Machine disant que la sauvegarde ne fonctionne pas.
Backblaze fonctionne presque tout seul et envoie aussi un rapport par e-mail une fois par semaine. Une restauration complète serait peut-être un peu pénible, mais c’est toujours mieux que de ne pas avoir de sauvegarde du tout.
J’ai créé un script shell relativement simple pour corriger cela.
https://github.com/torstenvl/tmutils
C’est encore assez bêta, donc il faut l’utiliser avec prudence. Il y a une procédure de confirmation pour les changements importants de métadonnées, et le script
dirdedupes’exécute par défaut en mode test. Pour faire réellement quelque chose, il faut utiliser le flag--execute.CCC est excellent, mais il ne sauvegarde pas de manière quasi temps réel et ne fait pas de gestion de versions. Il n’aurait pas pu me sauver comme l’a fait vendredi dernier, en déplacement, le Time Machine « intégré » dans le slot SD.
Ce qui frappe, c’est que l’auteur a obtenu 16 Go de stockage pour 25 dollars, puis a ajouté 70 dollars pour passer à 2 To
Pour les utilisateurs de GNU/Linux — même si cela fonctionnerait bien sûr aussi très bien avec des clients Microsoft et Apple — une bonne combinaison pour des mini-serveurs locaux et distants consiste à utiliser Syncthing et à ne faire tourner BorgBackup que côté serveur
Syncthing fournit une synchronisation quasi immédiate, tandis que BorgBackup propose des archives régulières selon la fréquence et la politique de rétention souhaitées
Pour l’isolation, il a mis en place une petite VM par membre de la famille et leur a indiqué de placer ce qui est vraiment précieux dans
~/work/ou~/private/Fait intéressant, l’APU prend en charge AES-NI et dispose aussi d’un petit accélérateur cryptographique pour SHA. Cela contraste avec le Raspberry Pi, qui n’a pas dépensé 1 dollar de plus pour les Armv8 Cryptography Extensions
Avec la même consommation au repos de 6,5 W et deux fois plus de cœurs, je recommande le t620 plutôt que le t520
Si 2 cœurs suffisent, le Fujitsu Futro s520 est aussi un bon choix
https://heap.ovh/tag/thin-client.html
Je ne suis pas vraiment certain que l’usage d’AFP, via Netatalk, soit le bon choix. Autant que je sache, le Time Machine « natif » actuel préfère plutôt CIFS/Samba sur le réseau
« Si vous avez le choix entre SMB et AFP, utilisez SMB pour un disque de sauvegarde externe »
https://support.apple.com/guide/mac-help/types-of-disks-you-...
Le raisonnement « Ne vous inquiétez pas. J’utilise aussi BackBlaze pour une sauvegarde externe automatique, et tous les projets sont aussi stockés sur GitHub et sur plusieurs PC » est malin
En 20 ans, j’ai subi 7 pannes de disque catastrophiques, dont 4 à l’époque où j’utilisais des sauvegardes maison. À force de paresse et d’approximation, j’ai perdu beaucoup de données dans 2 de ces cas. Les solutions de sauvegarde bricolées ne me conviennent pas
Le billet semble avoir été écrit aujourd’hui, mais il est important de noter que le Mac mentionné dans l’article exécute un macOS vieux de 5 ans. Ayant moi-même utilisé un Raspberry Pi dans une configuration similaire pendant un certain temps, je pense que ce n’est plus une bonne idée aujourd’hui
Si vous utilisez Time Machine de nos jours, il faut sauvegarder vers un volume APFS avec snapshots. C’est bien plus rapide et fiable qu’un disque HFS+. Je ne le recommande plus, d’autant plus que macOS pourrait un jour abandonner complètement la prise en charge des nouvelles sauvegardes HFS+
Le problème, c’est qu’il n’existe pas réellement de pilote APFS pour Linux à un niveau de fiabilité suffisant pour lui confier des sauvegardes. Le choix réaliste consiste donc à avoir un Mac pour s’en charger. Sur mon réseau, j’ai un ancien MacBook Pro, l’une des dernières générations avant la Touch Bar, branché en filaire sur le backbone. C’est cher, mais on peut considérer que c’est la configuration souhaitable
Au passage, si vous utilisez Time Machine sur un partage réseau, je recommande d’avoir aussi une autre sauvegarde « au pire des cas », rafraîchie périodiquement. Les disques réseau sont pratiques pour les sauvegardes régulières et l’accès rapide, mais il arrive parfois que Time Machine s’endommage lui-même d’une manière qu’il ne peut pas réparer seul
Une autre solution Time Machine réseau peu coûteuse consiste à utiliser un Intel Mac Mini d’occasion. Une configuration avec Intel i5 à 2,5 GHz, 8 Go de RAM et SSD de 256 Go coûte environ 120 dollars, puis il suffit de la configurer pour exposer le disque Time Machine sur le réseau
Non seulement c’est un « vrai » Time Machine, mais cela permet aussi de continuer les sauvegardes à partir d’un disque Time Machine existant auparavant branché directement. Rien de nouveau à apprendre
Ma sauvegarde Time Machine principale — pour mon MBP et celui de ma femme — se fait via SMB sur le ZFS RAIDZ2 du NAS. Cela fonctionne plutôt bien depuis environ 2 ans
Le problème que j’ai rencontré semblait lié au manque d’espace à cause du quota configuré. À cause des snapshots ZFS, le mécanisme de nettoyage automatique de Time Machine ne libérait pas d’espace comme prévu. Heureusement, j’ai pu retrouver un snapshot ZFS récent et sain via un rollback, supprimer manuellement d’anciens snapshots ZFS pour recréer de l’espace, lancer une vérification Time Machine, puis continuer à l’utiliser. Avant cela, j’avais aussi créé manuellement un snapshot « connu comme sain »
J’ai récemment découvert le réglage ZFS refquota, qui semble résoudre cette procédure pénible ci-dessus et faire fonctionner le quota comme Time Machine l’attend. Bien sûr, les snapshots ZFS consomment toujours de l’espace supplémentaire, mais les données Time Machine ne représentent qu’une petite partie de la capacité totale de la baie, donc ce n’est pas un problème
Mon autre souci concernait les mises à niveau du noyau et les problèmes dkms en utilisant ZFS sur Arch, mais depuis mon passage à NixOS, c’est stable. Les sauvegardes Time Machine via Tailscale sont aussi très bien
J’ai également une deuxième sauvegarde Time Machine sur un disque USB branché à un AirPort Extreme
J’utilise aussi restic sur le même NAS pour des sauvegardes multiplateformes, et ce NAS envoie les snapshots ZFS des données Time Machine et restic vers un serveur distant
Enfin, je garde un disque USB dans un coffre, et environ une fois par mois, je le sors pour lancer manuellement une sauvegarde Time Machine locale connectée en direct
Sauvegarder absolument tout faisait à moitié partie, à moitié pour rire, de nos vœux de mariage. Il y a beaucoup en jeu
La principale raison pour laquelle j’ai ouvert le lien était de voir quel modèle de client léger l’auteur avait choisi, et justement c’était un HP T520, dont j’ai moi-même un exemplaire
Je ne peux rien dire au sujet de Time Machine, mais avec cette combinaison matériel + Linux, c’était un serveur plus stable que des ordinateurs monocartes similaires comme le Raspberry Pi ou l’Odroid. Il ne consommait pas beaucoup plus d’électricité, il était simplement plus volumineux