Los 4 scripts que van primero en un servidor Linux nuevo
Cada vez que provisionás un servidor nuevo, hay una decisión que define cuánto vas a sufrir los próximos dos años: qué instalás antes de tocar la aplicación. El consenso entre quienes ya se comieron suficientes incidentes en producción es claro. Los scripts esenciales para un servidor nuevo en Linux son cuatro y van primero: monitoreo de disco, pipeline de backups con retención, chequeo diario de certificados SSL y un watchdog que reinicia servicios caídos en menos de 60 segundos.
Estos scripts no son código complejo. Cada uno tiene entre 15 y 50 líneas. Son la capa de monitoreo que se instala antes de configurar nginx, antes de levantar la base de datos, antes de deployar nada. La lógica es simple: la primera vez que necesitás monitoring, ya lo necesitabas hace días. Son scripts de Bash que corren vía cron, alertan por email o webhook, y existen porque alguien los escribió bajo presión a las 3 de la mañana cuando ya era tarde.
En 30 segundos
- El orden importa: la capa de monitoreo se instala primero, antes de configurar la aplicación, no después del primer incidente.
- Cuatro scripts base: monitoreo de disco, backups con retención automática, verificación de SSL y watchdog de servicios.
- Watchdog reactivo: reinicia nginx o Postgres dentro de los 60 segundos del crash, en vez de las 6 horas que tarda alguien en notarlo.
- SSL a las 8am: el chequeo diario te avisa cuando faltan 30 días para que expire el certificado, no cuando ya venció.
- Versiones gratis y pagas: los snippets básicos están en BashSnippets.xyz sin costo; el toolkit de producción cuesta USD 9.
¿Qué scripts debería instalar primero en un servidor nuevo antes de configurar la aplicación?
Ponele que levantás un droplet de USD 5 en DigitalOcean para un proyecto personal, o una caja de producción para un cliente. El reflejo natural es ir directo al deploy: instalar el stack, configurar el dominio, subir la app. El monitoreo queda para después. ¿Y cuándo llega ese “después”? Exacto, cuando ya se rompió algo.
El planteo del autor del toolkit (que open-sourceó las versiones básicas en BashSnippets.xyz) invierte el orden. La capa de monitoreo va antes de tocar la aplicación. Antes de nginx. Antes de la base de datos. La razón es práctica: estos scripts no sirven cuando todo anda bien, sirven cuando algo falla, y para entonces ya tienen que estar corriendo.
Lo interesante es de dónde salieron. Según su propio relato en dev.to, le llevó cerca de dos años de incidentes armarlos. No porque sean difíciles, sino porque cada uno nació de una falla puntual donde no tenía la herramienta que necesitaba y la tuvo que improvisar en el peor momento. Cada script es la cicatriz de un downtime.
Son cuatro piezas. Veamos cada una.
Monitoreo de disco: cómo detectar falta de espacio antes del outage
El disco lleno es uno de los outages más estúpidos que existen. No se cae nada por una causa exótica: simplemente Postgres no puede escribir, los logs no rotan, nginx empieza a tirar 500 y vos te enterás por el mail de un usuario. Cubrimos ese tema en detalle en soluciones CI/CD modernas para despliegue.
El script de monitoreo de disco corre por cron cada pocos minutos y revisa el uso de cada partición con un df. Cuando cruza un umbral (ponele 85%), dispara una alerta. Punto. Son 15 o 20 líneas que te dan el margen para entrar, hacer un du, y borrar los logs viejos antes de que el sitio caiga.
Para discos físicos conviene sumarle smartmontools y su utilidad smartctl, que lee los datos S.M.A.R.T. del disco y te avisa de sectores reasignados o errores de lectura antes de que el hardware muera del todo. En servidores headless, donde no tenés a nadie mirando una pantalla, esa alerta temprana es la diferencia entre un reemplazo planificado y una pérdida de datos.
Pipeline de backups automáticos con retención inteligente
Un backup que no tiene política de retención no es un backup, es una bomba de tiempo que te llena el disco (y mirá qué ironía, te dispara la alerta del script anterior). El segundo script arma un pipeline completo.
La mecánica básica es conocida: un tar o un pg_dump que corre por cron, comprime, y manda el archivo a un destino remoto. Lo que separa un backup de juguete de uno de producción es la retención escalonada. La idea es no guardar todo para siempre ni borrar demasiado pronto.
- Diarios de la última semana: para recuperarte de un error reciente con granularidad de un día.
- Semanales del último mes: cuatro snapshots que cubren el mes sin ocupar tanto.
- Mensuales del último año: doce puntos de restauración para auditorías o data que se corrompió hace rato y nadie notó.
La parte que la gente olvida es el script de limpieza: un proceso que recorre el directorio de backups y borra lo que ya quedó fuera de la ventana de retención. Sin eso, el pipeline funciona divino tres meses y después te quedás sin espacio. Si trabajás con infraestructura web o VPS en la región, podés tirar los backups a un bucket externo o a un segundo servidor en donweb.com para no tenerlos en la misma caja que estás respaldando (porque respaldar en el mismo disco que podés perder no respalda nada).
¿Qué hacer para que los certificados SSL no expiren sin aviso?
Te cuento una clásica: configurás Let’s Encrypt con su renovación automática, te olvidás del tema, y nueve meses después el sitio tira NET::ERR_CERT_DATE_INVALID porque el cron de certbot se rompió en silencio y nadie lo estaba mirando. El primero en enterarse es un cliente. Más contexto en comparativa de herramientas de automatización.
El tercer script corre todos los días a las 8 de la mañana y verifica la fecha de expiración de cada certificado. No depende de que la renovación funcione: la chequea de afuera, como lo haría un usuario. Si a algún certificado le quedan menos de 30 días, te manda la alerta.
Esos 30 días de anticipación son todo. Te dan tiempo de revisar por qué no renovó, correr el comando a mano, validar el challenge, lo que haga falta, sin la presión de tener el sitio caído mientras lo resolvés. La verificación se hace con openssl s_client apuntando al puerto 443 y parseando la fecha del notAfter. Quince líneas que te ahorran un papelón.
Watchdog de servicios: reinicio automático de nginx y Postgres en 60 segundos
Los servicios se caen. Por un OOM killer que se llevó puesto el proceso, por un bug, por una actualización que salió mal. La pregunta no es si se van a caer, es cuánto vas a tardar en darte cuenta.
El watchdog monitorea los procesos clave (nginx, Postgres, lo que definas) y, si detecta que uno está caído, lo reinicia automáticamente. La ventana de reacción baja de las clásicas 6 horas (el tiempo que tarda un humano en notar que el sitio está down un domingo) a unos 60 segundos. Tema relacionado: configuración correcta para sitios multiidioma.
Acá conviene una aclaración honesta: para muchos servicios, systemd ya hace gran parte de esto con Restart=always en el unit file. El valor del watchdog como script aparte está en los chequeos que systemd no hace solo: que el puerto realmente responda, que la base acepte conexiones, que nginx devuelva un 200 en el health endpoint y no solo que el proceso exista. Un proceso vivo que no responde es tan inútil como uno muerto, y el watchdog bien hecho cubre ese caso.
BashSnippets.xyz: versión gratis vs toolkit de USD 9
Las versiones básicas de estos scripts son gratis y, según el autor, van a seguir siéndolo. Están en BashSnippets.xyz como scripts single-purpose, cada uno resolviendo un problema, completos y funcionando. Para la mayoría de los proyectos personales, con eso zafás.
La diferencia con el toolkit de USD 9 está en el salto a producción: las versiones que el autor corre de verdad incluyen manejo de errores más robusto, configuración de alertas por múltiples canales y ajustes que solo aprendés cuando un script te falló en serio. Es la brecha entre el código del tutorial y el código que aguanta un cliente real.
| Característica | Snippets gratis | Toolkit (USD 9) |
|---|---|---|
| Costo | Gratis | USD 9 (pago único) |
| Enfoque | Single-purpose, tutorial | Producción |
| Tamaño por script | 15-50 líneas | 15-50 líneas (endurecidas) |
| Manejo de errores | Básico | Robusto |
| Canales de alerta | Email simple | Email y webhook |
| Ideal para | Side projects, aprender | Cajas de producción y clientes |
¿Cómo implementar estos scripts sin desconfigurar nada?
La gran ventaja de que cada script sea independiente y de 15 a 50 líneas es que no hay un “instalador” que te toque medio sistema. Los integrás de a uno y cada uno hace lo suyo.
- Elegí según necesidad: en un servidor sin disco físico propio quizás el monitoreo S.M.A.R.T. no aplica, pero el de SSL y el watchdog sí. No instales lo que no vas a usar.
- Programá con cron: disco cada 5 minutos, SSL una vez al día a las 8am, backups en horario de baja carga (madrugada), watchdog cada minuto. Un
crontab -ey listo. - Configurá el canal de alerta primero: definí a dónde van las notificaciones (email o webhook a Slack/Discord) antes de activar nada. Una alerta que nadie ve es ruido.
- Probá el camino de falla: bajá nginx a propósito y mirá si el watchdog lo levanta. Llená el disco con un archivo dummy y verificá que llegue la alerta. Un backup que nunca restauraste no es un backup.
Errores comunes al automatizar el monitoreo de un servidor
- Instalar el monitoreo después del primer incidente. El error de fondo. Para cuando lo necesitás, ya estás pagando el downtime. Va primero, siempre.
- Backups sin retención ni restauración probada. Guardar dumps que nunca borrás te llena el disco; guardar dumps que nunca restauraste no te garantiza nada. Probá una restauración real al menos una vez.
- Confiar en la renovación de SSL sin verificarla. Que
certbotesté instalado no significa que esté renovando. El chequeo diario externo es el que te salva del certificado vencido. - Watchdog que solo mira si el proceso existe. Un Postgres vivo que no acepta conexiones igual te tira el sitio. Chequeá respuesta real, no presencia del proceso.
- Alertas a un canal que nadie mira. Mandar todo a un mail que revisás cada tres días es casi peor que no tener alertas, porque te da una falsa sensación de cobertura.
Preguntas Frecuentes
¿Cuáles son los scripts esenciales para un servidor nuevo en Linux?
Los cuatro básicos son monitoreo de disco, pipeline de backups con retención automática, verificación diaria de certificados SSL y un watchdog de servicios. Cada uno tiene entre 15 y 50 líneas de Bash y corre por cron. La regla es instalarlos antes de configurar la aplicación, no después. Ya lo cubrimos antes en ejecutar herramientas sin dependencias externas.
¿Cómo automatizo el monitoreo de disco en mi servidor?
Con un script que corre por cron cada pocos minutos, revisa el uso de cada partición con df y dispara una alerta cuando cruza un umbral (por ejemplo, 85%). Para discos físicos, smartmontools y su comando smartctl agregan detección temprana de fallas de hardware vía datos S.M.A.R.T.
¿Cómo evito que un certificado SSL expire sin que me avisen?
Con un script que corra a diario (por ejemplo, a las 8am) y verifique la fecha de expiración con openssl s_client contra el puerto 443. Si quedan menos de 30 días, manda una alerta. No dependas solo de la renovación automática de certbot: chequealo de afuera por separado.
¿Cuánto cuesta el toolkit de scripts de producción?
El toolkit completo cuesta USD 9 en un pago único e incluye las versiones endurecidas para producción. Las versiones básicas de cada script son gratis y están disponibles en BashSnippets.xyz, pensadas para side projects y para aprender.
¿Sirve systemd en lugar de un watchdog propio?
Systemd con Restart=always cubre el reinicio de procesos que mueren, pero no verifica que el servicio responda de verdad. Un watchdog dedicado chequea que el puerto conteste y que el endpoint devuelva un 200, no solo que el proceso exista. Para servicios críticos conviene combinar ambos.
Conclusión
Lo que cambia con este enfoque no es la tecnología, es el orden. Poner la capa de monitoreo antes que la aplicación convierte cuatro scripts de 15 a 50 líneas en la diferencia entre enterarte de un problema por una alerta a tiempo o por el mail de un usuario enojado.
Si estás por levantar un servidor esta semana, el plan es directo: instalá primero el monitoreo de disco y el watchdog, configurá el chequeo de SSL diario, y dejá andando el pipeline de backups con su limpieza de retención. Después deployá la app. Arrancá con las versiones gratis de BashSnippets.xyz, probá el camino de falla de cada uno, y si el servidor es de un cliente, evaluá el toolkit de USD 9. La próxima vez que algo se caiga a las 3 de la mañana, lo vas a agradecer.
