[06/04/2022] Existen muchas opciones para hacer backups de las bases de datos, y lo que es mejor varía de una base de datos a otra y cómo se entrega. A continuación, recomendaciones para siete de ellos, con un vistazo a cómo se eligieron las opciones para ayudar a informar su toma de decisiones.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Oracle
Oracle tiene muchas opciones para backup, pero la respuesta oficial para respaldar Oracle sería Recovery Manager o RMAN, que también es el nombre del comando real que lo invoca. Entre muchas opciones, RMAN soporta una opción de imagen que puede fusionar backups incrementales más antiguos en backups completos, lo que le brindaría varios puntos de recuperación sin tener que realizar varios backups completos. Esa es una opción eficiente de volcado y barrido, pero el desafío es que necesita suficiente espacio en disco para almacenar un backup completo y una serie de archivos incrementales. Si tiene poco espacio en el disco, también puede usar el comando SQL para modificar la base de datos y comenzar el backup antes de realizar el backup, y modificar el backup final de la base de datos cuando termine. Esto le permitirá utilizar cualquier método de backup que elija. Oracle en Windows también se integra con Volume Shadow Copy Services (VSS), lo que le permite realizar backups activos sin tener que crear ningún script. La opción de imagen RMAN, con un enfoque de volcado y barrido, ofrece las mejores velocidades de recuperación.
SQL Server
El comando de backup de la base de datos puede automatizar backups completos, o incrementales, de la base de datos o sus registros de transacciones en el disco (para un volcado y barrido), en Azure (para el backup en la nube) o para transmitirlos directamente a una herramienta de backup de terceros. Al igual que Oracle, también se puede realizar un backup de SQL Server en caliente mediante VSS en Windows. El método VSS se integra más fácilmente en los backups de máquinas virtuales y no requiere un área de preparación del disco. El método que la mayoría de los DBA parecen preferir es el enfoque de volcado y barrido.
DB2
El comando de base de datos de backup se puede utilizar para realizar backups completos, o incrementales, de la totalidad o parte de una base de datos DB2 y sus registros de transacciones en el disco para un volcado y barrido, o transmitirlos directamente a una herramienta de backup de terceros. El comando también soporta un indicador de imagen instantánea, que se integra con los dispositivos de almacenamiento, y se puede utilizar para crear una imagen instantánea coherente con la aplicación de una base de datos. Al igual que otras imágenes instantáneas, debe replicar dicha imagen en otro lugar, una vez que se crea. Proporciona una gran velocidad de recuperación con poco esfuerzo inicial.
MySQL
Lo primero que debe hacer con MySQL es dejar de usar tablas MyISAM y obtener todos los datos importantes en un tipo de tabla más moderno, como InnoDB. Los clientes de MySQL Enterprise Edition pueden usar la función Enterprise Backup, que les permite colocar la base de datos en un modo de backup activo antes de realizar el backup de sus archivos de datos (como Oracle). El comando mysqldump es más universal y está disponible para todos los clientes, pero es bastante lento para bases de datos grandes. De todos modos, es la mejor manera de hacerlo si no tiene acceso a la función Enterprise Backup.
PostgreSQL
El método habitual con PostgreSQL es el comando pg_dump, que crea un volcado de SQL completo en el disco para una configuración de volcado y barrido, pero solo puede recuperarse cuando realizó el backup. Si desea un objetivo de punto de recuperación (RPO, por sus siglas en inglés) más estricto que su frecuencia pg_dump, debe habilitar el registro de escritura anticipada continua (WAL, por sus siglas en inglés), luego poner la base de datos dentro y fuera del modo de backup en caliente usando pg_start_backup y pg_stop_backup antes y después de un backup del sistema de archivos. Durante una recuperación, comienza restaurando el sistema de archivos, luego usa los archivos WAL para reproducir las transacciones que ocurrieron después del backup. Esta opción es eficiente y refleja las estrictas opciones de recuperación de RPO de las bases de datos más costosas.
MongoDB
Si utiliza MongoDB Atlas (la versión PaaS del producto), el mejor método de backup sería un backup continuo en la nube con recuperación puntual. Usted especifica qué tan atrás desea poder recuperarse, y Atlas realiza automáticamente los backups que necesita para poder restaurar su clúster, a cualquier punto en el tiempo, dentro de la ventana que especificó. Si aloja su propia instalación de MongoDB, puede usar MongoDB Cloud Manager (SaaS) u Ops Manager (software on premises). Cloud Manager soporta varios SLA a diferentes precios y parece la opción obvia si no está utilizando Atlas. Si está ejecutando MongoDB 4.2 o superior, también puede hacer un backup del sistema de archivos subyacente mientras se ejecuta mongod, y MongoDB detectará las claves "sucias” después de una restauración y las corregirá. La opción mongodump también está disponible para usar en forma de volcado y barrido, pero solo se recomienda para implementaciones pequeñas, porque mongodump no puede garantizar la atomicidad de las transacciones entre fragmentos.
Cassandra
Sus opciones de backup con Cassandra varían ampliamente en función de si está utilizando la versión de código abierto, la versión Enterprise o Astra (PaaS). Recuerde no confundir la resiliencia de Cassandra con backup; la resiliencia no le protegerá si alguien accidentalmente deja caer o trunca una tabla. La herramienta típica de backup en Cassandra se llama nodetool snapshot, que es un sistema similar a una imagen instantánea que crea una copia, completamente separada de todos los datos, de todos o ciertos espacios de claves o tablas usando enlaces físicos. Puede crear un backup completo o incremental. Esta copia luego se puede usar en una configuración de ajuste y barrido para obtener estos datos en otro lugar. Los clientes que ejecutan cualquier versión de Cassandra, en un proveedor de la nube, pueden crear una imagen instantánea en la nube de todo su clúster a la vez. Esto proporciona opciones de restauración mucho mejores que las que se pueden hacer con el comando de nodetool snapshot. Datastax también tiene una oferta para usuarios empresariales, llamada DSE Backup and Restore Service, diseñada para backups y restauración de todo el clúster. Los clientes de Datastax Astra reciben un backup automático cada cuatro horas.
Backup de DynamoDB
Dado que DynamoDB solo se ofrece como un servicio de AWS, las opciones de backup son relativamente sencillas. AWS proporciona backups automatizados que soportan la recuperación, en un momento dado, de la totalidad o parte de su tabla en DynamoDB. Todo lo que tiene que hacer es habilitar la recuperación en un momento dado y AWS administrará todo por usted. AWS también ofrece backups bajo demanda que puede controlar, pero no ofrecen restauración en un momento dado.
Recuerde: independientemente del método que elija, pruebe las recuperaciones utilizando su método de backup. A nadie le importa si puede hacer un backup; solo les importa si usted puede restaurar.
Basado en el artículo de W. Curtis Preston (Network World) y editado por CIO Perú