Snapshots e políticas

Snapshots

Um instantâneo é uma cópia de um volume em um determinado momento:

Console
API
CLI
Go

Vá para Storage → Snapshots e escolha Create Snapshot, em seguida, escolha o Volume e dê um Name. A página do próprio volume tem um botão Create Snapshot que abre o mesmo formulário com esse volume já selecionado; ele está desabilitado a menos que o volume esteja available ou in_use.

POST /v1/snapshots
{ "volume": "5f8d2c1a-...", "name": "pre-upgrade" }

basaltic storage snapshot create --volume vol-1 --name pre-upgrade

snap, err := storage.New(cfg).CreateSnapshot(ctx, &storage.SnapshotCreateRequest{
    Volume: volumeID,
    Name:     "pre-upgrade",
})

Pegue-o

Permitido contra um volume em available ou in_use — você não precisa desacoplar para snapshot. O snapshot é criado de forma assíncrona (202, status creating).

Aguarde por disponibilidade

Pesquisa GET /v1/snapshots/{snapshot_id}. available significa que o snapshot está completo e pode ser restaurado; error significa uma falha de erro ativa — leia faults.

Os nomes de snapshot são fixos após a criação porque as políticas do IAM abordam snapshots por seus CRNs. Atualizações contendo name retornam um erro de validação, incluindo valores inalterados, vazios ou null. Os instantâneos existentes mantêm seus nomes atuais. Um nome de snapshot é único por volume, então nightly em dois volumes diferentes é bom. size_gb é o tamanho do volume congelado no momento em que o snapshot foi tirado — o volume pode ter sido estendido desde então, então não leia isso como o tamanho atual do volume, e não leia isso como o espaço que o snapshot ocupa.

A captura de um volume anexado captura o dispositivo como ele está naquele instante, incluindo qualquer coisa que o convidado tenha armazenado em buffer, mas ainda não tenha sido limpo. Para um banco de dados ou qualquer outra coisa com estado na memória, faça quietude ou flush dentro do convidado antes de tirar o snapshot se você precisar que ele seja consistente com o aplicativo.

Restaurar a partir de um instantâneo

Restaurar significa criar um novo volume a partir do instantâneo. Não há reversão no local:

Console
API
CLI
Go

Em Create Volume, alterne Source para From snapshot e escolha o Snapshot. Size (GB) deve ser pelo menos o tamanho do instantâneo e o Tier é escolhido por você — uma restauração não está vinculada ao nível em que o volume de origem estava.Storage → Snapshots também tem uma ação de linha Create volume from snapshot que abre o mesmo formulário com o instantâneo preenchido.

POST /v1/volumes
{
  "name": "app-data-restored",
  "volume_type": "ssd",
  "size_gb": 200,
  "source_snapshot": "7b1e9c4d-..."
}

basaltic storage volume create \
  --name restored-01 --volume-type ssd --size-gb 100 \
  --source-snapshot snap-1

vol, err := storage.New(cfg).CreateVolume(ctx, &storage.VolumeCreateRequest{
    Name:             "restored-01",
    VolumeType:       "ssd",
    SizeGB:           100,
    SourceSnapshot: basaltic.String(snapshotID),
})

Uma restauração é um novo volume, então a camada é sua para escolher — não precisa corresponder ao volume do qual o instantâneo veio.

O snapshot tem que estar available, e size_gb deve ser pelo menos o tamanho congelado do snapshot — você pode restaurar para um volume maior, nunca um menor. O volume restaurado registra source_snapshot_id, que também é o que impede a retenção de colher um snapshot do qual algo ainda depende.

Políticas de snapshots

Uma política é uma programação anexada a um volume: tire um instantâneo a cada interval_minutes, em seguida, mantenha no máximo retention_count dos instantâneos que a política criou.

Console
API
CLI
Go

Abra a guia Snapshot schedules do volume e escolha Create schedule. Preencha Name, Every (minutes), Keep e, opcionalmente, Also delete after (days) e escolha Create schedule.Cada linha tem ações para editar, pausar ou retomar e excluir essa programação. A edição abre suas configurações; Save aplica suas alterações.

POST /v1/snapshot-policies
{
  "volume": "5f8d2c1a-...",
  "name": "nightly",
  "interval_minutes": 1440,
  "retention_count": 7,
  "retention_days": 30
}

basaltic storage snapshot-policy create \
  --volume vol-1 --name nightly \
  --interval-minutes 1440 --retention-count 7

pol, err := storage.New(cfg).CreateSnapshotPolicy(ctx, &storage.SnapshotPolicyCreateRequest{
    Volume:          volumeID,
    Name:            "nightly",
    IntervalMinutes: 1440,
    RetentionCount:  7,
})

up to 16 policies per volume

obrigatório

Cada política tem seu próprio intervalo, configurações de retenção e estado habilitado. Os nomes devem ser exclusivos em toda a conta. As programações sobrepostas criam snapshots separados, cada um contando para sua cota e cobranças de snapshot. Uma décima sétima política retorna 409.

Você também pode definir agendamentos em cada novo volume de inicialização ou de dados ao iniciar uma instância.

1–43200

obrigatório

Um intervalo mínimo, não uma cadência exata. Um instantâneo aterrissa no intervalo ou depois dele e nunca antes, e pode chegar um minuto ou dois atrasado quando o passe de agendamento estiver ocupado. O mínimo é de um minuto porque é com essa frequência que o passe avalia os cronogramas; o máximo é de 30 dias.

1–256

obrigatório

Quantos instantâneos dessa política devem ser mantidos. Quando uma corrida leva a contagem além disso, o mais antigo vai primeiro.

0–3650, default 0

Um limite de idade opcional aplicado em cima da contagem: um instantâneo fora de qualquer janela é colhido. 0 significa sem idade limitada.

O primeiro snapshot aterrissa um intervalo a partir de agora. Anexar uma agenda não é em si uma solicitação de snapshot — use POST /v1/snapshots se você quiser um imediatamente.

Os nomes de políticas de snapshot também são fixos após a criação: eles formam o CRN da política usado pelo IAM. Ao editar uma programação, omita name; fornecendo-o, mesmo inalterado, vazio ou null, retorna um erro de validação. Você ainda pode alterar o intervalo, as configurações de retenção, a descrição, as tags e o estado ativado. As políticas existentes mantêm seus nomes atuais. Os snapshots agendados são chamados de <policy>-<UTC timestamp>, por exemplo, nightly-20260115T000000Z, e eles herdam as tags da política para que uma listagem diga qual programação os produziu sem uma segunda pesquisa.

O que a retenção nunca irá excluir

Uma agenda também é um apagador automático, então os limites do que ela pode remover importam mais do que os limites do que ela mantém:

Instantâneos que você tirou à mão

A retenção corresponde apenas a instantâneos que carregam o snapshot_policy_id dessa política. Um instantâneo criado por uma pessoa não tem nenhuma tag e nunca é um candidato, independentemente das tags que ele tenha.

Snapshots algo depende de

Um instantâneo a partir do qual um volume foi criado — incluindo uma restauração ainda em execução — é ignorado e reexaminado em uma execução posterior. Ele se torna colhível uma vez que o volume dependente desaparece.

O único snapshot mais novo

O snapshot mais recente está isento do limite de idade. Um volume que não pode ser capturado por mais tempo do que a janela nunca perde todo o seu histórico dessa forma.

Qualquer coisa, enquanto estiver em pausa

enabled: false impede que novas execuções de snapshot e exclusões de retenção sejam reivindicadas. O trabalho já reivindicado antes da pausa pode terminar. Outras políticas no mesmo volume continuam sendo executadas de forma independente.

A retomada de uma política pausada aplica a janela de retenção novamente na próxima execução. Se você diminuiu retention_count enquanto estava em pausa, tudo agora fora da janela é colhido nessa execução.

Lendo o estado de uma agenda

GET /v1/snapshot-policies/{policy_id} retorna onde a política está em seu ciclo:

Campo de jogo	O que ele diz a você
`next_run_at`	Quando o próximo snapshot deve ser feito.
`last_run_at`	Quando a política foi ativada pela última vez. Ausente até a primeira corrida.
`faults`	Por que uma execução não produziu nenhum snapshot. Esvaziado após uma corrida que teve sucesso. Sempre um `warning` — uma execução falhada deixa `enabled` sozinho e a política nunca relata `error`.

faults é o campo para verificar em uma programação que parou de produzir snapshots — ele carrega razões como uma cota de snapshots esgotada, ou um volume que estava no meio do extensão quando a janela apareceu. O envio, a execução e a retenção têm cada um seu próprio código e se recuperam de forma independente.

Código	Significado e recuperação
`SNAPSHOT_POLICY_DISPATCH_FAILED`	A política não pôde iniciar uma execução. A próxima janela tenta novamente.
`SNAPSHOT_POLICY_EXECUTION_FAILED`	Uma execução começou e não tirou nenhuma foto. Verifique a cota e o status do volume.
`SNAPSHOT_POLICY_RETENTION_FAILED`	Um instantâneo dentro da janela não pôde ser colhido. Mais tarde executa retenção de retenções.

A tabela Snapshot schedules mostra a próxima e a última execução de cada política e quaisquer falhas ativas, para que uma programação parada possa ser lida sem sair do console.

Uma janela perdida custa um snapshot, não um por janela perdida. next_run_at é re-estabelecido para now + interval_minutes cada vez que a política dispara, nunca para previous + interval, então uma programação que não poderia ser executada por seis horas leva um único instantâneo quando ele retoma em vez de uma explosão de recuperação. Alterar interval_minutes re-baseia a próxima execução agora também, então encurtar uma programação diária para horária tem efeito dentro da hora.

A exclusão de uma política separa a programação e mantém todos os instantâneos que ela já tirou — eles se tornam instantâneos comuns que você possui e nunca são recuperados novamente. Outras políticas no volume e seus snapshots permanecem inalteradas. O trabalho já reivindicado antes da exclusão pode terminar. Exclua os próprios snapshots se for isso que você quis dizer.

Referências de recursos

Use volume com um UUID, CRN ou nome exato de volume de propriedade da conta ao criar um instantâneo ou uma política. Os CRNs de snapshot incluem seu pai, por exemplo, crn:storage:sa-saopaulo-1:my-account:volume/data/snapshot/nightly. Os filtros de lista usam correspondências exatas de name e crn. Um filtro name de snapshot requer volume; snapshot_policy aceita um UUID de política, CRN ou nome de escopo de conta. As solicitações de restauração usam source_snapshot com um UUID ou CRN aninhado, já que elas não fixam um volume de origem. CRNs mal formados retornam 400; CRNs válidos fora da conta, região ou tipo de recurso solicitado retornam uma página vazia.

Primeiros passos

Produtos

Plataforma

Ajuda

Snapshots e políticas

Snapshots

Restaurar a partir de um instantâneo

Políticas de snapshots

O que a retenção nunca irá excluir

Instantâneos que você tirou à mão

Snapshots algo depende de

O único snapshot mais novo

Qualquer coisa, enquanto estiver em pausa

Lendo o estado de uma agenda

Referências de recursos

​Snapshots

​Restaurar a partir de um instantâneo

​Políticas de snapshots

​O que a retenção nunca irá excluir

Instantâneos que você tirou à mão

Snapshots algo depende de

O único snapshot mais novo

Qualquer coisa, enquanto estiver em pausa

​Lendo o estado de uma agenda

​Referências de recursos

Snapshots

Restaurar a partir de um instantâneo

Políticas de snapshots

O que a retenção nunca irá excluir

Lendo o estado de uma agenda

Referências de recursos