💾 Backup e segurança

O coração do Postiz é o Postgres: posts agendados, contas conectadas, tokens OAuth, métricas. Perder o volume é perder semanas de trabalho. A primeira camada de defesa é um pg_dump diário em formato -Fc (custom) — comprimido, mais rápido pra restaurar e permite restore seletivo de tabelas.

Use cron do host, não cron dentro do container. Container morre, cron morre junto. O dump roda via docker exec no Postgres já em execução.

# /usr/local/bin/postiz-backup.sh
#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR=/var/backups/postiz
STAMP=$(date +%F_%H%M)
mkdir -p "$BACKUP_DIR"

# -Fc = custom format (comprimido + restore seletivo)
docker exec postiz-postgres \
  pg_dump -U postiz -d postiz -Fc \
  > "$BACKUP_DIR/postiz_${STAMP}.dump"

# Retenção local: 7 dias
find "$BACKUP_DIR" -name "postiz_*.dump" -mtime +7 -delete

echo "[$(date -Iseconds)] backup ok: postiz_${STAMP}.dump"

# Tornar executável e agendar (03:00 todo dia)
chmod +x /usr/local/bin/postiz-backup.sh

crontab -e
# adicionar:
0 3 * * * /usr/local/bin/postiz-backup.sh >> /var/log/postiz-backup.log 2>&1

Conceitos-chave

Dump no mesmo host onde o Postiz roda não é backup — é uma cópia. Se o disco morrer, morre junto. A camada off-site usa restic: encripta com AES-256 antes de subir, faz dedup em blocos (vários dumps quase iguais ocupam quase nada) e tem retenção declarativa.

Cloudflare R2 é a opção barata: zero egress fee, API S3-compatível, ~$0.015/GB-mês. AWS S3 funciona igual com endpoint default. O segredo de encriptação fica só no servidor — sem ele, o backup é lixo aleatório no bucket.

# Instalar restic
sudo apt install restic

# Variáveis (idealmente em /etc/postiz-backup.env, chmod 600)
export AWS_ACCESS_KEY_ID=<r2_access_key>
export AWS_SECRET_ACCESS_KEY=<r2_secret>
export RESTIC_REPOSITORY=s3:https://<account>.r2.cloudflarestorage.com/postiz-backups
export RESTIC_PASSWORD=<senha_forte_de_64_chars>

# Inicializar repo (UMA vez)
restic init

# Backup do diretório de dumps
restic backup /var/backups/postiz --tag daily

# Política de retenção: 7 diários, 4 semanais, 6 mensais
restic forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
  --prune

# Adicionar ao postiz-backup.sh, após o pg_dump
source /etc/postiz-backup.env

restic backup "$BACKUP_DIR" --tag daily --quiet
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune --quiet

Conceitos-chave

Backup não testado é boato. Você só descobre que o dump está corrompido, que faltou uma tabela, que o segredo está errado ou que ninguém anotou o procedimento — no dia em que precisa. Marque no calendário: primeiro domingo de cada mês, restore de teste num ambiente isolado.

O teste roda em uma VM ou container separado da produção. Restore o dump mais recente, suba um Postiz apontando para esse Postgres, faça login e verifique se posts agendados, contas conectadas e métricas voltaram.

# Em ambiente isolado (host de teste)
restic snapshots                    # listar backups disponíveis
restic restore latest --target /tmp/restore

# Subir Postgres temporário
docker run -d --name pg-restore \
  -e POSTGRES_USER=postiz \
  -e POSTGRES_PASSWORD=teste \
  -e POSTGRES_DB=postiz \
  postgres:16-alpine

# Restaurar o dump (-c = drop antes, --if-exists = idempotente)
cat /tmp/restore/var/backups/postiz/postiz_*.dump | \
  docker exec -i pg-restore \
    pg_restore -U postiz -d postiz -c --if-exists

# Smoke test: contar registros das tabelas críticas
docker exec pg-restore psql -U postiz -d postiz -c "
  SELECT 'users' tbl, count(*) FROM users
  UNION ALL SELECT 'posts', count(*) FROM posts
  UNION ALL SELECT 'integrations', count(*) FROM integrations;"

# Limpar
docker rm -f pg-restore

Conceitos-chave

Tokens de longa duração são superfícies de ataque permanentes. Um vazamento de log, um backup que escapou, um dev que saiu da empresa — todos viram acesso eterno enquanto o token estiver válido. A política mínima é rotacionar tudo em ciclos previsíveis.

# Rotacionar JWT_SECRET (zero-downtime parcial)
# 1) Gerar novo segredo
NEW=$(openssl rand -hex 64)

# 2) Atualizar .env
sed -i "s|^JWT_SECRET=.*|JWT_SECRET=${NEW}|" ~/postiz/.env

# 3) Reiniciar Postiz (sessões atuais caem — avise!)
docker compose -f ~/postiz/docker-compose.yml up -d --force-recreate postiz

# 4) Confirmar
docker compose logs --tail=20 postiz | grep -i ready

Conceitos-chave

Toda credencial deve ter o mínimo de poder necessário pra fazer seu trabalho — e nada além disso. Token de backup acessa só o bucket de backup. Token do app acessa só o banco do app. Chave OAuth de Twitter só com escopos que o Postiz realmente usa.

Se um atacante conseguir uma credencial, o estrago é limitado pelo que ela pode fazer. Uma chave R2 com permissão de Object Read & Write em um único bucket é infinitamente melhor que uma chave master da conta.

# Exemplo: policy AWS S3 mínima para o backup
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject",
      "s3:ListBucket"
    ],
    "Resource": [
      "arn:aws:s3:::postiz-backups",
      "arn:aws:s3:::postiz-backups/*"
    ]
  }]
}
# SEM s3:* ou Resource: "*" — atacante não enumera outros buckets

Conceitos-chave

Um DR plan responde duas perguntas antes do desastre: RTO (Recovery Time Objective — quanto tempo até voltar) e RPO (Recovery Point Objective — quanto de dados pode perder). Para um Postiz pessoal: RTO de 2h e RPO de 24h é razoável. Para SaaS pago: RTO <30min, RPO <1h exige replicação contínua.

A defesa robusta é a regra 3-2-1: três cópias, em dois meios diferentes, com uma off-site. Volume Docker (1), dump local em /var/backups (2), restic no R2 (3) — meios diferentes (disco do servidor vs. object storage), uma off-site (R2).

# Runbook em script — DR_RESTORE.sh (mantenha no repositório)
#!/usr/bin/env bash
set -euo pipefail

source /etc/postiz-backup.env

echo "[1/4] Baixando último snapshot..."
restic restore latest --target /tmp/dr

echo "[2/4] Subindo Postgres..."
cd ~/postiz && docker compose up -d postgres
until docker exec postiz-postgres pg_isready -U postiz; do sleep 2; done

echo "[3/4] Restaurando dump mais recente..."
LATEST=$(ls -t /tmp/dr/var/backups/postiz/postiz_*.dump | head -1)
docker exec -i postiz-postgres pg_restore -U postiz -d postiz -c --if-exists < "$LATEST"

echo "[4/4] Subindo aplicação..."
docker compose up -d
sleep 10
curl -fsS http://localhost:5000/api/health && echo "DR concluído ✓"

Conceitos-chave