Hola, ¿qué tal? ¿Cómo estás? Espero que todo vaya muy bien. Te saluda Alex Ávalos y este es Panel de Control,
el podcast para quienes quieren tener el control de su propio servidor y disfrutar de las ventajas del Hosting VPS.
En el episodio anterior hablamos de las SSH Keys, de las claves SSH,
y cómo son más seguras y recomendables que las contraseñas.
En este episodio vamos a hablar algo muy importante,
pero que muchos lo tienen así de menos.
Y se ponen a darle importancia hasta que ya es demasiado tarde.
Estamos hablando de las actualizaciones y el mantenimiento.
Hay una frase muy popular en el mundo de la tecnología y de la informática.
Si funciona, no se toca.
Y suena lógico, la verdad es que sí.
Por ejemplo, si tu servidor está funcionando, todo está funcionando, las webs cargan bien, las bases de datos funcionan bien, el servidor funciona bien, todo está bien.
¿Para qué vas a actualizar? ¿Para qué vas a arriesgarte a que algo se rompa?
Este pensamiento, este tipo de pensamiento, esta actitud es muy peligrosa.
Y es el error más grande que puedes cometer.
En el 2017 pasó algo que cambió el Internet.
La IA, no.
Facebook, no.
MSN Messenger, tampoco.
El Ramsonware WannaCry infectó más de 200,000 computadoras en 150 países.
Un caos.
hospitales, empresas, gobiernos, todo paralizado.
¿Y cómo entró este ransomware?
Entró por una vulnerabilidad en Windows.
Y ya antes, no, no, no, no, no, no, ya, ya, ya, ya.
Cualquiera va a decir, ay, Windows tenía que ser, fíjate que no.
Microsoft ya había hecho las tareas.
Microsoft había parcheado dos meses antes.
Es decir, que ya había solucionado dos meses antes del desastre. Dos meses antes ya estaba disponible la actualización que corregía este problema, esta vulnerabilidad.
Ya estaba y gratis y era cuestión de instalar, actualizar, ya estaba listo todo. Pero la gente no actualizó. Las empresas no actualizaron. En el hospital no actualizaron. En los gobiernos tampoco actualizaron.
Siguieron la regla. Si funciona, no se toca. Y WannaCry entró por esa puerta abierta de esa vulnerabilidad. En tu servidor VPS pasa lo mismo. Cada día se descubren nuevas vulnerabilidades, tanto para tu sistema operativo como para los programas y servicios que corres y que tenés funcionando en tu servidor.
incluso en las librerías que usas también.
Y cada día salen parches, salen, digamos, actualizaciones que corrigen esas vulnerabilidades.
Si vos no actualizas, tu servidor tiene estas puertas abiertas a un potencial hackeo
y cualquiera puede usar y aprovechar.
Por eso ya luego vienen los sustos y los disgustos.
Si no se actualiza.
Y si hablamos de las actualizaciones y el mantenimiento,
estamos hablando de un nuevo superpoder que estás a punto de conocer,
aprender y espero aprovechar.
Y todo esto comienza con entender que no todas las actualizaciones son iguales.
Hay tres tipos de actualizaciones.
El primer tipo son las actualizaciones de seguridad.
Estas son críticas.
Arreglan vulnerabilidades que podrían ser explotadas, no son opcionales.
No puedes decir, lo voy a hacer después.
No, en el momento que están disponibles, se tienen que instalar inmediatamente.
Inmediatamente, justo en el momento de estar disponibles.
Por ejemplo, sale un parche de seguridad para el protocolo SSH.
Esta vulnerabilidad permitiría el acceso no autorizado.
Si vos decís, la voy a actualizar después. Ese después, durante ese después, el tiempo de ese después, justo en ese espacio, alguien va a explotar la vulnerabilidad, va a entrar a tu servidor y desastre.
Las actualizaciones de seguridad no son negociables, no son para después, no son para cuando se pueda y a mi criterio son las únicas que deberíamos de permitir que se ejecutan de forma automatizada.
Siguientes, las actualizaciones menores. Estas mejoran el sistema, traen nuevas funcionalidades, corrigen bugs menores, mejoras de rendimiento, pero no son tan urgentes. Son importantes, pero no son tan urgentes como las de seguridad.
Esto de que no sean tan urgentes son el motivo por el cual la gran mayoría las ignoran.
Pero como máximo, yo te recomendaría hacer estas actualizaciones menores cada mes, por lo menos.
Veamos ahora las actualizaciones mayores de nuestros sistemas operativos.
estas si son delicadas
y van a depender mucho de cada
proyecto y de cada servidor
y estamos hablando
de ese cambio de versión del sistema
operativo a la inmediata
superior, por ejemplo
en Ubuntu la 22.04
la actualización
mayor fue a la
24.04, por ejemplo
estas si o si
requieren de una planificación
y se puede esperar
O sea, no hay que correr, podemos esperar.
Podemos probar primero en un servidor de pruebas,
podemos evaluar si nuestro proyecto, el stack, el software,
lo requiere y es compatible.
Y dependiendo del sistema operativo,
esto debería de hacerse sí o sí.
Pero eso depende.
porque el soporte de la versión vieja termina en algún momento
y en ese momento en el que termina ya el sistema queda bajo riesgo.
Y te digo yo que esto es un depende porque en caso de que uses Ubuntu,
cada versión que usamos de Ubuntu son LTS,
que por sus siglas en inglés significan soporte prolongado.
Y vamos a tener soporte hasta 15 años.
Y esto, por supuesto, va a reducir el riesgo.
Porque Canonical va a seguir actualizando todo lo de seguridad en nuestra versión.
Por ejemplo, si en este momento estás utilizando Ubuntu 24.04,
sin problema vas a poder seguir por muchos años más,
Porque el soporte LTS al día de hoy llega hasta 15 años.
Y cualquiera diría, hombre, ¿y vos haces esto manual?
No, hombre, Alex, estás en la prehistoria.
Esto lo deberías de automatizar.
Esto lo deberías de integrar a un sistema, a un workflow y hacerlo automático.
Bueno, vamos a responder a la pregunta del millón.
¿Actualizaciones automáticas o manuales?
Mi respuesta depende del tipo de actualización.
Te lo dije, te di spoiler hace un rato.
Pero también depende del tipo de servidor y de su propósito.
No es lo mismo actualizar el servidor en el que tenés la web, el sistema, la herramienta, la base de datos, que el de backups, que el de respaldo, que el de tu política anti desastre.
Es muy diferente, muy, muy diferentes. En el caso de las actualizaciones de seguridad, estas sí deberían de ser automáticas. ¿Por qué?
Porque nosotros no podemos estar 24-7.
Por lo tanto, las actualizaciones de seguridad sí deberían de ser automáticas, sin dudas, sin excepción.
Y podés configurar para que revise si hay disponible y las ejecute, instale automáticamente.
Así que estas sí deberían de ser automáticas, sin lugar a dudas, sin excepción.
De preferencia todos los días a una hora específica en la que haya de preferencia menor tráfico o menor uso de tu servidor.
¿Pero por qué? Porque son críticas y porque no estamos 24-7 activos y posiblemente no vamos a enterarnos si hay una nueva actualización de seguridad.
Porque probablemente no vamos a estar revisando todos los días si hay un parche de seguridad.
El servidor puede hacerlo por nosotros. El servidor se entera, el sistema operativo se entera y hace la diferencia entre las de seguridad, las menores y las mayores. Entonces nosotros podemos perfectamente.
Recuerdo el único panel de control que yo he usado que recuerdo que sí te ponía cuando tenías actualizaciones de seguridad disponibles y te lo marcaba en el servidor y te decía tantas actualizaciones disponibles total.
Y además te aparecía en un apartado las de seguridad.
O sea, son por ejemplo 30 actualizaciones menores y de esas 30 menores, pues son 30.
Y de seguridad, 10, por ejemplo.
Y tenías la opción de darle solo la de seguridad o programarlo para que lo hiciera.
Ploi se llama el panel de control.
En lo que respecta a las actualizaciones menores, esto sí, yo te recomendaría hacerlo manual y con criterio.
Estas perfectamente las puedes hacer manual, una vez por semana, cada dos semanas, como máximo cada mes.
Te conectas, apt update, revisas qué hay, actualizas, apt upgrade.
Si es necesario, aunque yo siempre te recomiendo reiniciar el servidor, reinicias.
¿Por qué manual?
Porque así tenés el control y te enteras, sabes que se está actualizando.
Y además también porque si lo haces manual,
puedes hacer un snapshot antes de hacer la actualización.
Si algo, aunque es poco probable, pero si algo llegara a salir mal o después de actualizar manualmente estas actualizaciones menores, algo queda funcionando de forma irregular, vos vas a saber exactamente qué pasó.
e incluso como hiciste snapshot, vas a poder volver atrás a un par de minutos.
Cuando hiciste el snapshot y hiciste la actualización, vas a poder volver atrás.
Todos los sistemas quedan funcionando, el servidor queda funcionando como estaba exactamente antes de esto
y podés tirar del hilo, reportar o esperar cuando la actualización sea estable, sin complicación.
Por eso debería de ser manual.
En el caso de las actualizaciones mayores, siempre tienen que ser manual y planificado. Siempre, siempre, siempre con planificación, con backup completo, avisando a clientes y usuarios de la ventana de mantenimiento, teniendo a mano un plan B por si algo sale mal y nunca, nunca, nunca, nunca, nunca dejar que una actualización mayor se haga automáticamente.
Porque puede salir mal. Además, porque se pueden sobreescribir archivos de configuración y además porque tu panel de control puede que no sea compatible con esa actualización mayor.
Y claro, hemos hablado de las actualizaciones, pero también es muy importante hablar del mantenimiento rutinario.
Actualizar no es lo único. También tu servidor necesita mantenimiento.
Si nosotros la queremos comparar, por ejemplo, lo podríamos comparar con un auto, con un vehículo, con un carro o una moto.
Vos, para tu carro, no solo le cambias el aceite cuando ya no enciende.
No, para el aceite, dependiendo del kilometraje, dependiendo del uso, de la marca, el modelo, el año, se debe de hacer con cierta regularidad.
De hecho, incluso dependiendo del aceite, el carro, el motor, te dejan un tiempo, cada tres meses, cada tanto.
Entonces, vos religiosamente vas y lo haces.
Con tu servidor, para el mantenimiento rutinario, lo primero que deberías de revisar son los LOGS, los registros de acceso y error.
Esto son el diario vivir de tu servidor.
Son, querido diario, hoy intentaron hackearme 100 veces.
Querido diario, esta IP intentó ataque de fuerza bruta 400 veces.
Es el diario, por así decirlo, ¿no?
Todo lo que pasa en tu servidor queda registrado en los logs.
¿Cada cuánto deberías de revisarlo?
Depende.
Si es un servidor crítico, deberías de hacerlo a diario.
Si es tu VPS personal, donde tenés proyectos, desarrollos, bueno, cada semana estaría bien.
Y cuando lo revises, ¿qué vas a buscar o qué vas a revisar?
Vas a buscar revisar errores repetidos, intentos de acceso fallidos, servicios que posiblemente se han caído,
volvieron a funcionar, reiniciaron, pero se cayeron, entonces ¿por qué?
Es decir, que vas tras cualquier cosa que sea raro, extraño y fuera de lo normal. Al final tampoco hace falta leerlo todo. Lo que yo te recomiendo es buscar patrones y buscar dentro las cosas que te interesen. Por ejemplo, downtime que se cayó, stop, service stop, error crítico, warnings y cosas así.
Esto, podés copiarlo y dárselo a una IA y que la IA más o menos te ubique cómo está tu servidor.
Y también hay herramientas que podés instalar y conectar con tu servidor para poder hacer esto más rápido.
También dentro del mantenimiento está el espacio en disco.
El disco lleno es uno de los problemas más comunes y también un poco más tontos.
Pero, ¿cómo preverlos?
¿Qué pasa? Bueno, los logs van creciendo.
Parece broma, pero nosotros en alojamiento VPS hemos tenido webs que pasaron de pesar 800 megas a 12 gigas.
Y esos gigas era el archivo de log, porque le activamos la depuración, porque estaban pasando cosas.
Imagínate, gigas. Y entre más webs tenés, más herramientas tenés, más logs.
Bueno, también los backups, lamentablemente, se acumulan. Algunos plugins o implementaciones deberían, una vez que suben o envían el backup a la nube o al servidor de backups, debería eliminarlo, pero algunas veces no lo hacen.
Justamente ese problema también estamos teniendo con el plugin All-in-One WP Migration en las webs de alojamiento VPS.
Entonces, ya sin lugar.
Lo vamos a cambiar sí o sí por otras cosas también, pero este problema también.
Hicimos un script para que revisara y eliminara, pero no nos parece la mejor implementación y ya nos estaba dando otro problema el plugin.
Lo vamos a eliminar.
Las bases de datos también van aumentando de tamaño y dependiendo de la aplicación, dependiendo del CMS, bueno, pueden ocupar demasiado.
Y ya ves, de repente entre una cosa y la otra, un día el servidor ya no arrancó, la base de datos se cayó, el servidor de base de datos se cayó y ¿qué pasó?
Pues no hay espacio. ¿Qué puedes hacer? Revisar el espacio disponible con frecuencia.
Si está por encima del 80%, es momento de hacer una limpieza o de considerar aumentar el disco,
pero la mayoría de veces con la limpieza es suficiente.
Y en el caso de limpiar, pues surge la pregunta, ¿qué limpiar?
Ya hablamos, los logs viejos, los backups antiguos que ya no se necesitan, archivos temporales, paquetes que ya no se usan.
Pues eso se puede eliminar para ahorrar o volver al espacio normal en el disco.
Siguiente, verificar los servicios.
Si tu servidor corre servicios, ya sea servicios webs, bases de datos, etc.,
lo que sea, lo que sea que tengas instalado, es muy buena idea revisar y verificar que todo está funcionando
y está corriendo con cierta frecuencia, como mínimo una vez por semana, como mínimo.
Pero dependiendo de lo que sea, esto debería de hacerse de diario si son críticos.
Porque sería muy penoso que tu cliente te diga a vos, hey, la web no me carga.
De verdad, qué raro.
Sí, ya tiene varios días, pero me dio pena decirte, imagínate, varios días y vos sin darte cuenta.
Hablando del mantenimiento, también deberíamos de incluir los backups.
Porque hacer backups, ya hablamos, no es negociable.
Pero si nunca probas que funcionen, realmente no tienes backups.
Porque no sabes si de verdad funcionan.
Una vez al mes, yo te recomiendo, por lo menos, restaurar un backup en otro servidor, en una máquina local.
Solo para verificar que el backup sirva.
Porque un backup que no se puede restaurar, no es un backup.
Simplemente es un archivo inútil ocupando espacio en disco.
Vamos ya cerrando el mantenimiento y vamos a hablar de esto último, que también es importante.
Reiniciar cuando hace falta.
Yo, de hecho, cuando actualizo semanalmente mi servidor, siempre lo reinicio, aunque no haga falta.
Pero muchos piensan que un servidor nunca se debe de reiniciar. E incluso dicen, ah, mi servidor lleva 500 días sin reiniciarse. Y te lo dicen como si esto mereciera una medalla de honor.
Pero no. Hay momentos en los que sí es necesario. Por ejemplo, después de actualizar el kernel de tu sistema operativo, después de hacer cambios importantes, después de actualizar tu panel a una versión superior, después de procesos como el memory leaks o si hay algo que está funcionando de forma irregular.
Esto debería de ser un reinicio planificado cada semana, cada 15 días o cada mes.
Y esto no debería de producir un problema.
Si bien es cierto que va a haber un pequeño apagón, un downtime, se va a caer, va a dejar de funcionar,
pero por eso debería de planificarlo y notificarlo.
Ventana de mantenimiento.
Estimado cliente, queremos hacer de tu conocimiento que el mantenimiento semanal incluye el reinicio de tu servidor.
Esto significa que durante cinco minutos tus servicios no van a estar disponibles.
Lo vamos a hacer en horas de madrugada o en horas de menor tráfico.
Así afectamos lo menos posible.
¿Ya?
¿Sabías? Estos pequeños reinicios incluso pueden resolver pequeños problemas en algunos paquetes del sistema
que ni siquiera sabías vos que estaban produciéndose.
Y bueno, como el objetivo de este episodio es motivarte a realizar tus actualizaciones y tu mantenimiento,
creo y considero que también es muy buena idea hablar de los errores comunes.
Vamos con el primero.
No actualizar nunca.
paquetes, menos paquetes y menos dependencias.
Si vos lo dejas un año, claro, algo puede pasar.
Porque a la hora de los avisos ni te lo lees y le das sí a todo y estás sobre escribiendo.
Error número dos.
Actualizar todo sin hacer backups primero.
Actualizar.
Porque se tiene que actualizar.
Uy, actualizaste y algo se rompió y no tenés backups.
¡Wow! Ahí sí ya la hemos liado. Por eso siempre hace una copia instantánea, un snapshot o un backup antes de actualizar. Por si es necesario, puedes volver atrás inmediatamente.
Error número tres. No probar después de actualizar. Actualizas y decís, ya está, listo y cierro con mi vida. Exit, cierro la terminal y a otra cosa, mariposa. No.
Te vas y no verificaste que todo seguía funcionando. Y vos decís, hombre, ¿y qué pasa? Probá. Cuando todo, termines todo, las actualizaciones y el mantenimiento, probá. Entra en tu web, verifica las bases de datos, verifica que todo conecte, verifica los servicios, verifica que todo funcione con normalidad.
Error número cuatro, actualizar el día y hora que te viene bien. Y lamentablemente eso puede ser en horas de mayor tráfico. Si tu web tiene tráfico intenso en horas de la mañana, por supuesto no vas a actualizar en la mañana.
Si tu cliente lanza productos y servicios por la tarde, no vas a actualizar por la tarde.
Lo ideal es revisar, conocer las horas, los picos de mayor tráfico de la gran mayoría de tus clientes o de tu cliente,
de su web, de su servicio, de su servidor y hacerlo en la hora de menos.
Normalmente esto es en hora de madrugada.
Si tienes la suerte, como yo, que tus clientes están en el otro lado del mundo, claro, nosotros en AlojamientoVPS el 80% de nuestros clientes están en España. Entonces, claro, nosotros aquí lo hacemos de tarde noche, pero allá es de madrugada. Fantástico.
¿Y cuál es el plan? El horario de bajo tráfico garantiza que si algo no sale bien o se tarda, se prolonga en volver todo a funcionar, no vamos a afectar a los usuarios.
Error número cinco. No tener un plan de volver atrás, de rollback. ¿Qué haces? ¿Qué pasaría si la actualización sale mal? ¿Tenés copia? ¿Tenés snapshot? ¿Tenés backup? ¿Sabes cómo volver atrás en un snapshot? ¿Cómo restaurar a este punto?
Si no tienes un plan B, mejor no actualices.
Déjalo así.
Y delega esto a manos de profesionales que lo hacemos de lunes a domingo.
Cuando nosotros nos pasamos al hosting VPS y nos creamos nuestro propio hosting con un servidor,
lo que sucede es que venimos bastante mal acostumbrados del hosting compartido tradicional.
En el hosting compartido tradicional no tenemos nosotros que hacerle mantenimiento al sistema operativo de nada, al servidor de nada, al panel de nada.
Simplemente pues entramos, trabajamos y funcionamos.
Cuando comenzamos a hablar de nuestro propio servidor y nos damos cuenta que es necesario actualizar y darle mantenimiento, puede sonar a mucho trabajo.
Puede sonar algo muy laborioso estar actualizando, revisando los logs, haciendo el mantenimiento y fíjate que sí, tenés toda la razón. Es trabajo, pero también es parte de tener tu propio servidor VPS.
Volviendo al ejemplo del carro, del auto, del vehículo, el carro le tenés que dar mantenimiento, le tenés que cambiar el aceite, le tenés que cambiar el aceite del motor, le tenés que cambiar el aceite de la caja de transmisión, tenés que revisar los frenos, el líquido de freno, las pastillas de freno.
Por supuesto, de vez en cuando lo tienes que lavar, porque si no, qué mugrero.
Tienes que revisar el sistema eléctrico, tienes que revisar el sistema de dirección,
tienes que revisar el sistema de suspensión.
Y mira, pudieras seguir, pero ya entendés el punto, ¿no?
Hay que dar mantenimiento.
Si querés algo que no requiera mantenimiento,
hombre, lo mejor es delegar contratando servicios especializados.
La gran mayoría de proveedores de VPS te ofrecen planes con el servidor mantenido. O sea, ellos se encargan de toda la parte técnica. Entonces, estaría bien. Porque si elegiste el VPS para tener el control, hombre, el control también implica responsabilidad.
Pero si no lo vas a hacer, lo mejor es delegarlo a profesionales. Por supuesto, lo puedes contratar, como te decía, con el proveedor o te puedes poner en contacto con AlojamientoVPS y nosotros te podemos dar presupuesto de tu propio servidor administrado por nosotros.
Vamos a ver, pero digamos que a vos dentro de lo que cabe, lo ves laborioso, pero querés, te gusta, se te da bien, ¿no? Aquí viene una muy buena noticia con la que vamos a cerrar este episodio.
Hacer actualizaciones y mantenimiento con el tiempo se vuelve una rutina.
Configurar las actualizaciones automáticas de seguridad es muy buena idea.
Revisar los logs una vez por semana, hacer el mantenimiento básico regularmente.
Y sabes que en cuestión de 30 minutos por semana lo tendrías casi todo hecho.
Y tendrías todo bajo control.
No es tanto.
Y te ahorras grandes sustos y grandes disgustos.
El punto es, se tiene que hacer.
Pero como te digo, se puede volver rutinario y con el tiempo le vas agarrando el truquito,
vas creando tu propio sistema y lo tenés resuelto muy rápido, muy, muy rápido.
Nosotros lo hacemos en AlojamientoVPS para todos y cada uno de los servidores de nuestros clientes.
No lo hacemos de un solo tirón, lo dividimos en viernes, sábado y domingo.
Pero cada viernes, sábado y domingo queda hecho todo.
Y te digo por experiencia, al final uno se vuelve muy productivo y uno lo resuelve muy, muy rápido.
Así que ánimo.
Con esto vamos cerrando esta terminal y te recuerdo, las actualizaciones no son opcionales,
son parte fundamental de mantener tu servidor seguro.
actualizaciones de seguridad sí pueden ser automáticas. Las de mantenimiento básico, digamos,
las actualizaciones menores una vez por semana. Y siempre, siempre, siempre hacer snapshot antes
de actualizar. En el próximo episodio vamos a retomar el tema de los backups y los snapshots
porque también es muy importante. Si tienes alguna duda sobre lo que hemos hablado en este
episodio o me quieres compartir tu experiencia, no te voy a dar la IP, pero sí te voy a dar la URL,
paneldecontrol.org barra contacto. ¿Te parece si nos conectamos en el próximo episodio? Espero que sí.
Hasta entonces ¡Salú!