Cómo actualizar el sistema operativo Linux

Hacen cosas distintas y por eso se usan juntas y en orden. El primero refresca la lista de paquetes disponibles: consulta los repositorios y anota qué versiones nuevas hay, pero no instala ni cambia nada en el sistema. El segundo es el que efectivamente aplica esas actualizaciones, descargando e instalando las versiones nuevas de lo que ya tenés. Por eso la secuencia correcta es siempre primero refrescar la lista y después aplicar, porque aplicar sin haber refrescado trabajaría con información vieja. Es un error muy común creer que el primer comando ya actualiza el sistema; en realidad solo prepara el terreno para el segundo.

Las actualizaciones de paquetes, seguido: una vez por semana es un buen ritmo para un equipo de uso personal, y en un servidor conviene que al menos las de seguridad se apliquen de forma automática y frecuente. No hay riesgo real en hacerlo a menudo, y sí lo hay en postergarlo, porque cada actualización de seguridad que no aplicás deja expuesta una vulnerabilidad ya conocida y publicada. Los saltos de versión son harina de otro costal: esos se hacen ocasionalmente, cuando querés pasar a una versión nueva, y con preparación previa. La regla general es actualizar paquetes con frecuencia y sin miedo, y subir de versión pocas veces y con cuidado.

Una versión de soporte prolongado es una que recibe actualizaciones de seguridad durante varios años sin cambiar sus componentes de fondo. En Ubuntu salen cada dos años y tienen cinco años de soporte. Te conviene si querés un sistema previsible que ande sin sorpresas, que es el caso de la mayoría: un equipo de trabajo o un servidor. La estrategia sana con una LTS es quedarte en ella y saltar solo a la siguiente LTS cuando llegue, en lugar de perseguir cada versión intermedia de seis meses. Esas versiones más frecuentes traen software más nuevo pero tienen soporte corto, y tienen sentido para quien quiere las novedades cuanto antes y no le molesta actualizar seguido.

Con la herramienta oficial de salto de versión, nunca editando los repositorios a mano. El procedimiento correcto tiene cuatro pasos: primero respaldar los datos, porque un salto de versión cambia componentes de fondo; segundo, poner completamente al día la versión actual, para saltar desde un sistema sano; tercero, leer las notas de la versión nueva para conocer cambios importantes o incompatibilidades; y cuarto, ejecutar la herramienta oficial, que gestiona los repositorios y guía el proceso. En un servidor al que solo llegás por SSH hay un cuidado extra: conviene tener una vía de acceso alternativa, porque si la actualización toca la red en el momento equivocado podrías quedar afuera con el proceso a medias.

Lo primero es no entrar en pánico, porque suele haber vuelta atrás. Si el equipo no arranca, el menú del gestor de arranque normalmente guarda versiones anteriores del núcleo, y elegir una previa suele devolverte a un estado que funcionaba. También existe un modo de recuperación que arranca lo mínimo para poder reparar. Si lo que falla es un servicio y no todo el sistema, los registros casi siempre dicen exactamente qué cambió o qué falta. Y si nada de eso alcanza, queda el respaldo: reinstalar desde cero y restaurar los datos. Justamente por esto el respaldo se hace antes de un salto de versión, no después de que algo se rompió.

Sí, y para las de seguridad es muy recomendable, sobre todo en un servidor. La mayoría de las distribuciones permiten configurar que solo las actualizaciones de seguridad se apliquen de forma desatendida, dejando el resto de los cambios para cuando vos decidas revisarlos. Ese equilibrio suele ser el ideal: las correcciones críticas se aplican solas y a tiempo, que es lo que más importa, y las actualizaciones que podrían cambiar comportamientos quedan bajo tu control. Automatizar todo sin criterio puede traer cambios inesperados en un momento inoportuno, y no automatizar nada garantiza que tarde o temprano un parche de seguridad importante quede sin aplicar por olvido.