Versionado de archivos: no pierdas nunca tus cambios

El versionado de ficheros guarda cada revisión para que puedas revertir sobreescrituras accidentales, eliminaciones y daños de ransomware. Actívalo a nivel de plataforma — S3 Versioning, Azure Blob Versioning, Google Cloud Storage Object Versioning, historial de versiones de Dropbox, versiones mayores/menores de SharePoint — y combínalo con reglas de ciclo de vida que caduquen las versiones antiguas tras 30-180 días. Sin versionado, un solo rm -rf o un cliente de sincronización con errores puede vaporizar años de trabajo en segundos, y la "copia de seguridad en la nube" que creías tener es solo una copia sincronizada del daño.

Qué hace realmente el versionado de plataforma

Cuando el versionado está activado, una sobreescritura no reemplaza el objeto — crea una nueva versión con un nuevo VersionId. Los bytes antiguos permanecen en disco, recuperables por ese ID. Una eliminación se convierte en un "marcador de eliminación" en lugar de una destrucción; las versiones anteriores siguen siendo restaurables hasta que las elimines explícitamente.

Esto importa porque la mayoría de la pérdida de datos no es un fallo catastrófico de hardware (la durabilidad de la nube se encarga de eso). Es alguien que guarda una hoja de cálculo vacía sobre una rellenada, o un script con un error que trunca mil ficheros, o un ransomware que cifra todo lo que puede alcanzar. El versionado te permite retroceder 30 días y continuar desde donde las cosas estaban bien.

El coste de conservar todas las versiones

Las versiones consumen almacenamiento, y el almacenamiento cuesta dinero. Un bucket con 10 TB de ficheros y edición activa puede acumular entre 30 y 50 TB de versiones en un año. La mitigación: reglas de ciclo de vida que caduquen las versiones no actuales tras un período determinado, o las muevan a niveles más baratos.

Una política práctica de ciclo de vida en S3:

• Versiones no actuales: pasar a S3 Standard-IA tras 7 días
• Versiones no actuales: pasar a Glacier Flexible Retrieval tras 30 días
• Versiones no actuales: eliminar tras 180 días
• Marcadores de eliminación sin versiones no actuales: eliminar tras 1 día

En Azure y GCS los equivalentes usan condiciones de antigüedad de blobVersion o Noncurrent. Modela el coste: 10 TB de versiones en S3 Standard son 230 USD/mes; en Glacier Flexible son 36 USD/mes. La transición de nivel vale unos minutos de YAML.

Versiones mayores frente a menores

Los sistemas orientados a documentos como SharePoint, Google Workspace y Notion distinguen las versiones mayores (publicadas) de las menores (borrador). Los borradores se acumulan entre hitos; las mayores representan un estado estable que alguien aprobó. Para contratos, documentos de política y especificaciones, esta distinción es muy valiosa — puedes compartir el enlace a la "versión mayor v3" públicamente mientras sigues editando el borrador v3.1, v3.2 en privado.

Usa las versiones mayores como punto de referencia para las partes externas. Bloquéalas con permisos de solo lectura o flujos de aprobación para que nadie sobreescriba accidentalmente el estado publicado. La columna "Requerir aprobación de contenido" de SharePoint es un clic; el flujo de aprobación de Google Drive es una configuración de 2 minutos.

Control de versiones para código fuente frente a documentos

Git funciona de maravilla para texto (código fuente, markdown, ficheros .tf) porque las diferencias son significativas por línea. Funciona mal para binarios: un fichero .psd de 50 MB registrado dos veces duplica el tamaño del repositorio, y git diff no puede ayudarte. Git LFS (Large File Storage) mueve los binarios a un almacén separado y conserva punteros en el repositorio — razonable para recursos artísticos, malo para documentos en general.

Para ficheros .docx, .xlsx, .pptx y .pdf, usa el versionado integrado de la plataforma en la nube en lugar de Git. SharePoint, Drive y Dropbox almacenan todos los deltas por versión de forma nativa y muestran una interfaz de línea de tiempo que los usuarios de negocio pueden navegar. Para contenido mixto (código más PDFs más ficheros de diseño), algunos equipos usan DVC o LakeFS como capas Git-para-datos sobre el almacenamiento de objetos — merece la pena investigar para equipos de ML y datos.

Retención vinculada a los calendarios de cumplimiento

Las normativas dictan cuánto tiempo deben vivir las versiones. La SEC Rule 17a-4 requiere los registros de corredores de bolsa durante 3-6 años. HIPAA retiene los registros un mínimo de 6 años. SOX exige 7 años para los registros financieros. El RGPD limita por el otro lado — no conserves datos personales más tiempo del necesario; en España, la LOPDGDD especifica plazos concretos para distintas categorías de datos que complementan lo establecido en el RGPD.

Etiqueta los ficheros sensibles para que las reglas de ciclo de vida respeten los mínimos y máximos normativos. Una etiqueta de S3 como retention-class: sox-7y puede impulsar las transiciones del ciclo de vida, las duraciones de Object Lock y la eliminación final. Usa S3 Object Lock con modo Compliance para copias regulatorias inmutables — ni siquiera los usuarios root pueden eliminar dentro del período de retención, que es exactamente lo que exigen las normas WORM (Write Once Read Many).

Protección contra ransomware mediante versiones

Un ataque de ransomware que alcanza tus clientes de sincronización cifrará los ficheros en el endpoint y enviará las versiones cifradas a la nube. El versionado te salva — las versiones anteriores al cifrado siguen existiendo. Pero solo si dos condiciones se cumplen: el versionado está activado antes del ataque, y la retención es lo suficientemente larga como para cubrir el tiempo de detección.

El tiempo de permanencia medio del ransomware en 2025 ronda los 11 días para empresas medianas. Una retención de versiones de 30 días es el mínimo; 90 días es más seguro. Combina el versionado con la protección contra eliminación (S3 MFA Delete, Azure soft delete con un administrador diferente) para que un atacante que comprometa una cuenta no pueda purgar el historial de versiones. Prueba la restauración trimestralmente — simula la eliminación de una carpeta de prueba y cronometra la recuperación.

Convenciones de nomenclatura para versiones compartidas

Cuando compartes una versión específica externamente — enviando a un cliente "la versión 3 aprobada del contrato" — necesitas un puntero estable que no cambie cuando alguien edite. Usa uno de estos tres patrones:

1. URL prefirmada a un VersionId específico (S3: ?versionId=...) — válida durante 7 días como máximo, inmutable
2. Una copia de la versión aprobada en un bucket /publicado/ separado con la versión en el nombre del fichero (contrato-v3.0-2026-12-15.pdf)
3. Una exportación a PDF como instantánea, para que los cambios posteriores no afecten a la copia compartida

Para compartir una vez una instantánea específica con alguien fuera de tu plataforma, las herramientas de transferencia cifradas de extremo a extremo envían un fichero específico con un enlace de un solo uso. HexaTransfer sirve para esto: carga la versión congelada, envía el enlace, y el destinatario obtiene exactamente lo que querías sin necesitar acceso a toda tu plataforma.

Monitorización y alertas sobre eventos de versionado

El historial de versiones solo es útil si te das cuenta de cuándo lo necesitas. CloudTrail (AWS), el Registro de actividad (Azure) y Cloud Audit Logs (GCP) registran cada evento de versionado. Alerta sobre tasas de eliminación inusuales — 10.000 llamadas DeleteObject en una hora probablemente no sea un usuario haciendo limpieza.

Construye un panel sencillo que muestre los recuentos de versiones por bucket, el almacenamiento total de versiones y los ratios de marcadores de eliminación. Un bucket donde los marcadores de eliminación de repente superan a los objetos activos es una señal de alarma: o bien se produjo una eliminación masiva, o la retención del versionado está a punto de purgar cosas que querías conservar. Los resúmenes semanales por correo superan con creces esperar a la auditoría trimestral.

El runbook de recuperación

Documenta el proceso de restauración antes de necesitarlo. Un buen runbook cubre:

1. Cómo listar las versiones (aws s3api list-object-versions, az storage blob list --include v)
2. Cómo restaurar un VersionId específico para que sea la versión actual (S3: copiar con --version-id)
3. Cómo restaurar en masa un prefijo entero a un punto en el tiempo (scripts usando filtros de marca de tiempo)
4. Cómo restaurar objetos eliminados (eliminar los marcadores de eliminación)
5. Quién tiene permiso para hacer cada cosa (normalmente no la misma persona que causó la pérdida)

Imprímelo. Recórrelo una vez al trimestre con un escenario ficticio. Cuando ocurra el evento real, la memoria muscular supera a leer la documentación bajo presión.

Pruébalo en hexatransfer.com — gratis, sin cuenta, máximo 10 GB.