Sin copias de seguridad: el terror tecnológico más antiguo sin monstruos

Qué significa realmente “sin copias de seguridad”

La mayoría de los equipos que “no tienen copias de seguridad” no carecen literalmente de todo. Tienen artefactos. Instantáneas en el lugar equivocado. Un trabajo cron que se ejecutó una vez. Un bucket con una regla de ciclo de vida que borra silenciosamente la única copia. Una política de rotación de cintas diseñada con cariño en 2009 y nunca ejecutada desde que la persona que la entendía se fue.

En términos operativos, “sin copias de seguridad” significa que al menos una de estas afirmaciones es cierta:

• No existe una copia independiente. Todas las copias comparten el mismo dominio de fallo: misma cuenta, misma región, mismo sistema de almacenamiento, mismas credenciales, mismo radio de alcance de ransomware.
• No existe una ruta de restauración verificada. La copia puede estar presente, pero no puedes restaurarla dentro del RTO, o incluso no puedes restaurarla en absoluto.
• No existe un punto conocido y bueno. Las copias pueden estar corruptas, incompletas, cifradas con claves perdidas o capturadas a mitad de una transacción sin consistencia.
• Nadie es responsable de la recuperación. Las copias “pertenecen a IT” y las restauraciones “pertenecen al equipo de la app”, lo que se traduce en “nadie las tocará hasta que sea demasiado tarde”.
• Ninguna monitorización detecta la falla. El trabajo no se ha ejecutado en 47 días y nadie lo notó porque los dashboards verdes son decorativos.

Puedes almacenar datos en diez lugares y aun así no tener copias de seguridad. Las copias de seguridad no van de copiar. Van de recuperación: recuperación controlada, repetible, acotada en el tiempo, que puedas ejecutar bajo estrés y con sueño incompleto.

Un consejo que te ahorrará dinero y dolor: si no has realizado un ejercicio de restauración recientemente, no tienes copias de seguridad—tienes esperanza.

Hay una razón por la que la gente de operaciones habla de copias de seguridad con el tono que suele reservarse para incendios eléctricos. Es la categoría de fallo donde el sistema parece estar bien hasta que deja de estarlo, y entonces no es el sistema el que falla: es la historia que te contaste sobre el sistema.

Broma corta #1: Las copias de seguridad son como los paracaídas: si solo las pruebas una vez, estarás muy confiado por poco tiempo.

RPO y RTO: las únicas palabras que importan cuando se van las luces

RPO (Recovery Point Objective) es cuánto dato estás dispuesto a perder. Si tu RPO es 15 minutos, una copia que se ejecuta una vez al día no es un plan de backup; es una carta de renuncia escrita en YAML.

RTO (Recovery Time Objective) es cuánto tiempo estás dispuesto a estar caída. Si tu RTO es 1 hora, una restauración que requiere que alguien encuentre una clave de descifrado en la bóveda personal de un ex empleado no es una restauración; es una búsqueda del tesoro.

No negocies RPO/RTO en medio de un incidente. Decide por adelantado, obtén aprobación y construye el sistema para cumplirlos. Seguirás teniendo incidentes. Simplemente no tendrás sorpresas.

Hechos e historia: por qué esto sigue pasando

“Sin copias de seguridad” existe desde antes que la mayoría de los lenguajes de programación en producción. Persiste porque se sitúa en la intersección del optimismo humano, la presión presupuestaria y sistemas que fallan de formas creativas.

8 hechos y puntos de contexto (cortos y concretos)

1. Las primeras copias empresariales se hicieron sobre cinta porque los discos eran caros; la disciplina operativa importaba más que el hardware. El medio cambió; la disciplina no.
2. La regla “3-2-1” (tres copias, dos tipos de medio, una fuera de sitio) precede al bombo de la nube y aún captura una verdad central: la independencia vence a la elegancia.
3. RAID se malinterpretó durante décadas como “backup”; RAID es disponibilidad, no recuperabilidad. Previene algunos fallos y amplifica otros.
4. Las snapshots se generalizaron porque son baratas y rápidas (copy-on-write), lo que hizo fácil confiar demasiado en ellas—hasta que el sistema de snapshots comparte el mismo dominio de fallo.
5. El ransomware cambió el modelo de amenaza de “fallo de hardware” a “adversario activo”. Si los atacantes pueden borrar las copias, no tienes copias.
6. La nube introdujo una nueva ilusión: que la durabilidad implica automáticamente recuperabilidad. La durabilidad de objetos no ayuda si sobrescribes lo incorrecto o eliminas el bucket con credenciales de administrador.
7. Las fallas del software de backup suelen ser silenciosas porque el éxito se mide por “trabajo completado” en lugar de “restauración verificada”. Puedes “completar” basura.
8. Los regímenes de cumplimiento aumentaron las demandas de retención (y los costes), lo que empujó a los equipos a deduplicación agresiva y reglas de ciclo de vida—dos herramientas potentes y peligrosas cuando están mal configuradas.

La idea de fiabilidad que vale la pena recordar

Aquí hay una sola frase que debería vivir en tus runbooks:

“Todo falla; diseña para que el fallo sea sobrevivible.” — Werner Vogels

Si construyes sistemas, ese es el trabajo. No evitar la falla. Sobrevivirla.

Modos de fallo: cómo “tenemos backups” se convierte en “nunca los tuvimos”

1) Misma cuenta, mismas claves, mismo radio de daño

Tus copias están en la misma cuenta cloud que producción. El mismo rol IAM que puede borrar prod puede borrar las copias. Durante un evento de ransomware o una fuga de credenciales, los atacantes no evitan educadamente tu bucket de “backup”.

Solución: coloca las copias en una cuenta/proyecto/tenant separado con credenciales distintas y patrones estrictos de escritura cruzada. Si puedes navegar el repositorio de backups desde tu portátil con tu rol SSO habitual, ya lo has hecho demasiado fácil de destruir.

2) Confundir snapshots con copias de seguridad

Las snapshots son excelentes. También frecuentemente no son copias de seguridad:

• Las snapshots en el mismo volumen no sobreviven la pérdida del volumen.
• Las snapshots en el mismo array de almacenamiento no sobreviven la pérdida del array.
• Las snapshots accesibles con las mismas credenciales de administrador no sobreviven el ransomware.

Trata las snapshots como recuperación local rápida. Las copias de seguridad son recuperación independiente.

3) “Las copias fallan” pero las restauraciones también fallan

Este es el clásico. Los logs del trabajo muestran “éxito”. El repositorio se llena de archivos. Luego intentas restaurar y aprendes:

• la cadena depende de incrementales faltantes,
• la clave de cifrado se perdió,
• la copia de la base de datos no es consistente,
• las instrucciones de restauración nunca fueron documentadas,
• la plataforma objetivo cambió (kernel, sistema de archivos, versión mayor de BD).

Las copias de seguridad son un producto; las restauraciones son la prueba de aceptación.

4) Políticas de retención que borran tu pasado

Una simple mala configuración de ciclo de vida puede eliminar los únicos puntos de restauración viables. Patrones comunes:

• Retención afinada por coste y accidentalmente puesta a “conservar 7 días” cuando el ransomware estuvo sin detectar 21.
• Reglas de “mover a almacenamiento más barato” que rompen los objetivos de tiempo de restauración porque la recuperación tarda horas.
• Versionado de objetos desactivado porque “cuesta demasiado”, luego un trabajo automático sobrescribe todo.

5) La trampa de la “optimización”: deduplicación y cadenas incrementales

La deduplicación y los incrementales son fantásticos cuando garantizas integridad y pruebas restauraciones. También son una forma de concentrar riesgo: corrompe un chunk en el almacén dedupe y muchas copias se vuelven inútiles simultáneamente.

Cuando alguien dice “ahorramos 60% de almacenamiento”, tu siguiente pregunta debe ser: “Muéstrame la prueba de restauración completa del mes pasado.”

6) Copias sin identidad ni procedencia

Una copia sin metadatos es una caja sellada. Si no sabes qué contiene, qué la produjo, cuándo se tomó, a qué versión corresponde y cómo restaurarla, es una responsabilidad con factura de almacenamiento.

Al mínimo, cada artefacto de backup debe ser rastreable a:

• identidad del sistema origen (host/db/cluster),
• ventana temporal,
• método de consistencia (congelado de sistema de archivos, snapshot BD, archivo WAL),
• clase de retención (diaria/semanal/mensual),
• método de cifrado y propiedad de la clave,
• referencia de procedimiento de restauración (sección de runbook, no memoria tribal).

Tres mini-historias corporativas desde las trincheras de backups

Mini-historia #1: el incidente causado por una suposición equivocada

Una empresa SaaS mediana ejecutaba su base de datos primaria en Postgres gestionado. También tenían “copias” en una VM separada: un trabajo nocturno que ejecutaba pg_dump y copiaba un archivo a object storage. Sobre el papel, parecía seguro: backups gestionados más su propia copia por si acaso.

La suposición equivocada fue sutil y extremadamente común: asumieron que la salida de pg_dump implicaba un snapshot consistente y restaurable. Normalmente lo hace—hasta que no. Sus tablas más grandes estaban bajo carga constante de escritura, y el volcado tardó lo suficiente como para solaparse con varios cambios de esquema. El volcado terminó, reportó éxito y se subió al almacenamiento. Todos durmieron.

Entonces ocurrió un error operativo: un script de migración borró una tabla en el esquema equivocado. La recuperación punto en el tiempo gestionada existía, pero el equipo nunca la había practicado y desconocía las limitaciones del proveedor. Se volcaron sobre el archivo “simple”.

La restauración falló con errores sobre relaciones faltantes y estado de esquema inconsistente. El volcado no era una vista limpia punto en el tiempo de la base de datos como la aplicación la esperaba; era un artefacto de un sistema en evolución. Su “backup” no era erróneo; simplemente no era la copia que necesitaban para la recuperación que intentaban.

Finalmente recuperaron vía PITR gestionado tras una larga y estresante sesión de aprendizaje y mucho downtime. La solución no fue exótica: dejar de tratar volcados como la red de seguridad primaria para una base de datos caliente y cambiante. Usar un método de backup diseñado para consistencia (backups físicos con WAL, snapshots coordinados con la BD, o PITR nativo del proveedor) y ejecutar simulacros de restauración trimestralmente.

Mini-historia #2: la optimización que salió mal

Un equipo de servicios financieros decidió recortar costes de backup. Su repositorio crecía rápido y la factura mensual llamó la atención ejecutiva—del tipo que llega sin contexto técnico y se va con “acciones a realizar”. Un ingeniero bienintencionado activó deduplicación agresiva y cambió los backups completos de semanales a mensuales, confiando mucho en incrementales.

Todo parecía mejor. El crecimiento de almacenamiento se aplanó. Los backups se ejecutaban más rápido. Los dashboards brillaban en verde. Incluso presumieron del “éxito de eficiencia” en una revisión de costes. La parte aterradora de la historia es que nada de esto era mentira.

Tres meses después, un bug en el controlador de almacenamiento corrompió una pequeña porción del almacén dedupe. No lo suficiente para colapsar el sistema de backup. No lo suficiente para aparecer en las métricas de “trabajo exitoso”. Lo justo para hacer que las cadenas de restauración fueran poco fiables.

Cuando necesitaron recuperar un servidor de aplicación tras una actualización de SO fallida, la restauración falló repetidamente al final del proceso. Diferentes archivos cada vez. El sistema leía chunks corruptos referenciados por muchas copias. La optimización había concentrado el riesgo en una única piscina compartida de bloques, y las largas cadenas incrementales significaban que no había un “ancla” completa reciente y limpia a la que recurrir.

Reconstruyeron el repositorio, añadieron fulls sintéticos periódicos (verificados) e implementaron pruebas automáticas de restauración que montaban sistemas de archivos recuperados y validaban checksums. El coste subió. También su capacidad de dormir.

Mini-historia #3: la práctica aburrida pero correcta que salvó el día

Una empresa de manufactura tenía un pequeño equipo SRE que soportaba una mezcla de VMs legacy y servicios containerizados. Su sistema de backups no era sofisticado: snapshots ZFS replicadas cada noche a un segundo sitio, más exportaciones semanales a object storage inmutable. Los runbooks eran dolorosamente detallados, y el equipo realizaba un ejercicio de restauración cada mes.

Durante una ventana de parches rutinaria, una actualización de firmware en el array de almacenamiento primario salió mal. El array no murió dramáticamente; simplemente dejó de presentar varias LUNs correctamente. Desde la perspectiva del SO, los sistemas de archivos se volvieron de solo lectura y luego inconsistentes. Las aplicaciones comenzaron a fallar de formas confusas. El incidente no fue llamativo. Fue un tropiezo en cámara lenta.

El equipo no debatió. Ejecutaron el plan documentado: congelar escrituras, conmutar servicios al dataset replicado y levantar un conjunto mínimo de aplicaciones críticas primero. Su primer objetivo de restauración no fue “todo”: fueron los sistemas que generan ingresos y pagan nóminas.

Estuvieron de nuevo en servicio antes de que el negocio comprendiera completamente lo ocurrido. El postmortem fue casi aburrido: sin heroísmos, sin scripts mágicos de recuperación, sin “encontramos una copia en el portátil de Bob” a medianoche. Solo replicación, inmutabilidad y un procedimiento practicado.

La lección silenciosa: la recuperación aburrida vence a la copia de seguridad ingeniosa. Si tu plan de backups requiere genialidad durante una caída, no es un plan.

Guía de diagnóstico rápido: encuentra el cuello de botella ya

Cuando alguien dice “el backup falla” o “la restauración es demasiado lenta”, necesitas una vía rápida al factor limitante. No empieces reescribiendo todo. Empieza por encontrar qué está realmente limitado: credenciales, capacidad, IOPS, red, CPU, salud del repositorio o corrección.

Primero: verifica qué tipo de fallo tienes (disponibilidad vs corrección vs tiempo)

• Disponibilidad: trabajos de backup que no se ejecutan, repositorio inaccesible, permisos denegados.
• Corrección: backups “exitosos” pero la restauración falla o los datos faltan/están corruptos.
• Tiempo: la restauración tarda más que el RTO, los backups se solapan y nunca terminan, la replicación con desfase rompe el RPO.

Segundo: comprueba los cuatro puntos de estrangulamiento en orden

1. Identidad y permisos: credenciales expiradas, políticas IAM rotas, claves rotadas, cambios en MFA/SSO.
2. Capacidad de almacenamiento y retención: repo lleno, snapshots podados temprano, ciclo de vida de objetos eliminando.
3. Rendimiento: red saturada, I/O de disco limitado, throttling en la nube, compresión mono-hilo.
4. Consistencia: falta de quiesce aplicado por la aplicación, backups DB no coordinados con logs.

Tercero: demuestra la viabilidad de restauración con una prueba pequeña y determinista

No apuntes a restaurar todo el entorno primero. Elige un artefacto y restáuralo en un host de pruebas:

• restaurar un solo disco de VM y montarlo en solo lectura,
• restaurar un base backup de Postgres + reproducir WAL hasta una marca temporal conocida,
• restaurar un árbol de directorios y verificar checksums y conteos.

Esto reduce el problema a hechos: ¿puedes recuperar datos, descifrarlos, montarlos, puede la aplicación leerlos y cuánto tiempo toma?

Tareas prácticas (con comandos): demuestra que puedes restaurar

Abajo hay tareas reales que puedes ejecutar hoy. Cada una incluye: un comando, salida de ejemplo, qué significa y la decisión que tomas. El objetivo no es admirar la salida del comando. El objetivo es cambiar tu postura de “creemos” a “sabemos”.

Tarea 1: Confirma que realmente tienes copias recientes (nivel sistema de archivos)

cr0x@server:~$ ls -lh /backups/daily | tail -n 5
-rw-r----- 1 root backup 1.8G Jan 22 01:05 app01-etc-2026-01-22.tar.zst
-rw-r----- 1 root backup  22G Jan 22 01:12 app01-varlib-2026-01-22.tar.zst
-rw-r----- 1 root backup 4.1G Jan 22 01:18 db01-config-2026-01-22.tar.zst
-rw-r----- 1 root backup  91G Jan 22 01:55 db01-basebackup-2026-01-22.tar.zst
-rw-r----- 1 root backup 3.4M Jan 22 02:01 manifest-2026-01-22.json

Significado de la salida: Puedes ver los artefactos de hoy y sus tamaños, además de un manifiesto. Anomalías de tamaño (demasiado pequeño/demasiado grande) son señales tempranas de advertencia.

Decisión: Si los archivos de hoy faltan o tienen un tamaño obviamente incorrecto, deja de confiar en los correos de éxito. Investiga los logs del trabajo y los permisos upstream de inmediato.

Tarea 2: Comprueba el éxito del trabajo de backup desde systemd timers

cr0x@server:~$ systemctl list-timers --all | grep backup
Tue 2026-01-22 01:00:00 UTC  6h left  Tue 2026-01-21 01:00:04 UTC  18h ago backup-daily.timer   backup-daily.service
Tue 2026-01-22 02:30:00 UTC  8h left  Tue 2026-01-21 02:30:02 UTC  16h ago backup-verify.timer  backup-verify.service

Significado de la salida: Los timers existen y se ejecutaron recientemente. Si la “última” vez es antigua, tus backups pueden haber parado hace semanas.

Decisión: Si los timers no se ejecutan, trátalo como riesgo de pérdida de datos, no como un ticket menor. Arregla la programación y el alertado antes de cualquier otra cosa.

Tarea 3: Inspecciona el estado de la última ejecución del servicio de backup

cr0x@server:~$ systemctl status backup-daily.service --no-pager
● backup-daily.service - Nightly backup job
     Loaded: loaded (/etc/systemd/system/backup-daily.service; enabled)
     Active: inactive (dead) since Tue 2026-01-21 01:55:13 UTC; 18h ago
    Process: 18422 ExecStart=/usr/local/sbin/backup-daily.sh (code=exited, status=0/SUCCESS)
   Main PID: 18422 (code=exited, status=0/SUCCESS)

Jan 21 01:00:04 server backup-daily.sh[18422]: starting backup run id=2026-01-21T010004Z
Jan 21 01:55:12 server backup-daily.sh[18422]: upload complete: s3://backup-prod/daily/...
Jan 21 01:55:13 server backup-daily.sh[18422]: finished OK

Significado de la salida: La unidad terminó con éxito y registró la finalización de la subida.

Decisión: El éxito aquí es necesario pero no suficiente. Aún necesitas verificar integridad y restaurabilidad (tareas abajo).

Tarea 4: Detecta “repositorio lleno” antes de que sea un outage

cr0x@server:~$ df -h /backups
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       7.3T  7.1T  110G  99% /backups

Significado de la salida: 99% usado es una falla en progreso. Muchas herramientas de backup comenzarán a fallar, algunas comenzarán a borrar y unas pocas mentirán.

Decisión: Pausa backups no esenciales, amplia la capacidad y revisa la retención. También verifica que el último backup esté completo; discos casi llenos conducen a artefactos parciales.

Tarea 5: Valida checksums de un artefacto de backup (chequeo puntual)

cr0x@server:~$ sha256sum -c /backups/daily/manifest-2026-01-22.sha256 | head
app01-etc-2026-01-22.tar.zst: OK
app01-varlib-2026-01-22.tar.zst: OK
db01-config-2026-01-22.tar.zst: OK
db01-basebackup-2026-01-22.tar.zst: OK

Significado de la salida: Los archivos coinciden con los hashes registrados. Esto detecta corrupción en almacenamiento o transferencia.

Decisión: Si algún archivo está “FAILED”, cuarentena ese conjunto de backups, investiga la salud del almacenamiento y confirma que tienes otro punto de restauración.

Tarea 6: Verifica versionado y estado de bloqueo en almacenamiento de objetos (resiliencia contra ransomware)

cr0x@server:~$ aws s3api get-bucket-versioning --bucket backup-prod
{
    "Status": "Enabled"
}

Significado de la salida: El versionado está habilitado; los borrados se convierten en delete-markers y las sobreescrituras mantienen versiones previas.

Decisión: Si el versionado está “Suspended” o vacío, eres más vulnerable a ser borrado. Habilita versionado y considera Object Lock (inmutabilidad) donde corresponda.

Tarea 7: Confirma la configuración de Object Lock en S3 (inmutabilidad)

cr0x@server:~$ aws s3api get-object-lock-configuration --bucket backup-prod
{
    "ObjectLockConfiguration": {
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 30
            }
        }
    }
}

Significado de la salida: La retención por defecto es inmutable por 30 días en modo compliance. Incluso los admins no pueden acortarla.

Decisión: Si Object Lock está ausente y tu modelo de amenaza incluye ransomware, necesitas una capa inmutable (Object Lock, WORM, offline o un sistema separado y controlado).

Tarea 8: Comprueba el desfase de replicación para snapshots ZFS (verificación RPO)

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation | tail -n 3
tank/appdata@2026-01-22T0100Z  Tue Jan 22 01:00 2026
tank/appdata@2026-01-22T0200Z  Tue Jan 22 02:00 2026
tank/appdata@2026-01-22T0300Z  Tue Jan 22 03:00 2026

Significado de la salida: Existen snapshots horarias. Ese es tu mejor RPO teórico local.

Decisión: A continuación, confirma que esas snapshots se replican fuera de host. Las snapshots locales por sí solas no cubren necesidades de recuperación ante desastre.

Tarea 9: Confirma que la replicación ZFS realmente avanzó en el destino

cr0x@server:~$ ssh backup-target "zfs list -t snapshot -o name,creation -s creation | grep tank/appdata | tail -n 3"
tank/appdata@2026-01-22T0000Z  Tue Jan 22 00:00 2026
tank/appdata@2026-01-22T0100Z  Tue Jan 22 01:00 2026
tank/appdata@2026-01-22T0200Z  Tue Jan 22 02:00 2026

Significado de la salida: El destino está un snapshot detrás de la fuente. Ese es un desfase de replicación: tu RPO real es actualmente ~1 hora, no “cada hora”.

Decisión: Si el desfase excede tu RPO, investiga el rendimiento de replicación, fallos o la planificación. Considera replicación continua para bases de datos o WAL shipping.

Tarea 10: Mide el throughput del repositorio durante una restauración (verificación RTO)

cr0x@server:~$ pv /backups/daily/db01-basebackup-2026-01-22.tar.zst > /dev/null
 91.2GiB 0:12:31 [ 124MiB/s] [==================================>] 100%

Significado de la salida: Puedes leer el archivo de backup a ~124 MiB/s desde el repositorio. Ese es un techo duro de velocidad de restauración antes de descompresión y replay de la aplicación.

Decisión: Si tu RTO requiere restaurar 2 TB en menos de una hora, esta ruta de repo no puede hacerlo. Añade paralelismo, almacenamiento más rápido o estrategias de restauración por niveles.

Tarea 11: Valida que tu backup contiene lo que piensas (listado tar)

cr0x@server:~$ zstd -t /backups/daily/app01-etc-2026-01-22.tar.zst
/backups/daily/app01-etc-2026-01-22.tar.zst : OK

Significado de la salida: El archivo comprimido pasa las comprobaciones de integridad en la capa de compresión.

Decisión: Si esto falla, no intentes restaurar desde él. Encuentra otro punto en el tiempo e investiga hardware y rutas de subida.

Tarea 12: Realiza un ejercicio real de restauración de un directorio a una ruta de prueba

cr0x@server:~$ mkdir -p /restore-test/app01-etc && tar -I zstd -xpf /backups/daily/app01-etc-2026-01-22.tar.zst -C /restore-test/app01-etc
cr0x@server:~$ ls -l /restore-test/app01-etc/etc | head
total 64
-rw-r--r-- 1 root root  296 Jan 21 23:59 hostname
-rw-r--r-- 1 root root 1177 Jan 21 23:59 hosts
drwxr-xr-x 2 root root 4096 Jan 21 23:59 systemd
drwxr-xr-x 2 root root 4096 Jan 21 23:59 ssh

Significado de la salida: Extrajiste con éxito el backup y puedes ver archivos esperados. Esto es una prueba mínima viable de restauración.

Decisión: Si la extracción falla o faltan archivos, considera las copias comprometidas. Arréglalo antes de que el próximo incidente te obligue a hacerlo.

Tarea 13: Comprueba backups de Postgres: ¿está configurado el archivado WAL?

cr0x@server:~$ sudo -u postgres psql -c "show wal_level; show archive_mode; show archive_command;"
 wal_level
----------
 replica
(1 row)

 archive_mode
--------------
 on
(1 row)

           archive_command
-------------------------------------
 test ! -f /wal-archive/%f && cp %p /wal-archive/%f
(1 row)

Significado de la salida: El archivado WAL está habilitado. Esto es esencial para recuperación punto en el tiempo más allá del base backup.

Decisión: Si el archivado está desactivado, tus “backups” quizá solo restauren hasta el último base backup. Activa archivado y prueba PITR.

Tarea 14: Verifica que el archivo WAL realmente recibe ficheros (no solo está configurado)

cr0x@server:~$ ls -lh /wal-archive | tail -n 3
-rw------- 1 postgres postgres 16M Jan 22 02:54 00000001000000A7000000FE
-rw------- 1 postgres postgres 16M Jan 22 02:58 00000001000000A7000000FF
-rw------- 1 postgres postgres 16M Jan 22 03:02 00000001000000A700000100

Significado de la salida: Nuevos segmentos WAL llegan cada pocos minutos. Es evidencia viva de que tu cadena PITR progresa.

Decisión: Si el directorio está inactivo, tu RPO está derivando silenciosamente. Arregla el archivado antes de confiar en cualquier plan de restauración.

Tarea 15: Confirma que las copias no solo están presentes sino que son restaurables (prueba rápida Postgres)

cr0x@server:~$ createdb restore_smoke
cr0x@server:~$ pg_restore --list /backups/daily/appdb-2026-01-22.dump | head
;
; Archive created at 2026-01-22 01:10:02 UTC
;     dbname: appdb
;     TOC Entries: 248
;     Compression: -1
;     Dump Version: 1.14-0

Significado de la salida: El dump es legible y contiene objetos. Es una comprobación ligera antes de una restauración completa.

Decisión: Si pg_restore no puede leer el archivo, tu backup es efectivamente imaginario. Cambia a otro tipo de backup y añade pasos de verificación.

Tarea 16: Verifica que puedes descifrar tus backups (realidad de gestión de claves)

cr0x@server:~$ gpg --decrypt /backups/daily/secrets-2026-01-22.tar.gpg > /dev/null
gpg: encrypted with 4096-bit RSA key, ID 7A1C2B3D4E5F6789, created 2025-10-03
gpg: decryption ok

Significado de la salida: La operación de descifrado tiene éxito con las claves actualmente disponibles.

Decisión: Si el descifrado falla, no tienes backups—tienes pisapapeles cifrados. Arregla el depósito de claves, los procedimientos de acceso y las políticas de rotación.

Broma corta #2: Lo único peor que no tener copias de seguridad es tener copias que no puedes descifrar—como una caja fuerte en la que guardaste la llave dentro.

Errores comunes: síntomas → causa raíz → solución

Esta sección está diseñada para respuesta a incidentes y postmortems. Los síntomas son lo que ves a las 2 a.m. Las causas raíz son por qué pasó. Las soluciones son acciones específicas que puedes ejecutar.

1) “Los backups dicen SUCCESS, pero las restauraciones fallan”

Síntomas: Los logs muestran éxito; errores de restauración incluyen incrementales faltantes, archivo corrupto, mismatch de checksum o la aplicación no arranca.

Causa raíz: El criterio de éxito era “el archivo subido existe” en lugar de “restauración completada y validada”. O corrupción en el almacén dedupe, o snapshot DB inconsistente.

Solución: Añade verificación automatizada de restauración (montar/extraer + checksum + prueba de humo a nivel de aplicación). Mantén backups completos verificados periódicamente. Para bases de datos, usa métodos aware de la aplicación y valida restaurando a una instancia de pruebas.

2) “Podemos restaurar, pero tarda días”

Síntomas: Throughput de restauración bajo; recuperación desde almacenamiento frío toma horas; descompresión consume CPU; red se satura.

Causa raíz: El RTO no informó la arquitectura. Backups almacenados en la capa más barata sin modelar el tiempo de recuperación. La tubería de restauración es mono-hilo o está limitada por IOPS del repositorio.

Solución: Mide throughput de restauración (no solo de backup). Usa backups por niveles: puntos recientes en una capa rápida, antiguos en fría. Paraleliza restauraciones, preubica datasets críticos y asegúrate de poder escalar los objetivos de restauración.

3) “El ransomware borró también nuestras copias”

Síntomas: Bucket de backups vaciado, snapshots borradas, repositorio encriptado, servidor de backup comprometido.

Causa raíz: Credenciales compartidas y falta de inmutabilidad. Backups accesibles con roles de admin. Sin separación de responsabilidades.

Solución: Separa cuentas y credenciales, aplica roles de solo escritura para subida, habilita Object Lock/WORM, restringe borrado y conserva una copia offline o lógicamente aislada. Audita IAM para permisos de borrado de backups.

4) “Restauramos lo equivocado”

Síntomas: Restauración completada pero los datos son más antiguos de lo esperado, faltan tablas, entorno equivocado o dataset de cliente incorrecto.

Causa raíz: Etiquetado/metadatos pobres, nombres inconsistentes, sin manifiesto, sin runbook para seleccionar puntos de restauración.

Solución: Estandariza nombres de backups y manifiestos. Rastrear procedencia del backup (identidad origen, timestamp, método de consistencia). Crea un procedimiento de selección de restauración con pasos de aprobación para restauraciones en producción.

5) “Los backups pararon hace semanas; nadie lo notó”

Síntomas: Último backup exitoso es antiguo. La monitorización no alertó.

Causa raíz: La monitorización mira la ejecución del trabajo, no el éxito end-to-end. Alertas enviadas a canales muertos. On-call no es pagado por fallos de backup.

Solución: Alerta sobre “tiempo desde el último punto de restauración verificado”. Añade métricas de frescura del repositorio. Página al equipo responsable de la recuperación.

6) “Tenemos snapshots, así que estamos bien”

Síntomas: Declaraciones confiadas hasta que el disco/array/cuenta muere; entonces no existe copia off-host.

Causa raíz: Confundir herramientas de disponibilidad (RAID, snapshots) con independencia de backup.

Solución: Replica snapshots a otro sistema/cuenta/región. Añade retención inmutable. Documenta qué fallos cubren y cuáles no las snapshots.

7) “La retención podó nuestro único buen punto de restauración”

Síntomas: Necesitas restaurar algo más antiguo que la ventana de retención (p.ej., tiempo de permanencia de ransomware), pero ya no existe.

Causa raíz: Retención basada en coste, no en tiempo de detección y riesgo del negocio. Reglas de ciclo de vida demasiado agresivas.

Solución: Define retención con input de seguridad y legal. Conserva puntos “mensuales” o “trimestrales” más largos. Usa almacenamiento inmutable para un subconjunto de backups.

Listas de verificación / plan paso a paso

Paso a paso: pasa de “creemos” a “podemos restaurar” en 10 pasos

1. Define RPO y RTO por sistema. No “la compañía”. La BD de nóminas y la wiki de marketing no merecen la misma ingeniería.
2. Clasifica datos por método de recuperación. Restauración de imagen VM, restauración a nivel de archivo, PITR de base de datos, rollback de versión de objetos, etc.
3. Mapea dominios de fallo. Identifica qué puede fallar junto: cuenta, región, array, credenciales, servidor de backup, claves KMS.
4. Implementa al menos una copia independiente. Cuenta/tenant separado con permisos restringidos. Prefiere inmutabilidad para escenarios de ransomware.
5. Haz que las copias sean consistentes. Snapshots aware de la aplicación, archivado WAL, congelado de filesystem o herramientas nativas de BD.
6. Escribe el runbook de restauración. Incluye prerequisitos, claves, pasos de acceso, comandos y cómo validar éxito. Trátalo como una característica de producción.
7. Automatiza la verificación. Como mínimo: verificación de checksum + restauración a entorno aislado mensual. Mejor: pruebas pequeñas de restauración continuas.
8. Monitoriza “tiempo desde el último punto de restauración bueno”. No “trabajo completado”. Alerta al on-call.
9. Realiza un ejercicio DR trimestral. Elige un sistema crítico. Restaúralo con cronómetro y documenta qué falló.
10. Revisa y endurece permisos. Separa funciones: los admins de producción no deberían poder borrar copias inmutables con facilidad.

Lista operativa: antes de aprobar un diseño de backup

• ¿Pueden las credenciales de producción borrar backups? Si sí, arregla eso primero.
• ¿Existe una capa de retención inmutable para sistemas críticos? Si no, añádela.
• ¿Se prueba la restauración en la plataforma/versión actual? Si no, programa un simulacro.
• ¿El diseño cumple RPO/RTO en pruebas medidas, no en estimaciones?
• ¿Las claves de cifrado son recuperables en condiciones de incidente (SSO caído, on-call con acceso limitado)?
• ¿La monitorización se basa en puntos de restauración verificados y no en la finalización de trabajos?
• ¿La retención cubre demoras de detección (seguridad) y requisitos legales?
• ¿El runbook está escrito para que un ingeniero competente y no familiar pueda ejecutarlo?

Checklist de ejercicio de restauración: cómo luce “hecho”

• Restauración completada en un entorno aislado sin tocar producción.
• Integridad validada (checksums, conteos de filas, verificaciones de salud de la aplicación).
• Tiempo de recuperación medido y comparado con el RTO.
• Punto de recuperación medido y comparado con el RPO.
• Incidencias registradas como tareas con responsables y fechas.
• Runbook actualizado de inmediato según sorpresas encontradas.

Preguntas frecuentes

1) ¿Son las snapshots copias de seguridad?

A veces. Si las snapshots se replican a un sistema independiente y están protegidas contra borrado, pueden formar parte de una estrategia de backup. Las snapshots solo locales son un botón de deshacer rápido, no recuperación ante desastres.

2) ¿RAID es un backup?

No. RAID maneja ciertos fallos de disco sin tiempo de inactividad. No ayudará si los datos se borran, encriptan, corrompen por software o si se pierde todo el array.

3) ¿Cuál es la estrategia mínima viable de backup para un equipo pequeño?

Empieza con: (1) backups automáticos diarios, (2) una copia off-host en una cuenta separada, (3) un ejercicio de restauración mensual a un entorno de pruebas, (4) alertas por backups faltantes. Añade inmutabilidad si el ransomware está en el alcance (y lo está).

4) ¿Con qué frecuencia deberíamos probar restauraciones?

Para sistemas críticos: al menos ejercicios completos trimestrales, además de verificaciones automáticas más pequeñas con mayor frecuencia (semanal o diaria). La cadencia correcta es la que detecta deriva antes de que ocurra un incidente.

5) ¿Qué ventana de retención es “suficiente”?

Depende del tiempo de detección y requisitos legales. Muchos incidentes de ransomware implican días o semanas de dwell time. Si solo guardas 7 días, apuestas el negocio a una detección perfecta. Esa es una mala apuesta.

6) ¿Podemos fiarnos de los backups del proveedor cloud?

Los backups del proveedor pueden ser excelentes, pero aún necesitas validar los flujos de restauración, entender las limitaciones y considerar independencia. Una segunda copia bajo tu control (cuenta separada, credenciales diferentes) suele estar justificada para datos críticos.

7) ¿Deben cifrarse las copias de seguridad?

Sí—usualmente. Cifra en tránsito y en reposo. Pero el cifrado sin una gestión de claves recuperable es autoboicot. Trata las claves como parte del plan de restauración: controladas por acceso, auditadas y testables durante los ejercicios.

8) ¿Qué debemos monitorizar: trabajos de backup o datos de backup?

Monitoriza la existencia de un punto de restauración verificado reciente. Un trabajo puede “tener éxito” mientras produce salida inutilizable. Rastrea la edad del último punto verificado, la capacidad del repositorio y los resultados de pruebas de restauración.

9) ¿Cómo controlamos costes sin aumentar riesgo?

Haz niveles en tus backups: puntos recientes en una capa rápida, los más antiguos en una capa más barata. Usa compresión con sentido. Ten cuidado con dedupe agresiva y cadenas incrementales largas a menos que tengas fuertes cheques de integridad y pruebas de restauración.

10) ¿Quién debe ser dueño de backups y restauraciones?

La propiedad debe ser explícita. Los equipos de infraestructura pueden poseer la plataforma, pero los equipos de aplicación deben poseer la corrección de la recuperación (¿funciona la app tras la restauración?). Un runbook compartido y simulacros conjuntos evitan el lanzarse la responsabilidad.

Conclusión: siguientes pasos que puedes hacer esta semana

Si estás en la fase de “realmente deberíamos hacer backups”, enhorabuena: identificaste el problema mientras aún tienes opciones. El objetivo no es construir el sistema de backups más sofisticado. El objetivo es convertir la pérdida de datos en un evento acotado, no en una crisis existencial.

Pasos prácticos que mueven la aguja:

1. Elige un sistema crítico y define RPO/RTO con el negocio. Escríbelo. Hazlo responsabilidad de alguien.
2. Realiza un ejercicio de restauración a un entorno de pruebas. Cronoméalo. Documenta cada sorpresa. Arregla una sorpresa.
3. Separa dominios de fallo: asegura al menos una copia off-host y que no sea borrable por credenciales de producción habituales.
4. Habilita inmutabilidad para las copias que importarían más durante un ransomware.
5. Cambia la monitorización de “trabajo exitoso” a “edad del último punto de restauración verificado”. Página ante deriva.

Los sistemas fallan. La gente comete errores. Existen atacantes. La única respuesta adulta es diseñar para la recuperación y probarla con ejercicios. Todo lo demás es contar historias.