log2ram: prolonga la vida de la tarjeta SD en tu Raspberry Pi (y en cualquier Linux con almacenamiento flash)

Una Raspberry Pi funcionando 24/7 escribe en su tarjeta SD constantemente. Los logs del sistema, el journal de systemd, las rotaciones periódicas — todo aterriza en la misma memoria flash que tiene un número limitado de ciclos de escritura. El resultado es predecible: la tarjeta falla antes de tiempo, normalmente en el peor momento.

log2ram resuelve esto con una idea simple: mover /var/log a la RAM del sistema y sincronizar a disco periódicamente. El resultado es una reducción de escrituras de entre el 70 y el 80%.

Lo probé en tres Raspberry Pi de mi infraestructura que funcionan como monitores de red y pasarelas. Aquí está lo que aprendí — incluyendo lo que pierdes, que es tan importante como lo que ganas.

El problema real

Una SD de consumo estándar aguanta entre 1.000 y 3.000 ciclos de escritura por celda (TLC NAND). Las de gama alta llegan a 10.000. Suena a mucho hasta que calculas lo que escribe un sistema Linux en funcionamiento continuo.

En una Raspberry Pi con Raspberry Pi OS, un análisis con tune2fs muestra el acumulado:

sudo tune2fs -l /dev/mmcblk0p2 | grep "Lifetime writes"

En mi caso, una RPi3 con apenas 12 meses de funcionamiento acumulaba 117 GB escritos. La tarjeta era una SanDisk SU32G genérica. Su TBW (terabytes escritos garantizados) no está especificado públicamente — lo que es ya una señal de aviso.

El síntoma típico no es un fallo catastrófico inmediato. La tarjeta empieza a tener sectores lentos. Los procesos que escriben en disco entran en estado de I/O wait. El sshd deja de responder porque no puede escribir en los logs. El sistema parece vivo — el ping funciona — pero es inaccesible por SSH. El único remedio es un reinicio físico.

Qué es log2ram y cómo funciona

log2ram es un servicio de systemd que, en el arranque del sistema, monta un tmpfs (sistema de ficheros en RAM) sobre /var/log. Los logs se escriben en memoria. En tres momentos los sincroniza de vuelta a disco:

El directorio real en disco pasa a llamarse /var/hdd.log. log2ram hace rsync entre RAM y disco en cada sincronización.

Instalación

Añadimos el repositorio oficial y lo instalamos:

sudo wget -O /usr/share/keyrings/azlux-archive-keyring.gpg https://azlux.fr/repo.gpg
echo "deb [signed-by=/usr/share/keyrings/azlux-archive-keyring.gpg] http://packages.azlux.fr/debian/ bookworm main" | sudo tee /etc/apt/sources.list.d/azlux.list
sudo apt update && sudo apt install log2ram

Reiniciamos para que entre en funcionamiento:

sudo reboot

Verificar que está activo

Tras el reinicio, comprobamos que el servicio está corriendo y que /var/log está en RAM:

systemctl is-active log2ram
df -h /var/log

La salida de df mostrará /var/log montado en un tmpfs, no en /dev/mmcblk0. Si es así, log2ram está funcionando.

Configuración

El fichero de configuración está en /etc/log2ram.conf. Los parámetros más relevantes:

SIZE=128M
JOURNALD_AWARE=true
PATH_DISK="/var/log"

SIZE — RAM reservada para los logs. 128M es suficiente para la mayoría de RPis domésticas. Si log2ram no arranca porque el tamaño de /var/log supera este límite, auméntalo a 256M. Para comprobarlo antes de instalar:

du -sh /var/log

JOURNALD_AWARE — cuando está activo (true), log2ram hace una rotación del journal de systemd antes de sincronizar los logs a disco. Requiere tener rsync instalado y es recomendable dejarlo en true.

Si usas JOURNALD_AWARE, es obligatorio limitar el tamaño máximo que journald puede ocupar en RAM. Sin este límite, el journal puede crecer gradualmente hasta superar el SIZE configurado en log2ram, y el servicio fallará al arrancar con el siguiente error:

ERROR: RAM disk for "/var/hdd.log/" too small. Can't sync.

Editamos /etc/systemd/journald.conf y añadimos o descomentamos:

[Journal]
SystemMaxUse=50M

Así nos aseguramos de que el journal no desborda el SIZE configurado en log2ram. Aplicamos el cambio sin reiniciar:

sudo systemctl restart systemd-journald

Cambiar la sincronización del timer

Por defecto, log2ram sincroniza los logs a disco una vez al día. Esto es configurable.

El timer está en /etc/systemd/system/log2ram-daily.timer. Para ver cuándo se ejecuta:

systemctl cat log2ram-daily.timer

Para cambiar la frecuencia a cada 6 horas editamos el timer:

sudo systemctl edit log2ram-daily.timer

Se abre un editor. Añadimos un override:

[Timer]
OnCalendar=
OnCalendar=*-*-* 00,06,12,18:00:00

Recargamos los timers para aplicar:

sudo systemctl daemon-reload
sudo systemctl restart log2ram-daily.timer

También podemos forzar una sincronización manual en cualquier momento sin reiniciar:

sudo systemctl restart log2ram

Troubleshooting: log2ram no arranca tras un reinicio

El síntoma más habitual es que log2ram falle silenciosamente al arrancar. El sistema sigue funcionando pero /var/log está en disco, no en RAM — se pierde todo el beneficio.

Para confirmarlo:

systemctl status log2ram
df -h /var/log

Si systemctl status log2ram muestra failed y el mensaje de error es RAM disk too small, el journal acumulado en disco supera el SIZE configurado. El diagnóstico:

du -sh /var/hdd.log/journal/

Si el resultado es mayor que el SIZE de /etc/log2ram.conf (por defecto 128M), el journal ha crecido sin límite porque SystemMaxUse no estaba configurado. La solución en dos pasos:

Paso 1 — reducir el journal acumulado:

sudo journalctl --vacuum-size=50M
du -sh /var/log/journal/   # debe ser < 50M

Paso 2 — arrancar log2ram:

sudo systemctl start log2ram
systemctl is-active log2ram
df -h /var/log   # debe mostrar tmpfs

Después de esto, asegúrate de tener SystemMaxUse=50M en /etc/systemd/journald.conf (ver sección anterior) para que no vuelva a ocurrir.

Lo que pierdes en un apagado accidental — el análisis honesto

Este es el punto que más importa entender antes de instalar log2ram.

En un apagado limpio (sudo reboot, sudo halt, corte de alimentación ordenado) los logs se sincronizan a disco correctamente. En un apagado abrupto — corte de luz, fallo de alimentación, kernel panic — los logs que estaban en RAM y no se habían sincronizado al disco se pierden.

Esto tiene implicaciones directas para el troubleshooting:

• Si el sistema se cuelga y necesitas entender por qué, los logs de los momentos previos al crash estarán en RAM. Si no hubo sync reciente, no los tendrás en disco.
• El journal de systemd del arranque anterior sí está disponible porque systemd lo persiste antes de montar el nuevo:

journalctl -b -1

• Los logs del boot previo al crash pueden estar completos o incompletos según cuándo fue la última sincronización.

Cómo compensarlo

Hay varias estrategias según el nivel de tolerancia que necesites:

Más frecuencia de sync — reducir el timer de diario a cada 2-4 horas minimiza la ventana de pérdida. Ver la sección anterior.

Forwarding a syslog remoto — enviar los logs a un servidor central (otro host en la red) en tiempo real. Así el log en RAM es una copia local, no la única copia:

# En /etc/systemd/journald.conf
[Journal]
ForwardToSyslog=yes

Luego configurar rsyslog para reenviar a un servidor remoto. Con esto, los logs críticos están en otro sitio independientemente de lo que pase con la SD.

Aceptar la pérdida — para una RPi de monitorización doméstica o de homelab, perder unos minutos u horas de logs de /var/log/syslog es un trade-off razonable a cambio de que la tarjeta dure años en lugar de meses.

Cuándo conviene — y cuándo no

Implementarlo tiene sentido en

• Raspberry Pi funcionando 24/7 (monitores de red, pasarelas, servidores domésticos)
• Cualquier SBC (Orange Pi, Rock Pi, Banana Pi) con almacenamiento en SD o eMMC
• Dispositivos IoT o kioscos Linux con tarjeta flash como único almacenamiento
• Sistemas embebidos con almacenamiento limitado en ciclos de escritura

No lo necesitas (o es irrelevante) en

• Sistemas con SSD NVMe o SATA — los SSDs modernos tienen TBW muy altos y wear leveling avanzado
• Sistemas que ya tienen /var/log en tmpfs por configuración manual
• Entornos donde la integridad de los logs en tiempo real es crítica (sistemas de auditoría, compliance)

Mi experiencia

Lo instalé en tres Raspberry Pi de la infraestructura: dos RPi3 que actúan como monitores de red y una RPi3 que funciona como pasarela SMS. Las tres llevaban meses funcionando sin incidencias graves, pero una de ellas había acumulado 117 GB escritos en 12 meses y mostraba el patrón descrito al inicio: apagados sucios periódicos por cuelgues del sshd.

Tras la instalación:

• /var/log en tmpfs en los tres hosts
• El sshd ya no se cuelga por I/O wait en la SD
• Los reboots son limpios: log2ram sincroniza antes de apagar
• El journal de journalctl -b -1 tiene toda la información del arranque anterior

Lo que cambié respecto a la configuración por defecto: dejé el timer en diario (suficiente para mi caso) y activé JOURNALD_AWARE=true con SystemMaxUse=50M en journald.conf para controlar el crecimiento del journal en RAM.

Complemento: noatime en el fstab

log2ram reduce las escrituras de logs, pero hay otro origen de escrituras silencioso: los timestamps de acceso. Por defecto, Linux actualiza el timestamp de cada fichero cada vez que se lee. En una SD esto genera escrituras innecesarias.

La solución es añadir noatime al montaje de la partición raíz en /etc/fstab:

PARTUUID=xxxxxxxx-02  /  ext4  defaults,noatime  0  1

Las versiones recientes de Raspberry Pi OS (Bookworm en adelante) ya lo incluyen por defecto. Para verificarlo:

cat /proc/mounts | grep "/ ext4"

Si aparece noatime en las opciones, ya está activo.

Conclusión

log2ram es una de esas herramientas que hacen exactamente lo que prometen, sin efectos secundarios graves si se entiende el trade-off. Cinco minutos de instalación y la tarjeta SD de tu Raspberry Pi deja de ser el punto débil de disponibilidad del sistema.

El único coste real es la ventana de pérdida de logs en caso de apagado abrupto. Para la mayoría de usos domésticos y de homelab es un precio más que razonable. Para entornos donde los logs son críticos, se puede mitigar con más frecuencia de sync o reenvío a un servidor remoto.

Combinado con noatime en el fstab, el impacto en la SD pasa de constante a casi testimonial.