Backup en Salesforce: Opciones disponibles y Alternativas

En este artículo, se enumeran los mecanismos nativos en Salesforce para la realización del Backup de datos, y su recuperación. También se analizan los puntos débiles de estas mecanismos ante los casos de uso más habituales de pérdida de datos.

58% of downtime incidents are caused by human error alone (Boston Computing Network)

Every Minute 3,535 data Records are lost (breachlevelindex)

Finalmente se concluye el estado actual y las alternativas dependiendo del tipo de proyecto que abordemos.

No es objetivo de este artículo, el definir como debe ser un Plan de Contingencia o Disaster Recovery, ni sus procedimientos asociados.

The average cost of downtime per hour is $25,000 to $50,000+ (Advertorial Infographic: Why Disaster Recovery in the Cloud Should Be in Your Plans, International Data Group, 2015)

Qué ofrece Salesforce

Salesforce ofrece los siguientes mecanismos, por los que podemos generar un Backup para recuperar/paliar una pérdida de datos:

1. Papelera de reciclaje
2. Data Export (lo más parecido al concepto tradicional de Backup)
3. Extracciones selectivas de datos :
   1. Data loader típicamente,
   2. Via Heroku Connect a una BD de Postgress
   3. Exportación manual de Reports
   4. Acceso via herramientas ETL para extracción mediante APIs
4. Creación entorno de Full Sandbox
5. Salesforce Data Recovery Service (servicio on Demand)

Adicionalmente, a veces también se nombra como mecanismo de salvaguarda, la replicación de Salesforce a Salesforce, pero que no se aborda en este artículo por tener una naturaleza completamente distinta a los enfoques de Backup/Restore.

Veremos cada uno de ellos respecto a los casos de pérdida habitual:

1. Cambio indeseado: usuario modifica registro/s y requiere deshacer el cambio inmediatamente
2. Eliminación equívoca: usuario elimina registro/s y requiere recuperación de esos registros
3. Modificación/borrado masivo: carga incorrecta o eliminación de una gran cantidad de registros (ej.: migración de datos interrumpida o errónea)
4. Desastre: Ataque interno/externo con pérdida total de datos. Este caso solo sería posible bajo un ataque simultáneo a las 2 instalaciones de Salesforce, que son utilizadas cuando modificamos datos en nuestras ORGs.

Papelera de reciclaje

Es la primera linea de defensa, accesible por el usuario del sistema. Como cubre los casos de uso anteriores:

1. Cambio indeseado: no cubre este caso, no permite el deshacer de cambios
2. Eliminación equívoca: el registro es recuperable, siempre que no se haya sobrepasado la capacidad máxima de la papelera y el período de purgado (15 días),  y no se haya realizado un Purge explícito
3. Modificación/borrado masivo: no cubre este caso
4. Desastre: no cubre este caso

La capacidad de la papelera depende del Data Storage de la ORG. Se calcula tal que:

• El número de registros preservados es  25x el Storage en MB, es decir, si nuestra ORG posee 1024 MB de Data Storage (1 GB), la papelera de reciclaje puede albergar como máximo 25600 registros eliminados
• El Storage ocupado por la papelera no computa contra el Storage contratado

Data Export

Esta es la funcionalidad que más se acerca al concepto de Backup, usado tradicionalmente, y es el mecanismo mayoritariamente usado.

Solo en ORGs Productivas:

• con una frecuencia máxima de carácter semanal,
• puede programarse la generación de ficheros que contienen todos/algunos de los objetos, y adicionalmente los ficheros y otros contenidos asociados (no metadata).
• los ficheros generados, fruto de la exportación, están disponibles para descarga manual, durante 48h, pasadas las cuales  estos ficheros se eliminan, tanto si hubo descarga como si no.

En la siguiente captura puede observarse como es la programación de un Data Export:

Configuración Data Export en Salesforce, seleccionamos periodicidad y contenido a replicar

Por tanto, en relación a los casos de uso:

• Cambio indeseado: cubre este caso, solo si existe un Backup descargado que contenga los valores del registro (modificaciones durante la ventana semanal no están nunca disponibles).
• Eliminación equívoca: análogo al anterior
• Modificación/borrado masivo: análogo al anterior pero con alta complejidad, ya que deberá gestionarse la integridad referencial de la recuperación
• Desastre: análogo al anterior

Y aquí encontramos una debilidad fundamental, Salesforce NO contempla un mecanismo automatizado de Recovery de un Data Export.

Extracción selectiva de datos

Estos métodos de extracción tienen en común que:

• utilizan las diferentes APIs para extraer los datos que indiquemos
• su gran versatilidad, es a su vez, su gran punto débil, ya que la utilidad de los datos en un escenario de Restore, depende de las Queries montadas y  de robotización que hayamos realizado del proceso.

Por ejemplo, mediante el mecanismo de Data Loader:

• Debemos proporcionar un mecanismo automatizado para la exportación de los ficheros CSV (máx 5M de registros)
• Por tanto se requiere un planificador de tareas externos.
• Cada proceso de Data Loader solo puede extraer información de un único objeto
• Podemos configurar las condiciones de la extracción para conseguir, exportaciones parciales, totales, etc.
• Deben considerarse el impacto sobre los límites de la ORG al usar la API seleccionada y el impacto en el rendimiento
• El Restore/Recover de los datos es manual, por tanto, debe establecerse un canal de comunicación ágil entre los usuarios del sistema y los responsables del backup.
  • En empresas con procesos inter-departamentales pesados, la petición y la ejecución se dilatan en el tiempo el momento de crisis
• La integridad referencial debe conciliarse manualmente

Es un mecanismo que da respuesta a los casos de uso habituales, dependiendo de la definición realizada de las Queries. El mecanismo de Recover es manual y por tanto expuesto a errores manuales.

Utilización de un  Full Sandbox

La creación y refresco de un entorno Full Sandbox permite, la recreación completa de un entorno Productivo. Existen condicionantes importantes:

• Costes adicionales considerables
• Periodo de refresco 29 días

Por tanto, es un mecanismo de Backup/Restore poco adecuado a los casos de uso habituales, pero permite el Backup más completo en la plataforma Salesforce, pero con una frecuencia tan elevada que lo relega a ser un mecanismo de último recurso.

Salesforce Data Recovery Service (servicio On Demand)

Salesforce ofrece un servicio de recuperación de datos, con las siguientes características:

• Servicio con coste adicional 15.000 USD – 25.000 USD
• La recuperación de datos, puede ser de un momento indeterminado del tiempo, no se garantiza de cuando exactamente
• El servicio tiene un plazo de entrega de  la exportación de 3 semanas en el mejor de los casos
• Es responsabilidad del cliente realizar el Recover de los datos

Por tanto es un servicio, que puede estar incluido en un Plan de contingencia como último recurso, pero que no responde a los casos de uso .

Data Export en detalle

Finalmente,  veamos el mecanismo de Data Export en detalle, ya que es el mecanismo de Backup, que la mayoría de empresas consideran para sus proyectos.

Fortalezas

1. Nativo y sin costes
2. Poco intrusivo
3. Periodicidad parametrizable
4. Contenido parametrizable
5. Sin complicaciones técnicas
6. La descarga de los ficheros generados es simple (se generan ficheros de 512 MB comprimidos, que en su interior albergan ficheros .CSV, que gestionarse manualmente para ser utilizados)

Debilidades

1. La frecuencia máxima de realización de un Backup es semanal
2. No está disponible para entornos no Productivos
3. La descarga de los ficheros generados es manual y por tanto requiere de intervención  dedicada a esta tarea, sin valor añadido
4. La ventana de descarga se limita a 48 horas
5. Se requiere de infraestructura adicional de almacenamiento
6. Se requieren políticas de acceso a datos sensibles estricta (ver punto más adelante) ya que los datos son accesibles a cualquier persona que tenga acceso a la pantalla de Data Export, durante la ventana de descarga
   1. No existe encriptación de datos, por lo que asegurar la confidencialidad de los datos sensibles es costoso
7. Siempre se ejecuta un Full Backup, sin opción para  incrementales,
8. Provocado por el punto anterior, el consumo de recursos es inadecuado en ocasiones, donde sería necesario una estrategia de Full Backup
9. Durante su ejecución, no se registran los cambios producidos en los registros, y por lo tanto, si se producen escenarios de cambios fortuitos, su recuperación no es posible hasta 1 semana posterior
10. La ejecución depende de la ocupación de los recursos en  la  instancia y de la carga de la ORG, impidiendo asegurar las horas exactas y ejecución del Backup
11. Solo se realiza Backup de Datos y ficheros, no de la metadata en la ORG
12. No es una herramienta que cubra la fase de Recover de un Plan de Contingencia para proyectos medianos/grandes o críticos y por tanto, la integridad referencial está sujeta a errores

Y ¿qué deberíamos tener?

Además, en proyectos de carácter crítico existen ciertos requerimientos que considero necesarios que por supuesto no ofrece Data Export:

Funcionalidades deseadas para el Backup en Salesforce

1. Granularidad en la frecuencia de ejecución en minutos
2. Granularidad variable en función de la criticidad que asignemos al objeto (los objetos que no son críticos para negocio, pueden no requerir frecuencias elevadas)
3. Granularidad en función de la tasa de modificación (los objetos sujetos a mayor número de cambios, serán los que deba respaldar con más frecuencia)
4. Backup incremental o parcial
5. Backup de Datos y de Metadatos y de todos los objetos que conforman la ORG
6. Posibilidad para Marcar instantes en el tiempo donde puedan recuperarse tablas completas (Snapshots temporales) o sistema completo
   1. Caso de uso: Inicio migración de datos masiva
7. Posibilidad de escenarios híbridos de almacenamiento, es decir, almacenar Cloud y/o OnPremise
8. Encriptación de los datos por clave generada por ORG
9. Establecimiento de una Política de retención de los Backups (diaria, semanal, mensual, etc.)
10. Control de acceso a los Backups en Cloud mediante aprobación requerida basada en Workflow de autorización
11. Restauración selectiva de registros: accesible directamente al usuario final, sin necesidad de interacción de otros equipos
12. Recover masivo de registros con mantenimiento de integridad referencial
13. Recreación automática de tablas (UPSERT), permitiendo así la recreación de tablas maestras de datos (Protección contra escritura de Datos Maestros inmutables)
14. Visualización de los cambios sufridos por un registro y selección de los valores a recuperar (aka Time Machine)
15. Sistema de alarmas bajo ciertas situaciones (borrado masivo de registros, modificaciones masivas en ciertas entidades, etc.)

Conclusiones

La definición de un Plan de Contigencia / Disaster Recovery basado exclusivamente en la funcionalidad estándar de Salesforce, parece solo posible en proyectos pequeños sin datos críticos.

Además, esta definición se volverá ardua para asegurar la confidencialidad de los datos, evitar fugas de gran volumen y asegurar con garantías, que el dato no ha sido comprometido.

Actualmente, debemos considerar los servicios de terceras empresas, que mitigan los puntos débiles del Backup y ofrecen servicios enriquecidos, con funcionalidades de calidad del dato, introspección de datos, análisis de tendencias, etc.

Por tanto, IMHO, la opción realista para proyectos medianos-grandes y/o críticos, es considerar servicios de Backup disponibles por terceras empresas colaboradoras con Salesforce, que ofrecen las capacidades de Backup & Recovery enunciadas en este artículo y mitigan casi por completo todos los puntos débiles encontrados.

Opciones alternativas

De las más conocidas y enunciadas por Salesforce en documentos públicos:

• Heroku Connect
• Backupify
• Odaseva Backup
• OwnBackup
• CopyStorm
• DBAmp/Pro
• Code Backup/Compare Tool
• CloudAlly Backup
• Bluewolf Replicator
• etc.

No es intención publicar un listado completo, sino nombrar las más conocidas, para facilitar la búsqueda de información.

Espero que el artículo, siendo no tan técnico como el anterior, ayude a aquellos que se inicien en el tema.

Enlaces interesantes del artículo

• Serie de 4 artículos sobre Backup y Restore de Salesforce
• Backup & Restore Help & Training Article
• High Level Steps to Retrieve Deleted Data
• Data Recovery Service and Cost FAQ

Anuncio publicitario