Introducción
Subir un borrador a la clave del informe de un equipo de finanzas reemplazaría el contenido aprobado que ven los lectores. Activarás el control de versiones, reproducirás ese error, recuperarás el contenido aprobado y eliminarás el historial de práctica después de comprobar la recuperación.
Completa primero Organiza documentos con claves y metadatos para conocer claves de objetos, propiedades, descargas y limpieza. Esta VM nueva proporciona la conexión de la CLI y los archivos aprobado y borrador; tú crearás el bucket. Utiliza Terminal para los comandos y la pestaña AWS View, a su lado, para comparar los objetos actuales con su historial.
Relación con las certificaciones
Este laboratorio ofrece práctica para los siguientes temas de examen.
- Solutions Architect – Associate (SAA-C03) · Tarea 1.3: Historial de versiones S3, marcadores de eliminación y recuperación de datos.
- Developer – Associate (DVA-C02) · Tarea 1.3: Historial de versiones S3, marcadores de eliminación y recuperación de datos.
- CloudOps Engineer – Associate (SOA-C03) · Tarea 2.3: Historial de versiones S3, marcadores de eliminación y recuperación de datos.
- Security – Specialty (SCS-C03) · Tarea 5.2: Práctica de fundamentos: Historial de versiones S3, marcadores de eliminación y recuperación de datos.
- Data Engineer – Associate (DEA-C01) · Tarea 2.3: Práctica de fundamentos: Historial de versiones S3, marcadores de eliminación y recuperación de datos.
Activa el control de versiones antes de publicar
En este paso, crearás un bucket vacío y activarás el control de versiones antes de subir cualquier informe.
Entra en el espacio de trabajo con cd (cambiar de directorio):
cd /home/labex/project
Crea el bucket de informes con mb (crear bucket):
aws s3 mb s3://labex-report-history
Deberías ver make_bucket: labex-report-history. El control de versiones es una configuración del bucket: una vez activado, las escrituras posteriores en una clave crean ID de versión en lugar de descartar su contenido almacenado anterior. Es útil para recuperar sobrescrituras accidentales, pero no impide que alguien elimine explícitamente una versión concreta.
aws s3api expone operaciones individuales de la API de S3. put-bucket-versioning actualiza esta configuración; --bucket identifica el contenedor y --versioning-configuration Status=Enabled solicita el estado activado:
aws s3api put-bucket-versioning --bucket labex-report-history --versioning-configuration Status=Enabled
La actualización correcta no muestra un cuerpo. Lee la configuración almacenada en lugar de confiar solo en el silencio:
aws s3api get-bucket-versioning --bucket labex-report-history
{
"Status": "Enabled"
}
AWS View ahora muestra Versioning: Enabled en el bucket. Sigue vacío: activar el control de versiones no sube un informe ni crea una versión histórica. Activa la configuración antes de escribir los datos que quieras proteger.
Crea una versión original y una sobrescrita
En este paso, publicarás un informe aprobado y después sobrescribirás su contenido actual con un borrador, conservando el original en el historial.
Inspecciona los archivos preparados con cat, que muestra su contenido:
cat report-approved.txt
Monthly revenue: 42000
cat report-draft.txt
Monthly revenue: 00000
Publica el archivo aprobado en la clave report.txt. El nombre del archivo de origen y la clave del objeto pueden ser distintos:
aws s3 cp report-approved.txt s3://labex-report-history/report.txt
En AWS View, abre report.txt y confirma los ingresos aprobados. El historial contiene una versión, marcada Current.
Ahora reproduce el error: sube el borrador a esa misma clave:
aws s3 cp report-draft.txt s3://labex-report-history/report.txt
La vista previa cambia a Monthly revenue: 00000. Sigue habiendo una clave de objeto actual, pero su historial ahora tiene dos versiones almacenadas. Ambos archivos tienen el mismo tamaño; el control de versiones registra escrituras en lugar de deducir los cambios solo a partir de su tamaño.
list-object-versions recupera los registros históricos además de la versión actual:
aws s3api list-object-versions --bucket labex-report-history
El array Versions contiene dos entradas con clave report.txt y valores VersionId distintos. IsLatest: true identifica el borrador como actual; la versión aprobada anterior tiene IsLatest: false. Los ID y las marcas de tiempo varían. Una lista normal de objetos muestra las claves actuales, así que utiliza la lista de versiones al investigar una sobrescritura.
En la S3 Console oficial, Show versions revela estas entradas del historial en la lista de objetos. Este ejemplo muestra otro objeto y más escrituras; utilízalo para reconocer la columna Version ID. No hace falta iniciar sesión en la Console para este laboratorio.
Fuente: AWS Storage Blog.
Recupera y publica la versión aprobada
En este paso, descargarás la versión aprobada anterior, comprobarás sus bytes y harás que ese contenido vuelva a ser el actual sin eliminar el historial.
En este momento hay exactamente dos versiones de report.txt. En la lista anterior, busca la entrada con IsLatest: false: es el original aprobado. Copia su VersionId.
Guarda ese ID en una variable del shell para reutilizarlo. Reemplaza PASTE_APPROVED_VERSION_ID a continuación por el valor que copiaste, manteniendo las comillas. Una asignación de variable no tiene espacios alrededor de =:
OLD_VERSION='PASTE_APPROVED_VERSION_ID'
Comprueba el valor antes de utilizarlo:
echo "$OLD_VERSION"
Deberías ver el ID de la versión anterior, en lugar del texto de sustitución. $OLD_VERSION lee la variable; las comillas dobles mantienen el valor unido como un argumento del comando.
get-object descarga el cuerpo de un objeto a la ruta local final. --version-id selecciona la copia histórica en lugar del borrador actual:
aws s3api get-object --bucket labex-report-history --key report.txt --version-id "$OLD_VERSION" recovered-report.txt
La salida JSON describe la copia recuperada. Lee su contenido:
cat recovered-report.txt
Monthly revenue: 42000
cmp compara bytes de archivos. && ejecuta el mensaje siguiente solo si la comparación tiene éxito:
cmp report-approved.txt recovered-report.txt && echo 'Approved historical content verified'
Recuperar una versión anterior no la convierte en la actual; los lectores de la clave sin un ID de versión siguen recibiendo el borrador. Publica los bytes recuperados en esa clave:
aws s3 cp recovered-report.txt s3://labex-report-history/report.txt
Esto crea una tercera versión que contiene el informe aprobado. Tanto la versión aprobada antigua como el borrador permanecen para la investigación. AWS View muestra el contenido aprobado como actual y tres registros de versiones. Enumera el historial para confirmarlo:
aws s3api list-object-versions --bucket labex-report-history
La entrada nueva tiene IsLatest: true. Restauraste los datos escribiendo una nueva versión actual en lugar de borrar las pruebas del error.
Este ejemplo muestra el informe recuperado como actual y tres entradas distintas del historial. Los ID de versión mostrados son ejemplos de esa sesión:
Restaura el acceso después de un marcador de eliminación
En este paso, observarás cómo un marcador de eliminación oculta un objeto con versiones y después eliminarás ese marcador para revelar la versión que era actual anteriormente.
Esquema: la eliminación añade un marcador actual mientras permanecen las tres versiones almacenadas del informe. Las etiquetas v1–v3 indican el orden de escritura, no los ID de versión reales.
En un bucket con el control de versiones activado, una solicitud de eliminación sin ID de versión crea un marcador de eliminación. Esta es una entrada actual del historial que indica que la clave está eliminada; no contiene bytes de archivo ni borra las versiones anteriores. Elimina la clave actual utilizando el comando habitual de archivos:
aws s3 rm s3://labex-report-history/report.txt
Una lista normal ahora no muestra objetos actuales:
aws s3 ls s3://labex-report-history/
En AWS View, el objeto actual desaparece, mientras permanecen tres filas Version y un Delete marker actual en el historial.
Intenta descargar la clave sin elegir una versión:
aws s3 cp s3://labex-report-history/report.txt unavailable-report.txt
Se espera que este comando falle con un error de recurso no encontrado. El marcador de eliminación actual hace que una lectura normal se comporte como si el objeto estuviera ausente. Esto no demuestra que los bytes históricos se hayan borrado.
Lee el historial completo:
aws s3api list-object-versions --bucket labex-report-history
La respuesta ahora contiene DeleteMarkers además de Versions. Busca la única entrada de DeleteMarkers y copia su VersionId. Este ID identifica el marcador, no un informe almacenado.
Reemplaza el texto de sustitución siguiente por ese ID de marcador:
MARKER_VERSION='PASTE_DELETE_MARKER_ID'
Elimina ese marcador exacto con delete-object. Proporcionar --version-id elimina la entrada seleccionada del historial en lugar de crear otro marcador:
aws s3api delete-object --bucket labex-report-history --key report.txt --version-id "$MARKER_VERSION"
La respuesta identifica el marcador eliminado. La versión aprobada anterior vuelve a ser la actual; esta operación no sube otra versión del informe. Confirma el acceso normal descargando la clave:
aws s3 cp s3://labex-report-history/report.txt accessible-report.txt
cmp report-approved.txt accessible-report.txt && echo 'Current report accessible again'
La comparación tiene éxito. AWS View vuelve a mostrar report.txt con el contenido aprobado y tres versiones. Eliminar un marcador restaura el acceso; eliminar permanentemente una versión de datos borraría esa copia concreta.
Elimina las versiones históricas y el bucket
En este paso, eliminarás todas las versiones de datos pertenecientes al laboratorio antes de eliminar el bucket vacío.
El historial de versiones consume almacenamiento incluso cuando una lista normal de objetos está vacía. Un simple aws s3 rm crearía otro marcador de eliminación, así que no basta para vaciar un bucket con versiones. El marcador del paso anterior ya se ha eliminado; permanecen las tres versiones de datos.
Enumera el historial antes de la limpieza permanente:
aws s3api list-object-versions --bucket labex-report-history
Deberías ver tres entradas en Versions y ninguna en DeleteMarkers. Todas las entradas pertenecen a este ejercicio desechable de informes.
Las tres entradas pertenecen a report.txt. Ya utilizaste delete-object --version-id para eliminar un marcador; la misma operación puede eliminar permanentemente una versión de datos.
Copia un VersionId de la lista y reemplaza el texto de sustitución siguiente. Ejecuta este comando una vez por cada uno de los tres ID distintos. La eliminación permanente no se puede deshacer, así que comprueba el bucket, la clave y el ID cada vez:
aws s3api delete-object --bucket labex-report-history --key report.txt --version-id 'PASTE_VERSION_ID'
Una respuesta correcta identifica la versión eliminada. Un ID de versión selecciona una copia histórica; no elimina todas las versiones de la clave. Después de eliminar las tres, confirma que no quedan versiones ni marcadores:
aws s3api list-object-versions --bucket labex-report-history
La respuesta correcta no tiene entradas Versions ni DeleteMarkers. Ahora elimina el bucket vacío con rb:
aws s3 rb s3://labex-report-history
La salida es remove_bucket: labex-report-history. Confirma que el almacenamiento sigue respondiendo:
aws s3 ls
No quedan buckets y AWS View muestra No buckets. Los archivos locales de informes siguen disponibles; solo se han eliminado los recursos de S3 del laboratorio y su historial.
Resumen
Activaste el control de versiones del bucket antes de publicar, distinguiste una clave actual de sus ID de versiones históricas y recuperaste un informe sobrescrito obteniendo una versión anterior y publicando sus bytes verificados. Después creaste y eliminaste un marcador de eliminación para restaurar el acceso normal sin subir otra versión.
El control de versiones conserva el historial; no hace reversible la eliminación explícita de versiones. Terminaste inspeccionando y eliminando permanentemente todas las versiones del laboratorio, confirmando que no quedaban marcadores y eliminando el bucket vacío.
