Versionamento de ficheiros: nunca mais perca alterações

O versionamento de ficheiros guarda cada revisão para que possa reverter sobrescritas acidentais, eliminações e danos de ransomware. Ative-o ao nível da plataforma — S3 Versioning, Azure Blob Versioning, Google Cloud Storage Object Versioning, histórico de versões do Dropbox, versões major/minor do SharePoint — e emparelhe com regras de ciclo de vida que expiram versões antigas após 30-180 dias. Sem versionamento, um único rm -rf ou um cliente de sincronização com erros pode vaporizar anos de trabalho em segundos, e o "backup na cloud" que pensava ter é apenas uma cópia sincronizada dos danos.

O Que o Versionamento de Plataforma Realmente Faz

Quando o versionamento está ativado, uma sobreescrita não substitui o objeto — cria uma nova versão com um novo VersionId. Os bytes antigos permanecem no disco, recuperáveis por esse ID. Uma eliminação torna-se um "marcador de eliminação" em vez de uma destruição; as versões anteriores permanecem restauráveis até as purgar explicitamente.

Isto importa porque a maioria das perdas de dados não é falha catastrófica de hardware (a durabilidade da cloud trata disso). É alguém a gravar uma folha de cálculo vazia por cima de uma preenchida, ou um script com um bug que trunca mil ficheiros, ou ransomware que encripta tudo o que consegue alcançar. O versionamento permite voltar 30 dias atrás e recomeçar onde as coisas faziam sentido.

O Custo de Manter Cada Versão

As versões consomem armazenamento, e o armazenamento custa dinheiro. Um bucket com 10 TB de ficheiros com edição ativa pode acumular 30-50 TB de versões ao longo de um ano. A mitigação: regras de ciclo de vida que expiram versões não atuais após um período definido, ou as movem para camadas mais baratas.

Uma política de ciclo de vida S3 prática:

• Versões não atuais: transição para S3 Standard-IA após 7 dias
• Versões não atuais: transição para Glacier Flexible Retrieval após 30 dias
• Versões não atuais: eliminar após 180 dias
• Marcadores de eliminação sem versões não atuais: eliminar após 1 dia

Para Azure e GCS, os equivalentes usam condições de idade blobVersion ou Noncurrent. Modele o custo: 10 TB de versões no S3 Standard são 230 EUR/mês; no Glacier Flexible são 36 EUR/mês. A transição de camada vale alguns minutos de YAML.

Versões Major vs Minor

Sistemas orientados a documentos como SharePoint, Google Workspace e Notion distinguem versões major (publicadas) de minor (rascunho). Os rascunhos acumulam-se entre marcos; as major representam um estado estável aprovado por alguém. Para contratos, documentos de política e especificações, esta distinção é valiosa — pode partilhar a ligação "major v3" publicamente enquanto continua a editar o rascunho v3.1, v3.2 de forma privada.

Use versões major como ponto de referência para partes externas. Bloqueie-as com permissões de apenas leitura ou fluxos de aprovação para que ninguém sobrescreva acidentalmente o estado publicado. A coluna "Exigir aprovação de conteúdo" do SharePoint é um clique; o fluxo de aprovação do Google Drive é uma configuração de 2 minutos.

Controlo de Versões para Código-Fonte vs Documentos

O Git funciona magnificamente para texto (código-fonte, markdown, ficheiros .tf) porque os diffs são significativos linha a linha. Funciona mal para binários: um ficheiro .psd de 50 MB confirmado duas vezes duplica o tamanho do repositório, e git diff não ajuda. O Git LFS (Large File Storage) move os binários para um store separado e mantém ponteiros no repositório — sensato para assets de arte, mau para documentos em geral.

Para ficheiros .docx, .xlsx, .pptx e .pdf, use o versionamento integrado da plataforma cloud em vez do Git. O SharePoint, Drive e Dropbox armazenam nativamente deltas por versão e renderizam uma UI de linha do tempo que os utilizadores de negócio conseguem navegar. Para conteúdo misto (código mais PDFs mais ficheiros de design), algumas equipas usam DVC ou LakeFS como camadas Git-para-dados sobre armazenamento de objetos — vale investigar para equipas de ML e dados.

Retenção Ligada a Calendários de Conformidade

Os regulamentos ditam quanto tempo as versões devem viver. A SEC Rule 17a-4 exige registos de corretores por 3-6 anos. A HIPAA retém registos por no mínimo 6 anos. A SOX quer 7 anos para registos financeiros. O RGPD limita pela outra direção — não guarde dados pessoais mais tempo do que o necessário, conforme o princípio da limitação do prazo de conservação do Artigo 5.º(1)(e); em Portugal, a CNPD supervisiona esta conformidade.

Etiquete ficheiros sensíveis para que as regras de ciclo de vida respeitem os mínimos e máximos regulatórios. Uma etiqueta S3 como retention-class: sox-7y pode conduzir transições de ciclo de vida, durações de Object Lock e eventual eliminação. Use o S3 Object Lock com Compliance Mode para cópias regulatórias imutáveis — mesmo os utilizadores root não conseguem eliminar dentro do período de retenção, que é exatamente o que as regras WORM (Write Once Read Many) exigem.

Proteção Contra Ransomware Através de Versões

Um ataque de ransomware que alcança os clientes de sincronização encriptará ficheiros no endpoint e enviará as versões encriptadas para a cloud. O versionamento salva-o — as versões pré-encriptação ainda existem. Mas apenas se duas coisas forem verdade: o versionamento está ativado antes do ataque, e a retenção é suficientemente longa para cobrir o tempo de deteção.

O tempo médio de permanência de ransomware em 2025 situa-se em cerca de 11 dias para empresas de mercado médio. Uma retenção de versões de 30 dias é o mínimo; 90 dias é mais seguro. Emparelhe o versionamento com proteção contra eliminação (S3 MFA Delete, eliminação suave do Azure com um admin diferente) para que um atacante que comprometa uma conta não possa purgar o histórico de versões. Teste o restauro trimestralmente — simule a eliminação de uma pasta de teste e cronometre a recuperação.

Convenções de Nomes para Versões Partilhadas

Quando partilha uma versão específica externamente — enviando a um cliente "o v3 aprovado do contrato" — precisa de um ponteiro estável que não mude quando alguém edita. Use um de três padrões:

1. URL pré-assinado para um VersionId específico (S3: ?versionId=...) — válido por no máximo 7 dias, imutável
2. Uma cópia da versão aprovada para um bucket /publicado/ separado com a versão no nome do ficheiro (contrato-v3.0-2026-12-15.pdf)
3. Um snapshot de exportação PDF para que alterações posteriores não afectem a cópia partilhada

Para partilha única de um snapshot específico com alguém fora da plataforma, ferramentas de transferência com cifração ponta a ponta enviam um ficheiro específico com uma ligação de utilização única. O HexaTransfer serve para isto: carregue a versão congelada, envie a ligação, e o destinatário recebe exatamente o que pretendia sem precisar de acesso a toda a plataforma.

Monitorização e Alertas em Eventos de Versão

O histórico de versões só é útil se notar quando precisar dele. O CloudTrail (AWS), Activity Log (Azure) e Cloud Audit Logs (GCP) registam cada evento de versionamento. Alerte sobre taxas incomuns de eliminação — 10.000 chamadas DeleteObject numa hora provavelmente não é um utilizador a fazer limpeza.

Construa um dashboard simples a mostrar contagens de versões por bucket, armazenamento total de versões e rácios de marcadores de eliminação. Um bucket onde os marcadores de eliminação de repente excedem os objetos ativos é um sinal de problema: ou ocorreu uma eliminação em massa, ou a retenção de versões está prestes a purgar coisas que pretendia manter. Resumos semanais por e-mail superam esperar pela auditoria trimestral.

O Runbook de Recuperação

Documente o processo de restauro antes de precisar dele. Um bom runbook cobre:

1. Como listar versões (aws s3api list-object-versions, az storage blob list --include v)
2. Como restaurar um VersionId específico para ser a versão atual (S3: copiar com --version-id)
3. Como restaurar em massa um prefixo inteiro para um ponto no tempo (scripts usando filtros de timestamp)
4. Como restaurar objetos eliminados (remover marcadores de eliminação)
5. Quem tem permissão para cada passo (geralmente não a mesma pessoa que causou a perda)

Imprima-o. Percorra-o uma vez por trimestre com um cenário falso. Quando o evento real acontece, a memória muscular supera ler documentação sob pressão.

Experimente em hexatransfer.com — gratuito, sem conta necessária, máximo de 10 GB.