O que você de fato perderia

Recuperação de desastres começa com um inventário, e não com um plano. Até você saber o que é insubstituível, todo cronograma de backup é um palpite, e o inventário desta aplicação tem um formato que vale olhar de perto.

Dois tipos de dados

O catálogo é reproduzível. Todos os cursos e lições ficam em db/seeds.rb e db/seeds/*.json, no controle de versão, e o bin/rails import:lessons os reconstrói a partir desses arquivos.

Perder o banco não perde o catálogo. Perde o tempo de rodar uma tarefa de importação.

Tudo o que um aluno fez não é reproduzível: contas, matrículas, conclusões de lições, submissões de código, pontos de experiência. Nada disso existe em outro lugar além do Postgres e dos backups dele.

flowchart TB
  D["o banco de produção"] --> R["catálogo: cursos e lições"]
  D --> I["dados de aluno: matrículas, conclusões, submissões, XP"]
  R --> G["também no git. reconstruível por uma tarefa"]
  I --> N["em nenhum outro lugar. perdido é perdido"]
  G --> S["a maior parte dos bytes"]
  N --> T["toda a perda"]

A assimetria é o ponto

A maior parte dos dados é reproduzível, e todos os dados insubstituíveis são pequenos.

Essa combinação é incomumente favorável, e muda o que é um backup sensato. Você não está protegendo um banco grande; está protegendo um punhado de tabelas.

Um time que não fez esse inventário tende a pensar no banco como uma coisa só, concluir que fazer backup direito é um projeto e adiar. O inventário é o que o transforma de volta numa tarde de trabalho.

A coisa que nem está no banco

O RAILS_MASTER_KEY decifra o config/credentials.yml.enc.

Ele fica no shell do operador e no ambiente do contêiner em execução, como o curso de nível Sênior "Infraestrutura: Kamal 2" mostrou, e de propósito fora do repositório.

Se ele se perder, o arquivo de credenciais no controle de versão fica indecifrável para sempre. Nenhum backup do banco ajuda, porque a chave nunca esteve no banco.

É a perda mais grave possível neste projeto, e não é um problema de banco.

Os uploads

O /opt/newbieonrails/storage no host guarda os arquivos do Active Storage, como logos de parceiros e capas de cursos.

Eles não estão no banco nem no git, então um plano de backup precisa nomear esse diretório além do banco.

Pontos-chave

• A recuperação de desastres começa com um inventário do que é insubstituível, e não com um cronograma.
• O catálogo está no git e pode ser reconstruído, então perder o banco não o perde.
• Os dados dos alunos existem só no Postgres e nos backups dele.
• A maior parte dos dados é reproduzível, e todos os dados insubstituíveis são pequenos.
• O RAILS_MASTER_KEY é a perda mais grave possível, e ele não está no banco.