> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Snapshots e políticas

> Instantâneos pontuais, restauração de um e os cronogramas que os fazem para você.

## Snapshots

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

<Tabs>
  <Tab title="Console">
    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`.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST /v1/snapshots
    { "volume": "5f8d2c1a-...", "name": "pre-upgrade" }
    ```
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic storage snapshot create --volume vol-1 --name pre-upgrade
    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    snap, err := storage.New(cfg).CreateSnapshot(ctx, &storage.SnapshotCreateRequest{
        Volume: volumeID,
        Name:     "pre-upgrade",
    })
    ```
  </Tab>
</Tabs>

<Steps>
  <Step title="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`).
  </Step>

  <Step title="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`.
  </Step>
</Steps>

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.

<Warning>
  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.
</Warning>

<a id="restoring-from-a-snapshot" />

### 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:

<Tabs>
  <Tab title="Console">
    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.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST /v1/volumes
    {
      "name": "app-data-restored",
      "volume_type": "ssd",
      "size_gb": 200,
      "source_snapshot": "7b1e9c4d-..."
    }
    ```
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic storage volume create \
      --name restored-01 --volume-type ssd --size-gb 100 \
      --source-snapshot snap-1
    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    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.
  </Tab>
</Tabs>

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.

<a id="snapshot-policies" />

## 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.

<Tabs>
  <Tab title="Console">
    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.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST /v1/snapshot-policies
    {
      "volume": "5f8d2c1a-...",
      "name": "nightly",
      "interval_minutes": 1440,
      "retention_count": 7,
      "retention_days": 30
    }
    ```
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic storage snapshot-policy create \
      --volume vol-1 --name nightly \
      --interval-minutes 1440 --retention-count 7
    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    pol, err := storage.New(cfg).CreateSnapshotPolicy(ctx, &storage.SnapshotPolicyCreateRequest{
        Volume:          volumeID,
        Name:            "nightly",
        IntervalMinutes: 1440,
        RetentionCount:  7,
    })
    ```
  </Tab>
</Tabs>

<ResponseField name="volume" type="up to 16 policies per volume" required>
  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`.
</ResponseField>

Você também pode definir agendamentos em cada novo volume de inicialização ou de dados ao [iniciar uma instância](/pt/compute/instances#snapshot-schedules-at-launch).

<ResponseField name="interval_minutes" type="1–43200" required>
  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.
</ResponseField>

<ResponseField name="retention_count" type="1–256" required>
  Quantos instantâneos dessa política devem ser mantidos. Quando uma corrida leva a contagem além disso, o mais antigo vai primeiro.
</ResponseField>

<ResponseField name="retention_days" type="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.
</ResponseField>

<Note>
  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.
</Note>

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.

<a id="what-retention-will-never-delete" />

### 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:

<Columns cols={2}>
  <Card title="Instantâneos que você tirou à mão" icon="shield">
    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.
  </Card>

  <Card title="Snapshots algo depende de" icon="git-branch">
    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.
  </Card>

  <Card title="O único snapshot mais novo" icon="clock">
    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.
  </Card>

  <Card title="Qualquer coisa, enquanto estiver em pausa" icon="pause">
    `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.
  </Card>
</Columns>

<Warning>
  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.
</Warning>

<a id="reading-a-schedules-state" />

### 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.

<Info>
  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.
</Info>

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.

<a id="resource-references" />

## 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.