Versionado de objetos

El versionado hace que OtterStorage conserve cada revisión de tus objetos en lugar de pisarlas. Cuando está activo, sobrescribir o borrar una clave no destruye su contenido anterior: cada cambio queda guardado bajo un identificador de versión (versionId), de modo que siempre puedes volver a un estado previo. Es la mejor defensa contra borrados y sobrescrituras accidentales.

Qué es y por qué usarlo

Sin versionado, cada vez que subes un objeto con una clave que ya existe, el nuevo contenido reemplaza al anterior y el original se pierde. Con el versionado activo, OtterStorage guarda la versión previa y crea una nueva versión "actual"; las antiguas quedan como versiones no actuales que puedes listar y restaurar.

Algunas razones para activarlo:

• Recuperación ante errores: deshaz una sobrescritura o un borrado accidental restaurando la versión anterior.
• Historial de cambios: mantén un registro de cómo ha evolucionado cada objeto a lo largo del tiempo.
• Protección frente a aplicaciones defectuosas: un proceso que sobrescribe datos por error no destruye nada de forma irreversible.
• Base para retención y cumplimiento: combina bien con Legal Hold para preservar el historial completo.

En OtterStorage no cobramos por peticiones ni por borrados, así que activar el versionado no añade coste por operaciones: solo pagas por el almacenamiento que ocupan las versiones que conservas.

Activar y suspender el versionado

El estado de versionado se controla a nivel de bucket con la operación put-bucket-versioning. Acepta dos estados: Enabled (activado) y Suspended (suspendido). Todos los ejemplos usan aws s3api apuntando al endpoint de OtterStorage; consulta cómo configurar la AWS CLI si aún no lo has hecho.

Para activar el versionado en el bucket mi-bucket:

aws s3api put-bucket-versioning \
  --endpoint-url https://s3.otterstorage.io \
  --region eu-mad \
  --bucket mi-bucket \
  --versioning-configuration Status=Enabled

Para suspenderlo, usa el mismo comando con Status=Suspended:

aws s3api put-bucket-versioning \
  --endpoint-url https://s3.otterstorage.io \
  --region eu-mad \
  --bucket mi-bucket \
  --versioning-configuration Status=Suspended

Suspender el versionado no borra las versiones existentes: las que ya tenías se conservan y siguen siendo recuperables. Lo único que cambia es que, a partir de ese momento, las nuevas escrituras dejan de generar versiones nuevas (las versiones que se creen llevarán el identificador especial null). Para retomar el comportamiento, vuelve a poner Status=Enabled.

Comprobar el estado actual

Verifica en qué estado está un bucket con get-bucket-versioning:

aws s3api get-bucket-versioning \
  --endpoint-url https://s3.otterstorage.io \
  --region eu-mad \
  --bucket mi-bucket

La respuesta es un pequeño JSON con el estado vigente:

{
  "Status": "Enabled"
}

Si el bucket nunca ha tenido el versionado activado, la respuesta llega vacía (sin campo Status), lo que equivale a "no versionado".

Cómo se comporta con el versionado activo

Una vez activado, OtterStorage cambia la forma en que trata las escrituras y los borrados:

Al sobrescribir: se conserva la versión previa

Cuando subes un objeto con una clave que ya existe, la versión anterior no se pierde: pasa a ser una versión no actual y la nueva se convierte en la versión actual. Cada PutObject devuelve el versionId asignado:

aws s3api put-object \
  --endpoint-url https://s3.otterstorage.io \
  --region eu-mad \
  --bucket mi-bucket \
  --key informe.pdf \
  --body informe-v2.pdf

{
  "ETag": "\"9b2cf5...\"",
  "VersionId": "3sL0nD02pX9aQ7Kf2bVtY8mZ1cR4wH6"
}

Cada vez que repitas la subida sobre la misma clave obtendrás un versionId distinto, y todas las versiones anteriores quedarán disponibles para listar o restaurar.

Al borrar: se crea un delete marker

Un borrado "normal" (sin indicar versión) no elimina los datos: OtterStorage coloca un delete marker (marcador de borrado) como nueva versión actual. El objeto parece desaparecer en un listado simple, pero todas sus versiones reales siguen ahí, intactas, detrás del marcador.

aws s3api delete-object \
  --endpoint-url https://s3.otterstorage.io \
  --region eu-mad \
  --bucket mi-bucket \
  --key informe.pdf

{
  "DeleteMarker": true,
  "VersionId": "Hk7Vd0pQ2aN8sLm4wR1bX6cT9zF3yJ5"
}

El VersionId devuelto identifica al propio delete marker. Recuerda que en OtterStorage los borrados no se facturan, así que esta operación no tiene coste por petición.

Recuperar una versión

Hay dos situaciones típicas de recuperación: traer una versión concreta de un objeto sobrescrito, o "resucitar" un objeto que fue borrado con un delete marker.

Descargar una versión concreta

Usa get-object con --version-id para recuperar exactamente la revisión que necesitas:

aws s3api get-object \
  --endpoint-url https://s3.otterstorage.io \
  --region eu-mad \
  --bucket mi-bucket \
  --key informe.pdf \
  --version-id 3sL0nD02pX9aQ7Kf2bVtY8mZ1cR4wH6 \
  informe-recuperado.pdf

Para restaurar esa versión como la actual, vuelve a subirla con put-object: se creará una versión nueva con el contenido antiguo, que pasará a ser la versión vigente.

Resucitar un objeto borrado

Si el objeto "desapareció" porque tiene un delete marker encima, basta con borrar el delete marker. Para ello, ejecuta delete-object indicando el --version-id del marcador (el que viste al borrar o el que aparece al listar versiones):

aws s3api delete-object \
  --endpoint-url https://s3.otterstorage.io \
  --region eu-mad \
  --bucket mi-bucket \
  --key informe.pdf \
  --version-id Hk7Vd0pQ2aN8sLm4wR1bX6cT9zF3yJ5

Al eliminar el marcador, la versión que había debajo vuelve a ser la actual y el objeto reaparece en los listados normales. Igual que cualquier borrado en OtterStorage, esta operación no se factura.

Listar todas las versiones

Un listado normal (list-objects-v2) solo muestra la versión actual de cada clave. Para ver el historial completo —incluidas versiones no actuales y delete markers— usa list-object-versions:

aws s3api list-object-versions \
  --endpoint-url https://s3.otterstorage.io \
  --region eu-mad \
  --bucket mi-bucket \
  --prefix informe.pdf

La respuesta separa las versiones reales (Versions) de los marcadores de borrado (DeleteMarkers). El campo IsLatest indica cuál es la versión actual de cada clave:

{
  "Versions": [
    {
      "Key": "informe.pdf",
      "VersionId": "3sL0nD02pX9aQ7Kf2bVtY8mZ1cR4wH6",
      "IsLatest": false,
      "LastModified": "2026-06-09T10:14:22.000Z",
      "Size": 184320
    },
    {
      "Key": "informe.pdf",
      "VersionId": "Qp8Wb1nM5tK2vL9cR3aX7dZ4yH6sF0jB",
      "IsLatest": false,
      "LastModified": "2026-06-08T17:03:51.000Z",
      "Size": 180224
    }
  ],
  "DeleteMarkers": [
    {
      "Key": "informe.pdf",
      "VersionId": "Hk7Vd0pQ2aN8sLm4wR1bX6cT9zF3yJ5",
      "IsLatest": true,
      "LastModified": "2026-06-10T08:41:09.000Z"
    }
  ]
}

Con estos versionId puedes descargar cualquier revisión concreta o eliminar el delete marker para recuperar el objeto, como hemos visto arriba.

Combinar con lifecycle para expirar versiones antiguas

Conservar todas las versiones para siempre acaba ocupando espacio que quizá no necesitas. La solución recomendada es usar el ciclo de vida (lifecycle) para expirar automáticamente las versiones no actuales pasado cierto tiempo, manteniendo siempre intacta la versión actual.

La regla NoncurrentVersionExpiration define cuántos días debe conservarse una versión después de dejar de ser la actual. Por ejemplo, para borrar las versiones no actuales 30 días después de quedar obsoletas:

aws s3api put-bucket-lifecycle-configuration \
  --endpoint-url https://s3.otterstorage.io \
  --region eu-mad \
  --bucket mi-bucket \
  --lifecycle-configuration '{
    "Rules": [
      {
        "ID": "expirar-versiones-antiguas",
        "Status": "Enabled",
        "Filter": { "Prefix": "" },
        "NoncurrentVersionExpiration": {
          "NoncurrentDays": 30
        }
      }
    ]
  }'

Con esta regla, la versión actual de cada objeto nunca se toca, pero las revisiones antiguas se limpian solas a los 30 días de quedar obsoletas. Como los borrados que ejecuta el ciclo de vida tampoco se facturan en OtterStorage, esta limpieza no añade coste por operaciones: solo reduces lo que pagas en almacenamiento. Para reglas más avanzadas (expirar también los delete markers, distintos prefijos, etc.), consulta la guía de ciclo de vida.

Buenas prácticas

• Actívalo pronto: el versionado solo protege los cambios que ocurren después de activarlo. Hazlo al crear el bucket.
• Pon límites con lifecycle: usa NoncurrentVersionExpiration para que el historial no crezca sin control.
• Suspende, no improvises: si necesitas dejar de versionar, usa Status=Suspended; tus versiones previas seguirán recuperables.
• Combínalo con retención: para escenarios de cumplimiento, súmalo a Legal Hold y preserva el historial completo del bucket.

Para más detalles sobre buckets, claves de acceso y el resto de operaciones, consulta la documentación.