- Incluso después de la descontinuación de Time Capsule, si instalas Linux en un equipo pequeño y de bajo consumo, puedes armar tú mismo un dispositivo de respaldo permanente para macOS a bajo costo
- El HP t520 de 25 dólares con envío incluido trae un AMD G-Series de doble núcleo, 4 GB de RAM, SSD M.2 SATA de 16 GB, Ethernet de 1 Gbps y puertos USB 3.0, suficiente para un servidor de propósito único
- El almacenamiento puede elegirse entre un SSD M.2 SATA interno y una unidad USB3 externa; usando un SSD M.2 SATA 2280 de 2 TB, el costo total queda en alrededor de 94 dólares
- En Bodhi Linux se instalan
netatalk y avahi-daemon para configurar un recurso compartido de Time Machine basado en AFP, pero tras la publicación se agregó una nota indicando que AFP está deprecado y que debe usarse Samba
- El respaldo inicial de 460 GB, que a 2 Mbit/s habría tardado 21 días, mejoró hasta 120 Mbit/s y se redujo a 8 horas gracias a Power Nap,
debug.lowpri_throttle_enabled=0 y ubicar el equipo cerca del AP Wi‑Fi
Idea de ThinMachine como reemplazo de Time Capsule
- Apple Time Machine fue uno de los motivos para cambiarse a Mac en 2007, y después se usó respaldo inalámbrico con Time Capsule
- La Time Capsule existente funcionó durante más de 10 años hasta que se averió, y macOS empezó a mostrar repetidamente avisos de que el respaldo estaba desactualizado
- Aunque Apple descontinuó Time Capsule, todavía es posible montar un dispositivo de respaldo parecido configurando un servidor Linux
- Si será un dispositivo de propósito único que estará siempre encendido, conviene usar hardware pequeño, de bajo consumo y que quepa en el clóset de red
- También podría usarse una Raspberry Pi, pero en ese momento era difícil conseguirla y costaba más de 80 dólares, además de requerir gabinete y fuente de poder por separado, así que perdía atractivo en costo
- Como alternativa se eligió una PC thin client usada, y se compró una HP t520 en eBay por 25 dólares con envío incluido
Hardware y consumo eléctrico de la HP t520
- La configuración base de la HP t520 de 25 dólares es suficiente para usarla como servidor de respaldo sencillo
- AMD G-Series GX-212JC de doble núcleo a 1.2 GHz con Radeon R2E
- 4 GB DDR3-1600
- SSD M.2 SATA de 16 GB
- Ethernet de 1 Gbps
- 2 puertos USB 3.0, 4 puertos USB 2.0
- 2 DisplayPort, 1 VGA
- Base vertical
- Adaptador de corriente de 18.5 V y cable
- No tiene Wi‑Fi, pero como se iba a colocar junto al router en el clóset de red, no fue un problema; si hace falta, se puede usar la ranura mini PCIe libre
- No se probó agregar Wi‑Fi directamente, así que no se confirma al 100% que funcione
- La t520 consume 6 W en reposo y 10 W en otros casos
- Tomando una tarifa eléctrica promedio de 0.35 dólares por kWh, mantener 6 W de forma continua cuesta unos 19 dólares al año
- Otros thin clients como la HP t610 pueden superar los 10 W en reposo por usar chipsets más antiguos
- Una Raspberry Pi 4 se midió en unos 4 W
- El sistema operativo base es HP Thin Pro, una distribución personalizada basada en Tiny Core Linux
- HP Thin Pro incluye clientes de Citrix y VMWare
- También se probó Tiny Core Linux original, pero la cantidad de paquetes disponibles era demasiado limitada
Elección del almacenamiento: SSD interno y USB3 externo
- La capacidad de SSD interno oficialmente soportada por la t520 es de 64 GB, pero esa especificación viene de una época en la que no existían SSD M.2 más grandes
- La ranura M.2 interna soporta formatos 2242 y 2260, y un SSD 2280 interfiere físicamente con la bocina
- La bocina puede retirarse levantando la placa madre y quitando 2 tornillos
- Antes de instalar el SSD 2280, hay que cubrir con cinta las almohadillas de cobre expuestas y las pistas en la parte trasera del SSD
- Como no hay tornillo de fijación, existe la posibilidad de que el SSD se salga del zócalo, aunque en esta configuración no se consideró una gran preocupación
- La ranura interna de la t520 solo soporta SSD M.2 SATA
- Los SSD de gran capacidad suelen ser NVMe, pero esta ranura no es para PCIe/NVMe
- HP eligió un conector incorrecto, así que un SSD NVMe puede entrar físicamente
- Si se inserta un SSD NVMe, existe la posibilidad de dañar el SSD, la placa madre o ambos
- Al elegir almacenamiento interno, había diferencias importantes de precio y formato
- Un SSD M.2 SATA 2260 de 2 TB costaba 149 dólares en Amazon
- Un SSD M.2 SATA 2280 de 2 TB se conseguía desde 69 dólares
- Un SSD SATA 2280 de 4 TB subía hasta 260 dólares
- El SSD M.2 SATA 2280 de 2 TB elegido funcionó correctamente, y el costo total de la ThinMachine de 2 TB quedó en 94 dólares
- Una unidad USB3 externa es una alternativa que reduce la dificultad de instalación
- Los SSD de 2.5 pulgadas de 4 TB parten desde 150 dólares, y también es posible usar capacidades mayores
- Es fácil desconectar la unidad para guardarla o conectarla a otra PC
- No hace falta abrir la t520
- La desventaja es que se necesita un enclosure USB3 y el resultado no se ve tan limpio
Instalación de Bodhi Linux y particionado
- Buscando una distribución basada en Ubuntu pero con imagen de instalación pequeña, se eligió Bodhi Linux
- La versión HWE era 5 MB más grande que la estándar, con 837 MB, y ofrecía soporte para hardware más reciente
- La descarga del ISO de Ubuntu era lenta, pero la del ISO de Bodhi Linux fue rápida
- El flujo de instalación es el habitual con arranque por USB
- Preparar una memoria USB de al menos 1 GB
- Grabar la imagen ISO en la USB con Balena Etcher
- Conectar la USB a la t520 y arrancar
- Seguir el instalador para instalar Bodhi Linux en el SSD de la t520
- Las particiones del SSD interno separan el sistema operativo de los datos de respaldo
/dev/sda1: efi, 1 GB, partición de arranque y debe ser la primera/dev/sda2: ext4, 16 GB, para instalar Bodhi Linux/dev/sda3: ext4, todo el resto, partición de datos de respaldo
- Los puntos de montaje también se separan claramente
/dev/sda2 se monta en el directorio raíz //dev/sda3 se monta en /mnt/timemachine
- Después de la instalación, Bodhi Linux usa poco más de 5 GB del SSD, así que asignar 16 GB deja margen para instalar herramientas adicionales
Cuenta del servidor Time Machine y configuración de AFP
- Primero se actualizan los paquetes a la última versión
sudo apt update && sudo apt dist-upgrade
- Se instalan los paquetes necesarios para que funcione Time Machine
sudo apt install procinfo netatalk avahi-daemon
- Avahi es una implementación de código abierto de funciones de red de configuración cero como Apple Bonjour, y permite que la Mac vea el servidor thinmachine en la red
- Netatalk es una implementación de código abierto del Apple Filing Protocol, e incluye soporte para Apple Time Machine
- Se crea una cuenta dedicada llamada
timemachine
- Esta cuenta no tiene privilegios de
root ni de sudo, y tampoco se crea un directorio /home
- Al conectar la Mac al servidor, se usa este nombre de usuario y contraseña
- Esta contraseña no es la contraseña de cifrado de los datos de respaldo
sudo useradd --no-create-home timemachine
sudo passwd timemachine
sudo chown timemachine:timemachine /mnt/timemachine/
- Se edita
/etc/netatalk/afp.conf para configurar el recurso compartido de Time Machine
- Con
vol size limit se puede limitar en MB cuánto espacio en disco usará Time Machine
- Aquí no se define límite de capacidad porque se usará toda la unidad para Time Machine
hostname no necesita coincidir con el nombre de host de Unix, pero se usa como el nombre visible en la red Bonjour
;
; Netatalk 3.x configuration file
;
[Global]
hostname = thinmachine
[ThinMachine]
path = /mnt/timemachine
time machine = yes
valid users = timemachine
;vol size limit = 500000
- Se habilitan e inician los demonios necesarios
sudo systemctl enable avahi-daemon
sudo systemctl start avahi-daemon
sudo systemctl enable netatalk
sudo systemctl start netatalk
- Se abren los puertos necesarios en el firewall y se reinicia Netatalk
sudo ufw allow 548
sudo ufw allow 427
sudo ufw allow 4700
sudo systemctl restart netatalk
- Esta configuración está basada en AFP y, después de la publicación, se agregó una nota indicando que AFP fue deprecado y que debe usarse Samba
Recuperación de energía y conexión de la Mac
- Como el appliance de respaldo debe encenderse automáticamente cuando vuelve la energía tras un corte, se cambia la configuración del BIOS
- Presionar F10 al inicio del arranque para entrar a la configuración del BIOS
- Ir a
Advanced → Power-On Options
- Configurar
After Power Loss en On
- En la configuración de Time Machine de la Mac, al pulsar
Select Disk, ThinMachine aparece como opción
- El cifrado de los datos de respaldo se realiza en la Mac, y el thin client no participa ni en el cifrado ni en el descifrado
- Si se pierde la contraseña del respaldo, no hay forma de recuperar los datos
- El primer respaldo puede tardar bastante
Mejoras de velocidad en el respaldo inicial
- La MacBook tenía 460 GB de datos, y el respaldo de Time Machine es atómico, así que si no termina, debe volver a empezar desde cero
- La velocidad inicial del respaldo era de unos 2 Mbit/s, lo que implicaba alrededor de 21 días para completar todo
- Durante ese tiempo, si se apagaba y encendía el servidor o la laptop salía del alcance del Wi‑Fi, había que reiniciar el respaldo desde el principio
- Se activó Power Nap incluso cuando se usa batería
- Si Power Nap está activado, el respaldo de Time Machine continúa aunque la laptop esté cerrada o funcionando con batería
- Si Power Nap está desactivado, el respaldo se interrumpe y vuelve a empezar
- Durante el primer respaldo completo, se desactivó la limitación de procesos en segundo plano
sudo sysctl debug.lowpri_throttle_enabled=0
- Con este ajuste, la velocidad del respaldo subió de 2 Mbit/s a 20 Mbit/s
- Después del respaldo inicial, conviene volver a activar la limitación
sudo sysctl debug.lowpri_throttle_enabled=1
- Al mover la laptop cerca del punto de acceso de la red Wi‑Fi mesh Eero, la velocidad subió de 20 Mbit/s a 120 Mbit/s
- Gracias al cambio de prioridad y a ubicarla cerca del AP, el tiempo del respaldo de 460 GB bajó de 21 días a 8 horas
Resultado de uso y posibilidades adicionales
- Tras unos días de uso, desapareció la alerta de respaldo desactualizado en la MacBook y los respaldos funcionaron correctamente en segundo plano
- También sería posible expandir la t520 como NAS conectándole unidades adicionales, pero no se vio necesario
- Como protección ante una falla de la unidad interna, también se podría hacer una copia completa periódica a una unidad externa
- Ya se usa Backblaze como servicio de respaldo externo, así que se consideró que había redundancia suficiente
1 comentarios
Comentarios en Hacker News
Ya no confío en Time Machine. Hace unos años hice un script de shell que automatiza casi por completo la configuración de todo el sistema usando
brewy demás, y de vez en cuando borro por completo el sistema y lo restauro con ese scriptPara el respaldo de datos uso restic. Una gran ventaja es que puedo leer los respaldos incluso sin tener un equipo macOS. Cuando mi único equipo macOS tuvo un problema de hardware, el respaldo de Time Machine fue prácticamente inútil hasta que conseguí una Mac nueva
No será la opción ideal para todos, pero Time Machine me corrompió los respaldos más de 5 veces y además es demasiado lento comparado con restic, así que no me dan ganas de volver a intentarlo cada vez que sale una nueva versión de macOS
Solo soy un usuario satisfecho desde hace 9 años, no tengo relación con la empresa
[1] https://www.arqbackup.com
Ahora uso Carbon Copy Cloner, Syncthing y Arq. Gracias a eso, los respaldos familiares ahora son más rápidos, más naturales y muchísimo más fáciles de administrar
Pero en macOS tengo 2 cuentas de usuario, la mía y la de mi esposa, y no pude lograr que Restic accediera a los datos de la otra cuenta. Soy administrador, lo ejecuté como root y también le di “Acceso total al disco”, pero igual no funcionó. Agradecería cualquier consejo
Incluso usando
brewybrew cask, hay muchas apps con GUI que requieren instalación manual, y sus configuraciones están dispersas en varios lugares. Si además piensas en herramientas CLI o servicios en segundo plano instalados manualmente, así como en la configuración del sistema, no veo bien cómo automatizar de forma razonable la recuperación de todo eso sin un respaldo al estilo Time Machine, o básicamente una imagen de discoTambién me pregunto si sufriste la misma corrupción en la versión con APFS
Tengo Pi-hole y Time Machine corriendo en una Raspberry Pi y quizá sea el producto tecnológico con mejor relación calidad-precio que he comprado. Seguí https://saschaeggi.medium.com/use-a-raspberry-pi-4-for-time-...
Es más cara, necesita una carcasa y una fuente de poder aparte, y no puedes usar un SSD M.2 sin una carcasa USB3 adicional. También tiene historial de corrupción de tarjetas flash, y el consumo en reposo apenas es un poco menor
Se la di a mi hija para que la usara cuando se fue a la universidad, pero dudo muchísimo que de verdad la haya usado, y hasta ver este artículo ni se me había ocurrido preguntarle
Para conservar la salud mental, recomiendo dejar de usar Time Machine y usar Carbon Copy Cloner [0]. Funciona bien, sigue funcionando, la documentación sobre los posibles escenarios de respaldo y recuperación es excelente, y muestra con transparencia qué está haciendo.
Time Machine funciona bien hasta que un día deja de hacerlo. Ni siquiera te avisa que el respaldo se rompió hasta que intentas restaurar. Los errores son crípticos, no hay soporte, los foros no ayudan y no se pueden reparar los respaldos dañados. Time Machine adopta un enfoque de “que se joda el usuario” en el que no da ninguna información sobre qué hace, qué no hace o qué intenta hacer.
Si tus datos valen lo suficiente como para respaldarlos, no deberías usar Time Machine.
[0] https://bombich.com
Con iCloud, la respuesta que oyes en todas partes es solo “los datos se están sincronizando”, “apágalo y vuelve a encenderlo”, “reinicia”. Al ver a Apple Support decir con total seguridad que reinicies iOS o reinstales por completo macOS por un problema menor de sincronización, se siente como hablar con un bot sádico kafkiano.
Ese es el manual de Apple. Criticarlo públicamente en redes sociales no sirve, los correos no reciben respuesta y las solicitudes de los clientes quedan bloqueadas. A veces hasta siento que deberían pagarme por usar productos de Apple.
Cuando un exgerente decía que, en cuanto recibía una Mac, ya fuera para uso personal o de trabajo, lo primero que hacía era instalar Linux, los recién llegados lo veían como algún fanático raro de GNU/FOSS. Él se reía y decía que con el tiempo lo entenderían, y ahora entiendo lo impotente y hostil que es el ecosistema de Apple. Después de aguantar limitaciones frustrantes y callejones sin salida, uno termina en una especie de situación de rehén donde parece que esa es la única forma posible.
A estas alturas, decir que Time Machine o cualquier función de Apple relacionada con la integridad y confiabilidad de los datos “funciona” o “es lo bastante buena”, o depender de algo como iCloud para respaldo e integridad de datos, me parece casi autodestructivo.
Estoy esperando el día en que en iOS sea más fácil acceder a archivos con permisos explícitos, o en que Android sea menos malo. Al final solo queda obligar a estas gloriosas plataformas duopólicas a abrirse; por voluntad propia no lo harán.
Time Machine es gratis y para la mayoría de la gente, para respaldos locales o en red local, es “lo bastante bueno”. Para respaldos remotos, BorgBase, Vorta —aunque la app GUI de borg es terrible— y Backblaze son opciones más o menos llevaderas.
Además, CCC no parece tener respaldos inmutables de solo escritura del lado del cliente después de crearse, como Borg, y en la lista de funciones tampoco veo cifrado ni deduplicación. https://bombich.com/features
Ahora respaldo con Time Machine tanto a un servidor TrueNAS como a un disco local, cuando me acuerdo de conectarlo. Mi directorio personal lo respaldo a B2 con Arq.
A mi familia la hago usar Backblaze. De verdad fue la única forma de configurarlo y olvidarse. Siempre se olvidan de conectar la unidad local de Time Machine, y si configuras Time Machine con una unidad de red, cada pocos meses se pone raro y simplemente ignoran los mensajes de Time Machine diciendo que ya no está respaldando.
Backblaze casi simplemente funciona y además manda un reporte por correo una vez por semana. La recuperación completa probablemente sería algo dolorosa, pero es mejor que no tener ningún respaldo.
Hice un script de shell relativamente simple para corregir eso.
https://github.com/torstenvl/tmutils
Sigue bastante en beta, así que hay que usarlo con cuidado. Para los cambios importantes de metadatos hay pasos de confirmación, y el script
dirdedupecorre en modo de prueba por defecto. Para que haga algo de verdad, hay que usar el flag--execute.CCC es excelente, pero no hace respaldos casi en tiempo real ni maneja versionado. No me habría salvado como sí lo hizo el Time Machine “integrado” en la ranura SD el viernes pasado mientras iba en camino.
Llama la atención que el autor consiguió 16 GB de almacenamiento por 25 dólares, y luego gastó 70 dólares más para subir a 2 TB
Para usuarios de GNU/Linux, aunque por supuesto también debería funcionar bien con clientes de Microsoft y Apple, una buena combinación para mini servidores locales y remotos es usar Syncthing y ejecutar BorgBackup solo del lado del servidor
Syncthing ofrece sincronización casi inmediata, y BorgBackup proporciona archivos periódicos según la frecuencia y la política de retención que quieras
Para aislarlos, puse una VM pequeña para cada miembro de la familia, y les indiqué que lo realmente valioso lo guardaran en
~/work/o~/private/Curiosamente, el APU soporta AES-NI y también tiene un pequeño acelerador criptográfico para SHA. Contrasta con que Raspberry Pi no haya gastado 1 dólar más en Armv8 Cryptography Extensions
Con el mismo consumo en reposo de 6.5 W y el doble de núcleos, recomiendo la t620 por encima de la t520
Si 2 núcleos te bastan, la Fujitsu Futro s520 también está bien
https://heap.ovh/tag/thin-client.html
No estoy realmente seguro de que usar AFP, vía Netatalk, sea lo correcto. Según entiendo, hoy en día Time Machine “nativo” prefiere CIFS/Samba en red
“Si puedes elegir entre SMB y AFP, usa SMB para un disco de respaldo externo”
https://support.apple.com/guide/mac-help/types-of-disks-you-...
El enfoque de “No se preocupen. También uso BackBlaze para respaldo automático externo, y todos los proyectos están guardados en GitHub y en varias PCs” es inteligente
En 20 años sufrí 7 fallas catastróficas de disco, y 4 de ellas ocurrieron cuando usaba respaldos hechos por mí. Por flojera y por hacer las cosas a medias, en 2 de esas ocasiones perdí muchos datos. Las soluciones de respaldo caseras no son para mí
Parece un artículo escrito hoy, pero es importante notar que la Mac mencionada en el texto corre un macOS de hace 5 años. Habiendo operado por un tiempo una configuración similar con Raspberry Pi, ya no me parece una buena idea
Si hoy usas Time Machine, deberías respaldar en un volumen APFS con snapshots. Es mucho más rápido y confiable que un disco HFS+. Ya no lo recomiendo porque parece posible que macOS en algún momento deje de soportar por completo nuevos respaldos en HFS+
El problema es que, para Linux, en la práctica no existe un driver de APFS lo bastante confiable como para depender de él para respaldos. Así que la opción realista es tener una Mac que se encargue de eso. En mi red tengo una vieja MacBook Pro, una de las últimas generaciones antes de la Touch Bar, conectada por cable al backbone. Es caro, pero puedes asumir que esa es la configuración que quieres
Como referencia, si usas Time Machine sobre un recurso compartido en red, recomiendo tener además otro respaldo para el “peor de los casos” que actualices periódicamente. Los discos en red son convenientes, así que sirven para respaldos regulares y acceso rápido, pero a veces Time Machine puede corromperse a sí mismo de una forma que no puede reparar sola
Otra solución barata para Time Machine en red es usar una Intel Mac Mini de segunda mano. Una con Intel i5 de 2.5 GHz, 8 GB de RAM y SSD de 256 GB cuesta alrededor de 120 dólares, y solo hay que configurarla para exportar el disco de Time Machine por red
No solo es un Time Machine “real”, sino que también puede continuar los respaldos a partir del disco de Time Machine existente que antes usabas conectado directamente. No hay nada nuevo que aprender
Mi respaldo principal de Time Machine, para mi MBP y la de mi esposa, se hace por SMB hacia un ZFS RAIDZ2 en el NAS. Ha funcionado bastante bien por unos 2 años
Los problemas que tuve parecían estar relacionados con que el espacio se agotaba por la cuota configurada. Debido a los snapshots de ZFS, el mecanismo automático de limpieza de Time Machine no liberaba espacio como se esperaba. Por suerte, pude encontrar un snapshot reciente sano con rollback de ZFS, borrar manualmente snapshots viejos de ZFS para liberar espacio, ejecutar la verificación de Time Machine y seguir usándolo. Antes de eso también había creado manualmente un snapshot de “estado correcto”
Hace poco descubrí la configuración ZFS refquota, y parece resolver todo ese proceso engorroso al hacer que la cuota funcione de la forma que Time Machine espera. Claro, los snapshots de ZFS consumen espacio adicional, pero los datos de Time Machine son una parte pequeña del almacenamiento total del arreglo, así que está bien
El otro problema era con actualizaciones de kernel y temas de dkms al usar ZFS en Arch, pero desde que me cambié a NixOS ha sido estable. Los respaldos de Time Machine por Tailscale también funcionan bastante bien
Además, tengo un segundo respaldo de Time Machine en un disco USB conectado a un AirPort Extreme
En el mismo NAS también uso restic para respaldos multiplataforma, y ese NAS envía snapshots de ZFS de los datos de Time Machine y de restic a un servidor remoto
Por último, guardo un disco USB en una caja fuerte y, más o menos una vez al mes, lo saco para ejecutar manualmente un respaldo local de Time Machine
Tener respaldado todo era, medio en broma y medio en serio, parte de los votos matrimoniales. Había mucho en juego
La razón principal por la que abrí el enlace era para ver qué modelo de thin client había elegido el autor, y justo era un HP T520, del cual yo también tengo uno
No puedo hablar sobre Time Machine, pero la combinación de hardware y Linux fue un servidor más estable que una SBC similar como Raspberry Pi u Odroid. Tampoco consumía mucha más energía; solo era más grande