Dbvisit

DISASTER RECOVERY

ORACLE, SQL Server & PostgreSQL

DBvist Standby MultiPlatform

Es un software de recuperación ante desastres (DR) de clase empresarial para ORACLE y Microsoft SQL Server y PostgreSQL que prioriza:

Todo desde una única interfaz de usuario común.

Disponible en las instalaciones (on-premise), en la nube o híbrido.

Dbvisit Datasheet PDF

Especificaciones Técnicas PDF

COMPARATIVO DE SOLUCIONES DE RECUPERACIÓN ANTE DESASTRES

Dbvisit Standby vs. Veeam

Dbvisit VS VEEAM

Dbvisit StandbyMP y Veeam son soluciones de reconocido prestigio en el campo de la recuperación ante desastres, que ofrecen opciones robustas para entornos en Base de Datos Oracle o en Microsoft SQL Server.

Mientras que Veeam se centra principalmente en proporcionar servicios de backup para varios tipos de datos, incluidos archivos, bases de datos y aplicaciones, Dbvisit StandbyMP se especializa en la funcionalidad de espera semiactiva o Standby, diseñada específicamente  para bases de datos críticas para el negocio.

 Backup vs Standby

Si bien una estrategia de copia de seguridad es una parte esencial de la mitigación de riesgos, por sí sola no proporciona capacidades adecuadas de recuperación ante desastres para las bases de datos críticas para el negocio. La recuperación ante desastres debe permitir a las empresas recuperarse rápidamente con integridad garantizada de la base de datos, para todos los escenarios de desastre.  Para lograr esto, Dbvisit StandbyMP va más allá de las copias de seguridad tradicionales, al ofrecer funcionalidad de espera semiactiva o Warm Standby, lo que garantiza una base de datos en espera lista para ser activada que contiene una copia verificada de la base de datos principal.

Por el contrario, el enfoque de backup de Veeam (replicación a nivel de bloque) carece de la capacidad de proporcionar una base de datos en espera transaccionalmente consistente y disponible al instante.

La importancia del reconocimiento de la base de datos y la integridad transaccional

La arquitectura de Dbvisit StandbyMP incluye el reconocimiento de la base de datos y se centra en la integridad transaccional. Al mantener una comprensión del estado de la base de datos y replicar activamente las transacciones, Dbvisit StandbyMP garantiza la coherencia de los datos y evita la corrupción de la base de datos en espera.

Veeam, por otro lado, se basa en un proceso a nivel de sistema y no tiene conocimiento directo de la base de datos. Este enfoque replica el estado de la base de datos basándose únicamente en los archivos de datos escritos en el disco, lo que aumenta el riesgo de incoherencias de datos y estados, lo que puede provocar daños en la base de datos.

Menor uso de la red, menos datos pesados

Dbvisit StandbyMP utiliza un mecanismo de replicación y compresión eficientes que minimizan el uso de la red. Emplea un método de replicación basado en registros, que solo transfiere los cambios (registros) realizados en la base de datos principal al modo de espera o Standby, lo que reduce significativamente la sobrecarga de la red. 

Veeam, por el contrario, se basa en la replicación a nivel de bloque, lo que significa que incluso un pequeño cambio de 1 byte puede dar lugar a una gran cantidad de datos que necesitan ser copiados a través de la red. Esto puede ser particularmente perjudicial en entornos híbridos donde los costos de transferencia de datos son una preocupación, como en las implementaciones en la nube.

Además, el enfoque de Veeam puede imponer una carga significativa en la base de datos primaria, lo que podría afectar su rendimiento. Por el contrario, el software específico de base de datos enfocado de Dbvisit Standby garantiza un menor uso y un rendimiento optimizado de la base de datos primaria, lo que la convierte en una opción ideal para organizaciones donde el rendimiento de la base de datos primaria es crítico. 

fácil Administración

Dbvisit Standby simplifica la administración a través de flujos de trabajo intuitivos y una presentación clara de la información. La interfaz permite a los usuarios supervisar fácilmente el estado de cada base de datos e instancia en espera. Los administradores pueden realizar acciones de línea de comandos o con un solo clic directamente en bases de datos individuales o en varias bases de datos en todas las instancias, lo que agiliza los procesos de administración. Este nivel de visibilidad y control permite un manejo eficiente de los problemas específicos de la base de datos y respuestas rápidas a cualquier problema potencial.

Por el contrario, Veeam se basa en un enfoque único de "caja" (VM) que contiene todos los componentes, incluida la base de datos. Si bien es técnicamente posible separar la base de datos del resto del sistema virtualizado, hacerlo presenta complejidades y desafíos. La administración de problemas individuales de bases de datos se vuelve más difícil dentro de este entorno consolidado. La necesidad de abordar las preocupaciones específicas de la base de datos y realizar acciones específicas no es tan sencilla como con la interfaz dedicada y fácil de usar de Dbvisit Standby.

fácil Implementación

Dbvisit StandbyMP ofrece una experiencia de implementación sin complicaciones, con el software funcionando de forma inmediata (no se necesitan cambios en la arquitectura) en el 98% de las implementaciones de los clientes. Este proceso de implementación optimizado minimiza la necesidad de modificaciones o actualizaciones extensas del sistema, lo que garantiza una implementación rápida y eficiente

Por el contrario, la implementación de Veeam a menudo requiere cambios sustanciales y actualizaciones en los sistemas existentes para soportar el software, lo que puede prolongar la línea de tiempo de implementación e introducir complejidades adicionales.

Soporte de base de datos especializada

Dbvisit StandbyMP se distingue por proporcionar soporte especializado de primera línea centrado exclusivamente en la recuperación ante desastres de bases de datos. El equipo de soporte de Dbvisit está formado por administradores de bases de datos (DBA), con amplia experiencia trabajando en entornos de bases de datos del mundo real. Dbvisit StandbyMP cuenta con una tasa de satisfacción de soporte del 100% para el año 2023 e impresionante tiempo de respuesta de tickets de alta prioridad de 7 minutos. Este nivel de soporte garantiza que los clientes tengan acceso a recursos bien informados cuando los necesiten.

Por otro lado, el soporte de Veeam está diseñado para atender a una gama más amplia de tipos de datos, incluidos archivos, bases de datos y aplicaciones. Si bien proporcionan soporte general para backup y recuperación, carecen del soporte especializado centrado en bases de datos que ofrece Dbvisit. 

Conclusión

En conclusión, al comparar Dbvisit StandbyMP y Veeam para Disaster Recovery, surgen varias diferencias clave. La funcionalidad de espera activa de Dbvisit StandbyMP, la replicación transaccional y compatible con la base de datos, el menor uso de la red, la administración optimizada, la implementación más fácil y el soporte especializado de bases de datos lo convierten en la mejor opción para las organizaciones que buscan una solución de recuperación ante desastres robusta y eficiente.

Al elegir Dbvisit StandbyMP, las organizaciones pueden garantizar una recuperación rápida, integridad de datos y un rendimiento óptimo para sus bases de datos críticas de ORACLE o Ms SQL Server, minimizando en última instancia el tiempo de inactividad y protegiendo sus operaciones comerciales.

¿Copia en Bloque o 

Replicación?

La gente a menudo pregunta sobre las diferencias entre la copia en bloque y la replicación. Adjuntamos un gran vídeo sobre la copia en bloque frente al envío de registros. El vídeo es corto y sencillo. Si bien no cubre todos los detalles minuciosos de la copia de bloques, sí destaca algunas de las diferencias muy importantes entre estos dos métodos diferentes de recuperación ante desastres.

El vídeo comienza destacando que los cambios realizados en la base de datos principal se cambian en varias áreas. Cuando un usuario actualiza los datos en la base de datos de en SQL Server o en Oracle. En Oracle esos cambios de datos se realizan en los archivos de datos reales, para deshacer los archivos de datos de tablespace y en los registros de rehacer de Oracle.

Sí, Oracle en realidad cambia de bloque en tres lugares diferentes. Eventualmente, esos cambios en los REDO LOGS se copian en un registro de archivo. Esos mismos datos residen en cuatro lugares diferentes.

Oracle hace esto porque perder datos es terriblemente malo y Oracle quiere asegurarse de que puedas recuperarte de los bloqueos. Los REDO LOGS se llaman así porque pueden "rehacer" los datos si hay un problema.

La copia en bloque a menudo se considera "similar a un zombi". No sabe la diferencia y copia todos los cambios realizados. Esto puede dar lugar a que los datos se transfieran 3-4 veces desde el sitio principal al sitio de espera. Contraste esto con el método de LOG SHIPPING. Solo se envían los ARCHIVE LOGS. Todos los cambios en la base de datos terminan en los ARCHIVE LOGS, por lo que no hay necesidad de enviar cambios redundantes. Esto significa que en lugares con ancho de banda restringido o bases de datos que son extremadamente grandes, puede ahorrar costos de red considerables.

Estos métodos de copia de bloques son a menudo una solución de "todo o nada". El peligro radica en el hecho de que si hubiera una corrupción de los datos en el sitio primario, eso se transferiría directamente al sitio secundario. Esto sería tanto por corrupción lógica de los datos como por corrupción física por fallos de hardware. Con el método LOG SHIPPING, puede hacer que la base de datos en STANDBY esté en un "tiempo configurado" detrás de la principal. Podrías construir un retraso de 2-3 horas si esa es la preferencia. Esto a menudo te daría tiempo para detener cualquier corrupción lógica antes de que llegara al sitio secundario.

La corrupción física a menudo se detiene en su camino, ya que cuando los registros se envían al sitio secundario, el software de Oracle se asegura de que los registros de archivo no estén dañados antes de que se apliquen a la base de datos de espera, lo que garantiza que ninguna corrupción física se extienda desde el sitio principal hasta el sitio de espera.

Los métodos de copia en bloque a menudo requieren una red de área de almacenamiento (SAN). El LOG SHIPPING no requiere una SAN en ninguno de los dos lados y a menudo puede usar una amplia variedad de dispositivos de almacenamiento. Las SAN también pueden ser muy caras, mientras que el LOG SHIPPING suele tener varias opciones. Al igual que una SAN, todo el mecanismo de copia en bloque puede ser un producto de software muy caro. Muchas herramientas de copia en bloque no son necesariamente compatibles con todos los diferentes proveedores de la nube disponibles en la actualidad.

Los métodos de envío de registros o LOG SHIPPING ofrecen opciones en sitio, híbridas o en la nube. Y tal vez la última "mejor" razón por la que el LOG SHIPPING es superior a la copia en bloque es que el método de LOG SHIPPING es el mismo que utilizan los propios proveedores. Oracle utiliza el LOG SHIPPING para su producto integrado Oracle Data Guard para la recuperación ante desastres. Estos productos se construyen pensando en Oracle y en LOGS, en lugar de solo una herramienta de copia de zombis.

https://dbvisit.com/blog/block-or-not

DBVISIT_StandbyMP_Datasheet_ES_1-02.pdf
Disaster Recovery Infographic
DBVisit_StandbyMP_TechnicalFeatures_ES_1-02.pdf