Recuperar Archivos Eliminados en S3: Guía Completa con Versionado

Eliminaste un archivo en S3 y lo necesitas de vuelta — si tenías el versionado habilitado en el bucket, el objeto no desapareció realmente: S3 insertó un marcador de eliminación (delete marker) encima de las versiones anteriores. Este artículo explica cómo localizar esa versión anterior y restaurarla sin pérdida de datos.

TL;DR: Recuperación Rápida de Archivos Eliminados en S3

Situación¿Recuperable?Acción
Versionado habilitado, eliminación simple✅ SíEliminar el delete marker
Versionado habilitado, eliminación de versión específica⚠️ Solo si hay versiones anterioresCopiar o restaurar versión previa
Versionado suspendido al momento de la eliminación⚠️ Depende del estadoVerificar si existe versión con ID explícito
Versionado nunca habilitado❌ NoSin recuperación nativa posible

Cómo Funciona el Versionado de S3 y los Delete Markers

Cuando el versionado está activo en un bucket, S3 nunca sobreescribe ni elimina físicamente un objeto al recibir una operación DELETE sin versionId explícito. En su lugar, crea un delete marker: un objeto especial sin cuerpo que actúa como la versión 'actual' del objeto. Las versiones anteriores permanecen almacenadas y accesibles por su versionId.

Piensa en el versionado de S3 como una pila de hojas de papel. Cuando 'eliminas' un archivo, S3 coloca una hoja en blanco encima de la pila — el contenido original sigue debajo. Restaurar significa retirar esa hoja en blanco.

El flujo completo desde la eliminación hasta la restauración se ve así:

graph TD A["Objeto existe
con versiones"] --> B["DELETE sin versionId"] B --> C["S3 crea Delete Marker
IsLatest: true"] C --> D["GET sin versionId
devuelve 404"] D --> E{"¿Cómo restaurar?"} E --> F["Opción A: Eliminar
el Delete Marker"] E --> G["Opción B: Copiar versión
específica sobre sí misma"] F --> H["Versión anterior
queda como actual"] G --> I["Nueva versión creada
con contenido histórico"] H --> J["GET devuelve 200 ✅"] I --> J
  1. Estado original: el objeto existe con una o más versiones numeradas.
  2. DELETE sin versionId: S3 crea un delete marker como la versión más reciente. Las versiones anteriores no se tocan.
  3. Objeto 'invisible': cualquier operación GET sin versionId devuelve un error 404, porque el delete marker es la versión actual.
  4. Restauración: eliminar el delete marker hace que la versión anterior vuelva a ser la 'actual', sin mover ni copiar datos.

Paso 1: Verificar que el Versionado Está Habilitado en el Bucket

Antes de buscar versiones, confirma el estado del versionado. Un bucket con versionado 'suspendido' puede tener versiones históricas, pero las nuevas escrituras generan objetos con versionId igual a null, lo que complica la recuperación.

aws s3api get-bucket-versioning \
  --bucket nombre-de-tu-bucket

Respuesta esperada cuando el versionado está activo:

{
    "Status": "Enabled"
}

Si el resultado está vacío o muestra "Status": "Suspended", el comportamiento de recuperación cambia — continúa leyendo la sección de advertencias al final.

Paso 2: Listar Todas las Versiones del Objeto Eliminado

Con el versionado confirmado, lista todas las versiones del objeto para identificar el delete marker y las versiones recuperables. Este paso es crítico porque necesitas el versionId exacto tanto del marcador como de la versión que quieres restaurar.

aws s3api list-object-versions \
  --bucket nombre-de-tu-bucket \
  --prefix ruta/al/archivo.txt

La respuesta contiene dos secciones clave:

🔽 Ejemplo de respuesta completa (haz clic para expandir) 
{
    "Versions": [
        {
            "ETag": "\"abc123...\"",
            "Size": 1024,
            "Key": "ruta/al/archivo.txt",
            "VersionId": "Kg98mN2xQpL7vR3tYwZa1bCdEfGhIjKl",
            "IsLatest": false,
            "LastModified": "2024-01-15T10:30:00.000Z"
        },
        {
            "ETag": "\"def456...\"",
            "Size": 980,
            "Key": "ruta/al/archivo.txt",
            "VersionId": "Ab12cD34eF56gH78iJ90kL12mN34oP56",
            "IsLatest": false,
            "LastModified": "2024-01-10T08:15:00.000Z"
        }
    ],
    "DeleteMarkers": [
        {
            "Key": "ruta/al/archivo.txt",
            "VersionId": "Mn78oP90qR12sT34uV56wX78yZ90aB12",
            "IsLatest": true,
            "LastModified": "2024-01-20T14:22:00.000Z"
        }
    ]
}

Identifica y anota dos valores antes de continuar:

  • El versionId del delete marker — el que tiene "IsLatest": true dentro de DeleteMarkers.
  • El versionId de la versión que quieres recuperar — normalmente la más reciente dentro de Versions.

Paso 3: Eliminar el Delete Marker para Recuperar Archivos Eliminados en S3

Eliminar el delete marker es la forma más limpia de restaurar el objeto — no mueve datos, simplemente expone la versión anterior como la actual. Para esto necesitas el versionId exacto del marcador identificado en el paso anterior.

aws s3api delete-object \
  --bucket nombre-de-tu-bucket \
  --key ruta/al/archivo.txt \
  --version-id Mn78oP90qR12sT34uV56wX78yZ90aB12

Si el comando tiene éxito, S3 devuelve una respuesta con "DeleteMarker": true, confirmando que eliminaste el marcador y no una versión de datos real.

Verifica que el objeto es accesible nuevamente:

aws s3api head-object \
  --bucket nombre-de-tu-bucket \
  --key ruta/al/archivo.txt

Una respuesta con código HTTP 200 y metadatos del objeto confirma la restauración exitosa.

Paso 4 (Alternativo): Restaurar una Versión Específica Anterior

Si el delete marker ya no existe pero necesitas una versión anterior específica — no la más reciente — la estrategia es copiar esa versión sobre sí misma. Esto crea una nueva versión 'actual' con el contenido histórico que necesitas.

aws s3api copy-object \
  --bucket nombre-de-tu-bucket \
  --copy-source nombre-de-tu-bucket/ruta/al/archivo.txt?versionId=Ab12cD34eF56gH78iJ90kL12mN34oP56 \
  --key ruta/al/archivo.txt

Este comando crea una nueva versión del objeto con el contenido de la versión Ab12cD34eF56gH78iJ90kL12mN34oP56. Las versiones anteriores permanecen intactas en el historial.

graph LR START(["Objeto eliminado
GET devuelve 404"]) --> CHECK{"¿Existe Delete
Marker activo?"} CHECK -->|"Sí"| ROUTE_A["Ruta A: Eliminar
Delete Marker"] CHECK -->|"No / ya eliminado"| ROUTE_B["Ruta B: Copiar versión
histórica específica"] ROUTE_A --> CMD_A["delete-object
--version-id <marker-id>"] ROUTE_B --> CMD_B["copy-object
--copy-source ...?versionId=..."] CMD_A --> VERIFY["head-object sin versionId
debe devolver 200"] CMD_B --> VERIFY VERIFY -->|"200 OK"| DONE(["✅ Restauración exitosa"]) VERIFY -->|"404 aún"| DEBUG["Revisar list-object-versions
y permisos IAM"]
  1. Ruta A — Eliminación simple: existe un delete marker, se elimina directamente. La versión anterior queda expuesta sin mover datos.
  2. Ruta B — Versión específica: se usa copy-object para promover una versión histórica como la nueva versión actual.
  3. Verificación final: en ambos casos, head-object sin versionId debe devolver 200.

Permisos IAM Necesarios para la Recuperación

Las operaciones de restauración requieren permisos específicos que van más allá del acceso estándar de lectura/escritura. La eliminación de un delete marker usa la misma API que eliminar una versión real — S3 distingue el tipo por el versionId, no por el permiso.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestoreVersionedObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObjectVersion",
        "s3:ListBucketVersions",
        "s3:DeleteObjectVersion",
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::nombre-de-tu-bucket",
        "arn:aws:s3:::nombre-de-tu-bucket/*"
      ]
    }
  ]
}

Nota importante: s3:ListBucketVersions se aplica al recurso del bucket (arn:aws:s3:::nombre-de-tu-bucket), no al prefijo de objeto. Si la política solo incluye el ARN con /*, el listado de versiones fallará con un error de acceso denegado — un error que se ve con frecuencia en entornos donde las políticas fueron escritas solo para acceso a objetos.

El Error que Comete Casi Todo el Mundo la Primera Vez

La situación típica: el bucket tiene versionado habilitado, ejecutas el comando de eliminación del delete marker, pero el objeto sigue sin aparecer. Revisas los permisos, todo parece correcto. El problema real: eliminaste una versión de datos en lugar del marcador.

Ocurre cuando copias el versionId de la sección Versions en lugar de DeleteMarkers. S3 elimina esa versión de datos sin error, y el delete marker sigue siendo la versión actual. El objeto continúa devolviendo 404.

La señal de alerta: si la respuesta del comando delete-object no incluye "DeleteMarker": true, eliminaste una versión de datos real, no el marcador. Detente y vuelve a ejecutar list-object-versions para evaluar el estado actual antes de continuar.

Eliminar la versión incorrecta no es reversible de la misma forma — si borras la única versión de datos disponible, esa versión desaparece permanentemente.

Advertencias y Casos Especiales

Versionado Suspendido

Si el versionado estaba suspendido cuando se realizó la eliminación, el objeto puede tener un delete marker con versionId igual a null. La eliminación de este marcador sigue el mismo proceso, pero debes especificar explícitamente --version-id null en el comando. Verifica el comportamiento exacto en la documentación oficial de AWS para versionado suspendido antes de proceder.

Bucket con MFA Delete Habilitado

Si el bucket tiene MFA Delete habilitado, la eliminación de versiones y delete markers requiere incluir el token MFA en la solicitud. Esta operación no es posible directamente desde la AWS CLI estándar sin configuración adicional — consulta la documentación de S3 MFA Delete para el procedimiento correcto.

Políticas de Ciclo de Vida

Las reglas de ciclo de vida configuradas en el bucket pueden eliminar versiones antiguas o delete markers automáticamente después de un período definido. Si no encuentras las versiones esperadas, verifica las reglas de ciclo de vida activas:

aws s3api get-bucket-lifecycle-configuration \
  --bucket nombre-de-tu-bucket

Recuperación desde la Consola de AWS (Alternativa Visual)

Si prefieres la consola web para una recuperación puntual:

  1. Navega al bucket en la consola de S3.
  2. Activa 'Mostrar versiones' en el encabezado de la lista de objetos.
  3. Localiza el archivo — verás el delete marker marcado con una etiqueta especial y las versiones anteriores debajo.
  4. Selecciona el delete marker y elige 'Eliminar' para restaurar la versión anterior, o selecciona una versión específica y descárgala manualmente.

La consola es útil para recuperaciones puntuales, pero para operaciones en lote o automatización, la CLI es el camino correcto.

Próximos Pasos y Recursos para Recuperar Archivos en S3

Si esta situación te tomó por sorpresa, considera implementar estas medidas preventivas:

  • Habilita el versionado en todos los buckets críticos — si aún no lo tienes activo, hazlo ahora: aws s3api put-bucket-versioning --bucket nombre-de-tu-bucket --versioning-configuration Status=Enabled
  • Configura S3 Object Lock para objetos que no deben eliminarse bajo ninguna circunstancia.
  • Revisa las políticas de ciclo de vida para asegurarte de que no eliminan versiones históricas antes de que las necesites.
  • Implementa SCPs en AWS Organizations para prevenir la deshabilitación accidental del versionado en buckets críticos.

Documentación oficial de referencia: Amazon S3 Versioning — AWS Documentation.

Glosario de Términos Clave

TérminoDefinición
Delete MarkerObjeto especial sin cuerpo que S3 inserta como versión actual cuando se elimina un objeto versionado sin especificar un versionId. Hace que el objeto aparezca como eliminado para operaciones GET estándar.
versionIdIdentificador único asignado por S3 a cada versión de un objeto cuando el versionado está habilitado. Necesario para acceder o eliminar versiones específicas.
Versionado SuspendidoEstado del bucket donde el versionado estuvo habilitado pero fue desactivado. Las versiones históricas se conservan, pero las nuevas escrituras generan objetos con versionId nulo.
MFA DeleteCapa de seguridad adicional en S3 que requiere autenticación multifactor para eliminar versiones de objetos o cambiar el estado del versionado del bucket.
Ciclo de Vida (Lifecycle)Reglas configurables en S3 que automatizan la transición o eliminación de objetos y versiones basándose en criterios de tiempo o prefijo.

Comentarios

Publicar un comentario

Entradas populares de este blog

EC2 sin acceso a Internet en VPC personalizada: Internet Gateway y Route Table

Creaste una VPC personalizada, lanzaste una instancia EC2 en una subred pública y no puedes hacer ping a google.com — ni SSH funciona desde fuera. Este es uno de los problemas más frecuentes al trabajar con redes en AWS, y casi siempre se reduce a tres capas que deben estar alineadas: el Internet Gateway, la Route Table y la configuración de IP pública. Si falla cualquiera de las tres, el tráfico no sale. TL;DR — Acceso a Internet en EC2 dentro de VPC personalizada Capa Qué debe estar configurado Error típico Internet Gateway Creado y adjunto a la VPC IGW existe pero no está adjunto Route Table Ruta 0.0.0.0/0 apuntando al IGW Route Table sin ruta de salida Subred pública Asociada a la Route Table correcta Subred usa la Route Table principal sin IGW IP pública Auto-assign habilitado o EIP asignado Instancia sin IP pública Security Group Regla de salida 0.0.0.0/0 permitida Egress bloqueado por SG restr...
Leer más

Actualizar Contenido en CloudFront: Cómo Crear una Invalidación para Limpiar el Caché del Edge

Reemplazaste un archivo en S3, recargaste el navegador, y CloudFront sigue sirviendo la versión antigua. Es uno de esos momentos donde sabes exactamente qué pasó, pero necesitas la solución correcta ahora mismo — sin esperar que el TTL expire solo. Este artículo explica cómo funciona el caché de CloudFront y cómo crear una invalidación de CloudFront para forzar la purga inmediata del edge. TL;DR — Invalidación de CloudFront en 30 Segundos Situación Acción Archivo actualizado en S3, CloudFront sirve versión vieja Crear invalidación con la ruta del archivo Múltiples archivos actualizados Usar wildcard /* o listar rutas específicas Quieres evitar invalidaciones frecuentes Usar versionado de archivos en el nombre (cache busting) Herramienta Consola AWS, CLI ( aws cloudfront create-invalidation ), o SDK Cómo Funciona el Caché de CloudFront CloudFront opera como una red de puntos de presencia distribui...
Leer más

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción

Tu función Lambda se detiene a los 3 segundos, pero el proceso que ejecuta necesita 10. No es un bug en tu código — es el timeout por defecto de Lambda actuando exactamente como fue diseñado. El problema es que ese valor predeterminado de 3 segundos sorprende a casi todos la primera vez, especialmente cuando la función funciona perfectamente en local pero falla en producción con un error Task timed out after 3.00 seconds . TL;DR — Aumentar el Timeout de Lambda Aspecto Detalle Timeout por defecto 3 segundos Timeout máximo 15 minutos (900 segundos) Dónde configurarlo Consola AWS, CLI, CloudFormation, SAM, Terraform Error observable Task timed out after X.XX seconds Coste asociado Mayor timeout = mayor ventana de facturación potencial Alternativa para tareas largas AWS Step Functions o procesamiento asíncrono Cómo Funciona el Timeout en AWS Lambda Lambda ejecuta tu función dentro de un entor...
Leer más