WD My Cloud OS5: optimizar cron, servicios y tareas de mantenimiento para reducir la actividad del disco

En los capítulos anteriores analizamos la arquitectura del WD My Cloud Gen 2, recuperamos el botón Shutdown, configuramos Boot Scripts e implementamos un monitor para medir el tiempo que el disco duro permanece activo, inactivo o suspendido.

En esta sexta entrega abordaremos un problema relacionado: las tareas de mantenimiento que ejecuta automáticamente My Cloud OS5 y su posible influencia sobre la suspensión del HDD.

Durante nuestra investigación encontramos diversos procesos programados que realizan operaciones administrativas, actualizan información del dispositivo o sincronizan datos.

Nuestro objetivo fue reducir la posibilidad de que estas tareas interrumpieran periodos de suspensión, sin deshabilitar indiscriminadamente las funciones de mantenimiento del NAS.

Los procedimientos descritos fueron investigados en un WD My Cloud Gen 2 con firmware OS5 5.33.102.

1. El problema: procesos que se ejecutan sin intervención del usuario

Un NAS puede realizar operaciones de lectura y escritura incluso cuando ningún usuario está copiando archivos.

El sistema operativo necesita ejecutar periódicamente diversas tareas, entre ellas:

• Actualizar información del dispositivo.
• Comprobar el estado de determinados servicios.
• Supervisar cuotas de almacenamiento.
• Administrar y rotar registros.
• Sincronizar información del sistema.
• Comprobar actualizaciones del firmware.
• Ejecutar operaciones de mantenimiento.

Estas tareas no son necesariamente innecesarias. Muchas forman parte del funcionamiento normal del dispositivo.

Sin embargo, cuando intentamos que el disco permanezca suspendido durante periodos prolongados, conviene identificar cuáles pueden provocar accesos al almacenamiento.

Es importante distinguir entre dos conceptos:

• Actividad de procesos: ejecución de programas en el sistema operativo.
• Actividad física del HDD: operaciones que requieren que el disco esté girando.

Un proceso puede ejecutarse sin acceder al disco principal. Por tanto, encontrar un proceso activo no demuestra automáticamente que sea responsable de un despertar.

2. Identificar las tareas programadas

My Cloud OS5 utiliza el servicio crond para ejecutar tareas en horarios determinados.

La herramienta principal para consultar estas tareas es:

crontab -l

Este comando muestra la programación del usuario actual. En nuestras pruebas utilizamos una sesión administrativa.

Para localizar tareas relacionadas con mantenimiento:

crontab -l | grep -E 'quota|rlog|sync_tm|auto_fw|stime|PullWdlog'

Durante la investigación identificamos tareas de diferentes frecuencias, desde ejecuciones cada minuto hasta operaciones programadas para determinadas horas del día.

3. Interpretar una entrada de cron

Una tarea programada utiliza normalmente cinco campos para determinar el momento de ejecución:

minuto hora dia mes dia_semana comando

Por ejemplo:

*/5 * * * * /ruta/del/script.sh

Esta expresión ejecuta el script cada cinco minutos.

Otro ejemplo:

0 */4 * * * /ruta/del/script.sh

Ejecuta el programa cada cuatro horas, a las 00:00, 04:00, 08:00, 12:00, 16:00 y 20:00.

Esta información permite comprender cuándo pueden coincidir varias operaciones de mantenimiento.

4. Las tareas identificadas en nuestro WD My Cloud

Durante las pruebas identificamos las siguientes tareas como candidatas para revisar su programación.

Tarea	Frecuencia o finalidad	Tratamiento
quota_monitor	Supervisión de cuotas, cada 30 minutos	Ejecución condicionada al estado del disco
rlog	Administración de registros, cada cuatro horas	Ejecución condicionada al estado del disco
sync_tm_to_hd.sh	Sincronización periódica, cada cuatro horas	Ejecución condicionada al estado del disco
stime	Mantenimiento de información temporal	Reprogramación a las 03:00
PullWdlogConfig.sh	Operación interna relacionada con registros	Reprogramación a las 03:05
auto_fw -a -c	Operación relacionada con firmware	Reprogramación a las 03:20
auto_fw -c 1	Operación relacionada con firmware	Reprogramación a las 03:25

También identificamos procesos como rt_script.sh y sysinfo_update.sh, con ejecuciones frecuentes.

No todos estos componentes fueron modificados. El hecho de que una tarea se ejecute periódicamente no es suficiente para justificar su desactivación.

5. Nuestra estrategia de optimización

En lugar de eliminar las tareas de mantenimiento, aplicamos dos estrategias.

5.1. Evitar determinadas operaciones cuando el disco está suspendido

Creamos pequeños scripts auxiliares que comprueban el estado del HDD antes de ejecutar determinados comandos originales del firmware.

Su lógica es:

1. Consultar el estado del disco mediante hdparm.
2. Si el resultado es STANDBY, no ejecutar la tarea.
3. Si el disco está activo o el estado es desconocido, ejecutar el comando original.

5.2. Concentrar tareas de mantenimiento durante la madrugada

Reprogramamos algunas tareas para ejecutarlas entre las 03:00 y las 03:25.

La intención fue concentrar determinadas operaciones en una ventana temporal, en lugar de distribuirlas en diferentes momentos del día.

Esta estrategia es una hipótesis de optimización: su efecto real debe evaluarse mediante mediciones.

6. Consultar el estado del disco antes de ejecutar una tarea

El comando utilizado es:

hdparm -C /dev/sda

En nuestros scripts extraemos el estado mediante:

STATE=$(hdparm -C /dev/sda 2>/dev/null | awk '/drive state is:/ {print $4}')

Después utilizamos una condición:

case "$STATE" in
    standby)
        exit 0
        ;;
    *)
        COMANDO_ORIGINAL
        ;;
esac

De esta manera, el script termina sin ejecutar la operación original cuando el disco está suspendido.

Si el estado no se reconoce, ejecuta el comando original. Esto evita omitir automáticamente la tarea ante un fallo en la consulta.

7. Optimización de quota_monitor

La primera tarea modificada fue quota_monitor.

Este programa forma parte de las herramientas de administración de cuotas del NAS.

Originalmente se ejecutaba cada 30 minutos.

Creamos un archivo temporal:

/tmp/quota-monitor-safe.sh

Con el siguiente contenido:

#!/bin/sh

STATE=$(hdparm -C /dev/sda 2>/dev/null | awk '/drive state is:/ {print $4}')

case "$STATE" in
    standby)
        exit 0
        ;;
    *)
        /usr/sbin/quota_monitor
        ;;
esac

La tarea de cron se modificó para ejecutar el wrapper en lugar del comando original.

*/30 * * * * /tmp/quota-monitor-safe.sh &

Si el disco está suspendido, la supervisión de cuotas se omite durante esa ejecución.

Esto puede reducir operaciones innecesarias, pero también retrasa dicha supervisión. Por tanto, no debe aplicarse sin considerar las necesidades administrativas del equipo.

8. Optimización de rlog

Otra tarea identificada fue rlog, utilizada para administrar determinados registros del sistema.

La instrucción original utiliza:

/usr/sbin/rlog -s /usr/local/modules/files/syslog_rotate.conf

Creamos el siguiente wrapper:

#!/bin/sh

STATE=$(hdparm -C /dev/sda 2>/dev/null | awk '/drive state is:/ {print $4}')

case "$STATE" in
    standby)
        exit 0
        ;;
    *)
        /usr/sbin/rlog -s /usr/local/modules/files/syslog_rotate.conf
        ;;
esac

Lo almacenamos en:

/tmp/rlog-safe.sh

La tarea de cron quedó:

0 */4 * * * /tmp/rlog-safe.sh

Esta modificación evita ejecutar la rotación programada cuando el HDD está en STANDBY.

Debe considerarse que omitir rotaciones puede afectar la administración de los registros, especialmente si el disco permanece suspendido durante mucho tiempo.

9. Optimización de sync_tm_to_hd.sh

También identificamos una tarea periódica que ejecuta:

sync_tm_to_hd.sh

Para evitar su ejecución cuando el disco estuviera suspendido, creamos:

/tmp/sync-tm-safe.sh

Contenido:

#!/bin/sh

STATE=$(hdparm -C /dev/sda 2>/dev/null | awk '/drive state is:/ {print $4}')

case "$STATE" in
    standby)
        exit 0
        ;;
    *)
        /usr/sbin/sync_tm_to_hd.sh
        ;;
esac

La programación resultante fue:

0 */4 * * * /tmp/sync-tm-safe.sh &

Esta configuración ejecuta la comprobación cada cuatro horas.

Si el disco está en STANDBY, no realiza la sincronización durante esa ejecución.

Importante: este método no pospone automáticamente la tarea hasta el siguiente despertar. Simplemente omite la ejecución programada.

10. Por qué utilizamos /tmp

Los tres scripts auxiliares se almacenan en el directorio:

/tmp

En nuestro WD My Cloud, esta ubicación corresponde al sistema temporal.

Los archivos almacenados allí desaparecen cuando reiniciamos el dispositivo.

Esta característica resulta útil porque los wrappers son pequeños archivos que no necesitan almacenarse permanentemente.

Sin embargo, existe una condición: deben reconstruirse antes de que cron intente ejecutarlos.

Para resolverlo, incorporamos su creación automática al script principal del monitor de suspensión.

Durante nuestras pruebas comprobamos que los tres archivos se regeneraban después de reiniciar.

11. Recuperación automática de los wrappers

El monitor principal se ejecuta cada cinco minutos.

Durante cada ejecución comprueba si existen los scripts auxiliares.

Si alguno no existe, lo crea nuevamente y le asigna permisos de ejecución.

Una comprobación típica es:

if [ ! -x /tmp/quota-monitor-safe.sh ]; then
    # Crear nuevamente el wrapper
fi

Esto permite reconstruir las herramientas temporales después del arranque.

No obstante, la recuperación depende de que el monitor principal esté funcionando.

Si su tarea programada desaparece, los wrappers pueden dejar de crearse y las tareas que dependen de ellos podrían fallar.

12. Corregir entradas restauradas por el firmware

Durante la investigación observamos que algunas tareas de cron podían volver a su configuración original.

Para resolverlo, el monitor incorpora comprobaciones que buscan entradas específicas del firmware.

Cuando encuentra una entrada original conocida, la sustituye por nuestra versión optimizada.

Por ejemplo, para quota_monitor utilizamos una expresión como:

if crontab -l 2>/dev/null |
   grep -q '^\*/30 \* \* \* \* /usr/sbin/quota_monitor &$'; then

    crontab -l 2>/dev/null |
    sed 's|^\*/30 \* \* \* \* /usr/sbin/quota_monitor &$|*/30 * * * * /tmp/quota-monitor-safe.sh \&|' |
    crontab -
fi

Esta lógica permite volver a aplicar la modificación cuando el firmware restaura una entrada original reconocida.

El procedimiento no modifica todas las tareas de cron, sino únicamente aquellas que coinciden con patrones previamente identificados.

Aun así, reemplazar entradas del crontab requiere precaución, ya que un error puede afectar servicios del sistema.

13. Concentrar el mantenimiento durante la madrugada

Además de los wrappers, modificamos los horarios de determinadas tareas.

La configuración final se concentró principalmente alrededor de las 03:00.

Horario	Tarea
03:00	stime
03:05	PullWdlogConfig.sh
03:20	auto_fw -a -c
03:25	auto_fw -c 1

El objetivo fue reducir la dispersión de determinadas operaciones de mantenimiento a lo largo del día.

En nuestro caso, la modificación de horarios se realizó mediante sustituciones controladas en el script de monitoreo.

No modificamos indiscriminadamente todas las tareas internas del NAS.

14. Consultar la configuración actual

Para revisar las tareas relacionadas con las modificaciones utilizamos:

echo "=== TAREAS OPTIMIZADAS ==="

crontab -l | grep -E \
'quota|rlog|sync-tm|stime|PullWdlog|auto_fw'

echo
echo "=== SCRIPTS AUXILIARES ==="

ls -l /tmp/*-safe.sh

echo
echo "=== ESTADO DEL HDD ==="

hdparm -C /dev/sda

Esta comprobación permite identificar:

• Las tareas de cron actualmente programadas.
• La existencia de los wrappers.
• Los permisos de los archivos auxiliares.
• El estado de energía del disco.

15. Comprobar el funcionamiento después de reiniciar

La persistencia es un aspecto importante de nuestra configuración.

Como el firmware reconstruye algunos archivos durante el arranque, una modificación que funciona inicialmente puede desaparecer.

En nuestro caso realizamos un reinicio y comprobamos lo siguiente:

1. La tarea principal del monitor seguía registrada.
2. El servicio cron estaba funcionando.
3. Los wrappers de /tmp habían sido reconstruidos.
4. Las tareas optimizadas aparecían en el crontab.

Para realizar esta comprobación:

echo "=== TIEMPO DESDE EL ARRANQUE ==="
uptime

echo "=== MONITOR ==="
crontab -l | grep disk-sleep-monitor

echo "=== WRAPPERS ==="
ls -l /tmp/*-safe.sh

echo "=== PROGRAMACION ==="
crontab -l | grep -E \
'quota|rlog|sync-tm|auto_fw|stime'

Estos resultados demostraron que la configuración podía recuperarse después de un reinicio completo.

16. Resultados medidos

Para evaluar las modificaciones utilizamos el monitor de suspensión descrito en el capítulo anterior.

Una medición de referencia obtenida durante el seguimiento fue:

Desde 2026-10-02 15:35:00:

Activo:       114.48 h  (44.2%)
Idle:         113.42 h  (43.8%)
Dormido:      31.26 h  (12.1%)
Desconocido:  0.00 h  (0.0%)
Total:        259.16 h
Despertares:  68

Posteriormente obtuvimos:

Desde 2026-10-02 15:35:00:

Activo:       146.40 h  (46.6%)
Idle:         136.39 h  (43.4%)
Dormido:      31.26 h  (10.0%)
Desconocido:  0.00 h  (0.0%)
Total:        314.06 h
Despertares:  68

La diferencia es significativa.

Durante aproximadamente 55 horas adicionales de monitoreo, el tiempo acumulado en STANDBY permaneció sin cambios.

El número de despertares también continuó en 68.

Esto significa que durante ese intervalo el monitor no detectó nuevos periodos de suspensión del disco.

Por tanto, aunque las modificaciones de cron funcionaban correctamente, todavía no existía evidencia de que hubieran aumentado el tiempo de suspensión del HDD.

17. Por qué una optimización puede no funcionar

El comportamiento de un NAS depende de numerosos componentes.

Aunque consigamos evitar ciertas tareas programadas, el disco puede seguir recibiendo operaciones de otros procesos.

Entre las posibles fuentes de actividad se encuentran:

• Servicios de compartición de archivos.
• Aplicaciones instaladas.
• Procesos internos del firmware.
• Operaciones de mantenimiento.
• Registros y archivos de estado.
• Accesos desde otros dispositivos de la red.
• Procesos de indexación o exploración de archivos.

Estas son categorías de actividad posibles, no causas confirmadas de nuestro caso.

Para atribuir un despertar a un proceso concreto sería necesario obtener evidencia adicional sobre las operaciones de entrada y salida realizadas durante ese momento.

18. Riesgos de modificar tareas internas

Las tareas del fabricante pueden cumplir funciones necesarias para el funcionamiento y mantenimiento del dispositivo.

Por ejemplo, retrasar una operación de sincronización o rotación de registros podría tener consecuencias no evidentes durante las primeras horas de funcionamiento.

Por esta razón, las modificaciones deben aplicarse cuidadosamente.

Conviene seguir estas recomendaciones:

1. Identificar exactamente la tarea antes de modificarla.
2. Conservar su comando original para poder restaurarlo.
3. Evitar eliminar servicios críticos.
4. Aplicar cambios de forma gradual.
5. Revisar periódicamente los registros del sistema.
6. Comprobar el comportamiento después de reiniciar.
7. Medir el efecto real sobre la suspensión del disco.
8. Revertir cualquier cambio que provoque problemas.

19. Cómo revertir las optimizaciones

Para revertir completamente las modificaciones es necesario actuar sobre dos componentes.

El primero es el monitor principal, que incorpora la lógica para volver a aplicar los ajustes de cron.

El segundo son las entradas del crontab que ejecutan los wrappers.

No basta con restaurar una entrada original si el monitor continúa configurado para sustituirla.

El procedimiento general consiste en:

1. Deshabilitar la lógica de optimización del monitor.
2. Restaurar las tareas originales del firmware.
3. Comprobar que los comandos originales funcionan.
4. Verificar la configuración después de reiniciar.

Debido a que la programación puede variar entre versiones del firmware, no es recomendable publicar un crontab completo para copiarlo indiscriminadamente en otros dispositivos.

Las entradas originales deben recuperarse de una referencia correspondiente al modelo y versión instalados.

20. Diagnóstico rápido

El siguiente conjunto de comandos permite obtener una revisión general sin modificar la configuración.

echo "=== SISTEMA ==="
uptime

echo
echo "=== ESTADO DEL HDD ==="
hdparm -C /dev/sda

echo
echo "=== TAREAS DE MANTENIMIENTO ==="
crontab -l | grep -E \
'quota|rlog|sync-tm|auto_fw|stime|PullWdlog'

echo
echo "=== WRAPPERS ==="
ls -l /tmp/*-safe.sh

echo
echo "=== MONITOR ==="
crontab -l | grep disk-sleep-monitor

echo
echo "=== REPORTE DE SUSPENSION ==="
/mnt/HD/HD_a2/.disk-sleep-monitor/bin/disk-sleep-report.sh

Este diagnóstico permite revisar la programación actual y comparar el estado del sistema con las estadísticas acumuladas del monitor.

21. Conclusiones

La investigación de las tareas programadas de My Cloud OS5 permitió identificar diferentes operaciones periódicas de mantenimiento del NAS.

Implementamos dos estrategias:

• Wrappers condicionados: omitir determinadas tareas cuando el disco está en STANDBY.
• Concentración de horarios: ejecutar algunas operaciones de mantenimiento durante la madrugada.

También desarrollamos un mecanismo que reconstruye los wrappers temporales y restaura determinadas modificaciones de cron.

El funcionamiento técnico quedó comprobado después de reiniciar.

Sin embargo, las mediciones mostraron que el HDD no había incrementado recientemente su tiempo de suspensión.

Por tanto, la conclusión principal es que la optimización de cron puede reducir determinadas operaciones, pero no garantiza por sí sola que un NAS entre en suspensión.

El siguiente paso consiste en continuar identificando las fuentes de actividad y analizar por separado el comportamiento de las aplicaciones y servicios que utilizan el almacenamiento.

---

Próximo capítulo

Capítulo 7. Almacenamiento, respaldos y sincronización programada de archivos en WD My Cloud OS5.

Analizaremos cómo organizar las operaciones de almacenamiento, cómo concentrar transferencias de archivos durante la madrugada y cómo comprobar su impacto sobre la actividad del HDD.

Documentación técnica basada en pruebas realizadas sobre WD My Cloud Gen 2 con firmware My Cloud OS5 5.33.102, septiembre y octubre de 2026.