Visão geral dos backups

Nesta página, você vai saber o que é um backup, como ele funciona, alguns casos de uso comuns e práticas recomendadas para criar e usar backups. Para saber como criar e gerenciar backups e como restaurar uma instância do Filestore de um backup, consulte Fazer backup de dados para recuperação de desastres.

O que é um backup?

Um backup do Filestore é uma cópia de um compartilhamento de arquivos que inclui todos os dados e metadados do compartilhamento de arquivos a partir do momento em que o backup é criado.

Depois de criar um backup de um compartilhamento de arquivos, é possível modificar ou excluir o compartilhamento de arquivos original sem afetar o backup.

É possível usar um backup para restaurar um compartilhamento de arquivos em uma nova instância do Filestore ou, para instâncias de nível básico, na origem de um compartilhamento de arquivos existente.

Os backups são recursos regionais que permanecem na região especificada no momento da criação. É possível criar backups na mesma região da instância do Filestore ou em outra região para reduzir o risco de perda de dados.

Os backups são globalmente endereçáveis e podem ser usados para restaurar compartilhamentos de arquivos em qualquer região, mas não podem ser compartilhados entre projetos.

Preços

As cobranças de transferência de rede se aplicam ao tráfego de rede entre regiões. Para mais detalhes, consulte a página Preços.

Criação do backup

O primeiro backup criado é uma cópia completa de todos os dados e metadados de um compartilhamento de arquivos. Cada backup subsequente copia as mudanças feitas nos dados desde o backup anterior.

Cadeias de backup

Um grupo de backups associados à mesma instância, região e CMEK (se usada) é chamado de cadeia de backup.

Uma cadeia de backup reside em um único bucket e região do Cloud Storage e pode estar localizada fora da região usada para armazenar a instância de origem.

Todos os níveis de serviço oferecem suporte a várias cadeias de backup, permitindo armazenar os backups de uma instância em várias regiões.

Sempre que um backup é criado, o anterior é verificado para mudanças diferenciais e incrementais:

  • Mudanças diferenciais:incluem alterações feitas nos arquivos do compartilhamento, como edições, adições ou exclusões de arquivos.

  • Mudanças incrementais:incluem mudanças no armazenamento no bucket em que os dados de backup estão localizados. Isso pode incluir a remoção de dados duplicados referenciados anteriormente na cadeia.

Toda vez que você salva um backup na mesma cadeia, o backup anterior é verificado para mudanças diferenciais e incrementais. Nesses casos, não é necessário fazer uma cópia completa.

No entanto, armazenar os dados de uma instância em várias cadeias de backup implica que você está salvando e armazenando backups em locais alternados.

Cada vez que você cria um novo backup em um local alternado, uma cópia completa do backup é gerada novamente. Aguarde uma latência maior nas operações de backup create ao alternar entre cadeias de backup.

Os dados inalterados contidos nos backups anteriores são referenciados, mas não copiados para os backups mais recentes. Se um backup mais antigo for excluído, os dados exclusivos dele serão copiados para o próximo backup mais recente, e todas as referências de dados internas serão atualizadas automaticamente.

Internamente, o histórico de uma cadeia de backup é rastreado usando snapshots, que consomem capacidade na instância de origem.

A criação do backup é instantânea, mas é preciso um período proporcional à quantidade de dados copiados para que o backup esteja disponível para uso. Durante esse período, o backup passa por três estados:

Estado Duração Descrição
Criando Alguns segundos Capturar o estado atual do compartilhamento de arquivos. As novas alterações nos dados do compartilhamento de arquivos podem ou não ser incluídas no backup. As gravações estáveis reconhecidas pela instância antes do início do backup são incluídas.
Finalizando Depende do tamanho Fazer upload dos dados para o backup. As novas alterações nos dados do compartilhamento de arquivos não são incluídas no backup.
Ready Até que o backup seja excluído O backup está pronto para uso.

Após a criação, os backups do nível básico são compactados automaticamente para reduzir os custos. O desempenho da instância pode ser reduzido ao criar um backup para instâncias nos níveis de serviço zonal, regional e empresarial. Criar um backup não afeta a disponibilidade ou o desempenho das instâncias do nível básico.

Como lidar com dados redundantes

Por padrão, os backups são incrementais para evitar o faturamento de dados redundantes e minimizar o uso de espaço de armazenamento. Para garantir a confiabilidade do histórico de mudanças subjacente, um backup pode capturar ocasionalmente uma cópia completa da instância.

Para mais informações, consulte Comparar snapshots e backups.

Exclusão de backup

Os backups são recursos no nível do projeto, não um sub-recurso da instância de origem, e exigem armazenamento separado. Como resultado, o ciclo de vida de um backup não está vinculado ao da instância de origem. A exclusão da origem não exclui os backups associados. Se você quiser excluir um backup, faça uma operação de exclusão explícita no backup, não na instância.

Exclua os backups indesejados. Se uma instância de origem for excluída, os backups restantes continuarão acumulando taxas.

A exclusão de um backup é permanente e não pode ser desfeita. Se a exclusão de um backup falhar, o status será marcado como invalid. Nesse caso, repita a operação delete.

Consistência no backup

Os backups do Filestore têm semântica de consistência NFSv3 e NFSv4.1. Antes de um backup ser iniciado, qualquer gravação que a instância do Filestore reconhece como gravada no armazenamento estável ou que é seguida por um COMMIT reconhecido é incluída no backup. Para mais detalhes, consulte a seção 3.3.7 do NFSv3 RFC-1813 ou Sobre protocolos de sistema de arquivos compatíveis.

Casos de uso comuns

As seções a seguir descrevem casos de uso comuns para backups.

Fazer backup de dados para recuperação de desastres

Imagine que você tem uma instância do Filestore em us-west1-c e quer proteger os dados contra desastres que afetam essa região. Você pode agendar um job que crie backups desta instância regularmente para uma região remota, como us- east1. Se ocorreu um desastre que envolve us-west1-c, é possível criar uma nova instância em outro local a partir de qualquer backup anterior.

Fazer backup de dados para proteção contra alterações acidentais

Se você quiser proteger os dados do Filestore contra alterações não intencionais, programe um job que crie backups da instância regularmente. Se você perder dados, poderá navegar na lista de backups para identificar aquele com a versão do arquivo necessária. Em seguida, crie uma instância do Filestore com base no backup, ative-a no mesmo cliente da instância original e copie o arquivo.

Antes de copiar o arquivo, use o comando diff do Linux nos dois pontos de montagem para verificar as diferenças entre os dados da instância original e os dados restaurados do backup. Depois que os dados forem recuperados, será possível excluir a instância restaurada e criar um novo backup para preservar o estado atual dos dados para uso futuro.

Como alternativa, você pode fazer uma restauração no local, em que os dados de backup são restaurados diretamente para a instância original do Filestore, substituindo todos os dados dela pelos dados do backup. Recomendamos que você crie um backup dos dados mais recentes antes de realizar uma restauração no local, porque todos os dados não armazenados serão perdidos.

Criar clones para desenvolvimento e teste

Imagine que você tenha uma configuração de banco de dados em uma instância do Filestore que exiba tráfego de produção. Se você quiser executar um teste com um banco de dados como entrada, poderá criar uma nova instância do Filestore a partir de um backup da instância de produção para o teste. Dessa maneira, o uso do teste não interfere na produção.

Da mesma forma, é possível usar backups para análise e investigação off-line sem afetar a produção.

Migração de dados

Depois de criar uma instância do Filestore, não será possível mudar o local ou o nível de serviço. Para migrar os dados para outra região, crie um backup deles e use o backup para criar uma instância do Filestore ou restaurá-la para uma instância atual.

Limitações do recurso

Os backups do Filestore estão em disponibilidade geral (GA) para todos os níveis de serviço.

Os backups do Filestore não podem ser combinados com o recurso compartilhamento múltiplo do Filestore.

As seções a seguir abordam outras limitações de recursos relacionadas a desempenho, armazenamento, capacidade, criptografia e outros tópicos em detalhes.

Desempenho

  • Em instâncias muito usadas, o desempenho pode ser reduzido em até 15% durante o upload de um backup. O desempenho da instância de nível Básico não é afetado pelas operações de backup create.

  • Armazenar os dados de uma instância em várias cadeias de backup afeta o desempenho do backup. Aguarde uma latência maior nas operações de backup create ao alternar entre cadeias de backup.

  • Operações de instância, como restore ou delete, podem ser adiadas até que uma operação de backup create seja concluída.

  • Em alguns casos, as operações delete podem levar até 24 horas para serem concluídas.

Simultaneidade de operações

  • As operações de backup delete associadas à mesma instância de origem precisam ser realizadas uma de cada vez.

  • As operações de backup em massa delete em uma cadeia de backup não são compatíveis. Enquanto uma operação delete estiver pendente, qualquer nova operação delete na mesma cadeia de backup vai retornar um erro RESOURCE_EXHAUSTED. Isso independe de a instância de origem ter sido excluída. Se a instância de origem tiver sido excluída, você vai receber um erro FAILED_PRECONDITION.

    O Filestore oferece suporte a operações simultâneas de backup delete quando os backups referenciam instâncias de origem separadas.

    Por exemplo, uma instância rotulada como Source1 tem dados de backup referenciados em Backup1 e Backup2. Source2 tem dados de backup referenciados em Backup3 e Backup4. Não é possível excluir Backup1 e Backup2 em paralelo, mas Backup2 e Backup3 podem ser excluídos.

  • As operações de backup create e delete iniciadas na mesma cadeia de backup podem ser executadas simultaneamente. Quando você já começou a criar um novo backup, é necessário aguardar a conclusão da operação para excluir o backup mais recente. Isso ocorre porque o backup mais recente contém os dados mais importantes necessários para concluir a operação de backup do create. Se você tentar excluir o backup mais recente, vai receber o erro FAILED_PRECONDITION.

    Por exemplo,Source1 tem uma cadeia de backup composta por Backup1 e Backup2. Quando você inicia uma operação de create para Backup3, não é possível excluir Backup2 até que a operação de create seja concluída.

  • Para mais informações sobre limites de taxa de operação, consulte Limites de taxa de operação para backups.

Armazenamento

  • É possível restaurar um backup de uma instância básica para a instância de origem do mesmo nível de serviço, uma instância já existente ou uma nova instância. Se você escolher uma nova instância, poderá escolher entre uma instância básica de HDD e uma básica de SSD, independentemente do nível da instância de origem.

  • Não é possível restaurar instâncias zonais, regionais e empresariais para uma instância de origem ou atual, apenas para uma nova. O nível da nova instância não precisa corresponder ao nível da instância de origem. Por exemplo, é possível restaurar o backup de uma instância regional para uma zonal. A capacidade provisionada da nova instância precisa ser igual ou maior que a da instância de origem.

Capacidade

  • Os backups criados para instâncias zonais, regionais e empresariais podem consumir a capacidade da instância. Essa capacidade varia de acordo com o escopo das mudanças feitas nos dados desde a criação do backup. Mais especificamente, quando um backup é criado, o Filestore cria um snapshot interno do sistema de arquivos que também ocupa uma parte da capacidade disponível da instância.

  • O tamanho do snapshot também é relativo ao escopo das mudanças feitas nos dados no compartilhamento desde a criação do último backup. Esse snapshot continua existindo até que o próximo backup seja criado e enviado.

  • Todos os dados referenciados pelo backup permanecem no estado em que estavam quando foram capturados e continuam ocupando capacidade do sistema de arquivos. Por exemplo, se você excluir dados do sistema de arquivos montado, essa ação não vai liberar capacidade. Em vez disso, crie um novo backup depois de excluir ou substituir quantidades significativas de dados.

    Para uma descrição detalhada das mudanças diferenciais e incrementais e como elas são processadas, consulte Criação de backup.

  • Para antecipar capacidade suficiente para suas cargas de trabalho, considere aplicar uma das seguintes opções:

    • Aumente a capacidade da instância para cargas de trabalho com mudanças de dados significativas e frequentes ou uma alta taxa de mudança.

    • Faça backups com frequência. Se o último backup estiver desatualizado, o snapshot interno poderá acumular mais mudanças e consumir mais capacidade da instância.

Criptografia

Ao usar a CMEK para criptografar suas cadeias de backup, as seguintes limitações se aplicam:

  • Toda uma cadeia de backup é criptografada usando a mesma CMEK.

  • Ao criar um backup com CMEK, a CMEK precisa estar na mesma região do backup de destino.

  • Se você armazenar uma cadeia de backup em uma região separada da instância de origem, talvez seja necessário aplicar chaves separadas, uma para a origem e outra para a cadeia de backup.

    • Todos os níveis de serviço oferecem suporte a várias cadeias de backup ou à capacidade de armazenar backups de uma instância em várias regiões. Se você optar por usar a CMEK para criptografia, uma chave de CMEK precisará estar na mesma região que o recurso criptografado. Se você estiver armazenando backups em uma região separada da origem e a CMEK não for uma chave multirregional, use chaves CMEK separadas. Para mais informações, consulte Restrições da CMEK e Escolher o melhor local da CMEK.

  • Uma única CMEK é aplicada ao bucket do Cloud Storage em que a cadeia de backup é armazenada e não pode ser combinada nem substituída.

  • O suporte à CMEK não está disponível para backups do nível Básico.

Para mais informações, consulte Suporte da CMEK para cadeias de backup.

Protocolos

  • Ao restaurar um backup, a nova instância precisa usar o mesmo protocolo da instância de origem.

Práticas recomendadas

As seções a seguir abordam as práticas recomendadas.

Como preparar o compartilhamento de arquivos para ter uma melhor consistência de backup

A qualidade de um backup depende da capacidade do aplicativo de se recuperar dos backups criados durante cargas de trabalho de gravação pesadas. Na maioria das situações, é possível criar backups com boa consistência, mesmo que os aplicativos gravem dados no compartilhamento de arquivos. No entanto, se os aplicativos exigirem consistência rigorosa, recomendamos executar uma ou mais das seguintes opções:

  • Use a montagem de sincronização. Para mais informações, consulte a seção "Opção de montagem de sincronização" em nfs(5). Você também pode abrir arquivos com as flags O_DIRECT|O_SYNC. Para mais informações, consulte open(2).
  • Pause os aplicativos ou processos do sistema operacional que gravam dados no compartilhamento de arquivos e faça com que eles limpem as alterações no compartilhamento de arquivos antes de iniciar o backup. Para ver mais informações, consulte fsync(2).
  • Se os aplicativos exigirem consistência entre vários compartilhamentos, pause todos os aplicativos em todas as instâncias que estiverem gravando nos compartilhamentos de arquivos e crie backups de todos os compartilhamentos de arquivos antes de retomar os aplicativos.
  • Se você precisar de consistência no nível do aplicativo, interrompa seus aplicativos e desative o compartilhamento de arquivos antes de criar um backup.

Como usar backups existentes como referência para novos backups a fim de reduzir o tempo de criação

Os backups atuais de um compartilhamento de arquivos em uma região são usados como valores de referência para criar backups do compartilhamento de arquivos, reduzindo o tempo de criação do backup. Portanto, recomendamos que você faça o seguinte:

  • Faça um novo backup de um compartilhamento de arquivos antes de excluir o backup anterior.

  • Aguarde que novos backups estejam no estado Ready antes de criar backups subsequentes do mesmo compartilhamento de arquivos.

Como programar backups fora do horário de pico para reduzir o tempo de criação

A criação de backups fora do horário de pico reduz o tempo que leva para criar um backup. Se você programar backups regulares dos compartilhamentos de arquivos, recomendamos que eles sejam programados fora do horário de pico, quando possível.

Os horários de pico para a criação de backups são o final de cada dia útil e a meia-noite da região onde a instância do Filestore está localizada. Recomendamos que você crie os backups no início da manhã ou durante o dia útil.

Como organizar seus dados em instâncias separadas do Filestore para maximizar a eficiência

Quanto mais dados o compartilhamento de arquivos tiver, maior será o backup e o custo. Para fazer backup apenas dos dados necessários, recomendamos organizá-los em compartilhamentos de arquivos separados, a saber:

  • Armazenamento de dados críticos com diferentes padrões de gravação ou requisitos de backup distintos em diferentes compartilhamentos de arquivos.
  • Ao manter dados semelhantes em um compartilhamento de arquivos, você reduz o número de backups que precisam ser criados.

Cota

Há um limite de cota para o número de backups por região nos níveis de serviço SSD básico e HDD básico.

Os limites de cota de backup não se aplicam aos níveis de serviço zonal, regional e empresarial.

Para mais informações, consulte Níveis de serviço e cota.

Começar a usar backups do Filestore

Para começar a usar o recurso, consulte Fazer backup de dados para recuperação de desastres.

A seguir