Los sistemas de bases de datos tienen la responsabilidad de almacenar y garantizar la disponibilidad constante de datos relevantes siempre que se necesiten y en cualquier momento de la operación. La mayoría de las empresas no logran continuar con el negocio después de casos de pérdida de datos como resultado de una falla de la base de datos, un puente de seguridad, un error humano o una falla catastrófica que puede destruir por completo los nodos operativos en producción. Mantener las bases de datos en el mismo centro de datos lo pone a uno en alto riesgo de perder todos los datos en caso de estos ultrajes.
La replicación y la copia de seguridad son las formas comúnmente utilizadas para garantizar una alta disponibilidad de datos. La selección entre los dos depende de la frecuencia con la que cambian los datos. La copia de seguridad es preferible cuando los datos no cambian con más frecuencia y no se espera tener tantos archivos de copia de seguridad. Por otro lado, se prefiere la replicación para datos que cambian con frecuencia, además de otros méritos asociados, como servir datos en una ubicación específica al reducir la latencia de las solicitudes. Sin embargo, tanto la replicación como la copia de seguridad se pueden utilizar para lograr la máxima integridad y consistencia de los datos durante la restauración en caso de falla.
Las copias de seguridad de la base de datos brindan más ventajas además de proporcionar un punto de restauración para proporcionar los elementos básicos para crear nuevos entornos para el desarrollo, el acceso abierto y la puesta en escena sin alterar la producción. El equipo de desarrollo puede probar rápida y fácilmente las nuevas funciones integradas y acelerar su desarrollo. Las copias de seguridad también se pueden usar para el punto de control de errores de código donde los datos resultantes no sean consistentes.
Consideraciones para realizar copias de seguridad de MongoDB
Las copias de seguridad se crean en ciertos puntos para reflejar (actuando como una instantánea de la base de datos) qué datos alberga la base de datos en ese momento dado. Si la base de datos falla en un punto dado, podemos usar el último archivo de copia de seguridad para revertir la base de datos a un punto antes de que fallara. Sin embargo, uno debe tener en cuenta algunos factores antes de realizar una recuperación y estos incluyen:
- Objetivo de punto de recuperación
- Objetivo de tiempo de recuperación
- Aislamiento de base de datos e instantáneas
- Complicaciones con Sharding
- Proceso de restauración
- Factores de rendimiento y almacenamiento disponible
- Flexibilidad
- Complejidad de implementación
Objetivo de punto de recuperación
Esto se lleva a cabo para determinar cuántos datos está dispuesto a perder durante el proceso de copia de seguridad y restauración. Por ejemplo, si tenemos datos de usuario y datos de flujo de clics, los datos de usuario tendrán prioridad sobre el análisis de flujo de clics, ya que este último se puede regenerar al monitorear las operaciones en su aplicación después de la restauración. Se debe preferir una copia de seguridad continua para datos críticos, como información bancaria, datos de la industria de producción e información de sistemas de comunicación, y se debe realizar en intervalos cortos. Si los datos no cambian con frecuencia, puede resultar menos costoso perder gran parte de ellos si realiza una instantánea restaurada de, por ejemplo, 6 meses o 1 año antes.
Objetivo de tiempo de recuperación
Esto es para analizar y determinar qué tan rápido se puede realizar la operación de restauración. Durante la recuperación, sus aplicaciones incurrirán en un tiempo de inactividad que también es directamente proporcional a la cantidad de datos que deben recuperarse. Si está restaurando un gran conjunto de datos, llevará más tiempo.
Aislamiento de base de datos e instantáneas
El aislamiento es una medida de qué tan cerca están las instantáneas de respaldo de los servidores de base de datos primarios en términos de configuración lógica y físicamente. Si están lo suficientemente cerca, el tiempo de recuperación se reduce a expensas de una mayor probabilidad de que se destruyan al mismo tiempo que se destruye la base de datos. No es aconsejable alojar las copias de seguridad y el entorno de producción en el mismo sistema para evitar que cualquier interrupción en los servidores mitigue también las copias de seguridad.
Complicaciones con fragmentación
Para un sistema de base de datos distribuido mediante fragmentación, se presenta cierta complejidad de copia de seguridad y es posible que las actividades de escritura deban pausarse en todo el sistema. Diferentes fragmentos terminarán diferentes tipos de copias de seguridad en diferentes momentos. Teniendo en cuenta las copias de seguridad lógicas y las copias de seguridad de instantáneas,
Copias de seguridad lógicas
- Los fragmentos son de diferentes tamaños, por lo tanto, terminarán en diferentes momentos
- Los volcados basados en MongoDB ignorarán --oplog, por lo tanto, no serán consistentes en cada fragmento.
- El equilibrador podría estar apagado cuando se supone que debe estar encendido solo porque algunos fragmentos tal vez no hayan terminado el proceso de restauración
Copias de seguridad instantáneas
- Funciona bien para una única réplica de las versiones 3.2 y posteriores. Por lo tanto, debería considerar actualizar su versión de MongoDB.
Proceso de restauración
Algunas personas realizan copias de seguridad sin probar si funcionarán en caso de restauración. En esencia, una copia de seguridad es proporcionar una capacidad de restauración, de lo contrario, será inútil. Siempre debe intentar ejecutar las copias de seguridad en diferentes servidores de prueba para ver si funcionan.
Factores de rendimiento y almacenamiento disponible
Las copias de seguridad también tienden a tener muchos tamaños como los datos de la propia base de datos y deben comprimirse lo suficiente para no ocupar mucho espacio innecesario que puede reducir los recursos de almacenamiento generales del sistema. Se pueden archivar en archivos zip, lo que reduce su tamaño total. Además, como se mencionó anteriormente, uno puede archivar las copias de seguridad en diferentes centros de datos desde la propia base de datos.
Las copias de seguridad pueden determinar diferentes rendimientos de la base de datos, ya que algunas podrían degradarla. En ese caso, las copias de seguridad continuas generarán algunos inconvenientes, por lo que deben convertirse en copias de seguridad programadas para evitar el agotamiento de las ventanas de mantenimiento. En la mayoría de los casos, los servidores secundarios se implementan para respaldar las copias de seguridad. En este caso:
- No se pueden realizar copias de seguridad de nodos individuales de manera consistente porque MongoDB usa lectura no confirmada sin un registro de operaciones cuando se usa el comando mongodump y, en ese caso, las copias de seguridad no serán seguras.
- Utilice nodos secundarios para las copias de seguridad, ya que el proceso en sí toma tiempo de acuerdo con la cantidad de datos involucrados y las aplicaciones conectadas sufrirán algún tiempo de inactividad. Si usa el principal que también tiene que actualizar los Oplogs, entonces puede perder algunos datos durante ese tiempo de inactividad
- El proceso de restauración lleva mucho tiempo, pero los recursos de almacenamiento asignados son pequeños.
Flexibilidad
Muchas veces es posible que no desee algunos de los datos durante la copia de seguridad, como en el ejemplo del objetivo del punto de recuperación, es posible que desee realizar la recuperación y filtrar los datos de los clics del usuario. Para hacerlo, necesita una estrategia de copia de seguridad parcial que le brinde la flexibilidad para filtrar los datos que no le interesarán y, por lo tanto, reducir la duración de la recuperación y los recursos que se habrían desperdiciado. La copia de seguridad incremental también puede ser útil, ya que solo se realizará una copia de seguridad de las partes de datos que han cambiado desde la última instantánea en lugar de realizar copias de seguridad completas para cada instantánea.
Complejidad de implementación
Su estrategia de respaldo debe ser fácil de configurar y mantener con el tiempo. También puede programar sus copias de seguridad para que no tenga que hacerlas manualmente cuando lo desee.
Conclusión
Los sistemas de bases de datos garantizan la "vida después de la muerte" si solo existe un sistema de respaldo bien establecido. La base de datos podría ser destruida por factores catastróficos, errores humanos o ataques de seguridad que pueden provocar la pérdida o corrupción de los datos. Antes de hacer una copia de seguridad, se debe considerar el tipo de datos en términos de tamaño e importancia. No siempre es recomendable mantener sus copias de seguridad en el mismo centro de datos que su base de datos para reducir la probabilidad de que las copias de seguridad se destruyan simultáneamente. Las copias de seguridad pueden alterar el rendimiento de la base de datos, por lo que se debe tener cuidado con la estrategia a utilizar y cuándo realizar la copia de seguridad. No realice sus copias de seguridad en el nodo principal, ya que puede provocar un tiempo de inactividad del sistema durante la copia de seguridad y, en consecuencia, la pérdida de datos importantes.
