Cómo los snapshots incrementales de EBS permiten restauración completa - El mecanismo interno de gestión de diferencias a nivel de bloque
Explicamos el mecanismo por el cual los snapshots de EBS, siendo backups incrementales, pueden restaurar un volumen completo desde cualquier snapshot, desde la gestión de diferencias a nivel de bloque, la estructura de almacenamiento en S3 y el funcionamiento interno de la restauración rápida de snapshots.
Concepto básico del backup incremental
Los snapshots de EBS son backups incrementales. El primer snapshot es una copia completa del volumen, pero los snapshots posteriores solo almacenan los bloques que cambiaron desde el snapshot anterior. Para un volumen de 100GB donde 5GB de datos cambiaron entre snapshots, el segundo snapshot solo consume 5GB de almacenamiento. Este método incremental reduce significativamente el tiempo de creación y el costo de almacenamiento de los snapshots. Sin embargo, surge una pregunta: si es un backup incremental, ¿no sería necesario aplicar secuencialmente el backup completo inicial + todos los incrementos al restaurar? En los backups tradicionales en cinta eso es correcto, pero los snapshots de EBS funcionan con un mecanismo diferente.
Estructura de referencia a nivel de bloque
La estructura interna de los snapshots de EBS es una tabla de punteros por unidad de bloque (normalmente 512KB). Cada snapshot tiene punteros para todos los bloques del volumen. Los bloques modificados se almacenan como datos nuevos, y los bloques sin cambios referencian los datos del snapshot anterior. Explicamos con un ejemplo concreto. Supongamos que un volumen está compuesto por 100 bloques. El snapshot A almacena los datos de los 100 bloques. El snapshot B, como los bloques 5 y 10 cambiaron, almacena los datos nuevos de estos 2 y los 98 restantes referencian los datos del snapshot A. El snapshot C, como los bloques 3 y 5 cambiaron, almacena los datos nuevos de estos 2 y el resto referencia los datos del snapshot B (o su referencia al A). Con esta estructura, desde cualquier snapshot se pueden rastrear los datos de todos los bloques. Al restaurar desde el snapshot C, el bloque 3 y 5 usan datos de C, el bloque 10 usa datos de B, y el resto usa datos de A. Esta resolución de referencias la realiza EBS internamente de forma automática, por lo que el usuario no necesita preocuparse por el orden de los incrementos.
Eliminación de snapshots y reestructuración de referencias
Lo más confuso de los backups incrementales es el comportamiento cuando se elimina un snapshot intermedio. Si tenemos snapshots A → B → C y eliminamos B, ¿qué sucede? En backups incrementales tradicionales, eliminar B haría que C fuera irrecuperable. Sin embargo, en los snapshots de EBS se puede eliminar B de forma segura. Al eliminar B, los datos de bloques que solo B mantenía (bloques modificados en B pero no en C) se consolidan en C. Es decir, la tabla de punteros de C se actualiza para que los punteros que referenciaban a B ahora referencien directamente los datos de A o los datos consolidados. Este proceso de consolidación lo realiza EBS internamente de forma automática. Como resultado, sin importar qué snapshot se elimine, no hay impacto en la restauración desde los snapshots restantes. Incluso eliminando el primer snapshot A, B y C se pueden restaurar normalmente porque los datos que solo A mantenía se consolidan en B.
Destino de almacenamiento de snapshots y latencia de restauración
Los datos de los snapshots de EBS se almacenan en S3. Sin embargo, no en los buckets S3 del usuario sino en la infraestructura interna de S3 administrada por AWS, por lo que no se pueden ver directamente los datos del snapshot desde la consola de S3. Al restaurar un volumen desde un snapshot, los datos se transfieren desde S3 a la infraestructura de almacenamiento de EBS. Lo importante aquí es que la restauración se realiza mediante Lazy Loading (carga diferida). La creación del volumen se completa inmediatamente, pero transferir todos los bloques desde S3 toma tiempo. Si se accede a un bloque que aún no se ha transferido, se obtiene bajo demanda desde S3 en ese momento. Este lazy loading causa una penalización de primer acceso donde la latencia aumenta en el primer acceso. Para evitar esta penalización en entornos de producción, se habilita Fast Snapshot Restore (FSR). FSR precarga los datos del snapshot en la infraestructura de almacenamiento de EBS, permitiendo acceso a pleno rendimiento inmediatamente después de la restauración. El precio de FSR es 0.75 USD por hora por cada AZ habilitada.
EBS Snapshots Archive - Opción de reducción de costos
EBS Snapshots Archive, introducido en 2021, es una función que mueve snapshots de baja frecuencia de acceso a una capa de almacenamiento hasta 75% más barata. Los snapshots normales cuestan 0.05 USD mensuales por GB, mientras que la capa Archive cuesta 0.0125 USD. Sin embargo, la restauración desde la capa Archive toma de 24 a 72 horas. Archive es adecuado para snapshots que necesitan retención a largo plazo por requisitos de cumplimiento pero no necesitan acceso frecuente. Por ejemplo, si hay una regulación que requiere retener backups completos mensuales durante 7 años, se pueden mantener los últimos 3 meses como snapshots normales y mover los anteriores a Archive, reduciendo significativamente los costos de almacenamiento. La gestión del ciclo de vida de snapshots se puede automatizar con Amazon Data Lifecycle Manager (DLM). DLM crea automáticamente snapshots según un programa, elimina automáticamente snapshots antiguos según el período de retención, y también puede automatizar el movimiento a la capa Archive. Para aprender sistemáticamente sobre diseño de backup de EBS, pueden ser útiles libros especializados (Amazon).