Google Cloud Backup: la guía completa sobre BaaS

Cómo identificar a un proveedor que no haya desarrollado realmente su solución para GCP

Se puede saber si un proveedor de copias de seguridad ha desarrollado realmente su solución para Google Cloud por lo que pregunta en la primera llamada comercial. Si sus primeras preguntas son «¿cuántos servidores de copia de seguridad necesita?» o «¿cuál es su capacidad máxima en terabytes?», es que no han desarrollado su solución para Google Cloud. Han creado un dispositivo fijo y lo han trasladado a GCP.

Este patrón se repite con tanta frecuencia que ahora lo utilizo como criterio de diagnóstico. Las preguntas que formula un proveedor revelan la arquitectura que ofrece. Las arquitecturas nativas de la nube no requieren esas respuestas. Los dispositivos alojados en la nube sí las requieren.

Este artículo analiza lo que debe ofrecer un verdadero BaaS para Google Cloud, las preguntas adecuadas para evaluar a los proveedores y qué cubren las funciones nativas de GCP frente a las carencias que presentan. 

Por qué las funciones integradas de Google Cloud no constituyen una estrategia

Google proporciona primitivas de protección útiles: instantáneas de Persistent Disk, copias de seguridad automatizadas de Cloud SQL, control de versiones de objetos de GCS e instantáneas de tablas de BigQuery. Sin embargo, no constituyen una estrategia de copias de seguridad. 

El modelo de responsabilidad compartida de GCP es explícito. Google se encarga de la seguridad y la disponibilidad de la infraestructura. El cliente se encarga de los datos. Si un administrador elimina un proyecto, un ransomware cifra un Persistent Disk, un error de configuración borra los datos de Cloud SQL o un desarrollador elimina por error una tabla de BigQuery, Google aplicará diligentemente dicha acción. La recuperación es responsabilidad del cliente.

Hay cuatro lagunas que las funciones nativas no cubren: la retención independiente, para que las copias de seguridad se mantengan incluso si se elimina la carga de trabajo de origen; la consistencia de la aplicación, para que las bases de datos y las aplicaciones se recuperen correctamente, y no solo de forma consistente ante fallos; Aislamiento entre regiones y entre proyectos, para que una vulnerabilidad en una ubicación no anule la protección. Y recuperación granular, para que se pueda restaurar un único archivo, una tabla o una máquina virtual sin tener que reconstruirlo todo.

Qué significa realmente una cobertura completa de GCP

Un proveedor que solo protege las máquinas virtuales de Compute Engine está vendiendo copias de seguridad en la nube de 2018. Un verdadero BaaS protege todas las clases de cargas de trabajo a través de un único plano de gestión.

Las preguntas adecuadas que debe plantear a cualquier proveedor de copias de seguridad de GCP

Cinco preguntas que ponen de manifiesto la diferencia entre la arquitectura nativa de la nube y los dispositivos alojados en la nube.

¿Puede la solución escalar de forma elástica con Google Cloud? La respuesta correcta es sí, a través de políticas de copia de seguridad y buckets de Cloud Storage, sin necesidad de aprovisionar nodos ni prever la capacidad. Si mañana añade un nuevo proyecto de GCP, la protección debería activarse automáticamente sin intervención operativa.

¿En qué medida es nativa e integrada la solución? Tres pruebas concretas. En primer lugar, IAM. ¿Se autentica el servicio a través de Google Cloud IAM, heredando los permisos existentes y la estructura del proyecto? En segundo lugar, la interfaz de la API. ¿Funciona el servicio a través de las API de Google Cloud, de modo que los datos nunca salgan de los límites de GCP? En tercer lugar, la facturación. ¿Se puede adquirir a través de Google Cloud Marketplace y se facturan los cargos a través del sistema de facturación existente de GCP? 

¿Es compatible con Cloud SQL, BigQuery, GKE y SAP HANA, y no solo con Compute Engine? Las copias de seguridad exclusivas para máquinas virtuales dejan fuera la mayor parte de lo que se ejecuta en los entornos modernos de GCP. Solicite detalles específicos sobre cada clase de carga de trabajo. Las respuestas genéricas implican una protección genérica. 

¿Cómo funciona la recuperación entre regiones y entre proyectos? Las cargas de trabajo se expanden hasta convertirse en implementaciones multirregionales y multiproyecto. El mecanismo de copia de seguridad que funcionaba en un único proyecto falla en los límites. Pida al proveedor que le explique paso a paso una restauración que abarque ambos ámbitos.

¿Cómo se adapta el precio a medida que crece el entorno? Busque un modelo económico de «pago por lo que se protege» basado en los datos de origen realmente copiados, no en la capacidad máxima reservada.

Tres pilares: copia de seguridad, migración y recuperación ante desastres

El BaaS para Google Cloud opera en tres casos de uso estrechamente relacionados. Las soluciones sólidas gestionan los tres a través de una única plataforma, un único marco de políticas y un único modelo de recuperación.

La copia de seguridad en sí misma. Copia de seguridad y recuperación coherentes con la aplicación para cada clase de carga de trabajo, utilizando instantáneas nativas de Google Cloud como primer nivel de protección y Google Cloud Storage para la retención a largo plazo. La estrecha integración con la plataforma supone un impacto prácticamente nulo en el rendimiento de producción. 

Migración a GCP y dentro de GCP. El mismo mecanismo de copia de seguridad sirve también como mecanismo de migración. Traslade las cargas de trabajo de producción desde instalaciones locales, desde otra nube o de una región de GCP a otra, utilizando los datos de copia de seguridad existentes como fuente de migración. La coherencia de la aplicación se mantiene durante el traslado. 

Recuperación ante desastres mediante GCP. Google Cloud como destino de recuperación ante desastres (DR) para cargas de trabajo locales o de otras nubes. El modelo económico es fundamental. Almacene copias de seguridad de forma continua en GCP a bajo coste, pero solo consuma recursos de computación y almacenamiento de alto rendimiento cuando se declare efectivamente la recuperación ante desastres. La mayor parte del año pagará únicamente por el almacenamiento. En los contados casos en que se produzca un desastre, se paga por la capacidad de computación. Esto supone una fracción del coste de una recuperación ante desastres siempre activa.

Cómo funciona realmente el «lift-and-shift» de GCP con datos de copia de seguridad

El flujo técnico consta de cuatro pasos a la hora de migrar cargas de trabajo de Compute Engine desde un entorno local. 

Recupere la imagen del disco de la máquina virtual de producción a partir de la copia de seguridad existente. Exporte a un destino SMB o NFS accesible desde la estación de trabajo de migración.

Instale el SDK de Google Cloud en la estación de trabajo. 

Cree un depósito de Cloud Storage en el proyecto de destino y cargue los archivos de disco de la máquina virtual.

Importe los discos como imágenes personalizadas de Compute Engine mediante el comando «gcloud compute images import», especificando el depósito de origen y el sistema operativo.

Una vez que la imagen personalizada existe, las nuevas instancias de Compute Engine se inician directamente a partir de ella. Este mismo patrón sirve para la migración entre regiones dentro de GCP y para la migración desde otras nubes.

Preguntas frecuentes sobre las copias de seguridad en GCP

¿Puedo confiar únicamente en las funciones integradas de Google Cloud?

No. Las funciones integradas son herramientas básicas útiles, pero carecen de retención independiente, consistencia de aplicaciones en cargas de trabajo con múltiples recursos, aislamiento entre proyectos y recuperación granular para muchos tipos de cargas de trabajo. El verdadero BaaS se superpone a las funciones integradas.

¿Cómo puedo recuperar los datos tras un borrado accidental o un ataque de ransomware? 

Restaure los datos a cualquier punto en el tiempo conservado, incluso tras un borrado o un cifrado. Las opciones de recuperación abarcan desde un único archivo dentro de una máquina virtual, una única tabla en BigQuery o un único espacio de nombres en GKE, hasta la restauración completa de una máquina virtual o de todo un proyecto, ya sea en la región original o en otra diferente. La retención es independiente de la carga de trabajo de origen. 

¿Es seguro y cumple con la normativa el BaaS de GCP?

Cifrado en tránsito y en reposo, integración con Google Cloud IAM y certificaciones según SOC 2, HIPAA y el RGPD. Gracias a su arquitectura nativa de la nube, los datos de copia de seguridad permanecen dentro de los límites de GCP en todo momento. 

¿Funciona el BaaS con SAP HANA, GKE y BigQuery?

Debería hacerlo. SAP HANA requiere una copia de seguridad sensible a la aplicación integrada con la gestión de registros de HANA. GKE necesita granularidad a nivel de contenedor, volumen persistente y espacio de nombres. BigQuery requiere copias de seguridad a nivel de conjunto de datos y de tabla. Un proveedor que solo gestione máquinas virtuales de Compute Engine se está perdiendo la mayor parte de lo que se ejecuta en el GCP moderno.

Pruébelo en su entorno

HYCU R-Cloud para Google Cloud está disponible directamente en Google Cloud Marketplace. La versión de prueba utiliza su cuenta real de GCP, sus cargas de trabajo reales y sus datos reales. Puede tenerla en funcionamiento en 15 minutos. La mayoría de los equipos saben en pocos días si les conviene. El enlace a la versión de prueba se encuentra en hycu.com/trial.