Generación de Backups de Bases de Datos

Generación de Backups de Bases de Datos

Introducción:

La protección de datos es una piedra angular de cualquier infraestructura tecnológica. La pérdida de datos, ya sea por fallos de hardware, errores humanos, ataques maliciosos o desastres naturales, puede tener consecuencias devastadoras para una organización. Una estrategia de backups robusta y bien implementada es esencial para garantizar la continuidad del negocio, la recuperación ante desastres y el cumplimiento de normativas.

Este documento proporciona una guía detallada para la generación de backups de los tipos de bases de datos más relevantes en la actualidad, tanto en entornos on-premise como en la nube. Cubriremos tanto bases de datos relacionales (SQL) como no relacionales (NoSQL), destacando las particularidades de cada una y las mejores prácticas para asegurar la integridad y disponibilidad de los datos.

1. Conceptos Generales y Mejores Prácticas para Backups de Bases de Datos:

Antes de abordar bases de datos específicas, es crucial comprender algunos conceptos fundamentales y las mejores prácticas aplicables a cualquier estrategia de backup:

• Tipos de Backups:
• Backup Completo (Full Backup): Copia todos los datos de la base de datos en un momento dado. Es la base de cualquier estrategia de backup y permite una restauración completa.
• Backup Diferencial (Differential Backup): Copia solo los datos que han cambiado desde el último backup completo. Requiere un backup completo previo para su restauración.
• Backup Incremental (Incremental Backup): Copia solo los datos que han cambiado desde el último backup (ya sea completo o incremental). Requiere la restauración del último backup completo y todos los backups incrementales posteriores.
• Backup Lógico (Logical Backup): Exporta la estructura de la base de datos (esquema, tablas, índices, etc.) y los datos en un formato legible (por ejemplo, archivos SQL, JSON, CSV). Útil para migraciones, auditorías y recuperación a nivel de objeto.
• Backup Físico (Physical Backup): Copia los archivos de datos subyacentes que componen la base de datos. Generalmente más rápido y eficiente para restauraciones completas.
• Frecuencia y Planificación de Backups: La frecuencia de los backups debe basarse en la criticidad de los datos y la tasa de cambio. Las bases de datos con alta actividad requerirán backups más frecuentes. Se deben establecer horarios de backup automáticos para evitar la dependencia de procesos manuales.
• Políticas de Retención de Backups: Define cuánto tiempo se deben conservar los backups. Esto puede variar según los requisitos normativos, las necesidades del negocio y las limitaciones de almacenamiento. Se deben implementar políticas de retención jerárquicas (por ejemplo, backups diarios durante una semana, backups semanales durante un mes, backups mensuales durante un año).
• Pruebas y Validación de Backups: Es fundamental probar periódicamente los backups para asegurar su integridad y la capacidad de restaurar la base de datos en caso de necesidad. Las pruebas deben simular diferentes escenarios de pérdida de datos.
• Seguridad de los Backups: Los backups deben protegerse contra accesos no autorizados, modificaciones y eliminaciones. Esto incluye el cifrado de los backups, el control de acceso al almacenamiento de backups y la implementación de medidas de seguridad física y lógica.
• Consideraciones de Recuperación ante Desastres (DR): La estrategia de backup debe integrarse con el plan de recuperación ante desastres de la organización. Esto puede implicar el almacenamiento de backups en una ubicación secundaria (fuera del sitio principal) o el uso de soluciones de replicación y failover.

2. Backups de Bases de Datos Relacionales (SQL):

Las bases de datos relacionales almacenan datos en tablas con relaciones definidas. Algunos de los sistemas de gestión de bases de datos relacionales (SGBDR) más populares incluyen MySQL, PostgreSQL, Microsoft SQL Server y Oracle Database.

2.1. MySQL:

• On-Premise:
• Backup Lógico: Utilizar la utilidad mysqldump para exportar la base de datos a un archivo SQL.
  Bash
  mysqldump -u [usuario] -p[contraseña] --databases [nombre_bd1] [nombre_bd2] ... > backup.sql
  Para un backup completo de todas las bases de datos:
  Bash
  mysqldump -u [usuario] -p[contraseña] --all-databases --routines --events > full_backup.sql
  
  
• Backup Físico:
• Copia de Archivos: Si MySQL está configurado con el motor de almacenamiento InnoDB y la opción innodb_file_per_table habilitada, se pueden copiar los archivos .ibd (datos) y .frm (estructura) de cada tabla. Sin embargo, esto requiere detener el servidor MySQL o utilizar herramientas como xtrabackup.
• Xtrabackup: Una herramienta de código abierto de Percona que permite realizar backups físicos en caliente (sin detener el servidor) de bases de datos MySQL InnoDB.
• Backups Incrementales: xtrabackup también soporta backups incrementales basados en el número de secuencia de log (LSN).
• Cloud (AWS RDS, Azure Database for MySQL, Google Cloud SQL for MySQL):
• Los proveedores de servicios en la nube ofrecen mecanismos de backup gestionados.
• AWS RDS: Utiliza snapshots de EBS (Elastic Block Store) para backups físicos. Se pueden configurar backups automáticos con una ventana de tiempo especificada y un periodo de retención. También se pueden crear snapshots manuales.
• Azure Database for MySQL: Ofrece backups automáticos del servidor (backups completos diarios, backups diferenciales cada hora o cada cinco minutos). El periodo de retención se puede configurar.
• Google Cloud SQL for MySQL: Realiza backups automáticos diarios. Se pueden configurar la hora y la frecuencia de los backups. También permite crear backups a demanda.
• En entornos cloud, también se pueden realizar backups lógicos utilizando las herramientas estándar de MySQL desde una instancia conectada a la base de datos en la nube.

2.2. PostgreSQL:

• On-Premise:
• Backup Lógico: Utilizar la utilidad pg_dump para exportar la base de datos a un archivo SQL.
  Bash
  pg_dump -U [usuario] -d [nombre_bd] -f backup.sql
  Para un backup completo de todas las bases de datos:
  Bash
  pg_dumpall -U [usuario] -f full_backup.sql
  
  
• Backup Físico:
• Copia de Archivos: Se puede realizar una copia de los archivos de datos del directorio PGDATA del servidor PostgreSQL. Esto requiere detener el servidor para asegurar la consistencia.
• Backups en Caliente con pg_basebackup: Una herramienta para realizar backups físicos en caliente de un clúster de PostgreSQL en ejecución.
  Bash
  pg_basebackup -h [host] -U [usuario] -D [directorio_backup] -P -v
  
  
• Backups Incrementales: PostgreSQL soporta Write-Ahead Logging (WAL), que se puede archivar para realizar backups point-in-time recovery (PITR). Esto permite restaurar la base de datos a un punto específico en el tiempo.
• Cloud (AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL):
• Similar a MySQL, los proveedores de nube ofrecen servicios de backup gestionados.
• AWS RDS: Utiliza snapshots de EBS para backups físicos. Se pueden configurar backups automáticos y snapshots manuales. También soporta PITR mediante la retención de logs de transacción.
• Azure Database for PostgreSQL: Ofrece backups automáticos del servidor (backups completos semanales, backups diferenciales diarios). Soporta PITR con un periodo de retención configurable.
• Google Cloud SQL for PostgreSQL: Realiza backups automáticos diarios y soporta PITR mediante la retención de logs de transacción. También permite crear backups a demanda.
• Al igual que con MySQL, se pueden utilizar las herramientas estándar de PostgreSQL para realizar backups lógicos desde un cliente conectado.

2.3. Microsoft SQL Server:

• On-Premise:
• Backup Completo: Utilizar SQL Server Management Studio (SSMS) o comandos T-SQL:
  SQL
  BACKUP DATABASE [NombreDeLaBaseDeDatos]
  TO DISK = 'C:\Backup\NombreDeLaBaseDeDatos.bak'
  WITH FORMAT;
  
  
• Backup Diferencial:
  SQL
  BACKUP DATABASE [NombreDeLaBaseDeDatos]
  TO DISK = 'C:\Backup\NombreDeLaBaseDeDatos_diff.bak'
  WITH DIFFERENTIAL;
  
  
• Backup de Log de Transacciones: Esencial para la recuperación a un punto específico en el tiempo (PITR) en el modelo de recuperación Full o Bulk-Logged.
  SQL
  BACKUP LOG [NombreDeLaBaseDeDatos]
  TO DISK = 'C:\Backup\NombreDeLaBaseDeDatos_log.trn';
  
  
• Agentes de Backup: SQL Server Agent permite programar backups automáticos.
• Cloud (Azure SQL Database, AWS RDS for SQL Server, Google Cloud SQL for SQL Server):
• Azure SQL Database: Realiza backups automáticos (backups completos semanales, backups diferenciales diarios, backups de log cada 5-10 minutos). La retención se puede configurar. También permite realizar backups a demanda.
• AWS RDS for SQL Server: Ofrece backups automatizados (snapshots del volumen de almacenamiento) y backups manuales (snapshots de la instancia de base de datos). También soporta PITR mediante la retención de logs de transacción.
• Google Cloud SQL for SQL Server: Realiza backups automáticos diarios. Se pueden configurar la hora y la frecuencia. También permite crear backups a demanda y soporta PITR.
• Se pueden utilizar las herramientas estándar de SQL Server (SSMS, comandos T-SQL) para interactuar con las bases de datos en la nube y realizar backups.

2.4. Oracle Database:

• On-Premise:
• Recovery Manager (RMAN): La herramienta recomendada por Oracle para realizar backups y recuperaciones. RMAN permite backups completos, incrementales, backups en caliente y PITR.
  Fragmento de código
  RMAN> CONNECT TARGET /
  RMAN> BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
  
  
• Backups en Frío (Offline): Requiere detener la base de datos. Se copian los archivos de datos, archivos de control y archivos de redo log.
• Backups en Caliente (Online): La base de datos permanece operativa. Requiere poner los tablespaces en modo de backup y archivar los redo logs. RMAN simplifica este proceso.
• Cloud (AWS RDS for Oracle, Azure Database for Oracle, Google Cloud SQL for Oracle):
• AWS RDS for Oracle: Ofrece backups automatizados (snapshots del volumen de almacenamiento) y backups manuales (snapshots de la instancia de base de datos). Soporta PITR mediante la retención de archivos de log de archivado. RMAN se puede utilizar para backups más avanzados.
• Azure Database for Oracle: Ofrece backups automáticos y permite realizar backups a demanda. Soporta PITR con un periodo de retención configurable.
• Google Cloud SQL for Oracle: Realiza backups automáticos diarios y permite crear backups a demanda. Soporta PITR mediante la retención de logs de archivado. RMAN también se puede utilizar.

3. Backups de Bases de Datos No Relacionales (NoSQL):

Las bases de datos NoSQL tienen diferentes modelos de datos y arquitecturas en comparación con las bases de datos relacionales. Esto influye en las estrategias de backup.

3.1. MongoDB:

• On-Premise:
• Backup Lógico: Utilizar la utilidad mongodump para exportar datos a formato BSON o JSON.
  Bash
  mongodump --host [host] --port [puerto] --username [usuario] --password [contraseña] --db [nombre_bd] --out /ruta/backup
  Para un backup completo de todas las bases de datos:
  Bash
  mongodump --host [host] --port [puerto] --username [usuario] --password [contraseña] --all --out /ruta/backup
  
  
• Backup Físico:
• Copia de Archivos: Si MongoDB está configurado con el motor de almacenamiento WiredTiger, se pueden copiar los archivos de datos del directorio dbPath. Esto requiere detener el servidor o utilizar el comando db.fsyncLock() para asegurar la consistencia.
• Backups en Caliente con mongorestore y Oplog: Para backups en caliente, se puede utilizar mongodump para obtener una copia inicial y luego aplicar las operaciones del oplog (log de operaciones) para poner la copia al día.
• MongoDB Atlas (servicio gestionado en la nube): Realiza backups continuos y permite la restauración a un punto específico en el tiempo.
• Cloud (AWS DocumentDB, Azure Cosmos DB API para MongoDB, Google Cloud Firestore en modo Datastore):
• AWS DocumentDB: Realiza backups automáticos y permite crear snapshots manuales. Soporta PITR con un periodo de retención configurable.
• Azure Cosmos DB API para MongoDB: Ofrece backups automáticos y a demanda. La restauración se puede realizar a un punto específico en el tiempo dentro del periodo de retención.
• Google Cloud Firestore en modo Datastore: Realiza backups automáticos diarios y permite crear backups a demanda.

3.2. Cassandra:

• On-Premise:
• Snapshots: Cassandra proporciona la funcionalidad de snapshots, que crea una copia consistente de los archivos de datos (SSTables) en el disco. Los snapshots son rápidos y no afectan el rendimiento.
  Bash
  nodetool snapshot -t [nombre_snapshot] [keyspace.table]
  
  
• Backups Completos: Para un backup completo, se deben copiar los directorios de datos de cada nodo en el clúster.
• Herramientas de Terceros: Existen herramientas como Medusa que facilitan la gestión de backups de Cassandra.
• Cloud (AWS Keyspaces para Cassandra, Azure Managed Instance para Apache Cassandra, Google Cloud Memorystore para Redis - aunque Redis no es Cassandra):
• AWS Keyspaces: Realiza backups automáticos y permite crear backups a demanda.
• Azure Managed Instance para Apache Cassandra: Ofrece backups automáticos y permite realizar backups a demanda.
• Google Cloud Memorystore para Redis: No es Cassandra. Para Cassandra en GCP, se puede utilizar la versión auto-gestionada en Compute Engine y aplicar las estrategias on-premise o utilizar soluciones de partners.

3.3. Redis:

• On-Premise:
• RDB (Redis Database File): Redis puede guardar snapshots de la base de datos en disco en formato RDB. Esto se configura en el archivo redis.conf o mediante comandos.
  Bash
  redis-cli SAVE
  Se pueden configurar reglas para guardar automáticamente la base de datos después de un cierto número de cambios en un periodo de tiempo específico.
• AOF (Append Only File): Redis también puede registrar cada operación de escritura en un archivo AOF. Esto proporciona una mayor durabilidad que RDB. Se puede configurar para escribir al disco en cada comando, cada segundo o nunca.
• Backup Manual: Copiar los archivos dump.rdb (para RDB) y appendonly.aof (para AOF).
• Cloud (AWS ElastiCache for Redis, Azure Cache for Redis, Google Cloud Memorystore para Redis):
• AWS ElastiCache for Redis: Permite crear snapshots y configurar backups automáticos.
• Azure Cache for Redis: Ofrece backups automáticos y permite realizar backups a demanda.
• Google Cloud Memorystore para Redis: Realiza backups automáticos diarios y permite crear backups a demanda.

3.4. Elasticsearch:

• On-Premise:
• Snapshots: Elasticsearch proporciona una API para crear snapshots de los índices. Primero, se debe registrar un repositorio de snapshots.
  JSON
  PUT _snapshot/my_backup_repository
  {
    "type": "fs",
    "settings": {
      "location": "/mnt/data/elasticsearch_backups"
    }
  }
  Luego, se puede crear un snapshot:
  JSON
  PUT _snapshot/my_backup_repository/snapshot_20230406
  {
    "indices": "my-index-*"
  }
  
  
• Herramientas de Terceros: Existen herramientas como Curator que ayudan a gestionar snapshots y políticas de retención.
• Cloud (AWS OpenSearch Service, Azure Cognitive Search, Google Cloud Elasticsearch):
• AWS OpenSearch Service: Permite crear snapshots manuales y automatizados.
• Azure Cognitive Search: Ofrece mecanismos de backup y restauración.
• Google Cloud Elasticsearch: Soporta snapshots de los índices. Se deben configurar un bucket de Google Cloud Storage como repositorio de snapshots.

Conclusión:

La implementación de una estrategia de backup efectiva es fundamental para la protección de datos en cualquier entorno. Este documento ha proporcionado una visión general de las consideraciones clave y las técnicas específicas para realizar backups de las bases de datos relacionales y no relacionales más relevantes, tanto on-premise como en la nube.

Es importante recordar que la estrategia de backup óptima dependerá de los requisitos específicos de cada organización, incluyendo la criticidad de los datos, la tolerancia a la pérdida de datos (RPO - Recovery Point Objective), el tiempo de inactividad aceptable (RTO - Recovery Time Objective) y las limitaciones presupuestarias.

Se recomienda encarecidamente probar y validar periódicamente los backups, así como revisar y actualizar la estrategia de backup a medida que evolucionan las necesidades del negocio y las tecnologías de bases de datos. La inversión en una estrategia de backup sólida es una inversión en la resiliencia y la continuidad del negocio.