¿Qué es un destino de copia de seguridad?

Un destino de copia de seguridad es el sistema de almacenamiento que recibe y conserva los datos generados por el software de copia de seguridad. Aplicaciones como Veeam, Commvault o Rubrik escriben los datos de backup en el destino y vuelven a leerlos durante una restauración. Por eso su capacidad, su rendimiento de lectura, su disponibilidad y sus controles de retención condicionan tanto el volumen de copias que puede conservarse como la rapidez con la que pueden restaurarse.

¿Qué hace realmente un destino de copia de seguridad?

Un destino de copia de seguridad se sitúa en el lado del almacenamiento del proceso de backup. Es la aplicación de copia de seguridad la que decide qué proteger, cuándo se ejecutan los trabajos y qué puntos de restauración están disponibles. El destino se encarga de almacenar los datos resultantes y de devolverlos cuando se solicita una restauración.

Esa distinción cobra importancia en el momento de la restauración. Que un trabajo de copia termine dentro de su ventana programada confirma que el destino admite datos al ritmo necesario. No demuestra que ese mismo sistema pueda devolver un volumen grande de datos con la rapidez suficiente durante una restauración masiva.

El rendimiento de lectura puede diferir bastante del de escritura según el diseño del almacenamiento. La deduplicación, la arquitectura de controladoras, el ancho de banda de red, las cargas de trabajo simultáneas y el número de nodos de almacenamiento implicados influyen todos en el rendimiento de restauración.

Por eso, evaluar un destino de copia de seguridad exige fijarse en el comportamiento en restauración tanto como en el rendimiento de ingesta.

¿Qué conviene evaluar en un destino de copia de seguridad?

Los requisitos varían según el entorno, pero varias características tienen un efecto directo en las operaciones de copia y restauración.

Rendimiento de restauración

El rendimiento de restauración mide la velocidad a la que los datos protegidos pueden leerse desde el destino de copia de seguridad y devolverse a los sistemas de producción.

Esto resulta especialmente importante en una recuperación tras un ransomware o ante un fallo grave de infraestructura, cuando decenas o cientos de cargas de trabajo deben restaurarse a la vez. Un sistema de almacenamiento que rinde bien durante las copias programadas puede convertirse igualmente en el cuello de botella de la recuperación si su ruta de lectura no soporta restauraciones en paralelo.

Las pruebas deben incluir, por tanto, escenarios de recuperación realistas y no solo los tiempos de finalización de los trabajos de copia.

Accesos simultáneos

Una restauración aislada exige relativamente poco a un sistema de almacenamiento moderno. Las recuperaciones a gran escala son otra cosa.

Varios proxies de copia o trabajos de restauración pueden solicitar datos al mismo tiempo. El destino necesita recursos suficientes de disco, CPU y red para atender esas peticiones sin canalizar la mayor parte de la carga a través de un número limitado de controladoras u otros componentes compartidos.

Dónde aparecen esos cuellos de botella depende de la arquitectura del destino.

Inmutabilidad y aplicación de la retención

El destino también puede aportar un control independiente sobre si los datos de copia conservados pueden modificarse o eliminarse.

Con S3 Object Lock, por ejemplo, la retención la aplica el propio sistema de almacenamiento de objetos. En modo cumplimiento, una versión de objeto protegida no puede sobrescribirse ni eliminarse antes de que expire su periodo de retención, ni siquiera por un usuario con credenciales de administración del almacenamiento.

Esto es distinto de un ajuste de retención que solo existe en la configuración del software de copia. Una retención aplicada por el almacenamiento sigue vinculada al objeto protegido aunque el propio software de copia quede comprometido.

Crecimiento de la capacidad

Los repositorios de copia acumulan datos a medida que se alargan los periodos de retención, crecen los conjuntos de datos protegidos y se incorporan nuevas cargas de trabajo al entorno de backup.

Por eso un destino necesita una forma práctica de añadir capacidad sin crear un repositorio nuevo cada vez que un sistema alcanza su límite.

El modelo de crecimiento también afecta al rendimiento. Algunos sistemas añaden sobre todo capacidad, mientras que los diseños de escalado horizontal suman además recursos de proceso y de red.

Comportamiento ante fallos

Los destinos de copia también deben evaluarse por lo que ocurre cuando falla el hardware.

El fallo de un disco, un nodo o una controladora puede desencadenar tareas de reconstrucción mientras siguen ejecutándose los trabajos de copia y restauración. El tiempo necesario para reconstruir los datos protegidos y los recursos que consume ese proceso pueden afectar tanto a la protección como al rendimiento de la recuperación.

De ahí el interés de probar en estado degradado al evaluar un destino de copia de seguridad para entornos grandes.

Ejemplo: cuando el rendimiento de la copia oculta un cuello de botella en la restauración

Pensemos en un hospital que protege unas 400 máquinas virtuales con Veeam.

Las copias nocturnas se escriben en un appliance de deduplicación construido en torno a un par de controladoras. Los trabajos terminan siempre dentro de su ventana programada, así que en el día a día el equipo de infraestructura tiene pocos motivos para cuestionar el rendimiento del destino.

Un incidente de ransomware genera una carga de trabajo muy distinta. Sesenta máquinas virtuales deben recuperarse a la vez.

El appliance tiene ahora que leer y reconstruir grandes volúmenes de datos deduplicados mientras varios trabajos de restauración compiten por los mismos recursos de controladora. Algunas cargas se restauran rápido y otras quedan en cola. La recuperación se alarga mucho más de lo que sugería el rendimiento habitual de las copias.

No ha fallado necesariamente nada en el sistema de almacenamiento. La carga de trabajo reveló una limitación que las operaciones de copia rutinarias no mostraban: el destino podía admitir datos de backup más deprisa de lo que podía devolverlos en una restauración paralela a gran escala.

Por eso las pruebas de un destino de copia de seguridad deben medir el rendimiento tanto en ingesta como en restauración, con el nivel de concurrencia previsto en una recuperación real.

Destino de copia de seguridad frente a repositorio de copia de seguridad

Los términos destino de copia de seguridad y repositorio de copia de seguridad se usan a veces indistintamente, aunque pueden designar cosas ligeramente distintas.

Un destino de copia de seguridad se refiere en general al sistema de almacenamiento, o al lugar, que recibe los datos de backup.

Un repositorio suele ser el recurso de almacenamiento lógico configurado dentro de la aplicación de copia. Según el producto, un mismo sistema de almacenamiento físico puede ofrecer varios repositorios, buckets o niveles de almacenamiento.

Tener presente la distinción ayuda a diagnosticar problemas de rendimiento. La configuración de un repositorio puede limitar la concurrencia aunque el destino subyacente todavía disponga de recursos, mientras que una limitación física del almacenamiento puede afectar a varios repositorios a la vez.

Destino de copia de seguridad frente a software de copia de seguridad

La aplicación de copia de seguridad y el destino de copia de seguridad tienen responsabilidades distintas.

El software de copia suele controlar la planificación de trabajos, el descubrimiento de cargas de trabajo, las políticas de backup, los catálogos y la orquestación de las restauraciones. El destino almacena los datos resultantes.

Los controles de seguridad pueden existir en ambas capas. El software de copia puede restringir el borrado mediante roles y permisos de aplicación, mientras que el destino puede aplicar controles como la retención a nivel de objeto, con independencia de la interfaz de administración del software.

Un buen diseño de backup tiene en cuenta las dos capas, en lugar de tratar el repositorio como simple capacidad de almacenamiento sin usar.

Cómo funciona el almacenamiento de objetos como destino de copia de seguridad

Muchos productos de copia de seguridad empresariales pueden escribir directamente en almacenamiento de objetos compatible con S3. El catálogo actual de compatibilidad de ARTESCA incluye, entre otras plataformas de backup, Veeam, Commvault, Rubrik y Veritas.

En lugar de almacenar los datos a través de una interfaz de sistema de archivos convencional, la aplicación escribe objetos en buckets mediante la API de S3.

El almacenamiento de objetos también puede combinar crecimiento de capacidad y procesamiento distribuido. En un despliegue de escalado horizontal, cada nodo adicional aporta CPU, memoria, ancho de banda de red y almacenamiento, lo que permite que el rendimiento agregado crezca con el clúster.

Esta arquitectura resulta útil en entornos de backup donde aumentan con el tiempo tanto la capacidad conservada como el número de flujos simultáneos de copia o restauración.

Cómo funciona ARTESCA como destino de copia de seguridad

ARTESCA ofrece almacenamiento de objetos compatible con S3 que puede utilizarse como destino de copia de seguridad con aplicaciones validadas, entre ellas Veeam, Commvault, Rubrik y Veritas.

Los datos de backup pueden protegerse con S3 Object Lock. Cuando la retención en modo cumplimiento está configurada correctamente, las versiones de objeto bloqueadas no pueden sobrescribirse ni eliminarse antes de que venza su fecha de retención. Así la retención la aplica la capa de almacenamiento, sin depender únicamente de los permisos del software de copia.

En entornos Veeam, ARTESCA está documentado actualmente como certificado Veeam Ready Repository y Veeam Ready Object with Immutability. Puede usarse como Performance Tier o Capacity Tier y admite la Smart Object Storage API (SOSAPI) de Veeam.

SOSAPI permite a Veeam obtener información de almacenamiento desde ARTESCA en lugar de tratar el destino S3 como un extremo opaco. La documentación de ARTESCA indica que el soporte de SOSAPI puede exponer métricas de bucket a Veeam y que se activa automáticamente cuando se aprovisiona un bucket mediante su asistente de Veeam VBR.

El diseño de escalado horizontal de ARTESCA significa además que añadir nodos aporta recursos de almacenamiento y de proceso, en lugar de ampliar capacidad detrás de un par de controladoras fijo. Eso es relevante cuando crecen a la vez el volumen de copias y el rendimiento de restauración necesario.

Términos relacionados

• S3 Object Lock e inmutabilidad — retención aplicada por el almacenamiento, que impide sobrescribir o eliminar una versión de objeto protegida.
• WORM (escribir una vez, leer muchas) — el modelo de inmutabilidad en el que se apoyan los controles de retención a nivel de objeto.
• Air gap lógico — el aislamiento de las copias respecto de las credenciales y las rutas de administración de producción.