Resumo

  • A Fly.io permite recuperar o identificador de um volume excluído por 24 horas. Com o ID já conhecido, é possível localizar os snapshots enquanto durar a retenção de cada cópia.
  • A retenção automática padrão é de cinco dias, configurável entre um e 60. Apagar o volume não reinicia esse prazo; mudar a configuração não prolonga snapshots antigos.
  • Volume pendente de exclusão deixa de gerar cobrança de volume. Armazenamento de snapshots tem medição separada, e restaurar uma cópia exige criar um novo volume.

Uma boa faxina na nuvem tem a aparência de uma pequena vitória. O recurso que ninguém usa desaparece, a conta perde uma linha e o responsável fecha o chamado. Na Fly.io, há um detalhe que merece ficar de fora do saco de lixo: o identificador do volume. A documentação informa que, depois da exclusão, ele pode ser recuperado durante 24 horas. Os snapshots podem durar mais. O balcão de informações fecha antes de o depósito ficar vazio.

Esse desencontro é o assunto. A plataforma permite usar um ID conhecido para encontrar snapshots ainda retidos de um volume apagado. Portanto, quem leva a referência consigo conserva uma rota documentada até a cópia. Quem a deixa para buscar depois depende de uma janela bem menor. O ativo sobrevivente e seu endereço deixam de ter o mesmo prazo de conveniência.

O número faz parte da entrega

Uma equipe pode registrar com cuidado quem aprovou a exclusão e quanto pretende economizar, mas esquecer o dado que torna a recuperação praticável. O identificador parece burocracia porque não contém o banco de dados. Seu valor aparece justamente quando o banco deixou de estar no lugar habitual.

O ID também não concede acesso por conta própria. É uma referência, não uma credencial, uma autorização ou um atestado de integridade. A recuperação precisa de uma cópia ainda existente, de permissões adequadas e de alguém capaz de usá-la. Um inventário útil conecta essas peças: volume, aplicação, snapshot, horário da captura e pessoa responsável pela restauração. Uma sequência de caracteres abandonada numa conversa não faz esse trabalho sozinha.

A documentação pública consultada não promete recuperação assistida pelo suporte quando o cliente perdeu o ID; uma garantia desse tipo mudaria o risco de depender do atendimento depois das 24 horas. O caminho descrito hoje favorece quem faz a passagem de bastão antes de apagar.

Cinco dias não começam no botão de excluir

Os snapshots automáticos diários vêm habilitados por padrão. A retenção padrão é de cinco dias, e a configuração aceita de um a 60. Há duas tentações comerciais nesse número. A primeira é anunciar cinco dias como se fossem uma franquia nova concedida após a exclusão do volume. A segunda é subir a retenção para 60 e imaginar que todas as cópias antigas receberam férias prolongadas. Nenhuma das duas corresponde ao funcionamento documentado.

Cada snapshot tem seu próprio tempo de vida. Uma cópia já envelheceu quando o volume é apagado; sobra apenas a retenção restante. E alterações no prazo valem para novos snapshots. O estoque antigo mantém o vencimento anterior. A configuração expressa uma regra para produção futura, não uma renegociação retroativa com os arquivos que já estão na prateleira.

Considere uma mudança hipotética de cinco para 60 dias. O painel pode mostrar 60 enquanto uma cópia anterior continua perto de vencer. A evidência necessária é o inventário de snapshots existentes, com seus horários e prazos, além da configuração atual. Até a configuração no Fly Launch tem alcance específico: mudanças usadas para criar volumes novos no deploy não reescrevem automaticamente o histórico dos antigos.

Há ainda o estado da captura. Um snapshot solicitado sob demanda passa por waiting, running e created. Pedir a cópia e ter a cópia pronta são etapas distintas. Apagar uma aplicação com base apenas no pedido de captura troca um procedimento por uma aposta. O recibo interessante é o de conclusão.

A semana pertence a outra operação

O estado pending_destroy também pede leitura cuidadosa. Na exclusão feita pelo usuário, o volume passa 24 horas nesse estado antes da destruição permanente. Em uma migração de host conduzida pela plataforma, o volume de origem fica retido por uma semana.

A semana protege aquela operação de migração. Transportá-la para a rotina de exclusão do cliente inventaria uma semana de resgate que a documentação não oferece. O mesmo nome de estado participa de dois processos com motivos e durações diferentes. Sistemas adoram reaproveitar nomes; apresentações comerciais adoram esquecer o contexto.

Mesmo dentro da janela correta, o produto de recuperação é outro volume. A restauração cria um volume novo, de tamanho igual ou maior. Ainda é preciso anexá-lo, iniciar a aplicação e verificar se os dados atendem ao uso esperado. A existência do snapshot encerra apenas uma parte da história. A empresa compra continuidade quando consegue transformar aquela cópia em serviço útil.

A economia tem duas linhas

Volumes são cobrados proporcionalmente por hora, inclusive quando estão desanexados ou quando a máquina está parada. Em pending_destroy, deixam de gerar cobrança de volume. Assim, excluir um recurso de fato pode resolver uma despesa que simplesmente desligar a máquina não resolveria.

Snapshots têm cobrança própria de armazenamento, também proporcional por hora, após a franquia gratuita aplicável. As cópias são incrementais: o armazenamento acompanha os dados alterados, não uma multiplicação automática do tamanho nominal por cada ponto de recuperação. A consequência financeira precisa é uma separação de contas. Encerrar a cobrança do volume não zera, por definição, toda despesa ligada às cópias remanescentes.

Essa despesa residual compra tempo. Para aproveitá-lo, alguém precisa conservar o meio de localizar a cópia. Pagar pela retenção e perder a referência é uma maneira bastante moderna de alugar uma saída de emergência e esquecer onde fica a porta.

Também é preciso comprar o tempo certo. Uma retenção longa conserva versões antigas; não captura as gravações ocorridas desde o último snapshot diário. Frescor e duração são variáveis diferentes. A documentação de volumes explica ainda a ligação ao hardware local e a relação de um volume com uma Machine. Um fork gera uma cópia independente, sem sincronização contínua por esse simples ato. A arquitetura concreta importa mais que a palavra tranquilizadora “backup”.

O cadastro primário da RIPE NCC identifica Fly.io, Inc e serve de base para a identidade da organização tratada aqui. A ficha de associação não localiza os dados de um cliente. Os prazos e comportamentos acima vêm das páginas operacionais da própria Fly.io. É nesses pequenos verbos — consultar, reter, criar, excluir — que a promessa de portabilidade encontra seu trabalho de verdade.

Fontes primárias