Copias, tareas programadas y emergencias

La copia que nadie ha restaurado no es una copia

Todo el mundo tiene copias de seguridad. Muy poca gente ha restaurado una. Y hasta que no se restaura, lo único que se sabe es que un proceso terminó sin error, que no es lo mismo que tener los datos.

Las formas de fallar son sorprendentemente aburridas: el archivo se copiaba vacío desde hace meses, el proceso se quedó sin espacio a mitad, o la copia de la base de datos se hizo mal y el archivo no sirve.

Las tres preguntas de una copia

¿Está en otro sitio?

Una copia en el mismo disco no protege de que el disco falle. En la misma máquina, no protege de que la máquina se pierda.

Y si un atacante entra en el servidor, se lleva también lo que esté montado ahí.

¿Se ha restaurado alguna vez?

La única prueba válida. Se toma la copia, se restaura en otro sitio y se abre para ver si los datos están.

Es lo que convierte una carpeta de archivos en un plan de recuperación.

¿Cuánto se pierde si falla hoy?

Si la copia es diaria a las 3, un fallo a las 20:00 pierde 17 horas de trabajo.

Eso puede estar perfectamente bien: lo que no puede es descubrirse el día del fallo.

Copiar con rsync

# Copia local: -a conserva permisos y fechas, -v muestra lo que hace
sudo rsync -av /var/www/ /respaldo/www/

# Copia a OTRA maquina, por SSH (es lo que de verdad protege)
sudo rsync -avz /var/www/ usuario@otro-servidor:/respaldo/www/

# Ensayo: dice que HARIA, sin tocar nada
sudo rsync -avn /var/www/ /respaldo/www/

La barra final del origen cambia el resultado, y es el despiste clásico de rsync. /var/www/ copia el contenido de la carpeta; /var/www copia la carpeta entera dentro del destino, y te deja /respaldo/www/www/.

De ahí que exista -n: enseña lo que haría sin hacerlo. Vale la pena usarlo siempre la primera vez.

Las bases de datos no se copian con cp

Esto merece decirse aparte porque produce copias que parecen correctas. Copiar los archivos de una base de datos mientras está funcionando da un archivo a medio escribir: pesa lo que debe, se guarda sin error, y el día que se necesita no abre.

Una base de datos se copia con su propia herramienta, que produce un archivo consistente aunque haya escrituras en curso.

La forma correcta, y la comprobación

# PostgreSQL
sudo -u postgres pg_dump mi_base | gzip > /respaldo/mi_base_$(date +%F).sql.gz

# MySQL / MariaDB
mysqldump -u usuario -p mi_base | gzip > /respaldo/mi_base_$(date +%F).sql.gz

# Comprobar que el archivo no esta vacio ni truncado
ls -lh /respaldo/mi_base_*.sql.gz
gunzip -t /respaldo/mi_base_2026-09-07.sql.gz && echo "archivo integro"

Ese gunzip -t es medio segundo y detecta la copia truncada -la que se cortó porque se acabó el disco-. No sustituye a restaurarla de verdad, pero atrapa el fallo más frecuente.

Que se haga solo: cron

Una copia que hay que acordarse de lanzar no se hace. cron ejecuta comandos a horas fijas, y es lo que convierte el procedimiento en rutina.

Programar una tarea

# Editar las tareas del usuario actual
crontab -e

# Formato:  minuto hora dia-del-mes mes dia-de-semana  comando
# Todos los dias a las 3:15 de la madrugada
15 3 * * * /opt/scripts/respaldo.sh >> /var/log/respaldo.log 2>&1

# Ver las tareas programadas
crontab -l

El >> /var/log/respaldo.log 2>&1 del final guarda la salida y los errores en un archivo. Sin eso, una tarea que falla todas las noches lo hace en silencio, y es como se descubren los respaldos rotos: seis meses después.

La trampa que muerde a todo el mundo: cron usa la hora del SERVIDOR, no la tuya. Muchos servidores vienen configurados en UTC. Si tu zona es UTC-5 y programas algo «a las 3 de la mañana», se ejecutará a las 10 de la noche hora local.

Con una copia da igual; con una tarea que fecha datos o cierra un día contable, los registros salen corridos un día y el error es dificilísimo de ver. Se comprueba con date en el servidor -nunca de memoria- y, si hace falta, se ajusta con sudo timedatectl set-timezone America/Bogota.

Cuando el servidor no responde

1. Separar el servidor de la red
ping a su dirección. Si responde, la máquina está viva y el problema es de un servicio. Si no, puede ser la red, el proveedor o la máquina entera.

Es la bifurcación que decide todo lo demás.
2. Entrar por la consola del proveedor
Si el SSH no responde pero la máquina está encendida, se entra por la consola del panel -no pasa por la red-.

Es el momento en que uno agradece haber comprobado que existía antes de necesitarla.
3. Las tres preguntas de siempre
df -h (¿disco lleno?), free -h (¿memoria agotada?), uptime (¿se reinició solo?).

Con eso, la mayoría de las emergencias quedan explicadas en un minuto.
4. Qué falló y qué dice el registro
systemctl --failed lista los servicios caídos.

sudo journalctl -p err --since "1 hour ago" muestra los errores recientes, y journalctl -b -1 -p err los del arranque anterior si se reinició.
5. Arreglar, verificar y anotar
Reiniciar el servicio es el parche. La pregunta que evita repetir la noche es por qué pasó.

Dos líneas escritas en algún sitio -qué pasó, qué se hizo- valen más que la memoria dentro de seis meses.

Costumbres que hacen la diferencia

Copia antes de tocar configuración

sudo cp archivo archivo.bak antes de editar cualquier cosa en /etc.

Dos segundos que ahorran la reconstrucción a ciegas de un archivo que funcionaba.

Validar antes de recargar

sudo nginx -t, sudo sshd -t: los servicios saben revisar su propia configuración y decir el archivo y la línea del error.

Recargar sin validar es cómo se cae un servicio a las 6 de la tarde.

Comprobar en una segunda sesión

Todo cambio que pueda dejarte fuera -SSH, firewall- se verifica abriendo otra conexión sin cerrar la actual.

Instalar lo mínimo

Cada paquete de más es superficie que defender y otra cosa que actualizar. Si se probó algo y no se usa, sudo apt purge.

Repaso final del curso

Responde antes de voltear cada tarjeta.

Compruébalo tú mismo

Tu respaldo copia con cp los archivos de PostgreSQL cada noche, sin errores. ¿Sirve?

Programas una tarea a las 3:00 y se ejecuta a las 22:00 hora local. ¿Qué pasó?

El servidor deja de responder. ¿Cuál es el primer paso?

Hasta dónde llegaste

Entras a un servidor con llave, te orientas en una máquina que no conoces, entiendes permisos y privilegios, lo mantienes actualizado, manejas y diagnosticas servicios, encuentras qué se comió el disco o la memoria, cierras lo que no debe estar abierto y dejas copias que restauran. Eso es administrar un servidor.

El certificado se saca en el aula. Las preguntas de estas lecciones eran para comprobarte a ti mismo: no guardan nota. La evaluación que certifica se presenta en el Aula Virtual, con tu cuenta, y al aprobarla se emite el certificado a tu nombre.

Por dónde seguir

Lo que corre en ese servidor casi siempre incluye una base de datos: Bases de datos SQL es la continuación natural. Seguridad digital completa lo que aquí se vio del lado del servidor -contraseñas, segundo factor, engaños y copias- para toda la organización. Y si vas a desplegar tu propio código, Git básico es la pieza que faltaba entre tu equipo y esta máquina.