Banco de dados (PostgreSQL)¶

O PostgreSQL roda na própria VM e aceita conexões somente locais. A API conversa com ele em localhost:5432.

1. Instalar¶

sudo apt install -y postgresql postgresql-contrib
sudo systemctl enable --now postgresql

Confirme:

psql --version
sudo systemctl status postgresql

Por padrão o PostgreSQL do Ubuntu escuta apenas em 127.0.0.1. Confira que continua assim:

sudo ss -tlnp | grep 5432

A saída deve mostrar 127.0.0.1:5432. Se aparecer 0.0.0.0:5432, o banco está exposto na rede e precisa ser corrigido em listen_addresses, no postgresql.conf.

2. Criar usuário e banco¶

Nesta instalação

O usuário do banco em uso é jhon, e a connection string de produção está em appsettings.Production.json. Os comandos abaixo usam braggo_user, como no plano original.

Gere uma senha forte (só letras e números, para não dar problema na connection string):

openssl rand -hex 24

Guarde essa senha, ela vai para o arquivo de variáveis da API. Agora abra o console do PostgreSQL como administrador:

sudo -u postgres psql

E rode (trocando SENHA_GERADA):

CREATE USER braggo_user WITH PASSWORD 'SENHA_GERADA';
CREATE DATABASE braggo_db OWNER braggo_user;
\q

O usuário braggo_user é dono do banco, então pode criar tabelas e rodar migrations. Ele não é superusuário, o que limita o estrago caso a senha vaze.

Teste o acesso com o novo usuário:

psql -h localhost -U braggo_user -d braggo_db

Digite a senha. Se aparecer o prompt braggo_db=>, funcionou. Saia com \q.

3. Migrations¶

Suposição

Esta seção assume Entity Framework Core. Se você aplica o schema de outra forma (scripts SQL, outra ferramenta), o princípio é o mesmo: rodar os scripts contra braggo_db com o braggo_user.

Primeiro, garanta a ferramenta no seu PC (uma vez só):

dotnet tool install --global dotnet-ef

Opção A: gerar um script SQL e rodar na VM (recomendada)¶

Nesta solução

O comando usado de fato é dotnet ef migrations script --idempotent --project Infra --startup-project Presentation -o schema.sql. Todo migrationBuilder.Sql("...") precisa terminar com ;, senão o script falha no psql (aconteceu na primeira subida: veja Estado e histórico).

O script gerado é idempotente: pode ser executado várias vezes sem duplicar nada, porque ele verifica quais migrations já foram aplicadas.

dotnet ef migrations script --idempotent --project .\src\Braggo.Api -o migrate.sql
scp migrate.sql servidor:/tmp/migrate.sql
ssh -t servidor "psql -h localhost -U braggo_user -d braggo_db -f /tmp/migrate.sql"
ssh servidor "rm /tmp/migrate.sql"

O que cada linha faz: gera o script no seu PC, copia para a VM, executa com o psql (o -t permite digitar a senha) e apaga o arquivo temporário. Ajuste --project para o caminho do projeto onde estão o DbContext e as migrations.

Opção B: túnel SSH direto do seu PC¶

Útil para aplicar migrations sem copiar arquivos. Em um terminal, abra o túnel e deixe aberto:

ssh -N -L 5433:localhost:5432 servidor

Isso faz a porta 5433 do seu PC apontar para a 5432 do banco na VM. Em outro terminal:

dotnet ef database update --project .\src\Braggo.Api --connection "Host=localhost;Port=5433;Database=braggo_db;Username=braggo_user;Password=SENHA_GERADA"

Quando terminar, feche o túnel com Ctrl+C.

Evite migrar automaticamente no startup

Chamar Database.Migrate() ao iniciar a API é prático, mas esconde erros de migration dentro da subida do serviço e dá ao usuário do banco mais poder do que o necessário no dia a dia. Prefira aplicar migrations como um passo explícito do deploy.

4. Comandos úteis do psql¶

Entre com psql -h localhost -U braggo_user -d braggo_db e use:

Comando	O que faz
`\l`	lista os bancos
`\dt`	lista as tabelas do banco atual
`\d nome_da_tabela`	mostra as colunas de uma tabela
`\du`	lista os usuários
`\q`	sai

5. Backup e restauração¶

Versão em uso

O backup que está de fato configurado na VM usa formato .dump e /etc/cron.d. Veja Backup do banco. Os passos abaixo (.sql.gz, crontab do root) são uma alternativa e não estão instalados.

Backup manual¶

sudo -u postgres pg_dump braggo_db | gzip > ~/braggo_db_$(date +%F).sql.gz

pg_dump exporta o banco inteiro como SQL e o gzip comprime. O $(date +%F) coloca a data (2026-10-25) no nome.

Backup automático diário¶

Crie o script como root em /usr/local/sbin (fora do alcance de edição do jhon, já que o cron do root vai executá-lo):

sudo nano /usr/local/sbin/braggo-backup-db.sh

#!/bin/bash
set -euo pipefail

DEST=/var/backups/braggo
ARQ="$DEST/braggo_db_$(date +%F_%H%M).sql.gz"

sudo -u postgres pg_dump braggo_db | gzip > "$ARQ"

# apaga backups com mais de 14 dias
find "$DEST" -name 'braggo_db_*.sql.gz' -mtime +14 -delete

sudo chmod 750 /usr/local/sbin/braggo-backup-db.sh
sudo crontab -e

Na última linha do crontab do root:

0 3 * * * /usr/local/sbin/braggo-backup-db.sh >> /var/log/braggo-backup.log 2>&1

Roda todo dia às 3h e registra o resultado em /var/log/braggo-backup.log. Teste uma vez na mão com sudo /usr/local/sbin/braggo-backup-db.sh e confira o arquivo em /var/backups/braggo.

Levar uma cópia para fora da VM¶

Backup que fica só dentro da VM se perde junto com ela. De tempos em tempos (ou em uma tarefa agendada do Windows), copie para o seu PC:

scp "servidor:/var/backups/braggo/*.sql.gz" C:\Backups\braggo\

Restaurar¶

sudo systemctl stop braggo-api
sudo -u postgres psql -c "DROP DATABASE braggo_db;"
sudo -u postgres psql -c "CREATE DATABASE braggo_db OWNER braggo_user;"
gunzip -c /var/backups/braggo/ARQUIVO.sql.gz | sudo -u postgres psql braggo_db
sudo systemctl start braggo-api

Esses comandos param a API, apagam o banco, recriam um banco vazio e despejam o backup dentro dele. Antes de fazer isso em produção, tire um snapshot da VM.

Checklist ao final desta etapa¶

[ ] ss -tlnp | grep 5432 mostra só 127.0.0.1
[ ] Login com braggo_user funciona
[ ] Migrations aplicadas (\dt mostra as tabelas e __EFMigrationsHistory)
[ ] Backup automático testado