Planificación de recuperación ante desastres
RPO, RTO y runbooks.
Planificación de recuperación ante desastres es una lección gratuita de SQL Academy en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de SQL Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de SQL Academy incluye 4 lecciones en total.
¿Qué es la recuperación ante desastres?
La recuperación ante desastres (DR) es el conjunto de políticas, herramientas y procedimientos diseñado para permitir la recuperación de infraestructura y sistemas tecnológicos vitales después de un desastre natural o provocado por el ser humano.
En el contexto de las bases de datos, la planificación de DR garantiza que sus datos permanezcan seguros y que sus sistemas puedan volver a estar en línea dentro de unos límites de tiempo aceptables después de eventos como un fallo de hardware, la eliminación accidental de datos, ataques de ransomware o interrupciones del centro de datos.
Objetivo de punto de recuperación (RPO)
RPO define la cantidad máxima aceptable de pérdida de datos, medida en tiempo. Si su RPO es de 1 hora, debe poder recuperar los datos hasta al menos 1 hora antes de que ocurriera el desastre.
Un RPO más corto exige copias de seguridad más frecuentes o replicación continua. Puede consultar el historial de copias de seguridad para verificar que cumple su objetivo de RPO.
-- Check the last backup time and calculate data loss window
SELECT
backup_id,
backup_type,
started_at,
finished_at,
EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;Objetivo de tiempo de recuperación (RTO)
RTO define el periodo máximo aceptable durante el cual su sistema puede permanecer fuera de servicio después de un desastre. Si su RTO es de 4 horas, su base de datos debe estar completamente operativa en un plazo de 4 horas desde el fallo.
El RTO condiciona las decisiones sobre servidores en espera, automatización de la conmutación por error y procedimientos de restauración. Hacer un seguimiento de la duración de las restauraciones a lo largo del tiempo le ayuda a prever si puede cumplir su RTO.
-- Track restore durations to validate RTO compliance
SELECT
restore_id,
triggered_at,
completed_at,
EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
CASE
WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
THEN 'WITHIN RTO'
ELSE 'RTO BREACHED'
END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;RPO frente a RTO — La diferencia clave
Estas dos métricas suelen confundirse. Esta es la forma más sencilla de recordarlas:
- RPO = ¿Cuántos datos puede permitirse perder? (orientado al pasado, medido en tiempo antes del desastre)
- RTO = ¿Cuánto tiempo puede permitirse estar fuera de servicio? (orientado al futuro, medido en tiempo después del desastre)
Juntos definen su ventana de recuperación e influyen directamente en la frecuencia de las copias de seguridad, la estrategia de replicación y el presupuesto de infraestructura.
-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
db_name VARCHAR(100) PRIMARY KEY,
rpo_minutes INT NOT NULL,
rto_minutes INT NOT NULL,
tier VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
updated_at TIMESTAMP DEFAULT NOW()
);
INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
('orders_db', 15, 60, 'CRITICAL'),
('analytics_db', 120, 240, 'MEDIUM'),
('archive_db', 480, 480, 'LOW');Tipos de copias de seguridad
Existen tres estrategias principales de copias de seguridad, cada una con un equilibrio distinto entre velocidad y almacenamiento:
- Copia de seguridad completa: una instantánea completa de toda la base de datos. Es la más lenta de crear y la más rápida de restaurar.
- Copia de seguridad diferencial: solo incluye los cambios desde la última copia de seguridad completa. Ofrece una velocidad moderada en ambos sentidos.
- Copia de seguridad incremental: solo incluye los cambios desde la última copia de seguridad de cualquier tipo. Es la más rápida de crear y la más lenta de restaurar, porque se necesitan varios archivos.
La mayoría de las estrategias de DR combinan copias de seguridad completas semanales con copias incrementales diarias para equilibrar el RPO y el coste de almacenamiento.
-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
backup_id SERIAL PRIMARY KEY,
db_name VARCHAR(100) NOT NULL,
backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
started_at TIMESTAMP NOT NULL,
finished_at TIMESTAMP,
size_mb NUMERIC(12, 2),
status VARCHAR(20) DEFAULT 'IN_PROGRESS'
);
INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
('orders_db', 'FULL', '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00', 320, 'SUCCESS'),
('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00', 290, 'SUCCESS');Recuperación a un momento dado (PITR)
La recuperación a un momento dado permite restaurar una base de datos a cualquier momento específico, no solo al momento de la última copia de seguridad. Esto se consigue reproduciendo los registros de transacciones (WAL en PostgreSQL) sobre una copia de seguridad base.
PITR es esencial cuando necesita recuperarse de una corrupción o eliminación accidental de datos que ocurrió en un momento conocido. Puede restaurar la base de datos justo antes de que ocurriera el evento dañino.
-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
segment_name VARCHAR(200) PRIMARY KEY,
archived_at TIMESTAMP DEFAULT NOW(),
size_bytes BIGINT,
storage_path TEXT
);
-- Find all WAL segments archived within a recovery window
SELECT
segment_name,
archived_at,
ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;Bases de datos en espera y replicación
Una base de datos en espera (réplica) es una copia de la base de datos principal que se actualiza continuamente y se ejecuta en hardware independiente. Cumple dos objetivos de DR:
- En espera activa: puede aceptar consultas de lectura y realizar una conmutación por error en segundos (RTO casi nulo).
- En espera templada: se mantiene sincronizada, pero no atiende tráfico; la conmutación por error tarda minutos.
Supervisar el retraso de replicación es fundamental: una réplica retrasada significa que su RPO real es peor de lo esperado.
-- Monitor replication lag on a PostgreSQL primary
SELECT
client_addr,
application_name,
state,
sent_lsn,
replay_lsn,
(sent_lsn - replay_lsn) AS lag_bytes,
EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;Runbooks: documentación de procedimientos de recuperación
Un runbook es un conjunto documentado de instrucciones paso a paso que un operador sigue durante un evento de recuperación ante desastres. Sin un runbook, incluso los DBA experimentados cometen errores costosos bajo presión.
Un buen runbook de DR incluye: a quién contactar, qué sistemas están afectados, los comandos exactos que se deben ejecutar, los resultados esperados en cada paso y los procedimientos de reversión si la recuperación falla. Almacenar los metadatos de los runbooks en una base de datos ayuda a realizar un seguimiento de las versiones y auditar su uso.
-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
runbook_id SERIAL PRIMARY KEY,
title VARCHAR(200) NOT NULL,
scenario VARCHAR(100),
version VARCHAR(20) DEFAULT '1.0',
last_tested DATE,
owner VARCHAR(100),
doc_url TEXT
);
INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
('Full Database Restore from S3', 'total_loss', '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
('Failover to Hot Standby', 'primary_down', '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
('PITR to Specific Timestamp', 'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');Registro de ejecución de runbooks
Cada vez que se ejecuta un runbook — ya sea durante un desastre real o un simulacro — debe registrarse. Los registros de ejecución permiten medir cuánto tarda realmente la recuperación, lo que valida su RTO, identificar pasos lentos o propensos a errores y demostrar el cumplimiento ante los auditores.
-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
execution_id SERIAL PRIMARY KEY,
runbook_id INT REFERENCES runbook(runbook_id),
triggered_by VARCHAR(100),
is_drill BOOLEAN DEFAULT FALSE,
started_at TIMESTAMP NOT NULL,
completed_at TIMESTAMP,
outcome VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);
-- Report average restore time per runbook
SELECT
r.title,
COUNT(*) AS executions,
ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;Pruebas de DR: simulacros periódicos
Un plan de DR que nunca se ha probado no es un plan: es un deseo. Los simulacros periódicos son obligatorios para garantizar que su equipo pueda ejecutar realmente los runbooks dentro del RTO definido y que las copias de seguridad se puedan restaurar de verdad.
Programar y realizar un seguimiento de los simulacros en su base de datos crea un registro de auditoría y ayuda a detectar los runbooks cuya prueba está atrasada.
-- Find runbooks that have not been drilled in over 90 days
SELECT
r.runbook_id,
r.title,
r.scenario,
MAX(e.completed_at) AS last_drill,
CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
ON e.runbook_id = r.runbook_id
AND e.is_drill = TRUE
AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;Políticas de retención de copias de seguridad
Las políticas de retención definen durante cuánto tiempo se conservan las copias de seguridad. Conservar todas las copias para siempre desperdicia almacenamiento; eliminarlas demasiado pronto incumple sus requisitos de RPO y cumplimiento normativo.
Una política habitual es conservar copias incrementales diarias durante 7 días, copias completas semanales durante 4 semanas y copias completas mensuales durante 12 meses. Puede aplicar y auditar la retención mediante consultas SQL sobre el registro de copias de seguridad.
-- Identify backups that are outside their retention window and ready to purge
SELECT
backup_id,
db_name,
backup_type,
finished_at,
CURRENT_DATE - finished_at::DATE AS age_days,
CASE backup_type
WHEN 'INCREMENTAL' THEN 7
WHEN 'DIFFERENTIAL' THEN 28
WHEN 'FULL' THEN 365
END AS retention_days,
CASE
WHEN (CURRENT_DATE - finished_at::DATE) >
CASE backup_type
WHEN 'INCREMENTAL' THEN 7
WHEN 'DIFFERENTIAL' THEN 28
WHEN 'FULL' THEN 365
END
THEN 'PURGE'
ELSE 'KEEP'
END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;Comprobación rápida
Compruebe que comprende las definiciones de RPO y RTO.
Repaso: planificación de recuperación ante desastres
En esta lección exploró los fundamentos de la planificación de la recuperación ante desastres de bases de datos:
- RPO define la pérdida de datos máxima tolerable, expresada en tiempo; un RPO más corto requiere copias de seguridad más frecuentes o replicación continua.
- RTO define la rapidez con la que debe restaurarse el sistema; un RTO más corto exige servidores en espera activa y conmutación por error automatizada.
- Los tipos de copias de seguridad —completas, diferenciales e incrementales— ofrecen distintos equilibrios entre el espacio de almacenamiento, la velocidad de creación y la velocidad de restauración.
- PITR (Point-in-Time Recovery) utiliza los registros de transacciones para restaurar el sistema a cualquier instante preciso y protegerlo frente a cambios accidentales.
- Los runbooks documentan cada paso de un procedimiento de recuperación; registrar las ejecuciones permite validar que el RTO es alcanzable en la práctica.
- Los simulacros de DR periódicos son la única forma de confirmar que las copias de seguridad se pueden restaurar y que su equipo puede cumplir los objetivos de RPO y RTO bajo una presión real.
- Las políticas de retención equilibran el coste del almacenamiento con los requisitos de cumplimiento y recuperación.
Un plan de DR probado exhaustivamente es una de las inversiones más valiosas que puede realizar un equipo de bases de datos.
Preguntas frecuentes
¿La lección «Planificación de recuperación ante desastres» es gratis?
Sí — el texto completo de «Planificación de recuperación ante desastres» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de SQL Academy, actualiza a CoddyKit PRO. El curso de SQL Academy incluye 4 lecciones en total.
¿Qué aprenderé en «Planificación de recuperación ante desastres»?
RPO, RTO y runbooks. Practicas SQL Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar SQL Academy?
No se requiere experiencia previa. SQL Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Planificación de recuperación ante desastres»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de SQL Academy?
Sí. Cada lección de SQL Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Copias de seguridad lógicas y físicas
- Recuperación a un momento dado
- Prueba de las restauraciones
- Planificación de recuperación ante desastres