Estrategia de copia de seguridad de datos

El ransomware atacó el viernes por la noche. El lunes por la mañana, el servidor de archivos estaba cifrado, y también el disco duro externo conectado a él. La «copia de seguridad» en Dropbox había sincronizado amablemente las versiones cifradas. La empresa pagó el rescate. La herramienta de descifrado tenía errores. La mitad de los archivos volvieron corruptos de todos modos.

Este escenario se repite en empresas pequeñas. Las copias de seguridad existían sobre el papel, pero fallaron en la práctica.

Este capítulo se asegura de que eso no le ocurra a usted. Configurará copias de seguridad que realmente funcionen, las probará antes de necesitarlas y creará una política que mantenga todo protegido.

Por qué las copias de seguridad fallan cuando las necesita

La mayoría de las empresas tienen algún tipo de copia de seguridad. La mayoría de esas copias fallarían en un desastre real. Esto es por qué:

Nunca probadas — La copia de seguridad se ejecuta cada noche. Nadie ha intentado restaurar desde ella. Cuando realmente la necesita, descubre que las copias han estado corruptas durante seis meses.

Mismo dominio de fallo — La unidad de copia está conectada al servidor. Ambas quedan cifradas por el ransomware. La copia de seguridad en la misma región en la nube. La región cae, la copia también es inaccesible.

Alcance incompleto — Los archivos del servidor están respaldados. Pero nadie pensó en los datos de SaaS, las bases de datos o los archivos de configuración. Después de la recuperación, la mitad de los sistemas no funcionan.

Sin documentación — La persona que configuró las copias dejó la empresa hace dos años. Nadie sabe cómo restaurar, cuáles son las contraseñas ni dónde viven realmente las copias.

Demasiado lento para recuperarse — Tiene copias de seguridad, pero restaurar 5 TB lleva 3 días. La empresa no puede sobrevivir 3 días de inactividad.

Una copia de seguridad que no se puede restaurar no es una copia de seguridad. Es una falsa sensación de seguridad.

La regla de copia de seguridad 3-2-1

La regla 3-2-1 ha sido el estándar durante décadas porque funciona:

3 copias de sus datos (el original + 2 copias de seguridad)
2 tipos de soporte de almacenamiento diferentes
1 copia fuera de las instalaciones (separada geográficamente)

Por qué importa cada número

3 copias — Redundancia. Si una copia de seguridad falla, tiene otra. Los discos fallan, los servicios en la nube tienen interrupciones, los archivos se corrompen. Dos copias de seguridad significan que puede sobrevivir a cualquier fallo único.

2 tipos de soporte diferentes — Protección contra fallos de causa común. Si todos sus datos están en el mismo tipo de unidad del mismo fabricante, un error de firmware podría destruirlos todos simultáneamente. Mezcle discos locales con almacenamiento en la nube, o SSDs con cinta, o NAS con almacenamiento de objetos.

1 copia fuera de las instalaciones — Protección contra desastres físicos. Incendio, inundación, robo o ransomware que se propaga por su red. Si su oficina se incendia, sus datos sobreviven porque existe una copia en otro lugar.

La regla moderna 3-2-1-1-0

Algunas organizaciones extienden esto a 3-2-1-1-0:

1 copia que está con aislamiento total (air-gapped) o es inmutable (no se puede modificar ni eliminar, ni siquiera por los administradores)
0 errores — las copias se verifican y prueban

El «1» adicional protege contra el ransomware que apunta específicamente a las copias de seguridad. Si los atacantes obtienen acceso de administrador, a menudo eliminan las copias antes de cifrar los datos de producción. Una copia inmutable o aislada sobrevive incluso a eso.

Tipos de copia de seguridad: completa, incremental, diferencial

No todas las copias de seguridad necesitan copiar todo cada vez.

Copia completa — Copia completa de todos los datos. Lleva más tiempo, usa más almacenamiento, pero es la más simple de restaurar. Ejecutar semanal o mensualmente.

Copia incremental — Solo los datos cambiados desde la última copia de seguridad (de cualquier tipo). Rápida y pequeña, pero la restauración requiere la última copia completa más todas las copias incrementales en secuencia. Si una copia incremental está corrupta, se pierde todo lo posterior.

Copia diferencial — Solo los datos cambiados desde la última copia completa. Más grande que la incremental, pero la restauración solo requiere la última copia completa más la última diferencial.

Cuál usar en cada caso

Estrategia	Tiempo de copia	Uso de almacenamiento	Complejidad de restauración	Mejor para
Solo completa	Lenta	Alto	Simple	Conjuntos de datos pequeños, archivos semanales
Completa + incremental	Diaria rápida	Bajo	Compleja (cadena)	Conjuntos de datos grandes, copias diarias
Completa + diferencial	Media	Medio	Simple	Equilibrio entre velocidad y fiabilidad

Recomendación práctica para empresas pequeñas:

Copia completa semanal (domingo por la noche)
Copia incremental o diferencial diaria
Mantener al menos 4 semanas de copias completas

La mayoría de las herramientas modernas (Restic, Borg, servicios de copia de seguridad en la nube) gestionan esto automáticamente con deduplicación: obtiene la eficiencia de almacenamiento de las copias incrementales con la simplicidad de las copias completas.

Qué respaldar

Antes de configurar nada, haga un inventario de lo que realmente necesita copia de seguridad.

Categorías de datos críticos

Datos de negocio

Bases de datos de clientes
Registros financieros
Contratos y documentos legales
Registros de empleados
Propiedad intelectual (código fuente, diseños, documentación)

Configuraciones del sistema

Configuraciones de servidores
Configuraciones de dispositivos de red
Configuración de aplicaciones
Archivos de Infraestructura como Código
Certificados SSL y claves

Datos de SaaS

Google Workspace (correos, documentos, drive)
Microsoft 365
Historial de Slack/Teams
Datos de CRM (Salesforce, HubSpot)
Gestión de proyectos (Asana, Jira, Notion)

Bases de datos

Bases de datos de producción
Bases de datos de aplicaciones
Datos de analítica

Secretos y credenciales

Exportaciones del gestor de contraseñas (Passwork admite exportaciones cifradas: prográmelas mensualmente)
Claves API (almacenadas de forma segura en el gestor de contraseñas como Passwork)
Claves de cifrado
Claves SSH
Las propias claves de cifrado de las copias de seguridad (guárdelas por separado, en Passwork o sin conexión)

Qué no necesita copia de seguridad

Archivos temporales y cachés
Software fácilmente redescargable
Datos que ya están almacenados en otro lugar (espejos, réplicas)
Archivos de registro más antiguos que los requisitos de retención

Centre los recursos de copia de seguridad en datos que son irremplazables o costosos de recrear.

Clasificación de datos por prioridad de copia de seguridad

Categoría	Ejemplos	Frecuencia de copia	Retención	Prioridad de recuperación
Crítico	Datos de clientes, financiero, BD de prod	Continuo/por hora	1+ año	Inmediata
Importante	Código fuente, configuraciones, documentos	Diaria	90 días	En horas
Estándar	Documentos internos, archivos de proyectos	Diaria/semanal	30 días	En 24h
Bajo	Archivos, proyectos antiguos	Semanal/mensual	30 días	Mejor esfuerzo

Métodos y herramientas de copia de seguridad

Diferentes datos necesitan diferentes enfoques de copia de seguridad.

Servidores locales/en las instalaciones

Para servidores Linux:

Restic — Copias de seguridad rápidas, cifradas y deduplicadas. Admite backends locales, S3, SFTP y muchos otros.

# Install
apt install restic

# Initialize repository (to S3)
restic init -r s3:s3.amazonaws.com/your-backup-bucket

# Backup a directory
restic backup /var/www /etc /home

# List snapshots
restic snapshots

# Restore
restic restore latest --target /restore/path

BorgBackup — Similar a Restic, excelente deduplicación, ligeramente más complejo.

# Initialize
borg init --encryption=repokey /path/to/backup/repo

# Backup
borg create /path/to/repo::backup-{now} /home /etc

# Restore
borg extract /path/to/repo::backup-name

Para bases de datos:

PostgreSQL:

# Automated daily backup
pg_dump -h localhost -U postgres mydatabase | gzip > /backup/mydb_$(date +%Y%m%d).sql.gz

# With pg_basebackup for point-in-time recovery
pg_basebackup -h localhost -D /backup/base -Ft -z -P

MySQL/MariaDB:

# Dump all databases
mysqldump --all-databases --single-transaction | gzip > /backup/all_$(date +%Y%m%d).sql.gz

# Or use Percona XtraBackup for hot backups
xtrabackup --backup --target-dir=/backup/xtrabackup/

MongoDB:

mongodump --out /backup/mongo/$(date +%Y%m%d)

Infraestructura en la nube

AWS:

Versioning de S3 — Active el versioning en los buckets críticos. Protege contra la eliminación accidental y el ransomware.
AWS Backup — Copia de seguridad gestionada para EC2, RDS, EFS, DynamoDB. Políticas centralizadas y retención.
Copias de seguridad automatizadas de RDS — Active con la retención apropiada (7 días por defecto, puede ampliarse a 35).
Instantáneas de EBS — Programe instantáneas regulares para volúmenes EC2.

# Enable S3 versioning
aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled

# Create EBS snapshot
aws ec2 create-snapshot --volume-id vol-1234567890 --description "Daily backup"

GCP:

Versioning de Cloud Storage — Similar a S3
Instantáneas de Persistent Disk — Programe mediante programas de instantáneas
Copias de seguridad automatizadas de Cloud SQL — Activadas por defecto, configure la retención

Azure:

Azure Backup — Servicio gestionado para VMs, SQL, recursos compartidos de archivos
Versioning de Blob Storage
Azure Site Recovery — Para recuperación ante desastres

Copia de seguridad de datos de SaaS

Sus aplicaciones en la nube tienen sus datos, pero no garantizan copias de seguridad de la manera que usted necesita.

Google Workspace:

La retención integrada de Google es limitada. Use copia de seguridad de terceros:

Backupify — Parte de Datto, completo
Spanning — También de Kaseya, bueno para PYMES
AFI Backup — Basado en IA, precios competitivos

O use Google Vault para retención (incluido en algunos planes, pero no es una copia de seguridad real).

Microsoft 365:

Situación similar: la retención de Microsoft no es una copia de seguridad:

Veeam Backup for Microsoft 365 — Autohospedado o en la nube
Druva — Nativo en la nube
AvePoint — Completo

Slack:

La exportación de datos de Slack tiene limitaciones (sin mensajes directos en planes gratuitos/pro). Considere:

Enterprise Grid incluye eDiscovery y exportación
Terceros: Rewind, Backupify

SaaS en general:

Muchas aplicaciones SaaS más pequeñas no tienen integraciones de copia de seguridad. Para estas:

Exporte datos manualmente según un calendario
Use Zapier/Make para automatizar las exportaciones donde sea posible
Documente dónde viven los datos y cómo exportarlos

Copias de seguridad de contenedores y Kubernetes

Velero — El estándar para copias de seguridad de Kubernetes:

# Install Velero
velero install --provider aws --bucket my-backup-bucket --secret-file ./credentials

# Backup namespace
velero backup create my-backup --include-namespaces my-namespace

# Schedule regular backups
velero schedule create daily-backup --schedule="0 2 * * *" --include-namespaces production

# Restore
velero restore create --from-backup my-backup

Volúmenes de Docker:

# Backup a volume
docker run --rm -v my_volume:/source -v /backup:/backup alpine tar czf /backup/my_volume.tar.gz -C /source .

# Restore
docker run --rm -v my_volume:/target -v /backup:/backup alpine tar xzf /backup/my_volume.tar.gz -C /target

Copias de seguridad inmutables y aisladas

Los operadores de ransomware apuntan específicamente a las copias de seguridad. Si pueden eliminarlas, usted tiene que pagar. Las copias de seguridad inmutables y aisladas protegen contra esto.

Almacenamiento inmutable

El almacenamiento inmutable evita la modificación o eliminación durante un período establecido, incluso por los administradores.

AWS S3 Object Lock:

# Enable Object Lock when creating bucket
aws s3api create-bucket --bucket my-backup-bucket --object-lock-enabled-for-bucket

# Set default retention
aws s3api put-object-lock-configuration --bucket my-backup-bucket --object-lock-configuration '{
  "ObjectLockEnabled": "Enabled",
  "Rule": {
    "DefaultRetention": {
      "Mode": "GOVERNANCE",
      "Days": 30
    }
  }
}'

El modo GOVERNANCE permite la anulación con permisos especiales. El modo COMPLIANCE no puede ser anulado por nadie, ni siquiera por el root.

Azure Immutable Blob Storage: Políticas de retención basadas en tiempo o retención legal.

Backblaze B2: Soporte de Object Lock, muy rentable.

Copias de seguridad aisladas (air-gapped)

Aislado significa físicamente o lógicamente desconectado de su red.

Aislamiento físico:

Discos externos que solo se conectan durante la copia de seguridad
Copias en cinta almacenadas fuera de las instalaciones
Almacenamiento sin conexión que se rota semanalmente/mensualmente

Aislamiento lógico:

Cuenta separada en la nube sin ruta de red desde producción
Copias extraídas (no enviadas) por un sistema con credenciales diferentes
Acceso de solo escritura: el servicio de copia puede escribir pero no eliminar

Arquitectura recomendada para protección contra ransomware

Production Environment
        │
        ▼
[Primary Backup] ──────► AWS S3 (same account)
        │                Daily, 30-day retention
        │
        ▼
[Secondary Backup] ────► AWS S3 (different account)
        │                Object Lock enabled
        │                Cross-account, no delete permissions
        │
        ▼
[Tertiary Backup] ─────► Offline/Air-gapped
                         Weekly to external drive
                         Stored offsite

Automatización de copias de seguridad

Las copias manuales no ocurren. Automatice todo.

Programación con cron

# /etc/cron.d/backup

# Daily database backup at 2 AM
0 2 * * * root /usr/local/bin/backup-database.sh >> /var/log/backup.log 2>&1

# Weekly full system backup at 3 AM Sunday
0 3 * * 0 root /usr/local/bin/backup-full.sh >> /var/log/backup.log 2>&1

# Monthly offsite sync at 4 AM on the 1st
0 4 1 * * root /usr/local/bin/backup-offsite.sh >> /var/log/backup.log 2>&1

Script de copia de seguridad de ejemplo

#!/bin/bash
# /usr/local/bin/backup-database.sh

set -e

BACKUP_DIR="/backup/database"
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=30

# Create backup
pg_dump -h localhost -U postgres mydb | gzip > "$BACKUP_DIR/mydb_$DATE.sql.gz"

# Verify backup is not empty
if [ ! -s "$BACKUP_DIR/mydb_$DATE.sql.gz" ]; then
    echo "ERROR: Backup file is empty" | mail -s "Backup Failed" [email protected]
    exit 1
fi

# Upload to S3
aws s3 cp "$BACKUP_DIR/mydb_$DATE.sql.gz" s3://my-backup-bucket/database/

# Clean old local backups
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

# Log success
echo "$(date): Backup completed successfully"

Monitorización de copias de seguridad

Las copias de seguridad fallan silenciosamente. Monitorícelas:

Compruebe la finalización:

# Alert if no backup file created in last 25 hours
find /backup -name "*.gz" -mtime -1 | grep -q . || alert "Backup missing"

Monitorización en la nube:

AWS CloudWatch para AWS Backup
Terceros: Healthchecks.io — Gratuito para monitorización simple
Prometheus/Grafana para métricas

Monitorización simple con healthchecks.io:

# Add to end of backup script
curl -fsS -m 10 --retry 5 https://hc-ping.com/your-uuid-here

Si el ping no llega según lo programado, recibe una alerta.

Prueba de la recuperación

La copia de seguridad no está completa hasta que haya restaurado desde ella.

Por qué importa la prueba

Los archivos de copia pueden estar corruptos
El proceso de restauración puede haber cambiado
Puede que le falten archivos críticos
La persona que sabe cómo restaurar puede no estar disponible

Calendario de pruebas de recuperación

Tipo de prueba	Frecuencia	Qué probar
Restauración de archivos	Mensual	Restaurar archivos aleatorios desde la copia
Restauración de bases de datos	Trimestral	Restaurar en entorno de prueba, verificar datos
Restauración completa del sistema	Anual	Restaurar servidor/servicio completo desde cero
Simulacro de recuperación ante desastres	Anual	Simular interrupción completa, cronometrar la recuperación total

Cómo probar la restauración de una base de datos

Cree un entorno de prueba — ¡No restaure en producción!
Restaure la copia de seguridad:

# PostgreSQL
gunzip -c backup.sql.gz | psql -h test-server -U postgres -d testdb

# MySQL
gunzip -c backup.sql.gz | mysql -h test-server -u root -p testdb

Verifique la integridad de los datos:

-- Check row counts
SELECT COUNT(*) FROM important_table;

-- Check for recent data
SELECT MAX(created_at) FROM transactions;

-- Run application smoke tests

Documente los resultados:

Tiempo necesario para restaurar
Errores encontrados
Resultados de la verificación de datos
Mejoras necesarias

Prueba completa de recuperación ante desastres

Una vez al año, simule un desastre completo:

Elija un sistema no crítico o use un entorno de prueba
Finja que el primario está destruido — No acceda a él en absoluto
Restaure solo desde las copias de seguridad
Mida:
- Recovery Time Objective (RTO): ¿cuánto tiempo hasta que el servicio se restaura?
- Recovery Point Objective (RPO): ¿cuántos datos se perdieron?
Documente todo: Qué funcionó, qué fue difícil, qué faltaba

Esto revela brechas que no encontrará de ninguna otra manera.

Cumplimiento y requisitos regulatorios

Si gestiona datos personales o trabaja con clientes empresariales, las copias de seguridad no son solo una buena práctica: a menudo son legalmente obligatorias.

RGPD

El RGPD no dice explícitamente «debe tener copias de seguridad», pero el Artículo 32 requiere:

«la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma oportuna en caso de incidente físico o técnico»

Esto significa:

Necesita copias de seguridad de cualquier sistema que contenga datos personales
Las copias deben estar cifradas (el Artículo 32 requiere «cifrado de datos personales»)
Las ubicaciones de copia importan — Almacenar copias fuera de la UE/EEE requiere mecanismos de transferencia apropiados (Cláusulas Contractuales Estándar, decisiones de adecuación)
Los períodos de retención se aplican también a las copias: no puede guardar datos de copia indefinidamente
Controles de acceso — El acceso a las copias debe ser limitado y registrado

El problema del derecho de supresión: El Artículo 17 da a las personas el derecho a que se eliminen sus datos. Pero eliminar registros específicos de las copias de seguridad es técnicamente difícil. El enfoque aceptado:

Elimine de los sistemas de producción de inmediato
Documente que los datos existen en las copias con una fecha de vencimiento específica
Cuando la copia expire o se restaure, aplique la eliminación de nuevo
No restaure datos eliminados en producción

Documentación requerida:

Períodos de retención de copias
Métodos de cifrado utilizados
Ubicación de la copia (país/región)
Retención del registro de acceso

ISO 27001

El Anexo A de la ISO 27001 tiene controles específicos para copias de seguridad:

A.12.3 Copia de seguridad de la información:

A.12.3.1 requiere que se realicen copias de seguridad de la información, el software y las imágenes del sistema y se prueben regularmente

Qué significa «probadas regularmente»:

Defina la frecuencia de prueba en su política (mínimo mensual recomendado)
Documente los resultados de las pruebas
Incluya la verificación de copias en el alcance de su SGSI

Controles adicionales que afectan a las copias:

A.8.2 (Clasificación de la información) — La retención de copias debe coincidir con la clasificación de datos
A.11.1 (Áreas seguras) — Protección física de los soportes y el almacenamiento de copias
A.12.4 (Registro y monitorización) — El acceso a las copias debe registrarse
A.18.1.3 (Protección de registros) — Algunos registros tienen retención legalmente obligatoria

SOC 2

Los Criterios de Servicios de Confianza de SOC 2 incluyen:

Disponibilidad (A1.2):

Los objetivos de recuperación (RTO/RPO) deben estar documentados y probados
Los procedimientos de copia deben estar documentados
Las pruebas de recuperación deben realizarse regularmente

Controles comunes:

CC6.1 — El acceso lógico a los sistemas de copia debe estar controlado
CC7.2 — Los cambios en el sistema (incluida la configuración de copias) deben gestionarse
CC7.3 — La integridad de las copias debe verificarse

Para las auditorías de SOC 2, deberá demostrar:

Política de copia documentada
Evidencia de ejecución de copias (registros)
Evidencia de pruebas de recuperación (resultados de pruebas con fechas)
Controles de acceso en los sistemas de copia

PCI-DSS (si gestiona datos de pago)

Requisitos de PCI-DSS 4.0:

Requisito 9.4.1: Las copias que contienen datos de titulares de tarjetas deben almacenarse de forma segura
Requisito 3.1: El almacenamiento de datos de titulares de tarjetas debe minimizarse, incluida la retención de copias
Requisito 12.10.1: El plan de respuesta a incidentes debe abordar los procedimientos de copia

Lista de verificación de cumplimiento práctica

Requisito	RGPD	ISO 27001	SOC 2	Su estado
Política de copia documentada	✓	✓	✓	☐
Cifrado en reposo	✓	✓	✓	☐
Cifrado en tránsito	✓	✓	✓	☐
Períodos de retención definidos	✓	✓	✓	☐
Pruebas regulares documentadas	Implícito	✓	✓	☐
Controles de acceso y registro	✓	✓	✓	☐
Ubicación de copias documentada	✓	✓	✓	☐
RTO/RPO definidos	Implícito	✓	✓	☐

El documento de política de copias de seguridad

Cree una política escrita para que todos conozcan el plan.

Plantilla de política de copias de seguridad

Política de copia de seguridad de datos de [Nombre de la empresa]

Objetivo: Garantizar que los datos críticos puedan recuperarse en caso de fallo de hardware, ransomware, eliminación accidental o desastre.

Alcance: Todos los datos de la empresa, incluidos servidores, bases de datos, aplicaciones SaaS y estaciones de trabajo de empleados.

Calendario de copias de seguridad:

Tipo de datos	Frecuencia	Retención	Ubicación
Bases de datos de producción	Por hora	30 días	AWS S3 + entre cuentas
Servidores de archivos	Diaria	90 días	Backblaze B2
SaaS (Google Workspace)	Diaria	1 año	Backupify
Configuraciones del sistema	Al cambiar + semanal	90 días	Git + S3
Portátiles de empleados	Continuo	30 días	[Servicio de copia]

Implementación 3-2-1:

Copia 1: Entorno de producción
Copia 2: Copia de seguridad en la nube primaria (AWS S3)
Copia 3: Copia de seguridad en la nube secundaria (Backblaze B2, proveedor diferente)
Fuera de las instalaciones: Todas las copias en la nube están distribuidas geográficamente
Inmutable: S3 Object Lock activado en la copia secundaria

Pruebas:

Mensual: Verificación de restauración aleatoria de archivos
Trimestral: Restauración completa de base de datos en entorno de prueba
Anual: Simulacro completo de recuperación ante desastres

Objetivos de recuperación:

RTO (Tiempo de recuperación): 4 horas para sistemas críticos, 24 horas para estándar
RPO (Punto de recuperación): 1 hora para bases de datos, 24 horas para archivos

Responsabilidades:

Configuración y monitorización de copias: [Nombre/Rol]
Pruebas de recuperación: [Nombre/Rol]
Revisión de política: [Nombre/Rol], anualmente
Titular de clave privada (autoridad de restauración): [Nombre/Rol]
Titular de acceso de emergencia: [Nombre/Rol]

Control de acceso:

Ubicación del registro de acceso a copias: [Enlace/ubicación]
Frecuencia de revisión de acceso: Trimestral
Personal autorizado para restaurar: [Lista de nombres]

Procedimiento de recuperación:

Evalúe qué necesita recuperarse
Acceda a las credenciales de almacenamiento de copias desde Passwork
Siga el manual en [ubicación]
Verifique la integridad de la recuperación
Documente el incidente

Cumplimiento:

Datos personales incluidos: Sí/No
Cifrado de copias: AES-256 (Restic)
Ubicación de clave de cifrado: Bóveda de Passwork «Backup Keys»
Regiones de almacenamiento: [UE/EE.UU./otro — documente para RGPD]
Gestión del derecho de supresión: Aplicar eliminación al restaurar, las copias expiran después de [X] días

Última actualización: [Fecha] Próxima revisión: [Fecha + 1 año]

Errores habituales en copias de seguridad

Error 1: Hacer copias en el mismo sistema

Si el ransomware cifra su servidor y el disco USB conectado, ambos se pierden. Las carpetas de sincronización en la nube (Dropbox, OneDrive, Google Drive) no son copias de seguridad: sincronizan los archivos cifrados también.

Solución: Las copias deben estar en sistemas separados con credenciales separadas.

Error 2: Sin copia fuera de las instalaciones

Incendio, inundación, robo o un empleado descontento con acceso de administrador pueden destruir las copias en las instalaciones.

Solución: Al menos una copia en una ubicación física diferente o región en la nube.

Error 3: Nunca probar las restauraciones

Se entera de que la copia no funciona cuando desesperadamente la necesita.

Solución: Pruebas de restauración programadas, resultados documentados.

Error 4: Respaldar las cosas equivocadas

Respalda el servidor de archivos pero se olvida de la base de datos, las aplicaciones SaaS o los archivos de configuración que hacen que todo funcione.

Solución: Inventario completo de lo que necesita copia antes de configurar nada.

Error 5: Sin monitorización

Las copias fallan silenciosamente. Nadie se da cuenta durante meses.

Solución: Monitorización automatizada y alertas para los trabajos de copia.

Error 6: Credenciales en un solo lugar

La contraseña de cifrado de la copia está en el servidor que fue cifrado.

Solución: Guarde las credenciales de copia en el gestor de contraseñas (Passwork), accesible por múltiples personas autorizadas.

Error 7: Perder la clave de cifrado

Las copias cifradas con una clave perdida no sirven para nada. La persona que configuró las copias se fue y nadie conoce la frase de contraseña.

Solución: Guarde las claves de cifrado en Passwork, cree una copia en papel en un lugar seguro y pruebe la recuperación con esas claves anualmente.

Error 8: No tener en cuenta las solicitudes de eliminación del RGPD

Alguien solicita la eliminación de datos según el RGPD. Elimina de producción, pero sus datos viven en 30+ copias de seguridad.

Solución: Documente su enfoque: datos eliminados de producción de inmediato, eliminación aplicada a cualquier copia restaurada, las copias expiran después de [X] días.

Control de acceso a copias de seguridad

¿Quién puede acceder a sus copias?

Las copias a menudo contienen datos más sensibles que los sistemas de producción: son una instantánea completa de todo. Sin embargo, el acceso a las copias suele ser una idea de último momento.

Mantenga un registro de acceso a copias:

Persona	Rol	Nivel de acceso	Fecha de concesión	Última revisión
[Nombre]	Security Champion	Completo (cifrar/descifrar/restaurar)	2024-01-15	2024-06-01
[Nombre]	DevOps Lead	Solo lectura/restauración	2024-02-01	2024-06-01
[Nombre]	CTO	Acceso de emergencia (credenciales selladas)	2024-01-15	2024-06-01

Reglas para el acceso a copias:

Mínimo necesario — La mayoría de las personas no necesitan acceso a las copias. Los desarrolladores raramente lo necesitan.
Separado de producción — Las credenciales de copia deben ser diferentes de las de producción
Revisión trimestral — Elimine el acceso de quienes se fueron o cambiaron de rol
Registre el acceso — Sepa quién accedió a las copias y cuándo
Regla de dos personas para datos críticos — Considere requerir dos personas para restaurar las copias más sensibles

Qué cuenta como datos críticos en las copias

Algunos datos requieren protección adicional:

Datos personales de clientes (alcance del RGPD)
Registros financieros y datos de pago
Credenciales de autenticación y secretos
Claves de cifrado
Código fuente (propiedad intelectual)
Registros de salud (alcance de HIPAA)
Información personal de empleados

Si sus copias contienen alguno de estos, considere el enfoque de cifrado asimétrico a continuación.

Cifrado híbrido: el Security Champion controla la restauración

Una configuración práctica donde solo el Security Champion (o administrador de copias designado) puede descifrar las copias. Usa cifrado híbrido: AES-256 rápido para los datos, RSA para la protección de claves.

Creación de copias (cualquiera con acceso al script puede ejecutarla):

Genere una clave AES-256 aleatoria
Cifre los datos de la copia con esa clave AES
Cifre la clave AES con la clave pública RSA
Almacene ambos: copia_cifrada + clave_cifrada

Restauración (solo el Security Champion):

Descifre la clave AES usando la clave privada RSA
Descifre los datos de la copia con la clave AES
Restaure

Por qué este patrón:

Los scripts de copia pueden ejecutarse automáticamente (solo necesitan la clave pública)
Solo el titular de la clave privada puede restaurar
Si el almacenamiento de copias se compromete, los datos siguen cifrados
AES-256 es rápido para archivos grandes; RSA gestiona el intercambio de claves

Paso a paso con OpenSSL

1. Genere el par de claves RSA (el Security Champion lo hace una vez):

# Generate 4096-bit RSA private key
openssl genrsa -aes256 -out backup_private.pem 4096

# Extract public key
openssl rsa -in backup_private.pem -pubout -out backup_public.pem

# Private key: store securely (Passwork, offline, safety deposit box)
# Public key: distribute to backup servers

2. Script de copia (se ejecuta automáticamente, usa solo la clave pública):

#!/bin/bash
# backup-encrypt.sh

BACKUP_FILE=$1
PUBLIC_KEY="/etc/backup/backup_public.pem"
OUTPUT_DIR="/backup/encrypted"
DATE=$(date +%Y%m%d_%H%M%S)

# Generate random 256-bit AES key
AES_KEY=$(openssl rand -hex 32)

# Encrypt backup with AES-256-CBC
openssl enc -aes-256-cbc -salt -pbkdf2 \
    -in "$BACKUP_FILE" \
    -out "${OUTPUT_DIR}/backup_${DATE}.enc" \
    -pass pass:"$AES_KEY"

# Encrypt AES key with RSA public key
echo "$AES_KEY" | openssl rsautl -encrypt -pubin \
    -inkey "$PUBLIC_KEY" \
    -out "${OUTPUT_DIR}/backup_${DATE}.key.enc"

# Clean up
unset AES_KEY
rm "$BACKUP_FILE"  # Remove unencrypted backup

echo "Backup encrypted: backup_${DATE}.enc + backup_${DATE}.key.enc"

3. Script de restauración (solo el Security Champion, requiere clave privada):

#!/bin/bash
# backup-decrypt.sh

ENCRYPTED_BACKUP=$1
ENCRYPTED_KEY="${ENCRYPTED_BACKUP%.enc}.key.enc"
PRIVATE_KEY="/secure/backup_private.pem"
OUTPUT_FILE="${ENCRYPTED_BACKUP%.enc}.restored"

# Decrypt AES key using RSA private key
AES_KEY=$(openssl rsautl -decrypt \
    -inkey "$PRIVATE_KEY" \
    -in "$ENCRYPTED_KEY")

# Decrypt backup with AES key
openssl enc -aes-256-cbc -d -salt -pbkdf2 \
    -in "$ENCRYPTED_BACKUP" \
    -out "$OUTPUT_FILE" \
    -pass pass:"$AES_KEY"

# Clean up
unset AES_KEY

echo "Backup decrypted: $OUTPUT_FILE"

4. Ejemplo completo — copia de seguridad de base de datos con cifrado:

#!/bin/bash
# full-db-backup.sh

DB_NAME="production"
BACKUP_DIR="/backup"
PUBLIC_KEY="/etc/backup/backup_public.pem"
DATE=$(date +%Y%m%d_%H%M%S)

# Dump database
pg_dump -h localhost -U postgres "$DB_NAME" | gzip > "${BACKUP_DIR}/db_${DATE}.sql.gz"

# Generate AES key and encrypt
AES_KEY=$(openssl rand -hex 32)

openssl enc -aes-256-cbc -salt -pbkdf2 \
    -in "${BACKUP_DIR}/db_${DATE}.sql.gz" \
    -out "${BACKUP_DIR}/db_${DATE}.sql.gz.enc" \
    -pass pass:"$AES_KEY"

echo "$AES_KEY" | openssl rsautl -encrypt -pubin \
    -inkey "$PUBLIC_KEY" \
    -out "${BACKUP_DIR}/db_${DATE}.key.enc"

# Remove unencrypted file
rm "${BACKUP_DIR}/db_${DATE}.sql.gz"

# Upload to S3 (encrypted files only)
aws s3 cp "${BACKUP_DIR}/db_${DATE}.sql.gz.enc" s3://backup-bucket/db/
aws s3 cp "${BACKUP_DIR}/db_${DATE}.key.enc" s3://backup-bucket/db/

# Cleanup and notify
unset AES_KEY
echo "$(date): Database backup encrypted and uploaded" >> /var/log/backup.log

Gestión de claves para esta configuración

Almacenamiento de la clave privada:

Primaria: Passwork (cifrada, en una bóveda a la que solo el Security Champion tiene acceso)
Copia de seguridad: Impresa en papel, guardada en la caja fuerte de la empresa o en una caja de seguridad
Nunca en los servidores de copia ni en el almacenamiento de copias

Distribución de la clave pública:

Se puede almacenar en los servidores de copia (es pública)
Incluya en los scripts de copia
El control de versiones está bien (no es secreta)

Rotación de claves:

Genere un nuevo par de claves anualmente
Mantenga las claves privadas antiguas para descifrar copias antiguas
Documente qué clave cifra qué rango de copias

Acceso de emergencia:

El CTO u otra persona debería tener una copia sellada de la clave privada
Procedimiento de «romper en caso de emergencia» documentado
Pruebe el acceso de emergencia anualmente

Consejos prácticos que ahorran dinero y problemas

Verifique la integridad de la copia sin una restauración completa

Las restauraciones completas llevan tiempo. Pero puede verificar que las copias son legibles:

# Restic: check backup integrity
restic check

# Restic: check and read all data (slower, but catches more problems)
restic check --read-data

# Borg: verify repository
borg check /path/to/repo

# Check backup file isn't empty or corrupted
gzip -t backup.sql.gz && echo "OK" || echo "CORRUPTED"

Programe comprobaciones de integridad semanalmente. Son más rápidas que las restauraciones completas pero detectan la mayor parte de la corrupción.

Gestión de claves de cifrado

Si pierde su clave de cifrado de copia de seguridad, sus copias son inútiles. Esto ocurre con más frecuencia de lo que se cree.

Haga esto:

Guarde las claves de cifrado en Passwork (separadas de la copia misma)
Cree una copia en papel guardada en una caja fuerte o caja de seguridad
Asegúrese de que al menos dos personas saben dónde están almacenadas las claves
Pruebe que las claves funcionan restaurando en un sistema nuevo

No haga esto:

Guarde la clave de cifrado en el mismo servidor que se está respaldando
Tenga solo una persona que conozca la clave
Use una contraseña que pueda olvidar

Optimización de la ventana de copia de seguridad

Las copias afectan a los sistemas de producción. Minimice el dolor:

Programe de forma inteligente:

# Run backup during low-traffic hours
0 3 * * * /usr/local/bin/backup.sh  # 3 AM

# For global teams, find the quietest hour (check your analytics)

Limite el ancho de banda:

# Restic: limit bandwidth to 50 MB/s
restic backup --limit-upload 50000 /data

# rsync: limit bandwidth
rsync --bwlimit=50000 /source /destination

# AWS S3: configure transfer acceleration or use multipart uploads

Use herramientas nativas de bases de datos:

PostgreSQL: pg_dump con --no-synchronized-snapshots para menos bloqueos
MySQL: --single-transaction para tablas InnoDB
MongoDB: copias de réplicas secundarias

Deduplicación para ahorrar costes de almacenamiento

La deduplicación almacena cada fragmento único de datos una sola vez, aunque aparezca en múltiples copias.

Herramientas con deduplicación integrada:

Restic, BorgBackup — excelente deduplicación
AWS S3 — sin deduplicación nativa, pero Glacier ahorra dinero para archivos
Backblaze B2 — sin deduplicación, pero suficientemente barato

Ahorro real: Un conjunto de datos de 100 GB con copias diarias durante 30 días:

Sin deduplicación: 3 TB de almacenamiento
Con deduplicación (reducción típica del 90%): 300 GB de almacenamiento

Haga una copia de seguridad de su gestor de contraseñas

Su gestor de contraseñas (Passwork) contiene las llaves de todo. Si lo pierde, la recuperación se vuelve mucho más difícil.

Para Passwork:

Use la función de exportación cifrada integrada
Programe exportaciones mensuales
Guarde las exportaciones en su sistema de copias (cifradas por separado)
Passwork autohospedado: incluya la base de datos y el almacenamiento de archivos como parte de su copia de infraestructura

Escenario de recuperación: Si su infraestructura está cifrada y no puede acceder a Passwork, necesita la copia de Passwork para obtener las credenciales de sus otras copias. Guarde al menos una exportación de Passwork en una ubicación completamente separada.

Rotación abuelo-padre-hijo

Para la retención a largo plazo sin almacenamiento interminable:

Diario (hijo): Mantener 7 copias diarias
Semanal (padre): Mantener 4 copias semanales (cada domingo)
Mensual (abuelo): Mantener 12 copias mensuales (el primero de cada mes)

Esto le da un año de puntos de restauración mensuales, un mes de puntos semanales y una semana de puntos diarios, con solo 23 copias en lugar de 365.

La mayoría de las herramientas de copia soportan esto con políticas de retención:

# Restic: keep 7 daily, 4 weekly, 12 monthly
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# BorgBackup
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=12

Resiliencia entre regiones y proveedores

Un proveedor de nube puede tener interrupciones. Para datos críticos:

Entre regiones (mismo proveedor):

# AWS: replicate S3 bucket to another region
aws s3api put-bucket-replication --bucket source-bucket --replication-configuration file://replication.json

Entre proveedores:

Copia primaria: AWS S3
Copia secundaria: Backblaze B2 o Google Cloud Storage
Use rclone para sincronizar entre proveedores

# rclone: sync S3 to Backblaze B2
rclone sync s3:my-backup-bucket b2:my-backup-bucket --transfers 8

Por qué ambos: Si AWS tiene una interrupción importante, todavía puede acceder a las copias. Si un proveedor sufre una brecha de seguridad, sus datos están en otro lugar.

Comprobación rápida del tamaño

Añada esto a los scripts de copia para detectar copias vacías o sospechosamente pequeñas:

#!/bin/bash
BACKUP_FILE=$1
MIN_SIZE_KB=1000  # Minimum expected size in KB

SIZE=$(du -k "$BACKUP_FILE" | cut -f1)

if [ "$SIZE" -lt "$MIN_SIZE_KB" ]; then
    echo "WARNING: Backup file suspiciously small ($SIZE KB)" | mail -s "Backup Size Alert" [email protected]
    exit 1
fi

Procedimientos de recuperación

Documente estos antes de necesitarlos.

Procedimiento de recuperación de archivos

Identifique qué necesita recuperarse (nombre del archivo, ruta, fecha aproximada)
Acceda al almacenamiento de copias (credenciales en Passwork: entrada «Backup - S3»)
Liste las instantáneas disponibles: restic snapshots
Encuentre el archivo: restic find filename
Restaure: restic restore snapshot_id --target /restore --include path/to/file
Verifique el archivo restaurado
Mueva a la ubicación de producción si es correcto

Procedimiento de recuperación de base de datos

Evalúe el daño (datos corruptos, eliminación accidental, pérdida completa)
Determine el punto de recuperación (¿a qué momento debemos restaurar?)
Detenga el acceso de la aplicación para evitar más escrituras
Acceda a las credenciales de copia desde Passwork
Descargue el archivo de copia
Restaure en entorno de prueba primero si el tiempo lo permite
Restaure en producción
Verifique la integridad de los datos
Reanude el acceso de la aplicación
Documente qué ocurrió y qué se perdió

Procedimiento de recuperación completa del servidor

Provisione un nuevo servidor (mismas especificaciones que el servidor fallido)
Instale el SO base
Recupere la configuración del servidor desde la copia
Restaure los archivos de configuración
Restaure los datos de la aplicación
Restaure la base de datos
Verifique que todos los servicios están funcionando
Actualice el DNS si es necesario
Pruebe a fondo antes de declarar la recuperación completa

Herramientas y servicios

Software de copia de seguridad

Código abierto:

Restic — Rápido, cifrado, deduplicado
BorgBackup — Excelente deduplicación
Duplicati — Basado en GUI, bueno para estaciones de trabajo
Velero — Copias de Kubernetes

Comerciales:

Veeam — Líder del sector, caro
Acronis — Buen todo en uno
Druva — Nativo en la nube

Almacenamiento de copias

Almacenamiento de objetos en la nube:

AWS S3 — Opción estándar, Glacier para archivos
Backblaze B2 — Mucho más barato que S3, API compatible con S3
Wasabi — Barato, sin tasas de salida
Google Cloud Storage — Buena opción si usa GCP

Servicios específicos de copia:

Backblaze Personal/Business — Copia simple de estaciones de trabajo
Tarsnap — Seguro, pago por uso, orientado a Unix

Monitorización

Healthchecks.io — Interruptor de hombre muerto para trabajos cron
Cronitor — Similar, más funciones
Nativo en la nube: AWS CloudWatch, GCP Monitoring, Azure Monitor

Taller: implemente su estrategia de copias de seguridad

Reserve de 3 a 4 horas para la configuración inicial y luego mantenimiento continuo.

Parte 1: Inventario y clasificación (45 minutos)

Liste todos los datos que necesitan copia de seguridad
Clasifique por prioridad (crítico, importante, estándar, bajo)
Identifique las brechas actuales en las copias
Documente dónde vive cada tipo de datos

Parte 2: Configure la copia primaria (60 minutos)

Elija la herramienta de copia (Restic, Borg o nativa en la nube)
Configure para sus datos críticos
Configure el calendario automatizado
Verifique que la primera copia se completa con éxito
Documente la configuración

Parte 3: Configure la copia fuera de las instalaciones/inmutable (45 minutos)

Cree un destino de copia secundario (proveedor/cuenta diferente)
Active la inmutabilidad si está disponible
Configure la replicación desde el primario
Verifique que la copia llega a la ubicación secundaria

Parte 4: Pruebe la recuperación (30 minutos)

Elija un archivo aleatorio de la copia
Restáurelo en una ubicación de prueba
Verifique que el contenido coincide con el original
Documente el proceso de restauración

Parte 5: Documentación (30 minutos)

Escriba su política de copias (use la plantilla anterior)
Documente los procedimientos de recuperación
Guarde las credenciales en el gestor de contraseñas
Programe pruebas de restauración recurrentes

Entregables:

Inventario completo de datos
Copias automatizadas en ejecución para datos críticos
Copia fuera de las instalaciones/inmutable configurada
Primera prueba de recuperación completada
Política de copias documentada
Procedimientos de recuperación documentados
Monitorización configurada

Cómo explicárselo a la dirección

Si alguien pregunta por qué invirtió tiempo en esto:

«Implementé una estrategia completa de copias de seguridad siguiendo la regla 3-2-1: tres copias de nuestros datos, dos tipos diferentes de almacenamiento, una fuera de las instalaciones. También activé el almacenamiento inmutable para que el ransomware no pueda eliminar nuestras copias incluso si los atacantes obtienen acceso de administrador. Y probé la recuperación para asegurarme de que realmente funciona. Si nuestros servidores fueran cifrados mañana, podríamos recuperar los sistemas críticos en 4 horas.»

Versión corta: «Configuré copias de seguridad adecuadas y probé que realmente podemos recuperarnos de ellas. El ransomware no puede derribarnos.»

Autoevaluación: ¿realmente lo hizo?

Cobertura de copias de seguridad

Inventarió todos los datos que necesitan copia de seguridad
Clasificó los datos por prioridad
Las bases de datos de producción están respaldadas
Los servidores/almacenamiento de archivos están respaldados
Los datos críticos de SaaS tienen solución de copia
Las configuraciones del sistema están respaldadas

Implementación 3-2-1

Existen al menos 3 copias de los datos críticos
Las copias están en diferentes tipos/proveedores de almacenamiento
Al menos una copia está fuera de las instalaciones/en la nube
Al menos una copia es inmutable o está aislada

Automatización y monitorización

Las copias se ejecutan automáticamente según el calendario
La monitorización alerta si una copia falla
Los registros de copia se conservan

Pruebas y documentación

Completó al menos una prueba de restauración
Política de copias documentada
Procedimientos de recuperación documentados
Credenciales almacenadas en el gestor de contraseñas
Calendario de pruebas de recuperación creado

Seguridad y cumplimiento

Las copias están cifradas (en reposo y en tránsito)
Las claves de cifrado están almacenadas separadas de las copias
Ubicación de copias documentada (para RGPD)
Períodos de retención definidos
Al menos dos personas pueden acceder a las credenciales de copia

Control de acceso

Registro de acceso a copias mantenido (quién puede acceder a qué)
Las credenciales de copia son distintas de las credenciales de producción
Las copias de datos críticos usan cifrado asimétrico (RSA + AES)
La clave privada se almacena de forma segura (Passwork + copia sin conexión)
Procedimiento de acceso de emergencia documentado

Si puede marcar al menos 18 de estos 26 elementos, está listo para continuar.

Qué viene después

Las copias de seguridad son sólidas. Una victoria rápida más antes de pasar a la seguridad en el desarrollo.

Próximo capítulo: protección del sitio web con Cloudflare — protección DDoS, WAF y mitigación de bots para sus sitios de cara al público.

Por qué las copias de seguridad fallan cuando las necesita​

La regla de copia de seguridad 3-2-1​

Por qué importa cada número​

La regla moderna 3-2-1-1-0​

Tipos de copia de seguridad: completa, incremental, diferencial​

Cuál usar en cada caso​

Qué respaldar​

Categorías de datos críticos​

Qué no necesita copia de seguridad​

Clasificación de datos por prioridad de copia de seguridad​

Métodos y herramientas de copia de seguridad​

Servidores locales/en las instalaciones​

Infraestructura en la nube​

Copia de seguridad de datos de SaaS​

Copias de seguridad de contenedores y Kubernetes​

Copias de seguridad inmutables y aisladas​

Almacenamiento inmutable​

Copias de seguridad aisladas (air-gapped)​

Arquitectura recomendada para protección contra ransomware​

Automatización de copias de seguridad​

Programación con cron​

Script de copia de seguridad de ejemplo​

Monitorización de copias de seguridad​

Prueba de la recuperación​

Por qué importa la prueba​

Calendario de pruebas de recuperación​

Cómo probar la restauración de una base de datos​

Prueba completa de recuperación ante desastres​

Cumplimiento y requisitos regulatorios​

RGPD​

ISO 27001​

SOC 2​

PCI-DSS (si gestiona datos de pago)​

Lista de verificación de cumplimiento práctica​

El documento de política de copias de seguridad​

Plantilla de política de copias de seguridad​

Errores habituales en copias de seguridad​

Error 1: Hacer copias en el mismo sistema​

Error 2: Sin copia fuera de las instalaciones​

Error 3: Nunca probar las restauraciones​

Error 4: Respaldar las cosas equivocadas​

Error 5: Sin monitorización​

Error 6: Credenciales en un solo lugar​

Error 7: Perder la clave de cifrado​

Error 8: No tener en cuenta las solicitudes de eliminación del RGPD​

Control de acceso a copias de seguridad​

¿Quién puede acceder a sus copias?​

Qué cuenta como datos críticos en las copias​

Cifrado híbrido: el Security Champion controla la restauración​

Paso a paso con OpenSSL​

Gestión de claves para esta configuración​

Consejos prácticos que ahorran dinero y problemas​

Verifique la integridad de la copia sin una restauración completa​

Gestión de claves de cifrado​

Optimización de la ventana de copia de seguridad​

Deduplicación para ahorrar costes de almacenamiento​

Haga una copia de seguridad de su gestor de contraseñas​

Rotación abuelo-padre-hijo​

Resiliencia entre regiones y proveedores​

Comprobación rápida del tamaño​

Procedimientos de recuperación​

Procedimiento de recuperación de archivos​

Procedimiento de recuperación de base de datos​

Procedimiento de recuperación completa del servidor​

Herramientas y servicios​

Software de copia de seguridad​

Almacenamiento de copias​

Monitorización​

Taller: implemente su estrategia de copias de seguridad​

Cómo explicárselo a la dirección​

Autoevaluación: ¿realmente lo hizo?​

Cobertura de copias de seguridad​

Implementación 3-2-1​

Automatización y monitorización​

Pruebas y documentación​

Seguridad y cumplimiento​

Control de acceso​

Qué viene después​