Un servidor que lleva meses funcionando acumula desorden: descargas de paquetes que ya no necesita, imágenes antiguas del kernel en /boot, contenedores Docker detenidos, cachés de compilación, archivos de registro rotados, actualizaciones de seguridad pendientes y servicios que poco a poco han ido perdiendo memoria. Nada de eso es un problema por sí solo, pero se va acumulando hasta que el disco se llena, una actualización falla o un sitio va más lento de lo que debería.
Limpiar este servidor es un botón que repasa todo eso de una sola vez — y una conversación de chat que confirma cualquier acción arriesgada antes de ejecutarla.
Qué hace exactamente
Tres categorías, cada una se puede ejecutar por separado: marca lo que quieras y deja el resto:
- Liberar espacio en disco — limpia la caché de descargas de paquetes, elimina dependencias de paquetes ya retirados, purga contenedores Docker detenidos e imágenes sin referencia, recorta la caché de compilación de Docker de más de una semana, reduce los registros de systemd a los últimos 30 días, elimina archivos de registro rotados (
.gz/.1/.old) de más de 30 días y, opcionalmente, elimina imágenes antiguas del kernel / revisiones snap deshabilitadas. - Instalar actualizaciones de seguridad — actualiza la lista de paquetes e instala la versión más reciente de cada paquete instalado (
apt update+apt upgrade). Si la actualización incluye un kernel nuevo, eso pasa a ser una tarea posterior de “reiniciar cuando venga bien”, no algo que simplemente ocurra sin avisarte. - Reiniciar servicios con fugas de memoria — opcional. Reinicia tus sitios web + bases de datos + workers uno por uno (~10–30 s de caída cada uno) para restablecer la memoria que han ido acumulando lentamente durante semanas. Medimos el tiempo de respuesta antes y después, y solo decimos que está “más rápido” si hay pruebas reales.
Además de eso, siempre se ejecutan algunas comprobaciones de solo lectura: informe de puntos calientes de disco (qué directorios están consumiendo tu disco), servicios fallidos (cualquier cosa marcada por systemd), inicios de sesión SSH recientes (para que detectes los desconocidos), estado de Fail2ban y una comprobación de /var/run/reboot-required (el archivo que deja la actualización del kernel para indicar “tienes que reiniciar”).
Cómo iniciarlo
Cuatro puntos de entrada, el mismo modal:
| Dónde estás | Cómo |
|---|---|
| Quieres empezar desde cero | Escribe /cleanup en el cuadro de chat y pulsa Intro |
| Estás explorando recetas | Abre , busca Limpiar este servidor y haz clic |
| El disco empieza a preocuparte | Abre Detalles del servidor → pestaña Almacenamiento → la tarjeta CTA Limpiar este servidor de la parte superior |
| Ves “N actualizaciones disponibles” en la pestaña Actualizaciones | Detalles del servidor → pestaña Actualizaciones → la tarjeta CTA Instalarlas con una limpieza completa |
La CTA de Almacenamiento es la ruta más habitual: viste que el disco se estaba llenando, fuiste a revisar el almacenamiento y el botón de limpieza está justo ahí.
El modal previo
Al hacer clic en cualquier punto de entrada se abre la misma lista de comprobación. El modal hace dos cosas a la vez: te muestra exactamente qué va a pasar y autoriza los pasos seguros para que el chat no te haga perder tiempo pidiéndote otra vez confirmación para cosas que ya marcaste.
Fíjate en los puntos: te indican qué puedes esperar:
- Salvia (seguro) — se ejecuta de inmediato. Sin aviso en el chat, sin confirmación; solo un estado de una línea indicando que se hizo.
- Melocotón (confirmar en el chat) — se detiene para pedir un sí/no en la conversación antes de ejecutarse. Se usa para cosas como instalar actualizaciones que podrían reiniciar servicios.
- Rosa (confirmar por elemento) — muestra cada candidato (por ejemplo, cada volumen Docker huérfano) y pregunta uno por uno. Es el nivel de “¿seguro que quieres hacerlo con este elemento concreto?”.
Cada fila también tiene un desplegable “¿Qué hace esto?” con el comando de shell exacto que ejecutaremos, para que los usuarios técnicos puedan comprobar que no hay sorpresas. Los usuarios no técnicos pueden ignorarlo.
El interruptor Reiniciar tus cargas de trabajo después de la limpieza en la parte inferior del modal es una decisión aparte. Reinicia cada sitio web / base de datos / worker en ejecución, uno a uno, con ~10–30 segundos de caída cada uno, mide el tiempo de respuesta antes y después y te cuenta la diferencia. Déjalo desactivado si ahora mismo la caída es peor que tener un poco de memoria con fugas; actívalo si ya estás haciendo mantenimiento.
Tus marcas se recuerdan por servidor: la próxima vez que abras el modal en el mismo servidor, las mismas casillas ya estarán marcadas. Las acciones nuevas añadidas por futuras actualizaciones aparecerán automáticamente marcadas por defecto si son seguras (y sin marcar para el resto).
Qué ocurre durante la ejecución
Haz clic en Iniciar limpieza y el modal se cierra. A partir de ahí, la conversación guía el proceso:
- Instantánea — un lote rápido de comandos de solo lectura captura la situación “antes” (disco libre, RAM, tamaño de registros, actualizaciones pendientes, servicios fallidos, directorios más grandes, inicios de sesión recientes, Fail2ban). El chat solo dice “Instantánea tomada, X GB libres, N actualizaciones pendientes. Iniciando limpieza…”; no ves un muro de salida sin procesar.
- Los pasos seguros se ejecutan solos.
apt update,apt clean,journalctl --vacuum,docker system prune, la eliminación de registros rotados: se ejecutan en silencio, y cada uno emite un estado de una línea. Sin solicitudes de aprobación (el modal ya los autorizó). - Los pasos delicados preguntan. Cualquier cosa con punto melocotón (
apt upgrade,docker system prune -a, eliminación de kernels, revisiones snap) hace una pregunta de una línea en el chat antes de ejecutarse. Si dices sí, la acción se ejecuta; si dices no, se omite y la siguiente acción continúa: la receta no se detiene por una sola negativa.
- Los pasos por elemento preguntan una vez por candidato. Si marcaste la eliminación de volúmenes huérfanos, Faro enumera cada volumen sin referencia y pregunta uno por uno, incluyendo una pista de qué imagen solía montarlo. “No a todo” / “para” / “omitir el resto” corta los elementos restantes.
- Reinicios opcionales de cargas de trabajo. Si lo activaste, cada sitio/base de datos en ejecución se reinicia con muestras de tiempo de respuesta antes y después.
Si en algún momento se actualiza el kernel y hace falta reiniciar para usar realmente el kernel nuevo, la receta no reinicia automáticamente. Muestra una tarjeta de seguimiento sobre la que puedes actuar más tarde.
Cuándo se produce un reinicio
Cualquier acción que corte la conexión SSH — systemctl reboot, reinicio de sshd / dbus / networking — activa un banner ámbar fijo en la parte superior del chat. El chat se detiene solo con un mensaje sintético “Reinicio solicitado. El chat quedará en silencio durante ~30–60 s…”; mientras el banner esté visible, no se puede enviar.
Entre bastidores, una sonda vuelve a intentar SSH cada pocos segundos usando las credenciales que Server Manager guardó en caché cuando te conectaste. Cuando el servidor responde, el banner cambia a verde (“El servidor ha vuelto · uptime 8 s · reanudando monitorización”), se cierra automáticamente a los 5 segundos y el cuadro de texto vuelve a activarse. No hace falta actualizar el navegador.
El resumen y “Qué tienes que hacer”
Cuando termina la ejecución, Faro publica un mensaje de cierre con las mejoras cuantificadas al principio y una tabla de métricas modificadas.
La tabla solo incluye filas en las que la acción subyacente se ejecutó Y el cambio no es cero; así que, si omitiste Docker, no tendrás una fila de Docker. La columna “Por qué importa” usa lenguaje claro (“Espacio para bases de datos y subidas”, “Vulnerabilidades corregidas”, “Menos competencia por la CPU”), no jerga.
Si un reinicio de carga de trabajo produjo una mejora medible, también verás una tabla Tiempo de respuesta de la carga de trabajo por carga de trabajo, y solo entonces. La receta no dirá “tu sitio va más rápido” basándose en ruido.
Tarjetas de acciones de seguimiento
Todo lo que la limpieza no pudo completar por sí sola — un reinicio pendiente, servicios ejecutando código de bibliotecas desactualizado, cargas de trabajo que rechazaste reiniciar, volúmenes huérfanos a los que dijiste no — se muestra como una sección Qué tienes que hacer con tarjetas numeradas. Cada tarjeta ofrece dos formas de gestionarlo:
- Opción A — pídemelo aquí — una ruta de chat de un clic. El texto de respuesta del recuadro aparece como un chip clicable encima del cuadro de texto, para que no tengas que volver a subir.
- Opción B — desde la consola de tu proveedor — pasos específicos de tu proveedor, clic por clic, para hacer lo mismo (por ejemplo, “DigitalOcean → Droplet → Power → Reboot”). Útil si prefieres hacerlo tú de forma deliberada.
- Compromiso — una frase por tarjeta que explica cuándo tiene más sentido cada ruta.
La tira de chips fijada encima del cuadro de texto refleja estas tarjetas como seguimientos pendientes ☐. Haz clic en un chip → su texto de respuesta rellena el cuadro de texto → pulsa Enviar. Mientras Faro trabaja en ello, el chip cambia a ⏳ en curso; cuando termina, aparece ✓ tachado y se borra automáticamente a los 5 segundos. Cada chip también tiene un pequeño botón × para descartarlo si has decidido ignorar ese seguimiento; al ocultarlo, permanecerá oculto durante el resto de la sesión del navegador.
Casos límite habituales
“No se encontraron volúmenes huérfanos” — la acción por elemento simplemente lo dice y se omite. No es un error; la lista estaba vacía.
reboot-required ya estaba marcado antes de la limpieza — es habitual cuando otra persona (o una ejecución anterior) instaló actualizaciones sin reiniciar todavía. La receta comprueba /var/run/reboot-required tanto en el momento de la instantánea como después de apt upgrade. Si ya estaba ahí, la tarjeta de seguimiento “Reiniciar el servidor” aparece aunque esta limpieza no haya instalado nada nuevo: sigue siendo la acción correcta.
Mis sitios están detrás de Traefik / nginx / Apache — la receta no toca la configuración de tu servidor web. Reinicia los contenedores subyacentes (o unidades systemd) de los sitios que puede identificar a partir del inventario; el proxy sigue funcionando con normalidad. Si el proxy inverso de una carga de trabajo está delante de contenedores que Server Manager no conoce (una configuración personalizada no gestionada), se omite en silencio: sin URL de prueba no hay reinicio medible.
Snap no está instalado en este servidor — el paso “Eliminar revisiones snap deshabilitadas” simplemente dice “Snap no está instalado — omitiendo.” y continúa. Marcarlo en un servidor sin snap no hace daño.
**apt autoremove eliminaría algo que quiero conservar** — cada paso autoremove va precedido de una ejecución de prueba que imprime “Se eliminaría: pkg-a, pkg-b, …”. Si la lista no te parece correcta, di no: la ejecución real solo ocurre después de que confirmes.
Dije que sí a un paso y quiero echarme atrás a mitad de camino — al pulsar Esc se detiene el agente. Los comandos que ya se están ejecutando no se interrumpen (terminan), pero el bucle sale. Más tarde puedes pedirle a Faro que vuelva sobre cualquier cosa que se haya omitido.
El chat parece bloqueado durante el reinicio de un servicio — cualquier cosa que reinicie sshd, dbus o la pila de red activa el mismo banner que un reinicio (variante de corto plazo). Si aparece el banner, el chat está en pausa intencionadamente; si no aparece y el chat parece realmente congelado, consulta Recuperar cuando SSH deja de funcionar.
El informe final: en qué fijarte
El mensaje de resumen tiene una estructura deliberadamente consistente para que puedas revisarlo rápido:
- Titular — una línea en negrita: “🧹 Recuperados 6,2 GB e instaladas 14 actualizaciones de seguridad.” Esa es la mejora. El número que no cambió no se menciona.
- Explicación en una línea — la mejora concreta más importante en lenguaje claro (más disco liberado, seguridad corregida, menos servicios fallando; lo que haya sido mayor).
- Tabla “Qué cambió” — Antes / Después / Cambio / Por qué importa, una fila por cada métrica que realmente haya cambiado. Filas posibles: espacio libre en disco (GB y %), inodos libres (%), uso de disco de Docker, tamaño de registros del sistema, actualizaciones de seguridad pendientes, servicios fallidos, memoria disponible, carga en segundo plano.
- Tabla “Tiempo de respuesta de la carga de trabajo” (solo si optaste por reinicios Y hubo una mejora medible) — antes / después / cambio por carga de trabajo.
- Sección “Qué tienes que hacer” (solo si hay seguimientos) — las tarjetas numeradas descritas arriba.
- Pie “Omitido: …” (solo si rechazaste pasos) — la lista de etiquetas de acciones para que puedas volver a ejecutar más tarde y revisarlas.
Si el servidor ya estaba ordenado y no había nada que hacer, Faro cierra con “Tu servidor ya está ordenado. No hay nada que hacer.”: sin tabla de resumen inventada, sin informe de relleno.
Referencia
Qué queda preautorizado y qué sigue preguntando
| Nivel | Ejemplos | Comportamiento |
|---|---|---|
| Seguro | apt update, apt clean, docker system prune -f, journalctl --vacuum-time=30d, find /var/log … -delete | Preautorizado por las marcas del modal: se ejecuta automáticamente, estado de una línea |
| Precaución | apt upgrade, docker system prune -a, eliminación de kernels, eliminación de revisiones snap | Se detiene para pedir sí/no en el chat |
| Por elemento | Eliminación de volúmenes huérfanos | Pregunta uno por uno; “detener”/“omitir el resto” corta el proceso |
| Comprobaciones de salud de solo lectura | df, free, last, fail2ban-client status, puntos calientes de disco | Siempre se ejecutan (sin importar las marcas) |
Almacenamiento de tus marcas — tu selección (y el interruptor de reinicio de cargas de trabajo) se guarda en el localStorage de tu navegador, asociado al hostname del servidor. Al borrar los datos del navegador, las marcas vuelven a la selección predeterminada.
Cómo funcionan los seguimientos y la omisión durante reinicios — cuando la receta de limpieza está activa, los scripts de instantánea de solo lectura de la receta y cualquier comando de nivel seguro que hayas marcado en el modal omiten el clasificador de comandos destructivos: eso evita los avisos duplicados de “¿Aprobar este comando?”. Los niveles de precaución y por elemento siempre vuelven a preguntar. La omisión tiene en cuenta el contenido (cada segmento de comando se valida contra una lista permitida de solo lectura) y los patrones prohibidos como rm -rf / siempre se bloquean.