Backups massivamente paralelos para Postgres em escala de petabytes

O ciclo de backup

A cada 12 horas, o sistema de backup da PlanetScale precisa transformar o estado inteiro de um banco de dados ativo em um snapshot consistente e criptografado, sem impactar queries de produção. Para bancos sharded (chamados Neki, que rodam Postgres particionado), o processo aproveita a paralelização natural dos shards.

Em vez de executar o backup diretamente nos nós primários, a PlanetScale sobe instâncias EC2 temporárias - uma por shard - dedicadas exclusivamente ao trabalho de backup. Cada instância restaura o backup anterior a partir do S3, aplica as mudanças acumuladas via replay do Write-Ahead Log (WAL) e envia o resultado final de volta ao object storage.

Reuso de backups antigos e replay do WAL

O primeiro passo é restaurar o backup mais recente (armazenado no S3) para cada shard nas instâncias temporárias. Isso consome banda e compute, mas tem duas vantagens: apenas o WAL recente é puxado do primário (minimizando impacto em produção) e cada ciclo valida que o backup anterior é restaurável.

Para o replay do WAL, a abordagem é híbrida: a maior parte dos dados vem do S3 (onde o WAL é arquivado continuamente via wal-g), e apenas os últimos minutos - que ainda não chegaram ao S3 por causa do archive_timeout - são transmitidos diretamente do primário. Quando todos os nós alcançam o mesmo ponto no tempo T, a replicação é interrompida, congelando o snapshot. O backup é então criptografado e enviado a um bucket S3 dedicado.

O primeiro backup

Para bancos recém-criados, usa-se pg_basebackup para semear cada nó de backup a partir do primário. Depois disso, o processo segue o mesmo fluxo de restaurar → atualizar → salvar, mantendo formato e restauração idênticos aos backups subsequentes.

Velocidade e paralelismo

A principal vantagem do sharding para backups é a velocidade. Um banco de 32 TB sem shard, com taxa de transferência de 500 MB/s, levaria cerca de 22 horas para completar o ciclo (restaurar + atualizar + enviar). Com 8 shards em paralelo, o tempo cai para ~2,8 horas. Com 32 shards, ~42 minutos. A velocidade escala linearmente com o número de shards: 100 TB em 100 shards tem tempo de backup semelhante a 1 TB em um único shard.

Usos além de segurança

Backups na PlanetScale não servem apenas para recuperação de desastres. Em bancos Metal (com NVMe local), eles são usados a cada redimensionamento: novas instâncias maiores são criadas, restauram o backup mais recente, sincronizam via WAL e assumem o lugar das antigas. Também são usados para substituir nós que falharam - algo estatisticamente frequente em bancos com centenas de shards.

MySQL

Para bancos MySQL sharded via Vitess, o processo é análogo, mas usa VTBackup em vez das ferramentas nativas do Postgres, binary log em vez de WAL, e o catch-up é feito diretamente do primário.