Joan zuzenean edukira

5.1. Fundamentos de las copias de seguridad (backups)

En cualquier entorno informático profesional —una empresa de desarrollo web, un centro educativo o una administración— las copias de seguridad no son opcionales. Forman parte de la seguridad básica del sistema.


1. ¿Qué es un backup?

Un backup (copia de seguridad) es una copia de información que se almacena en un lugar diferente al original, con el objetivo de poder recuperarla en caso de pérdida, fallo o ataque.

Se puede perder información por:

  • Borrados accidentales (un usuario borra una carpeta compartida).
  • Fallos de hardware (disco duro roto, RAID mal configurado).
  • Cortes eléctricos o apagados incorrectos.
  • Malware, virus, ransomware.
  • Errores humanos (mala configuración, comandos peligrosos).
  • Actualizaciones defectuosas (parches que rompen el sistema o la aplicación).
  • Incendios, robos, desastres físicos.

Un backup no evita el problema.

Sirve para poder recuperarse después del problema.


2. Objetivo real de un sistema de backups

Un sistema de copias de seguridad bien diseñado debe cumplir, como mínimo, tres objetivos:

  1. Garantizar la continuidad del servicio.
  2. Minimizar la pérdida de datos.
  3. Reducir el tiempo de recuperación.

En una empresa real, esto se traduce directamente en dinero:

  • Una web caída → pérdida de ventas, mala imagen.
  • Datos de clientes perdidos → posibles problemas legales (LOPD, RGPD).
  • Usuarios sin acceso a sus recursos → el trabajo se paraliza.

En un centro educativo, aunque no haya facturación directa, la caída de servicios (plataforma educativa, servidores de prácticas, repositorios) también tiene un impacto fuerte en la actividad diaria.


3. Conceptos clave: RTO y RPO

Antes de elegir herramientas y comandos, hay que entender qué nivel de servicio queremos ofrecer. Dos conceptos fundamentales son RTO y RPO.

3.1. RTO (Recovery Time Objective)

El RTO es el tiempo máximo aceptable que un servicio puede estar inactivo hasta que se recupere.

Ejemplos:

  • Una tienda online puede aceptar como máximo 30 minutos de caída.
  • Un instituto quizá pueda aceptar 24 horas sin una determinada aplicación web interna.

Cuanto más bajo es el RTO (menos tiempo de caída tolerable), más exigente y costosa será la estrategia de backups y recuperación.

3.2. RPO (Recovery Point Objective)

El RPO es la cantidad máxima de datos (en tiempo de trabajo) que la organización está dispuesta a perder cuando ocurre un desastre.

Ejemplos:

  • Si se hace un backup diario de la base de datos (por la noche), el peor caso es perder hasta 24 horas de datos.
  • Si se hace un backup cada hora, el peor caso es perder hasta 1 hora.

Cuanto más pequeño sea el RPO, más frecuentes deben ser las copias, y mayor será el consumo de almacenamiento y ancho de banda.


4. Otros conceptos básicos en backups

4.1. Dato original vs copia de seguridad

  • Dato original: la información que se usa en el día a día (por ejemplo, la carpeta \SERVIDOR\PERFILES, la base de datos de producción o el directorio /var/www/app).
  • Backup: la copia de esos datos, almacenada en otro soporte o otra ubicación.

Si el backup está en el mismo disco que el original, no es un backup válido.

4.2. Retención de copias

La retención es el tiempo durante el que se conservan las copias de seguridad antes de ser eliminadas.

Ejemplos típicos:

  • Copias diarias → conservar 15 días.
  • Copias semanales → conservar 3 meses.
  • Copias mensuales → conservar 1 año o más.

Una buena política suele combinar varios niveles de retención (diario, semanal, mensual).

4.3. Versionado

El versionado permite mantener varias versiones históricas de un mismo archivo o base de datos. Es útil, por ejemplo, cuando un fichero se corrompe y no se detecta el problema hasta días después.

4.4. Encriptación

Las copias deben estar cifradas si contienen datos sensibles (usuarios, notas, datos personales, etc.), sobre todo si se almacenan en la nube o se transportan en discos externos.


5. Tipos de backup

Es uno de los bloques más importantes. Al diseñar una estrategia, casi siempre se combinan varios tipos.

5.1. Backup completo

Se copia todo el contenido seleccionado en un único proceso (por ejemplo, toda la carpeta de la web o todos los perfiles de usuario).

Ventajas:

  • Restauración rápida: basta con recuperar una única copia.
  • Simplicidad: es fácil de entender y gestionar.

Inconvenientes:

  • Ocupa mucho espacio.
  • Tarda más tiempo en realizarse.

Ejemplos:

  • Copiar toda la carpeta de la web: /var/www/misitio.
  • Copiar todo el directorio de perfiles de usuarios en Windows Server.

5.2. Backup incremental

Solo copia los archivos que han cambiado desde el último backup (sea completo o incremental).

Ventajas:

  • Es muy rápido de ejecutar.
  • Ahorra mucho espacio de almacenamiento.

Inconvenientes:

  • La restauración es más compleja: hay que restaurar el último completo y todos los incrementales posteriores.
  • Mayor dependencia de que todas las copias estén intactas.

5.3. Backup diferencial

Copia todo lo que ha cambiado desde el último backup completo.

Ventajas:

  • Restauración más sencilla que con incrementales (solo se necesita el completo y el último diferencial).
  • Ocupa menos espacio que hacer un completo cada día.

Inconvenientes:

  • Cada día el diferencial suele ocupar más espacio (va acumulando cambios desde el completo).

5.4. Backup de imagen o clonado

Es una copia exacta de un disco o de una máquina virtual completa. Incluye sistema operativo, aplicaciones, configuraciones y datos.

Se utiliza para:

  • Recuperación completa del sistema ante un fallo grave.
  • Migrar máquinas a otro hardware o a otro hipervisor.

5.5. Snapshots

Los snapshots son “fotografías” rápidas del estado de un sistema en un momento concreto. Se usan sobre todo en:

  • Máquinas virtuales (por ejemplo, en Hyper‑V, VMware, Proxmox).
  • Sistemas de almacenamiento avanzados (cabinas NAS/SAN).

Son muy útiles antes de hacer cambios críticos (actualizaciones, instalación de roles, cambios en la configuración).

Importante: los snapshots no sustituyen a un sistema de backups completo, pero son un complemento muy valioso.


6. ¿Qué se debe copiar?

No todo lo que hay en un servidor es igual de importante. Hay que priorizar.

6.1. En un entorno Windows Server

Elementos que normalmente deben entrar en backup:

  • Active Directory (usuarios, grupos, OU).
  • GPO (políticas de grupo).
  • Perfiles móviles o carpetas de perfiles de usuario.
  • Carpetas compartidas (datos de departamentos, recursos comunes).
  • Carpetas privadas de usuarios (home directories).
  • Permisos NTFS y configuraciones de compartición.
  • Scripts de inicio de sesión y otros scripts administrativos.

6.2. En un entorno Linux + aplicaciones web

Elementos clave para incluir en las copias:

  • Código de la aplicación web (por ejemplo, proyecto Laravel).
  • Archivos subidos por usuarios (imágenes, documentos, etc.).
  • Base de datos (MySQL/MariaDB, PostgreSQL…).
  • Configuración del servidor web (/etc/apache2, /etc/nginx, virtualhosts, certificados, etc.).
  • Variables de entorno y ficheros de configuración sensibles (por ejemplo, .env en Laravel).

6.3. Errores típicos

  • Copiar solo el código y olvidar la base de datos.
  • Copiar los archivos pero no los permisos ni la configuración.
  • Tener backups pero no probar nunca la restauración.
  • Guardar los backups en la misma máquina (se pierden si el disco o la VM fallan).

7. ¿Cada cuánto se hace un backup? (periodicidad)

No existe una única respuesta correcta. Depende de:

  • Frecuencia de cambios en los datos.
  • Valor de la información.
  • Capacidad de almacenamiento disponible.
  • Riesgos del entorno (exposición a ataques, criticidad del servicio, etc.).

Ejemplo de criterios generales:

Tipo de dato Periodicidad recomendada
Base de datos Diario (o varias veces al día si es crítica)
Archivos de usuarios Diario
Código fuente Con cada despliegue / cambio importante
Sistema completo Semanal
Imagen de máquina/servidor Mensual o antes de cambios muy críticos

En entornos de prácticas, puedes adaptar estas ideas a la carga de trabajo real de los servidores del aula/laboratorio.


8. ¿Dónde se guardan los backups? Regla 3‑2‑1

Un sistema de copias de seguridad profesional suele seguir la regla 3‑2‑1:

  1. 3 copias de los datos (original + 2 copias).
  2. 2 soportes distintos (por ejemplo, disco local y NAS, o NAS y nube).
  3. 1 copia fuera del sistema principal o del edificio (off‑site o en la nube).

Algunos entornos añaden variantes como 3‑2‑1‑1‑0, donde:

  • Hay 1 copia inmutable (no se puede modificar/borrar fácilmente, por ejemplo, objeto WORM en la nube).
  • Se busca 0 errores en las verificaciones periódicas de restauración.

Ejemplos de destinos para backups:

  • Servidor de backups dedicado en la red.
  • Discos externos conectados solo durante el proceso de copia.
  • NAS (Network Attached Storage).
  • Nube privada o pública.
  • Otra máquina virtual ubicada en un host distinto.

9. Backup, sincronización y archivado

Estos conceptos se confunden a menudo:

  • Backup: copia de seguridad para recuperación ante desastres. Permite volver a un estado anterior.
  • Sincronización: mantiene dos ubicaciones idénticas (por ejemplo, un directorio sincronizado con un servicio de nube). Si se borra un archivo en un lado, se borrará en el otro.
  • Archivado: mover datos antiguos que ya no se usan a un almacenamiento más barato y lento, pero accesible si se necesitan en el futuro.

Servicios como Google Drive, OneDrive o Dropbox no son, por sí solos, un sistema de backups profesional, aunque pueden formar parte de una estrategia de protección de datos.


10. Ideas clave que deben quedar claras

  • Un backup que nunca se prueba no es un backup.
  • Un backup en el mismo disco no es un backup.
  • Un backup sin planificación no es profesional.
  • Sin restauración, el backup no sirve de nada.

En los siguientes apartados del tema trabajaremos ya con herramientas concretas (Windows Server, Linux, nube, etc.), aplicando estos conceptos teóricos en prácticas de laboratorio.