Decisión: ¿qué estrategia de backup?
Una estrategia de backup se elige equilibrando tres factores: cuánta pérdida de datos puede tolerar (RPO), el tamaño de sus datos y la rapidez con la que debe recuperarse (RTO). Ningún método se ajusta a todos los escenarios. Partiendo del objetivo de RPO, este árbol le orienta entre dumps lógicos, backups físicos + PITR y snapshots, y le recuerda que la regla 3-2-1 y la verificación no son negociables.
¿Cuál es su objetivo de pérdida de datos (RPO)?
Empiece por la restricción más decisiva: ante un desastre, ¿cuántos minutos/horas de datos puede permitirse perder? Si se requiere una pérdida de datos cercana a cero, el archivado continuo de logs (PITR) es obligatorio; si es aceptable una tolerancia de backup diaria/semanal, bastan métodos más sencillos. El RPO define el marco de la estrategia.
- Cercana a cero: debo poder volver a cualquier punto en el tiempo
- Son aceptables backups diarios/periódicos (unas horas de pérdida)
- Recuérdeme primero las buenas prácticas generales (3-2-1 / verificación)
¿Cuáles son los requisitos de tamaño de datos y portabilidad?
Si bastan los backups periódicos, la siguiente pregunta es la escala y el propósito: ¿la base de datos es pequeña/mediana y quiere que el backup sea portable a otro entorno/versión, o los datos son grandes y su principal preocupación es volver a estar operativo en minutos? Esto decide entre un dump lógico y un snapshot.
- Pequeña/mediana, portable y compatible entre versiones
- Datos grandes, la recuperación debe ser muy rápida (RTO bajo)
Recomendación: dump lógico
Exporta los datos a nivel lógico (definiciones de esquema + filas); la salida es SQL/texto (formato plain de pg_dump, mysqldump) o un dump binario propio de la herramienta (pg_dump -Fc, Oracle Data Pump). Un método flexible y portable para bases de datos pequeñas y medianas, migraciones, actualizaciones de versión y recuperación de tablas/objetos seleccionados.
Recomendación: backup físico + WAL/logs archivados (PITR)
Toma base backups físicos periódicos y archiva continuamente los logs de transacciones (WAL/redo/binlog). Esto le permite realizar una recuperación a un punto en el tiempo (Point-in-Time Recovery) a cualquier momento y reducir la pérdida de datos casi a cero.
Recomendación: snapshot
Toma una instantánea a nivel de bloque de los datos en la capa de almacenamiento o de virtualización. El backup y la restauración son muy rápidos incluso para bases de datos muy grandes; sin embargo, depende de la infraestructura y requiere un uso cuidadoso.
Recomendación: regla 3-2-1 + copia fuera del sitio + verificación obligatoria
Sea cual sea el método elegido, estos principios deben estar por encima de la estrategia. La mera existencia de un backup no basta; debe estar en otro soporte, en otra ubicación y probarse periódicamente. Es un marco que complementa todas las opciones anteriores.