Versionamento no S3: como funciona

⏱ 8 min de leitura

Apagou o arquivo errado? Sobrescreveu a versão boa de um documento com uma ruim? No object storage, há um recurso que torna esses acidentes reversíveis: o versionamento. Ele mantém o histórico de cada objeto, permitindo voltar no tempo quando algo dá errado.

Este artigo explica o que é o versionamento no S3, como ele funciona por baixo (com version IDs e delete markers), os três estados de um bucket, o impacto no custo e quando vale a pena ativar.

O que é versionamento no S3

Versionamento no S3 Versionamento no S3 é o recurso que mantém múltiplas variantes do mesmo objeto dentro de um bucket, preservando o histórico de cada arquivo. Com ele habilitado, cada gravação de um objeto (via PUT, POST ou Copy) gera um version ID único, e versões anteriores não são sobrescritas: ficam guardadas e podem ser restauradas. Ao apagar um objeto, o S3 não o remove de verdade; insere um delete marker (marcador de exclusão) que se torna a versão atual, enquanto a versão real permanece recuperável. Isso protege contra exclusão acidental e sobrescrita indevida. O versionamento vem desabilitado por padrão e precisa ser ativado explicitamente; um bucket pode estar em três estados: não versionado, versionamento habilitado ou versionamento suspenso. Cada versão é um objeto inteiro (não um diff), então múltiplas versões multiplicam o custo de armazenamento, o que torna comum combinar versionamento com regras de lifecycle para expirar versões antigas. O versionamento também é pré-requisito do Object Lock (imutabilidade WORM). Diversos provedores de object storage compatível com S3 suportam versionamento da mesma forma.

Versionamento no S3 é o recurso que mantém múltiplas variantes do mesmo objeto dentro de um bucket. Em vez de cada gravação sobrescrever a anterior, o versionamento preserva o histórico: cada versão do objeto fica guardada e pode ser recuperada.

A função é proteger contra dois acidentes clássicos do dia a dia: a exclusão acidental (alguém apaga algo que não devia) e a sobrescrita indevida (uma versão boa é substituída por uma ruim ou corrompida). Com versionamento, esses erros deixam de ser catastróficos, porque sempre há uma versão anterior para restaurar. Para entender a API que opera esse recurso, vale o conteúdo sobre a API S3.

Version ID: como cada versão é identificada

O mecanismo central do versionamento é o version ID (identificador de versão). Quando o versionamento está habilitado e você grava um objeto, o S3 atribui automaticamente um version ID único àquela versão.

Na prática, isso significa que o mesmo objeto (mesma chave/key) pode ter várias versões coexistindo no bucket, cada uma com seu version ID. A versão mais recente é a versão atual (a que você acessa por padrão), mas as anteriores continuam acessíveis se você especificar o version ID delas.

Quando você faz uma leitura simples (GET) sem especificar versão, o S3 retorna sempre a versão atual. Para acessar ou restaurar uma versão específica anterior, você indica o version ID correspondente. É assim que o histórico fica disponível: cada versão tem um endereço próprio.

O delete marker: por que apagar não apaga

Aqui está o comportamento mais importante (e mais contraintuitivo) do versionamento. Com versionamento habilitado, apagar um objeto não o remove de verdade.

Quando você executa um DELETE em um bucket versionado, o S3 não exclui o objeto. Em vez disso, ele insere um delete marker (marcador de exclusão), que se torna a nova versão atual do objeto. A partir daí, uma leitura simples não encontra o objeto (parece que foi apagado), mas a versão real continua lá, guardada, com seu version ID intacto.

Isso tem uma consequência poderosa: para "desfazer" a exclusão, basta remover o delete marker, e a versão anterior volta a ser a atual. O objeto reaparece como se nunca tivesse sido apagado. É essa mecânica que torna a exclusão acidental totalmente reversível em buckets versionados.

Para apagar um objeto de verdade (permanentemente) em um bucket versionado, é preciso excluir explicitamente a versão específica pelo seu version ID, não apenas fazer um DELETE simples. Essa distinção entre "esconder com delete marker" e "apagar a versão de verdade" é fundamental para entender o versionamento.

Os três estados de um bucket

Em relação ao versionamento, um bucket pode estar em três estados distintos:

Não versionado (padrão)

O estado inicial de todo bucket. Não há versionamento: cada gravação sobrescreve a anterior, e apagar remove de verdade. Sem histórico, sem proteção contra acidente.

Versionamento habilitado

O versionamento está ativo. Cada gravação gera uma nova versão com version ID, exclusões inserem delete markers, e todo o histórico é preservado. É o estado que oferece proteção.

Versionamento suspenso

O versionamento foi ativado e depois pausado. As versões antigas (criadas enquanto estava habilitado) continuam preservadas, mas as novas gravações recebem um version ID nulo e passam a se comportar como em um bucket não versionado (sobrescrevendo). É um meio-termo, usado em situações específicas.

Um detalhe importante: uma vez que o versionamento é habilitado em um bucket, ele não pode ser totalmente desativado, apenas suspenso. As versões já criadas permanecem. Por isso, ativar versionamento é uma decisão que vale planejar, especialmente pelo impacto no custo.

O impacto no custo: cada versão conta

Este é o ponto que mais surpreende quem ativa versionamento sem pensar: cada versão é um objeto inteiro, não um diff (diferença) da anterior.

Em sistemas de controle de versão de código, como o Git, cada versão geralmente guarda só as diferenças. No versionamento do S3, não é assim: se você tem três versões de um arquivo de 1 GB, ocupa (e paga por) 3 GB, porque cada versão é uma cópia completa. As versões se acumulam, e o custo de armazenamento cresce com elas.

Isso significa que versionamento sem gestão pode inflar a fatura silenciosamente: versões antigas que ninguém precisa continuam ocupando espaço indefinidamente. A solução padrão é combinar versionamento com regras de lifecycle, que expiram (apagam) automaticamente versões antigas após um período definido, mantendo o histórico útil sem deixar o custo crescer sem controle. Esse mecanismo de automação será detalhado no artigo sobre lifecycle policies. Em provedores com preço único e sem egress fee, o cálculo fica mais simples, mas o princípio permanece: versões acumuladas ocupam espaço, e vale ter política de expiração.

Quando ativar o versionamento

O versionamento faz sentido em vários cenários, mas não é obrigatório para todos. Vale ativar quando:

Os dados são críticos e a exclusão acidental seria grave. Documentos importantes, configurações, dados de produção: ter como voltar atrás compensa o custo extra.

Você vai usar Object Lock (imutabilidade). O versionamento é pré-requisito técnico do Object Lock. Se você quer imutabilidade WORM contra ransomware, precisa do versionamento ligado. Para entender a imutabilidade, vale o conteúdo sobre Object Lock e imutabilidade no S3.

O bucket recebe sobrescritas frequentes e você quer histórico. Quando arquivos são atualizados com regularidade e ter as versões anteriores tem valor (auditoria, recuperação de versões boas).

Por outro lado, para dados imutáveis por natureza (que nunca são sobrescritos, como logs append-only ou mídias que só são adicionadas) ou dados descartáveis, o versionamento pode adicionar custo sem benefício proporcional. A decisão deve pesar o valor da proteção contra o custo das versões acumuladas. Quando ativado, acompanhar com regras de expiração é a boa prática. Para a estratégia de proteção mais ampla, vale o conteúdo sobre backup imutável contra ransomware.

Versionamento no Object Storage S3 da EVEO

O Object Storage S3 da EVEO é compatível com a API S3 e suporta versionamento da mesma forma que o mercado conhece, incluindo o Object Lock nativo (que depende do versionamento) para imutabilidade WORM contra ransomware. As ferramentas que você já usa (Veeam, Commvault, Veritas, Restic, MSP360) operam o versionamento normalmente: basta trocar o endpoint.

Os diferenciais que importam quando se trata de versões acumuladas:

• Preço único e previsível: R$ 0,05 por GB, o que simplifica o cálculo do custo das versões armazenadas, sem surpresas.
• Sem egress fee: recuperar qualquer versão dos seus dados é gratuito, ao contrário das nuvens públicas.
• Sem cobrança por API: as operações de versionamento não pesam na fatura.
• Object Lock nativo: torne as versões imutáveis para proteção máxima.
• Soberania: dados e versões em data centers Tier III no Brasil (Cotia/SP, Osasco/SP, Curitiba/PR, Fortaleza/CE) mais Miami/FL, com suporte em português 24/7.

Para empresas que ativam versionamento e precisam de previsibilidade de custo, o preço único da EVEO torna o gerenciamento das versões mais simples, com economia que pode chegar a 80% em relação à nuvem global.

No fim, o versionamento é uma das proteções mais simples e eficazes contra o erro humano no object storage. Entender que o delete não apaga (apenas insere um marcador), que cada versão custa como um objeto inteiro, e que ele é a base do Object Lock, é o que permite usar o recurso com inteligência: ativando onde protege, gerenciando o custo com expiração de versões antigas, e combinando com imutabilidade quando a proteção precisa ser inviolável.

Perguntas frequentes sobre versionamento no S3

O que é versionamento no S3?

Versionamento no S3 é o recurso que mantém múltiplas variantes do mesmo objeto dentro de um bucket, preservando o histórico. Com ele habilitado, cada gravação gera uma versão com um version ID único, e as versões anteriores não são sobrescritas, ficando disponíveis para restauração. Protege contra exclusão acidental e sobrescrita indevida. Vem desabilitado por padrão e precisa ser ativado explicitamente.

O que é delete marker no versionamento?

Delete marker (marcador de exclusão) é o que o S3 cria quando você apaga um objeto em um bucket versionado. Em vez de remover o objeto, o S3 insere esse marcador, que se torna a versão atual, fazendo o objeto parecer apagado em uma leitura simples. A versão real continua guardada e pode ser recuperada removendo o delete marker. Por isso, em buckets versionados, apagar não apaga de verdade, apenas esconde.

Versionamento no S3 aumenta o custo?

Sim. Cada versão é um objeto inteiro, não um diff da anterior. Se você tem três versões de um arquivo de 1 GB, paga por 3 GB. As versões se acumulam e o custo cresce com elas. Por isso, é comum combinar versionamento com regras de lifecycle que expiram automaticamente versões antigas, mantendo o histórico útil sem deixar o custo crescer sem controle.

Versionamento é a mesma coisa que backup?

Não. Versionamento protege contra exclusão e sobrescrita acidental dentro do mesmo bucket e provedor. Se o bucket for comprometido, a conta invadida ou houver problema na região, as versões estão no mesmo lugar que os originais. Backup de verdade exige cópia em local separado, idealmente imutável (Object Lock) e seguindo a regra 3-2-1-1-0. Versionamento complementa o backup contra o erro humano do dia a dia, mas não o substitui.

Posso desativar o versionamento depois de ativar?

Não totalmente. Uma vez habilitado, o versionamento só pode ser suspenso, não removido por completo. No estado suspenso, as versões antigas (criadas enquanto estava habilitado) continuam preservadas, mas novas gravações recebem version ID nulo e passam a sobrescrever, como em um bucket não versionado. Por isso, ativar versionamento é uma decisão que vale planejar, considerando o impacto no custo das versões acumuladas.