smoonb 1.0.13 → 1.0.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +8 -0
- package/README.md +695 -695
- package/README.pt-BR.md +697 -697
- package/npm-shrinkwrap.json +2030 -2030
- package/package.json +71 -71
- package/src/commands/backup/index.js +10 -6
- package/src/commands/backup/steps/00-license.js +2 -2
- package/src/i18n/locales/en.json +3 -3
- package/src/i18n/locales/pt-BR.json +3 -3
- package/src/interactive/envMapper.js +4 -1
- package/src/utils/env.js +33 -15
package/README.pt-BR.md
CHANGED
|
@@ -1,697 +1,697 @@
|
|
|
1
|
-
# Supa Moonbase (smoonb)
|
|
2
|
-
|
|
3
|
-
**Ferramenta completa de backup e migração do Supabase**
|
|
4
|
-
|
|
5
|
-
Backup e restauração: completo e simples, como deveria ser
|
|
6
|
-
|
|
7
|
-
> **Produto comercial.** É necessário ter **licença ativa** e **assinatura válida** (ou estar em período de trial) para usar o smoonb. [www.smoonb.com/#price](https://www.smoonb.com/#price). O uso é regido pelos [Termos de Serviço](https://www.smoonb.com/terms) e pela [Política de Privacidade](https://www.smoonb.com/privacy). Não assumimos responsabilidade por danos causados pelo smoonb; os avisos legais abaixo permanecem válidos.
|
|
8
|
-
|
|
9
|
-
**Leia em outro idioma:** [English](README.md)
|
|
10
|
-
|
|
11
|
-
**Desenvolvido por:** Goalmoon Tecnologia LTDA
|
|
12
|
-
**Website:** https://www.smoonb.com
|
|
13
|
-
**GitHub:** https://github.com/almmello/smoonb
|
|
14
|
-
|
|
15
|
-
## 🎯 Objetivo
|
|
16
|
-
|
|
17
|
-
O **smoonb** resolve o problema das ferramentas existentes que fazem backup apenas da database PostgreSQL, ignorando componentes críticos do Supabase.
|
|
18
|
-
|
|
19
|
-
## 📦 Componentes de Backup
|
|
20
|
-
|
|
21
|
-
O smoonb faz backup completo de todos os componentes do seu projeto Supabase:
|
|
22
|
-
|
|
23
|
-
- ✅ **Database PostgreSQL** (backup completo via `pg_dumpall` + SQL separados, idêntico ao Dashboard)
|
|
24
|
-
- ✅ **Database Extensions and Settings** (extensões PostgreSQL e configurações)
|
|
25
|
-
- ✅ **Custom Roles** (roles personalizados do PostgreSQL)
|
|
26
|
-
- ✅ **Edge Functions** (download automático do servidor)
|
|
27
|
-
- ✅ **Auth Settings** (configurações de autenticação via Management API)
|
|
28
|
-
- ✅ **Storage Buckets** (backup completo: metadados, configurações e todos os arquivos via Management API + Supabase Client, cria ZIP no padrão do Dashboard)
|
|
29
|
-
- ✅ **Realtime Settings** (configurações atuais capturadas pela Management API)
|
|
30
|
-
- ✅ **Supabase .temp** (arquivos temporários do Supabase CLI)
|
|
31
|
-
- ✅ **Migrations** (todas as migrations do projeto via `supabase migration fetch`)
|
|
32
|
-
|
|
33
|
-
## ⚠️ Universal Disclaimer / Aviso Legal Universal
|
|
34
|
-
|
|
35
|
-
Ao continuar, você reconhece e concorda que o Supa Moonbase (smoonb) é fornecido "NO ESTADO EM QUE SE ENCONTRA" ("AS IS") e "CONFORME DISPONIBILIDADE" ("AS AVAILABLE"), sem garantias de qualquer natureza—expressas, implícitas ou legais—incluindo, sem limitação, garantias de comercialização, adequação a um fim específico e não violação, na máxima extensão permitida pela lei aplicável. Operações de backup e restauração envolvem riscos inerentes, os ambientes variam amplamente e não podemos prever ou validar todas as configurações dos usuários. Você é o único responsável por validar seu próprio ambiente, manter cópias independentes e verificar os resultados antes de utilizá-los em produção. Construímos o Supa Moonbase (smoonb) com repositórios públicos, auditáveis e de código aberto para ajudar pessoas a simplificar seus fluxos de trabalho, mas isso não cria qualquer garantia, promessa de suporte ou compromisso de nível de serviço.
|
|
36
|
-
|
|
37
|
-
**Limitação de responsabilidade** — Na máxima extensão permitida por lei, a Goalmoon Tecnologia LTDA, seus contribuidores e licenciadores não serão responsáveis por quaisquer danos indiretos, incidentais, especiais, consequentes, exemplares ou punitivos (incluindo perda de dados, interrupção de negócios ou lucros cessantes) decorrentes ou relacionados ao uso, incapacidade de uso, operações de backup/restauração realizadas por, ou resultados produzidos pelo Supa Moonbase (smoonb).
|
|
38
|
-
|
|
39
|
-
## 🚀 Instalação
|
|
40
|
-
|
|
41
|
-
**⚠️ IMPORTANTE: Instale APENAS localmente no projeto!**
|
|
42
|
-
|
|
43
|
-
**Instalar localmente no projeto:**
|
|
44
|
-
```bash
|
|
45
|
-
npm install smoonb
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
**Usar com npx:**
|
|
49
|
-
```bash
|
|
50
|
-
npx smoonb --help
|
|
51
|
-
```
|
|
52
|
-
|
|
53
|
-
**Não instalar globalmente** (será bloqueado):
|
|
54
|
-
```bash
|
|
55
|
-
npm install -g smoonb
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
### 🔄 Atualizar para a Última Versão
|
|
59
|
-
|
|
60
|
-
Para atualizar o smoonb para a versão mais recente disponível, execute no projeto atual:
|
|
61
|
-
|
|
62
|
-
```bash
|
|
63
|
-
npm install smoonb@latest
|
|
64
|
-
```
|
|
65
|
-
|
|
66
|
-
**⚠️ IMPORTANTE:** O smoonb deve ser instalado localmente no projeto. Não é permitido usar sem instalar (ex.: `npx smoonb@latest`).
|
|
67
|
-
|
|
68
|
-
**💡 Por que apenas local?**
|
|
69
|
-
- **🔒 Segurança**: Evita conflitos de versão
|
|
70
|
-
- **📦 Isolamento**: Cada projeto usa sua versão
|
|
71
|
-
- **🔄 Atualizações**: Controle granular por projeto
|
|
72
|
-
- **🛡️ Estabilidade**: Evita quebras em outros projetos
|
|
73
|
-
|
|
74
|
-
## 📋 Pré-requisitos
|
|
75
|
-
|
|
76
|
-
### 1. Docker Desktop (OBRIGATÓRIO)
|
|
77
|
-
|
|
78
|
-
Instale pelo [Docker Desktop](https://docs.docker.com/desktop/install/) (Windows/macOS) ou [Docker Engine](https://docs.docker.com/engine/install/) (Linux). Depois verifique se está rodando:
|
|
79
|
-
|
|
80
|
-
```bash
|
|
81
|
-
docker --version
|
|
82
|
-
docker ps
|
|
83
|
-
```
|
|
84
|
-
|
|
85
|
-
**⚠️ IMPORTANTE:** O Docker é necessário para:
|
|
86
|
-
- Backup da database via `pg_dumpall` (compatível com Dashboard do Supabase)
|
|
87
|
-
- Compressão de arquivos `.backup.gz`
|
|
88
|
-
- Restauração de backups `.backup` e `.backup.gz`
|
|
89
|
-
|
|
90
|
-
### 2. Supabase CLI
|
|
91
|
-
```bash
|
|
92
|
-
npm install -g supabase
|
|
93
|
-
```
|
|
94
|
-
|
|
95
|
-
**Política de versão:** o smoonb aceita qualquer versão do Supabase CLI que esteja **no máximo 1 minor atrás da latest** (mesma major). Recomendamos sempre usar a versão mais recente. Versões muito antigas são bloqueadas com mensagem de erro.
|
|
96
|
-
|
|
97
|
-
Se o seu gerenciador de pacotes (ex.: **Scoop** no Windows) instala com atraso e você quer avançar mesmo assim, use a flag `--skip-supabase-version-check` (veja a seção de uso abaixo).
|
|
98
|
-
|
|
99
|
-
Para atualizar o Supabase CLI: [Atualizando o Supabase CLI](https://supabase.com/docs/guides/cli/getting-started#updating-the-supabase-cli).
|
|
100
|
-
|
|
101
|
-
### 3. Personal Access Token do Supabase
|
|
102
|
-
É necessário obter um token de acesso pessoal do Supabase para usar a Management API:
|
|
103
|
-
|
|
104
|
-
1. Acesse: https://supabase.com/dashboard/account/tokens
|
|
105
|
-
2. Clique em "Generate new token"
|
|
106
|
-
3. Copie o token (formato: `sbp_...`)
|
|
107
|
-
4. Adicione ao `.env.local` como `SUPABASE_ACCESS_TOKEN`
|
|
108
|
-
|
|
109
|
-
### 4. Chave de licença (OBRIGATÓRIA para backup e restore)
|
|
110
|
-
O **smoonb** exige uma licença válida para executar backup e restore:
|
|
111
|
-
|
|
112
|
-
1. Obtenha sua licença no app desktop em https://www.smoonb.com
|
|
113
|
-
2. Defina no ambiente ou no `.env.local`: `SMOONB_LICENSE_KEY=[sua-chave-de-licença]`
|
|
114
|
-
3. A licença é validada no início de cada execução (step 00); não há cache. Se a validação falhar (rede/servidor), o CLI aborta. A licença **não** aparece no wizard de mapeamento de variáveis (já foi validada antes).
|
|
115
|
-
|
|
116
|
-
## ⚙️ Configuração
|
|
117
|
-
|
|
118
|
-
### Método Moderno: `.env.local` (RECOMENDADO)
|
|
119
|
-
|
|
120
|
-
O **smoonb** agora usa `.env.local` para configuração, seguindo o padrão da indústria. Isso torna o processo mais simples e integrado ao seu fluxo de trabalho.
|
|
121
|
-
|
|
122
|
-
#### 1. Criar ou editar `.env.local` na raiz do projeto
|
|
123
|
-
|
|
124
|
-
```bash
|
|
125
|
-
touch .env.local
|
|
126
|
-
```
|
|
127
|
-
|
|
128
|
-
#### 2. Adicionar as variáveis de ambiente necessárias
|
|
129
|
-
|
|
130
|
-
```env
|
|
131
|
-
SMOONB_LICENSE_KEY=[sua-chave-de-licença]
|
|
132
|
-
NEXT_PUBLIC_SUPABASE_URL=[sua-supabase-url]
|
|
133
|
-
NEXT_PUBLIC_SUPABASE_ANON_KEY=[sua-anon-key]
|
|
134
|
-
SUPABASE_SERVICE_ROLE_KEY=[sua-service-role]
|
|
135
|
-
SUPABASE_DB_URL=postgresql://postgres:[sua-database-password]@db.[seu-project-id].supabase.co:5432/postgres
|
|
136
|
-
SUPABASE_PROJECT_ID=[seu-project-id]
|
|
137
|
-
SUPABASE_ACCESS_TOKEN=[seu-access-token]
|
|
138
|
-
SUPABASE_POSTGRES_MAJOR=17
|
|
139
|
-
SMOONB_TELEMETRY_ENABLED=true
|
|
140
|
-
SMOONB_OUTPUT_DIR=./backups
|
|
141
|
-
```
|
|
142
|
-
|
|
143
|
-
Obrigatórias: `SMOONB_LICENSE_KEY` (app desktop em [smoonb.com](https://www.smoonb.com)), `SUPABASE_POSTGRES_MAJOR` (ex.: 17; veja no Dashboard → Project Settings → Infrastructure → Service Versions). Opcionais: `SMOONB_TELEMETRY_ENABLED`, `SMOONB_OUTPUT_DIR` (padrão `./backups`).
|
|
144
|
-
|
|
145
|
-
#### 3. Mapeamento Interativo
|
|
146
|
-
|
|
147
|
-
Ao executar `backup` ou `restore` pela primeira vez, o **smoonb** irá:
|
|
148
|
-
|
|
149
|
-
1. **Ler** seu `.env.local` atual
|
|
150
|
-
2. **Identificar** as chaves que você já tem
|
|
151
|
-
3. **Perguntar interativamente** quais chaves correspondem às esperadas (se os nomes forem diferentes)
|
|
152
|
-
4. **Adicionar** chaves faltantes se necessário
|
|
153
|
-
5. **Criar backup** automático do `.env.local` antes de qualquer alteração
|
|
154
|
-
6. **Salvar mapeamento** para futuras execuções
|
|
155
|
-
|
|
156
|
-
**Exemplo de mapeamento:**
|
|
157
|
-
```
|
|
158
|
-
🔧 Mapeando variável: NEXT_PUBLIC_SUPABASE_URL
|
|
159
|
-
Valor atual: https://abc123.supabase.co
|
|
160
|
-
Este é o valor correto do projeto alvo? (S/n): S
|
|
161
|
-
```
|
|
162
|
-
|
|
163
|
-
## 🌐 Internacionalização (i18n)
|
|
164
|
-
|
|
165
|
-
O **smoonb** suporta múltiplos idiomas automaticamente. Atualmente, os idiomas suportados são:
|
|
166
|
-
|
|
167
|
-
- **Inglês (en)** - Idioma padrão
|
|
168
|
-
- **Português do Brasil (pt-BR)** - Suporte completo
|
|
169
|
-
|
|
170
|
-
### Detecção Automática de Idioma
|
|
171
|
-
|
|
172
|
-
O idioma é detectado automaticamente na seguinte ordem de precedência:
|
|
173
|
-
|
|
174
|
-
1. **Variável de ambiente `SMOONB_LANG`** (no `.env.local` ou no ambiente)
|
|
175
|
-
2. **Locale do sistema** (LANG, LC_ALL, LC_MESSAGES). Exemplo: `LANG=pt_BR.UTF-8` → pt-BR
|
|
176
|
-
3. **Fallback para inglês (en)** se nenhum dos anteriores for detectado
|
|
177
|
-
|
|
178
|
-
### Idiomas Suportados e Aliases
|
|
179
|
-
|
|
180
|
-
- `en` ou `en-US` → Inglês
|
|
181
|
-
- `pt-BR`, `pt_BR` ou `pt` → Português do Brasil
|
|
182
|
-
|
|
183
|
-
### Notas Importantes
|
|
184
|
-
|
|
185
|
-
- **Saídas "máquina"** (ex.: `--json` se implementado) **não** são traduzidas; campos e chaves permanecem em inglês
|
|
186
|
-
- Se uma chave de tradução estiver ausente em um idioma, o sistema faz **fallback automático para inglês**
|
|
187
|
-
- O idioma é detectado uma vez no início da execução e aplicado a todas as mensagens do CLI
|
|
188
|
-
|
|
189
|
-
## 🎯 Uso
|
|
190
|
-
|
|
191
|
-
### Backup Completo
|
|
192
|
-
|
|
193
|
-
```bash
|
|
194
|
-
npx smoonb backup
|
|
195
|
-
```
|
|
196
|
-
|
|
197
|
-
**Opções disponíveis:**
|
|
198
|
-
|
|
199
|
-
| Flag | Descrição |
|
|
200
|
-
|------|-----------|
|
|
201
|
-
| `--skip-supabase-version-check` | Pula a checagem de versão do Supabase CLI. Use quando seu gerenciador de pacotes (ex.: Scoop) instala com atraso. Um aviso é exibido e o usuário assume o risco. |
|
|
202
|
-
|
|
203
|
-
**Exemplo com a flag:**
|
|
204
|
-
```bash
|
|
205
|
-
npx smoonb backup --skip-supabase-version-check
|
|
206
|
-
```
|
|
207
|
-
|
|
208
|
-
**Fluxo interativo do backup:**
|
|
209
|
-
|
|
210
|
-
1. **Termo de uso** - Exibe e solicita aceitação dos termos
|
|
211
|
-
2. **Validação de licença** - Valida `SMOONB_LICENSE_KEY` (env ou prompt); sem cache; aborta se a validação falhar
|
|
212
|
-
3. **Validação Docker** - Verifica se o Docker está rodando
|
|
213
|
-
4. **Consentimento** - Pede permissão para ler/escrever `.env.local`
|
|
214
|
-
5. **Mapeamento de variáveis** - Mapeia suas variáveis de ambiente (primeira vez; a licença não entra no wizard—já validada)
|
|
215
|
-
6. **Backup do .env.local** - Cria backup automático antes de alterações
|
|
216
|
-
7. **Seleção de componentes** - Pergunta quais componentes incluir:
|
|
217
|
-
- ⚡ Edge Functions (explicação sobre reset de link e download)
|
|
218
|
-
- 📦 Storage (explicação sobre backup completo: download de arquivos + ZIP no padrão do Dashboard)
|
|
219
|
-
- 🔐 Auth Settings (explicação sobre configurações)
|
|
220
|
-
- 🔄 Realtime Settings (explicação sobre captura interativa de 7 parâmetros)
|
|
221
|
-
- 🗑️ Opções de limpeza (functions, .temp, migrations após backup)
|
|
222
|
-
8. **Resumo de configurações** - Mostra tudo que será feito
|
|
223
|
-
9. **Confirmação final** - Confirma antes de iniciar
|
|
224
|
-
10. **Execução das etapas:**
|
|
225
|
-
- 📊 1/10 - Backup Database via `pg_dumpall` (Docker)
|
|
226
|
-
- 📊 2/10 - Backup Database SQL separado (schema, dados, roles)
|
|
227
|
-
- 🔧 3/10 - Backup Database Extensions and Settings
|
|
228
|
-
- 🔐 4/10 - Backup Auth Settings (se selecionado)
|
|
229
|
-
- 🔄 5/10 - Backup Realtime Settings (se selecionado) - 7 parâmetros capturados interativamente
|
|
230
|
-
- 📦 6/10 - Backup Storage (se selecionado) - Download completo de arquivos + ZIP no padrão do Dashboard
|
|
231
|
-
- 👥 7/10 - Backup Custom Roles
|
|
232
|
-
- ⚡ 8/10 - Backup Edge Functions (se selecionado)
|
|
233
|
-
- 📁 9/10 - Backup Supabase .temp (se selecionado)
|
|
234
|
-
- 📋 10/10 - Backup Migrations (se selecionado)
|
|
235
|
-
|
|
236
|
-
**Resultado:** Uma pasta `backups/backup-YYYY-MM-DD-HH-MM-SS/` contendo, por exemplo:
|
|
237
|
-
|
|
238
|
-
```
|
|
239
|
-
backups/backup-2025-10-31-09-37-54/
|
|
240
|
-
├── backup-manifest.json
|
|
241
|
-
├── db_cluster-31-10-2025@09-38-57.backup.gz
|
|
242
|
-
├── schema.sql
|
|
243
|
-
├── data.sql
|
|
244
|
-
├── roles.sql
|
|
245
|
-
├── database-settings-*.json
|
|
246
|
-
├── auth-settings.json
|
|
247
|
-
├── realtime-settings.json
|
|
248
|
-
├── storage/
|
|
249
|
-
│ └── [bucket-name].json
|
|
250
|
-
├── [project-id].storage.zip
|
|
251
|
-
├── storage_temp/
|
|
252
|
-
│ └── [project-id]/
|
|
253
|
-
│ └── [bucket-name]/
|
|
254
|
-
├── edge-functions/
|
|
255
|
-
│ └── [nome-da-function]/
|
|
256
|
-
├── supabase-temp/
|
|
257
|
-
├── migrations/
|
|
258
|
-
└── env/
|
|
259
|
-
├── .env.local
|
|
260
|
-
└── env-map.json
|
|
261
|
-
```
|
|
262
|
-
|
|
263
|
-
### Restauração Interativa
|
|
264
|
-
|
|
265
|
-
**Restaurar backup existente:**
|
|
266
|
-
```bash
|
|
267
|
-
npx smoonb restore
|
|
268
|
-
```
|
|
269
|
-
|
|
270
|
-
**Opções disponíveis:**
|
|
271
|
-
|
|
272
|
-
| Flag | Descrição |
|
|
273
|
-
|------|-----------|
|
|
274
|
-
| `--skip-supabase-version-check` | Pula a checagem de versão do Supabase CLI. Use quando seu gerenciador de pacotes (ex.: Scoop) instala com atraso. Um aviso é exibido e o usuário assume o risco. |
|
|
275
|
-
|
|
276
|
-
**Exemplo com a flag:**
|
|
277
|
-
```bash
|
|
278
|
-
npx smoonb restore --skip-supabase-version-check
|
|
279
|
-
```
|
|
280
|
-
|
|
281
|
-
**Fluxo interativo do restore:**
|
|
282
|
-
|
|
283
|
-
1. **Termo de uso** - Exibe e solicita aceitação dos termos
|
|
284
|
-
2. **Validação de licença** - Valida `SMOONB_LICENSE_KEY` (env ou prompt); aborta se a validação falhar
|
|
285
|
-
3. **Validação Docker** - Verifica se o Docker está rodando
|
|
286
|
-
4. **Consentimento** - Pede permissão para ler/escrever `.env.local`
|
|
287
|
-
5. **Mapeamento de variáveis** - Mapeia variáveis para o projeto de destino (inclui `SUPABASE_POSTGRES_MAJOR`)
|
|
288
|
-
6. **Backup do .env.local** - Cria backup automático
|
|
289
|
-
7. **Seleção de backup** - Lista e permite escolher qual backup restaurar
|
|
290
|
-
8. **Seleção de componentes** - Pergunta quais componentes restaurar:
|
|
291
|
-
- 📊 Database (sempre disponível)
|
|
292
|
-
- ⚡ Edge Functions (se disponível no backup)
|
|
293
|
-
- 🔐 Auth Settings (se disponível no backup)
|
|
294
|
-
- 📦 Storage (se disponível no backup)
|
|
295
|
-
- 🔧 Database Extensions and Settings (se disponível no backup)
|
|
296
|
-
- 🔄 Realtime Settings (se disponível no backup)
|
|
297
|
-
9. **Resumo detalhado** - Mostra backup selecionado, projeto destino e componentes
|
|
298
|
-
10. **Confirmação final** - Confirma antes de iniciar
|
|
299
|
-
11. **Endereços do projeto** - Confirma se as URLs Supabase nos dados e arquivos devem apontar para o novo projeto
|
|
300
|
-
12. **Execução da restauração:**
|
|
301
|
-
- 📊 Database - Restaura via `psql` (suporta `.backup.gz` e `.backup`)
|
|
302
|
-
- ⚡ Edge Functions - Faz deploy de uma cópia temporária, preservando as fontes locais
|
|
303
|
-
- 🔐 Auth Settings - Aplica via API e verifica os valores recuperados
|
|
304
|
-
- 📦 Storage - Restaura buckets e arquivos do ZIP, preserva metadados e verifica cada download
|
|
305
|
-
- 🔧 Database Settings - Restaura extensões e configurações via SQL
|
|
306
|
-
- 🔄 Realtime Settings - Aplica e verifica o snapshot registrado no backup
|
|
307
|
-
|
|
308
|
-
### Restauração verificada (1.0.8)
|
|
309
|
-
|
|
310
|
-
Use um projeto de destino novo e vazio e Node.js 20 ou mais recente. O backup completo existente da versão 1.0.7 pode ser reutilizado, sem nova captura. A versão 1.0.8 usa o dump completo como snapshot único: recupera a estrutura da aplicação, dados de Auth, histórico de migrações, buckets e metadados. Os schemas internos e as migrações da plataforma são mantidos na versão do destino.
|
|
311
|
-
|
|
312
|
-
A carga do banco usa uma transação com interrupção em erro, suspende triggers apenas nessa conexão, compara todas as colunas recuperadas e verifica chaves estrangeiras antes de confirmar. Permissões herdadas dos defaults do destino são removidas antes da reaplicação dos grants do backup. SQL com falha nunca é classificado como sucesso. O arquivo compactado e a pasta local de funções são preservados.
|
|
313
|
-
|
|
314
|
-
O remapeamento opcional troca apenas o domínio Supabase do projeto em URLs, inclusive em JSON e arquivos de texto. Não troca IDs isolados nem nomes de arquivos. URLs históricas também podem ser afetadas; escolha preservar quando isso for necessário. URLs assinadas, domínios personalizados, integrações externas e chaves de API da aplicação precisam de validação específica. As chaves de plataforma do destino não são substituídas.
|
|
315
|
-
|
|
316
|
-
As configurações legíveis de Auth e Realtime são aplicadas pela Management API e conferidas por nova leitura. A **senha SMTP não é exportável**: o Supabase devolve um valor protegido, que não pode ser usado como senha em outro projeto. A partir da versão 1.0.9, o smoonb solicita a senha real do provedor em campo oculto **antes de restaurar os componentes**, inclusive ao usar backups antigos. Ela permanece somente na memória e é enviada ao Supabase de destino. O relatório distingue senha aceita pela API de configurações verificadas por leitura (`applied_with_unverified_secrets`). Teste o envio de e-mail de autenticação no destino; aceitar uma senha pela API não comprova sua validade junto ao provedor.
|
|
317
|
-
|
|
318
|
-
Se uma restauração 1.0.8 parou em `Configuration verification failed: smtp_pass` e o `report.json` confirmou Database e Edge Functions, use o mesmo backup e projeto: execute `npx smoonb@1.0.9 restore`, responda **não** para Database e Edge Functions e **sim** para Auth, Storage, Database Settings e Realtime que ficaram pendentes. Informe a senha SMTP do provedor quando solicitada. Não é necessário refazer o backup nem recarregar o banco nesse caso.
|
|
319
|
-
|
|
320
|
-
A captura antiga de Realtime pode conter valores desatualizados: a restauração reproduz os valores e a data registrados, não o estado atual do projeto original. Novos backups capturam Realtime diretamente pela API. Em backups antigos sem o sinalizador de JWT de Functions, o padrão seguro é exigir JWT; os novos backups guardam esse sinalizador.
|
|
321
|
-
|
|
322
|
-
Desde a versão 1.0.10, se o Supabase não aplicar limites numéricos de Realtime, o smoonb mostra **valor do backup × valor atual do destino** e pergunta se você aceita manter os valores do destino. A partir da versão 1.0.11, o padrão recomendado é **sim — `(S/n)`**. Ao aceitar, ele relê as configurações e registra `completed_with_accepted_differences`, com os valores exatos, sem afirmar que o destino é idêntico ao backup. Configurações de segurança, ativação do serviço e pools de conexão continuam exigindo correspondência. A ferramenta não altera seu plano nem o limite de gastos.
|
|
323
|
-
|
|
324
|
-
Se uma restauração anterior terminou apenas com `Configuration verification failed: max_presence_events_per_second, max_payload_size_in_kb`, consulte o relatório anterior e execute `npx smoonb@1.0.11 restore` selecionando **somente Realtime Settings**. Não repita componentes já concluídos. Se concordar com os limites mostrados, responda **sim** à nova pergunta. Recusar mantém a etapa pendente e registra as diferenças; alterações já aplicadas não são desfeitas.
|
|
325
|
-
|
|
326
|
-
O relatório é salvo durante cada etapa, inclusive em falhas. Serviços externos não participam da transação do banco: se uma etapa posterior falhar, as anteriores permanecem registradas como concluídas. Não repita a carga do banco em um destino já preenchido. Resolva a etapa indicada e selecione apenas os componentes pendentes, ou use outro projeto vazio.
|
|
327
|
-
|
|
328
|
-
Dados internos não suportados (por exemplo, Vault com segredos criptografados sem migração da chave) e configurações incompatíveis com o plano/versão do destino interrompem o processo. O status verificado cobre os componentes selecionados; ainda é necessário validar login, envio de e-mail e fluxos de negócio antes de usar o destino em produção.
|
|
329
|
-
|
|
330
|
-
**Formato de arquivos suportados:**
|
|
331
|
-
- ✅ `.backup.gz` (compactado) - Descompacta automaticamente antes de restaurar
|
|
332
|
-
- ✅ `.backup` (descompactado) - Restaura diretamente
|
|
333
|
-
|
|
334
|
-
### Importar Backup do Dashboard do Supabase
|
|
335
|
-
|
|
336
|
-
Se você baixou um backup diretamente do Dashboard do Supabase (formato `.backup.gz`), você pode importá-lo para o formato esperado pelo smoonb. O comando também suporta importar arquivos de storage (`.storage.zip`) opcionalmente.
|
|
337
|
-
|
|
338
|
-
**Importar apenas database:**
|
|
339
|
-
```bash
|
|
340
|
-
npx smoonb import --file "caminho/completo/para/db_cluster-04-03-2024@14-16-59.backup.gz"
|
|
341
|
-
```
|
|
342
|
-
|
|
343
|
-
**Importar database e storage juntos:**
|
|
344
|
-
```bash
|
|
345
|
-
npx smoonb import --file "backup.backup.gz" --storage "meu-projeto.storage.zip"
|
|
346
|
-
```
|
|
347
|
-
|
|
348
|
-
**O que o comando faz:**
|
|
349
|
-
1. Lê o arquivo `.backup.gz` do Dashboard (obrigatório)
|
|
350
|
-
2. Se fornecido, lê o arquivo `.storage.zip` do Dashboard (opcional)
|
|
351
|
-
3. Extrai informações do nome do arquivo de backup (data e hora)
|
|
352
|
-
4. Cria uma pasta de backup no formato esperado (`backup-YYYY-MM-DD-HH-MM-SS`)
|
|
353
|
-
5. Copia o arquivo de backup para a pasta criada
|
|
354
|
-
6. Se fornecido, copia o arquivo de storage para a mesma pasta
|
|
355
|
-
7. Deixa o backup pronto para ser encontrado pelo comando `restore`
|
|
356
|
-
|
|
357
|
-
**Exemplo completo - Apenas database (usando import + restore):**
|
|
358
|
-
|
|
359
|
-
1. Baixe o backup do Dashboard do Supabase (ex.: `db_cluster-04-03-2024@14-16-59.backup.gz`).
|
|
360
|
-
2. Importe o arquivo e depois restaure:
|
|
361
|
-
|
|
362
|
-
```bash
|
|
363
|
-
npx smoonb import --file "C:\Downloads\db_cluster-04-03-2024@14-16-59.backup.gz"
|
|
364
|
-
npx smoonb restore
|
|
365
|
-
```
|
|
366
|
-
|
|
367
|
-
O backup importado aparecerá na lista de backups disponíveis.
|
|
368
|
-
|
|
369
|
-
**Exemplo completo - Database e Storage (usando import + restore):**
|
|
370
|
-
|
|
371
|
-
1. Baixe backup e storage do Dashboard do Supabase (ex.: `db_cluster-04-03-2024@14-16-59.backup.gz` e `meu-projeto.storage.zip`).
|
|
372
|
-
2. Importe ambos os arquivos e depois restaure:
|
|
373
|
-
|
|
374
|
-
```bash
|
|
375
|
-
npx smoonb import --file "C:\Downloads\db_cluster-04-03-2024@14-16-59.backup.gz" --storage "C:\Downloads\meu-projeto.storage.zip"
|
|
376
|
-
npx smoonb restore
|
|
377
|
-
```
|
|
378
|
-
|
|
379
|
-
O backup importado aparecerá na lista de backups disponíveis.
|
|
380
|
-
|
|
381
|
-
**Importante:**
|
|
382
|
-
- O arquivo de backup é **obrigatório** e deve estar no formato do Dashboard: `db_cluster-DD-MM-YYYY@HH-MM-SS.backup.gz`
|
|
383
|
-
- O arquivo de storage é **opcional** e deve estar no formato: `*.storage.zip`
|
|
384
|
-
- O storage depende de um backup, mas o backup não depende do storage
|
|
385
|
-
- Ambos os arquivos serão copiados para a mesma pasta de backup
|
|
386
|
-
- O caminho pode ser absoluto ou relativo
|
|
387
|
-
- O comando criará a estrutura de pastas necessária automaticamente
|
|
388
|
-
|
|
389
|
-
Após executar `import`, execute `restore` para escolher o backup importado na lista e restaurar.
|
|
390
|
-
|
|
391
|
-
## 🔧 Comandos Disponíveis
|
|
392
|
-
|
|
393
|
-
| Comando | Descrição |
|
|
394
|
-
|---------|-----------|
|
|
395
|
-
| `npx smoonb backup` | Backup completo interativo usando Docker |
|
|
396
|
-
| `npx smoonb backup --skip-supabase-version-check` | Backup pulando a checagem de versão do Supabase CLI |
|
|
397
|
-
| `npx smoonb restore` | Restauração interativa usando psql (Docker) |
|
|
398
|
-
| `npx smoonb restore --skip-supabase-version-check` | Restore pulando a checagem de versão do Supabase CLI |
|
|
399
|
-
| `npx smoonb import --file <path> [--storage <path>]` | Importar arquivo .backup.gz e opcionalmente .storage.zip do Dashboard do Supabase |
|
|
400
|
-
|
|
401
|
-
## 🏗️ Arquitetura Técnica
|
|
402
|
-
|
|
403
|
-
### Estrutura Modular
|
|
404
|
-
|
|
405
|
-
O código foi refatorado para uma **arquitetura modular** com etapas independentes:
|
|
406
|
-
|
|
407
|
-
#### Backup (`src/commands/backup/`)
|
|
408
|
-
```
|
|
409
|
-
backup/
|
|
410
|
-
├── index.js
|
|
411
|
-
├── utils.js
|
|
412
|
-
└── steps/
|
|
413
|
-
├── 00-license.js
|
|
414
|
-
├── 01-docker-validation.js
|
|
415
|
-
├── 02-database.js
|
|
416
|
-
├── 03-database-separated.js
|
|
417
|
-
├── 04-database-settings.js
|
|
418
|
-
├── 05-auth-settings.js
|
|
419
|
-
├── 06-realtime-settings.js
|
|
420
|
-
├── 07-storage.js
|
|
421
|
-
├── 08-custom-roles.js
|
|
422
|
-
├── 09-edge-functions.js
|
|
423
|
-
├── 10-supabase-temp.js
|
|
424
|
-
└── 11-migrations.js
|
|
425
|
-
```
|
|
426
|
-
|
|
427
|
-
#### Restore (`src/commands/restore/`)
|
|
428
|
-
A validação de licença (mesmo step do backup, `00-license.js` em backup/steps) roda no início. Em seguida:
|
|
429
|
-
```
|
|
430
|
-
restore/
|
|
431
|
-
├── index.js
|
|
432
|
-
├── utils.js
|
|
433
|
-
└── steps/
|
|
434
|
-
├── 00-backup-selection.js
|
|
435
|
-
├── 01-components-selection.js
|
|
436
|
-
├── 02-confirmation.js
|
|
437
|
-
├── 03-database.js
|
|
438
|
-
├── 04-edge-functions.js
|
|
439
|
-
├── 05-auth-settings.js
|
|
440
|
-
├── 06-storage.js
|
|
441
|
-
├── 07-database-settings.js
|
|
442
|
-
└── 08-realtime-settings.js
|
|
443
|
-
```
|
|
444
|
-
|
|
445
|
-
### Estratégia de Backup
|
|
446
|
-
|
|
447
|
-
#### Database
|
|
448
|
-
- **Backup Principal**: `pg_dumpall` via Docker (idêntico ao Dashboard)
|
|
449
|
-
- Arquivo: `db_cluster-XX-XX-XXXX@XX-XX-XX.backup.gz`
|
|
450
|
-
- Compatível com restauração via Dashboard do Supabase
|
|
451
|
-
- **Backup Separado**: SQL em arquivos distintos via Supabase CLI
|
|
452
|
-
- `schema.sql` - Estrutura das tabelas
|
|
453
|
-
- `data.sql` - Dados (comandos COPY)
|
|
454
|
-
- `roles.sql` - Roles e permissões
|
|
455
|
-
|
|
456
|
-
#### Edge Functions
|
|
457
|
-
- **Download Automático**: Via Supabase CLI `supabase functions download`
|
|
458
|
-
- **Reset de Link**: Garante link limpo com o projeto antes do download
|
|
459
|
-
- **Backup Completo**: Código completo de cada function
|
|
460
|
-
|
|
461
|
-
#### Migrations
|
|
462
|
-
- **Download Automático**: Via `supabase migration fetch`
|
|
463
|
-
- **Reset de Link**: Garante link limpo com o projeto
|
|
464
|
-
- **Backup Completo**: Todas as migrations do servidor
|
|
465
|
-
|
|
466
|
-
#### Storage
|
|
467
|
-
- **Backup Completo**: Download de todos os arquivos de todos os buckets
|
|
468
|
-
- **Estrutura Temporária**: Cria `storage_temp/project-id/bucket-name/arquivos...` dentro do backupDir
|
|
469
|
-
- **ZIP no Padrão Dashboard**: Cria `{project-id}.storage.zip` com estrutura `project-id/bucket-name/arquivos...`
|
|
470
|
-
- **Compatível com Restore**: O ZIP criado é compatível com o processo de restore (mesmo formato do Dashboard)
|
|
471
|
-
- **Pergunta Interativa**: Após criar o ZIP, pergunta se deseja limpar a estrutura temporária
|
|
472
|
-
- **Fallback**: Se não houver credenciais do Supabase, faz backup apenas de metadados
|
|
473
|
-
- **Management API**: Usa Personal Access Token para listar buckets e objetos
|
|
474
|
-
- **Supabase Client**: Usa Service Role Key para download de arquivos
|
|
475
|
-
|
|
476
|
-
#### Auth, Realtime
|
|
477
|
-
- **Management API**: Usa Personal Access Token
|
|
478
|
-
- **JSON Export**: Configurações exportadas como JSON
|
|
479
|
-
- **Realtime Settings**: Captura atual pela API, incluindo:
|
|
480
|
-
1. Habilitar serviço Realtime
|
|
481
|
-
2. Permitir acesso público
|
|
482
|
-
3. Tamanho do pool de conexões do database
|
|
483
|
-
4. Máximo de clientes simultâneos
|
|
484
|
-
5. Máximo de eventos por segundo
|
|
485
|
-
6. Máximo de eventos de presença por segundo
|
|
486
|
-
7. Tamanho máximo do payload em KB
|
|
487
|
-
- **Senha SMTP**: Não exportável; solicitada em campo oculto durante a restauração.
|
|
488
|
-
|
|
489
|
-
### Estratégia de Restauração
|
|
490
|
-
|
|
491
|
-
#### Database
|
|
492
|
-
- **Suporte a Formatos**:
|
|
493
|
-
- `.backup.gz` - Lê o conteúdo compactado sem alterar o arquivo original
|
|
494
|
-
- `.backup` - Restaura diretamente via `psql` (Docker)
|
|
495
|
-
- **Destino Vazio**: Exige destino vazio para restaurar o banco; desmarque esse componente ao repetir etapas posteriores que falharam.
|
|
496
|
-
|
|
497
|
-
#### Edge Functions
|
|
498
|
-
- **Deploy Isolado**: Usa uma pasta temporária, preservando os arquivos locais de `supabase/functions`
|
|
499
|
-
- **Destino Explícito**: Passa a referência do projeto de destino ao CLI
|
|
500
|
-
- **Deploy Automático**: Usa `supabase functions deploy`
|
|
501
|
-
|
|
502
|
-
#### Outros Componentes
|
|
503
|
-
- **Database Settings**: Restaura via SQL
|
|
504
|
-
- **Storage**: Restaura buckets e arquivos do ZIP (se disponível) ou exibe informações para configuração manual
|
|
505
|
-
- **Auth/Realtime**: Aplica e confere as configurações pela API; registra os limites da verificação SMTP e diferenças de capacidade do Realtime aceitas explicitamente.
|
|
506
|
-
|
|
507
|
-
### Multiplataforma
|
|
508
|
-
|
|
509
|
-
- **Windows/macOS/Linux**: Detecção automática de binários
|
|
510
|
-
- **Multiplataforma**: Usa `fs.promises.cp`, `path.join`, Docker
|
|
511
|
-
- **Docker para Tudo**: Backup, restore e compressão via Docker (garante consistência)
|
|
512
|
-
|
|
513
|
-
## 📊 Fluxo Recomendado
|
|
514
|
-
|
|
515
|
-
1. **Configurar `.env.local`** (primeira vez) com as credenciais do projeto origem.
|
|
516
|
-
2. **Backup do projeto origem:**
|
|
517
|
-
```bash
|
|
518
|
-
npx smoonb backup
|
|
519
|
-
```
|
|
520
|
-
(Mapeia variáveis interativamente na primeira vez, seleciona componentes, executa backup completo.)
|
|
521
|
-
3. **Criar novo projeto Supabase** (via Dashboard ou Supabase CLI).
|
|
522
|
-
4. **Editar `.env.local`** com as credenciais do novo projeto (apontar variáveis para o projeto destino).
|
|
523
|
-
5. **Restaurar backup** (modo interativo):
|
|
524
|
-
```bash
|
|
525
|
-
npx smoonb restore
|
|
526
|
-
```
|
|
527
|
-
(Seleciona backup desejado, componentes a restaurar, executa restauração.)
|
|
528
|
-
6. **Conferir o resultado**: leia `backups/restore-*/report.json` e teste login, e-mail e os fluxos da aplicação no destino.
|
|
529
|
-
|
|
530
|
-
## 🎨 Experiência do Usuário
|
|
531
|
-
|
|
532
|
-
### Interface em Português
|
|
533
|
-
|
|
534
|
-
Todas as interações são em **Português do Brasil**:
|
|
535
|
-
- Perguntas claras e diretas
|
|
536
|
-
- Explicações antes de cada processo
|
|
537
|
-
- Resumos detalhados antes de confirmar
|
|
538
|
-
- Confirmações com `(S/n)` ou `(s/N)` em português
|
|
539
|
-
|
|
540
|
-
### Mapeamento Inteligente de Variáveis
|
|
541
|
-
|
|
542
|
-
- **Detecção Automática**: Se a chave já existe com o nome esperado, pula a seleção
|
|
543
|
-
- **Opção de Adicionar**: Permite adicionar novas chaves se não existirem
|
|
544
|
-
- **Validação de Valores**: Confirma valores antes de salvar
|
|
545
|
-
- **Backup Automático**: Sempre cria backup do `.env.local` antes de alterações
|
|
546
|
-
|
|
547
|
-
### Processo Guiado
|
|
548
|
-
|
|
549
|
-
- **Validação Prévia**: Verifica Docker antes de começar
|
|
550
|
-
- **Explicações Contextuais**: Explica cada processo antes de perguntar
|
|
551
|
-
- **Resumo Final**: Mostra tudo que será feito antes de executar
|
|
552
|
-
- **Feedback Visual**: Cores e ícones para melhor experiência
|
|
553
|
-
|
|
554
|
-
## 🐛 Solução de Problemas
|
|
555
|
-
|
|
556
|
-
### Avisos de chaves estrangeiras circulares na exportação dos dados
|
|
557
|
-
|
|
558
|
-
Tabelas podem referenciar umas às outras ou a si mesmas. O PostgreSQL avisa que um dump **somente de dados** nem sempre pode ser restaurado com a verificação normal de chaves estrangeiras. Esse aviso isolado não significa falha na exportação: confira o resultado do comando e o manifesto do backup.
|
|
559
|
-
|
|
560
|
-
O smoonb agrupa esses avisos conhecidos, lista as tabelas envolvidas e registra os diagnósticos originais em `backup-manifest.json`, em `components.database_separated.warnings`. Outros avisos e erros continuam visíveis. Se schema, dados ou roles falharem, esse componente será marcado como incompleto.
|
|
561
|
-
|
|
562
|
-
Atualmente, o Supabase CLI coloca `SET session_replication_role = replica;` no início de `data.sql`. O smoonb verifica a primeira linha antes de informar sua presença. Isso **não valida a restauração**: a role de destino precisa ter permissão para alterar essa configuração. Restaure o schema antes dos dados e interrompa ao encontrar erros SQL. Para uma restauração controlada em destino separado e adequado, siga o [guia de backup/restauração do Supabase](https://supabase.com/docs/guides/platform/migrating-within-supabase/backup-restore):
|
|
563
|
-
|
|
564
|
-
```bash
|
|
565
|
-
psql --dbname "$TARGET_DB_URL" --single-transaction --variable ON_ERROR_STOP=1 --file roles.sql --file schema.sql --command 'SET session_replication_role = replica' --file data.sql
|
|
566
|
-
```
|
|
567
|
-
|
|
568
|
-
A configuração afeta essa conexão de restauração; não altera o banco de origem. Confira contagens e referências no destino restaurado antes de depender do backup. Não remova chaves estrangeiras da aplicação para silenciar os avisos. O `.backup.gz` principal é um dump completo do cluster; os SQL separados são arquivos adicionais.
|
|
569
|
-
|
|
570
|
-
### Verificações de desenvolvimento
|
|
571
|
-
|
|
572
|
-
Use Node.js 22 para as verificações de desenvolvimento: `npm test`, `npm run lint` e `npm run build`. O teste explícito `npm run test:docker` exige Docker, imagem `postgres:17` e Supabase CLI. Ele cria somente dados fictícios em um PostgreSQL descartável próprio, testa restaurações com e sem proteção e remove esse contêiner ao terminar. Não usa credenciais do projeto nem banco remoto.
|
|
573
|
-
|
|
574
|
-
|
|
575
|
-
### Docker não encontrado ou não está rodando
|
|
576
|
-
|
|
577
|
-
Verifique se o Docker está instalado e em execução:
|
|
578
|
-
|
|
579
|
-
```bash
|
|
580
|
-
docker --version
|
|
581
|
-
docker ps
|
|
582
|
-
```
|
|
583
|
-
|
|
584
|
-
Se não estiver, inicie o Docker Desktop (Windows/macOS) ou execute `sudo systemctl start docker` (Linux).
|
|
585
|
-
|
|
586
|
-
### Supabase CLI não encontrado
|
|
587
|
-
```bash
|
|
588
|
-
npm install -g supabase
|
|
589
|
-
```
|
|
590
|
-
|
|
591
|
-
### Supabase CLI desatualizado (abaixo da versão mínima aceita)
|
|
592
|
-
|
|
593
|
-
O smoonb aceita versões até **1 minor atrás da latest**. Se sua versão instalada estiver abaixo desse limite, você verá uma mensagem como:
|
|
594
|
-
|
|
595
|
-
```
|
|
596
|
-
❌ Supabase CLI X.Y.Z está abaixo da versão mínima aceita (X.W.0). Versão latest: X.V.Z. Atualize para pelo menos a versão X.W.0.
|
|
597
|
-
```
|
|
598
|
-
|
|
599
|
-
**Opção 1 — Atualizar o Supabase CLI:**
|
|
600
|
-
```bash
|
|
601
|
-
npm install -g supabase@latest # instalação global
|
|
602
|
-
npm install supabase@latest # instalação local/projeto
|
|
603
|
-
```
|
|
604
|
-
|
|
605
|
-
**Opção 2 — Pular a checagem (temporariamente, risco do usuário):**
|
|
606
|
-
```bash
|
|
607
|
-
npx smoonb backup --skip-supabase-version-check
|
|
608
|
-
npx smoonb restore --skip-supabase-version-check
|
|
609
|
-
```
|
|
610
|
-
|
|
611
|
-
> **Nota para usuários de Scoop (Windows):** o repositório do Scoop pode levar alguns dias para atualizar após um release. Use `--skip-supabase-version-check` até que o Scoop disponibilize a versão atualizada.
|
|
612
|
-
|
|
613
|
-
### Personal Access Token inválido ou ausente
|
|
614
|
-
|
|
615
|
-
1. Verificar se `SUPABASE_ACCESS_TOKEN` está no `.env.local`
|
|
616
|
-
2. Gerar novo token: https://supabase.com/dashboard/account/tokens
|
|
617
|
-
3. Atualizar `.env.local` com o novo token
|
|
618
|
-
|
|
619
|
-
### Database URL incorreta
|
|
620
|
-
- Verificar senha na URL de conexão
|
|
621
|
-
- Usar string de conexão do Dashboard Supabase (Settings → Database)
|
|
622
|
-
- Testar conexão: `psql "sua-database-url" -c "SELECT 1"`
|
|
623
|
-
|
|
624
|
-
### Arquivo .backup.gz não pode ser restaurado
|
|
625
|
-
|
|
626
|
-
O smoonb suporta automaticamente:
|
|
627
|
-
- ✅ `.backup.gz` - Lê o conteúdo compactado sem modificar o arquivo original
|
|
628
|
-
- ✅ `.backup` - Restaura diretamente
|
|
629
|
-
|
|
630
|
-
Se houver problemas:
|
|
631
|
-
1. Verificar se Docker está rodando
|
|
632
|
-
2. Verificar permissões do arquivo
|
|
633
|
-
3. Verificar espaço em disco
|
|
634
|
-
|
|
635
|
-
### Erro ao baixar Edge Functions
|
|
636
|
-
|
|
637
|
-
1. Verificar se `SUPABASE_ACCESS_TOKEN` está configurado
|
|
638
|
-
2. Verificar se o projeto está linkado: `supabase link`
|
|
639
|
-
3. Verificar se as functions existem no servidor
|
|
640
|
-
|
|
641
|
-
### Erro ao baixar Migrations
|
|
642
|
-
|
|
643
|
-
1. Verificar se `SUPABASE_ACCESS_TOKEN` está configurado
|
|
644
|
-
2. Verificar se o projeto está linkado: `supabase link`
|
|
645
|
-
3. Verificar se há migrations no servidor
|
|
646
|
-
|
|
647
|
-
## 🔒 Segurança
|
|
648
|
-
|
|
649
|
-
- **Backup Automático**: Sempre cria backup do `.env.local` antes de alterações
|
|
650
|
-
- **Mapeamento Local**: Mapeamento de variáveis salvo apenas localmente
|
|
651
|
-
- **Sem Dados Sensíveis**: Nenhum dado sensível é enviado para fora do seu ambiente
|
|
652
|
-
- **Docker Isolado**: Operações de database via Docker (isolamento)
|
|
653
|
-
|
|
654
|
-
## 💼 Acesso e assinatura
|
|
655
|
-
|
|
656
|
-
O código do Supa Moonbase é disponibilizado sob licença MIT (ver `LICENSE`). Para usar o smoonb é obrigatório ter **licença ativa** e **assinatura válida**, ou estar em **período de trial**. A validação da licença ocorre no início do backup e do restore; sem licença e assinatura válidas (ou trial), o CLI não executa essas operações.
|
|
657
|
-
|
|
658
|
-
[smoonb.com/#price](https://www.smoonb.com/#price).
|
|
659
|
-
|
|
660
|
-
## 🔒 Privacidade e LGPD (resumo)
|
|
661
|
-
|
|
662
|
-
O Supa Moonbase adota o princípio de minimização de dados. Tratamos apenas as informações estritamente necessárias para controle de acesso e faturamento (por exemplo, identificador de conta e contato). Os propósitos, bases legais e direitos do titular estão descritos na [Política de Privacidade](https://www.smoonb.com/privacy).
|
|
663
|
-
|
|
664
|
-
## 📋 Termos de Serviço e uso de marca
|
|
665
|
-
|
|
666
|
-
A licença de código (MIT) não substitui os [Termos de Serviço](https://www.smoonb.com/terms) que regem o acesso operacional e a validação de assinatura.
|
|
667
|
-
|
|
668
|
-
"Supa Moonbase" e elementos de identidade visual são marcas da Goalmoon Tecnologia Ltda.; o uso de marca e assets de branding é restrito, conforme os [Termos de Serviço](https://www.smoonb.com/terms).
|
|
669
|
-
|
|
670
|
-
[FAQ](https://www.smoonb.com/#faq).
|
|
671
|
-
|
|
672
|
-
## 📝 Licença
|
|
673
|
-
|
|
674
|
-
O código do Supa Moonbase é disponibilizado sob licença MIT. Veja [LICENSE](LICENSE) para o texto completo da licença. Uma tradução em português está disponível em [LICENSE.pt-BR.md](LICENSE.pt-BR.md) apenas para conveniência.
|
|
675
|
-
|
|
676
|
-
## 🤝 Contribuição
|
|
677
|
-
|
|
678
|
-
Contribuições são bem-vindas. [www.smoonb.com/#price](https://www.smoonb.com/#price).
|
|
679
|
-
|
|
680
|
-
|
|
681
|
-
---
|
|
682
|
-
|
|
683
|
-
**Desenvolvido por:** Goalmoon Tecnologia LTDA
|
|
684
|
-
**Website:** https://www.smoonb.com
|
|
685
|
-
**GitHub:** https://github.com/almmello/smoonb
|
|
686
|
-
|
|
687
|
-
Teste adicional do caminho real de restore: `npm run test:restore:docker`. Usa PostgreSQL descartável, dados fictícios e transporte HTTP simulado para Storage; cobre Auth, permissões, ciclos, rollback, arquivos e metadados.
|
|
688
|
-
|
|
689
|
-
## Estabilidade a partir da 1.0.12
|
|
690
|
-
|
|
691
|
-
Use Node.js LTS 22, 24 ou 26 e Docker ativo. O pacote inclui Supabase CLI 2.122.1 e npm-shrinkwrap.json; não utiliza o CLI global nem exige acompanhar latest. O canal v2 recebe manutenção, sem promessa de prazo LTS. Atualizações de ferramentas devem ser homologadas em uma nova versão do smoonb. A primeira exportação pode precisar baixar a imagem PostgreSQL usada pelo CLI; confira conectividade e espaço em disco.
|
|
692
|
-
|
|
693
|
-
O backup usa diretórios temporários para SQL, roles, Functions e migrations, preserva os arquivos do projeto e retorna código 1/status incomplete quando um componente solicitado falha. Os arquivos concluídos ficam disponíveis, mas o conjunto não deve ser tratado como completo.
|
|
694
|
-
|
|
695
|
-
Após publicação, no Sicoop execute `npm install --save-exact smoonb@1.0.
|
|
696
|
-
|
|
697
|
-
Na 1.0.13, bancos sem histórico de migrations concluem essa etapa com zero arquivos. Falhas reais de conexão/permissão continuam produzindo backup incompleto, sempre com resumo de todas as etapas.
|
|
1
|
+
# Supa Moonbase (smoonb)
|
|
2
|
+
|
|
3
|
+
**Ferramenta completa de backup e migração do Supabase**
|
|
4
|
+
|
|
5
|
+
Backup e restauração: completo e simples, como deveria ser
|
|
6
|
+
|
|
7
|
+
> **Produto comercial.** É necessário ter **licença ativa** e **assinatura válida** (ou estar em período de trial) para usar o smoonb. [www.smoonb.com/#price](https://www.smoonb.com/#price). O uso é regido pelos [Termos de Serviço](https://www.smoonb.com/terms) e pela [Política de Privacidade](https://www.smoonb.com/privacy). Não assumimos responsabilidade por danos causados pelo smoonb; os avisos legais abaixo permanecem válidos.
|
|
8
|
+
|
|
9
|
+
**Leia em outro idioma:** [English](README.md)
|
|
10
|
+
|
|
11
|
+
**Desenvolvido por:** Goalmoon Tecnologia LTDA
|
|
12
|
+
**Website:** https://www.smoonb.com
|
|
13
|
+
**GitHub:** https://github.com/almmello/smoonb
|
|
14
|
+
|
|
15
|
+
## 🎯 Objetivo
|
|
16
|
+
|
|
17
|
+
O **smoonb** resolve o problema das ferramentas existentes que fazem backup apenas da database PostgreSQL, ignorando componentes críticos do Supabase.
|
|
18
|
+
|
|
19
|
+
## 📦 Componentes de Backup
|
|
20
|
+
|
|
21
|
+
O smoonb faz backup completo de todos os componentes do seu projeto Supabase:
|
|
22
|
+
|
|
23
|
+
- ✅ **Database PostgreSQL** (backup completo via `pg_dumpall` + SQL separados, idêntico ao Dashboard)
|
|
24
|
+
- ✅ **Database Extensions and Settings** (extensões PostgreSQL e configurações)
|
|
25
|
+
- ✅ **Custom Roles** (roles personalizados do PostgreSQL)
|
|
26
|
+
- ✅ **Edge Functions** (download automático do servidor)
|
|
27
|
+
- ✅ **Auth Settings** (configurações de autenticação via Management API)
|
|
28
|
+
- ✅ **Storage Buckets** (backup completo: metadados, configurações e todos os arquivos via Management API + Supabase Client, cria ZIP no padrão do Dashboard)
|
|
29
|
+
- ✅ **Realtime Settings** (configurações atuais capturadas pela Management API)
|
|
30
|
+
- ✅ **Supabase .temp** (arquivos temporários do Supabase CLI)
|
|
31
|
+
- ✅ **Migrations** (todas as migrations do projeto via `supabase migration fetch`)
|
|
32
|
+
|
|
33
|
+
## ⚠️ Universal Disclaimer / Aviso Legal Universal
|
|
34
|
+
|
|
35
|
+
Ao continuar, você reconhece e concorda que o Supa Moonbase (smoonb) é fornecido "NO ESTADO EM QUE SE ENCONTRA" ("AS IS") e "CONFORME DISPONIBILIDADE" ("AS AVAILABLE"), sem garantias de qualquer natureza—expressas, implícitas ou legais—incluindo, sem limitação, garantias de comercialização, adequação a um fim específico e não violação, na máxima extensão permitida pela lei aplicável. Operações de backup e restauração envolvem riscos inerentes, os ambientes variam amplamente e não podemos prever ou validar todas as configurações dos usuários. Você é o único responsável por validar seu próprio ambiente, manter cópias independentes e verificar os resultados antes de utilizá-los em produção. Construímos o Supa Moonbase (smoonb) com repositórios públicos, auditáveis e de código aberto para ajudar pessoas a simplificar seus fluxos de trabalho, mas isso não cria qualquer garantia, promessa de suporte ou compromisso de nível de serviço.
|
|
36
|
+
|
|
37
|
+
**Limitação de responsabilidade** — Na máxima extensão permitida por lei, a Goalmoon Tecnologia LTDA, seus contribuidores e licenciadores não serão responsáveis por quaisquer danos indiretos, incidentais, especiais, consequentes, exemplares ou punitivos (incluindo perda de dados, interrupção de negócios ou lucros cessantes) decorrentes ou relacionados ao uso, incapacidade de uso, operações de backup/restauração realizadas por, ou resultados produzidos pelo Supa Moonbase (smoonb).
|
|
38
|
+
|
|
39
|
+
## 🚀 Instalação
|
|
40
|
+
|
|
41
|
+
**⚠️ IMPORTANTE: Instale APENAS localmente no projeto!**
|
|
42
|
+
|
|
43
|
+
**Instalar localmente no projeto:**
|
|
44
|
+
```bash
|
|
45
|
+
npm install smoonb
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
**Usar com npx:**
|
|
49
|
+
```bash
|
|
50
|
+
npx smoonb --help
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
**Não instalar globalmente** (será bloqueado):
|
|
54
|
+
```bash
|
|
55
|
+
npm install -g smoonb
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
### 🔄 Atualizar para a Última Versão
|
|
59
|
+
|
|
60
|
+
Para atualizar o smoonb para a versão mais recente disponível, execute no projeto atual:
|
|
61
|
+
|
|
62
|
+
```bash
|
|
63
|
+
npm install smoonb@latest
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
**⚠️ IMPORTANTE:** O smoonb deve ser instalado localmente no projeto. Não é permitido usar sem instalar (ex.: `npx smoonb@latest`).
|
|
67
|
+
|
|
68
|
+
**💡 Por que apenas local?**
|
|
69
|
+
- **🔒 Segurança**: Evita conflitos de versão
|
|
70
|
+
- **📦 Isolamento**: Cada projeto usa sua versão
|
|
71
|
+
- **🔄 Atualizações**: Controle granular por projeto
|
|
72
|
+
- **🛡️ Estabilidade**: Evita quebras em outros projetos
|
|
73
|
+
|
|
74
|
+
## 📋 Pré-requisitos
|
|
75
|
+
|
|
76
|
+
### 1. Docker Desktop (OBRIGATÓRIO)
|
|
77
|
+
|
|
78
|
+
Instale pelo [Docker Desktop](https://docs.docker.com/desktop/install/) (Windows/macOS) ou [Docker Engine](https://docs.docker.com/engine/install/) (Linux). Depois verifique se está rodando:
|
|
79
|
+
|
|
80
|
+
```bash
|
|
81
|
+
docker --version
|
|
82
|
+
docker ps
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
**⚠️ IMPORTANTE:** O Docker é necessário para:
|
|
86
|
+
- Backup da database via `pg_dumpall` (compatível com Dashboard do Supabase)
|
|
87
|
+
- Compressão de arquivos `.backup.gz`
|
|
88
|
+
- Restauração de backups `.backup` e `.backup.gz`
|
|
89
|
+
|
|
90
|
+
### 2. Supabase CLI
|
|
91
|
+
```bash
|
|
92
|
+
npm install -g supabase
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
**Política de versão:** o smoonb aceita qualquer versão do Supabase CLI que esteja **no máximo 1 minor atrás da latest** (mesma major). Recomendamos sempre usar a versão mais recente. Versões muito antigas são bloqueadas com mensagem de erro.
|
|
96
|
+
|
|
97
|
+
Se o seu gerenciador de pacotes (ex.: **Scoop** no Windows) instala com atraso e você quer avançar mesmo assim, use a flag `--skip-supabase-version-check` (veja a seção de uso abaixo).
|
|
98
|
+
|
|
99
|
+
Para atualizar o Supabase CLI: [Atualizando o Supabase CLI](https://supabase.com/docs/guides/cli/getting-started#updating-the-supabase-cli).
|
|
100
|
+
|
|
101
|
+
### 3. Personal Access Token do Supabase
|
|
102
|
+
É necessário obter um token de acesso pessoal do Supabase para usar a Management API:
|
|
103
|
+
|
|
104
|
+
1. Acesse: https://supabase.com/dashboard/account/tokens
|
|
105
|
+
2. Clique em "Generate new token"
|
|
106
|
+
3. Copie o token (formato: `sbp_...`)
|
|
107
|
+
4. Adicione ao `.env.local` como `SUPABASE_ACCESS_TOKEN`
|
|
108
|
+
|
|
109
|
+
### 4. Chave de licença (OBRIGATÓRIA para backup e restore)
|
|
110
|
+
O **smoonb** exige uma licença válida para executar backup e restore:
|
|
111
|
+
|
|
112
|
+
1. Obtenha sua licença no app desktop em https://www.smoonb.com
|
|
113
|
+
2. Defina no ambiente ou no `.env.local`: `SMOONB_LICENSE_KEY=[sua-chave-de-licença]`
|
|
114
|
+
3. A licença é validada no início de cada execução (step 00); não há cache. Se a validação falhar (rede/servidor), o CLI aborta. A licença **não** aparece no wizard de mapeamento de variáveis (já foi validada antes).
|
|
115
|
+
|
|
116
|
+
## ⚙️ Configuração
|
|
117
|
+
|
|
118
|
+
### Método Moderno: `.env.local` (RECOMENDADO)
|
|
119
|
+
|
|
120
|
+
O **smoonb** agora usa `.env.local` para configuração, seguindo o padrão da indústria. Isso torna o processo mais simples e integrado ao seu fluxo de trabalho.
|
|
121
|
+
|
|
122
|
+
#### 1. Criar ou editar `.env.local` na raiz do projeto
|
|
123
|
+
|
|
124
|
+
```bash
|
|
125
|
+
touch .env.local
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
#### 2. Adicionar as variáveis de ambiente necessárias
|
|
129
|
+
|
|
130
|
+
```env
|
|
131
|
+
SMOONB_LICENSE_KEY=[sua-chave-de-licença]
|
|
132
|
+
NEXT_PUBLIC_SUPABASE_URL=[sua-supabase-url]
|
|
133
|
+
NEXT_PUBLIC_SUPABASE_ANON_KEY=[sua-anon-key]
|
|
134
|
+
SUPABASE_SERVICE_ROLE_KEY=[sua-service-role]
|
|
135
|
+
SUPABASE_DB_URL=postgresql://postgres:[sua-database-password]@db.[seu-project-id].supabase.co:5432/postgres
|
|
136
|
+
SUPABASE_PROJECT_ID=[seu-project-id]
|
|
137
|
+
SUPABASE_ACCESS_TOKEN=[seu-access-token]
|
|
138
|
+
SUPABASE_POSTGRES_MAJOR=17
|
|
139
|
+
SMOONB_TELEMETRY_ENABLED=true
|
|
140
|
+
SMOONB_OUTPUT_DIR=./backups
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
Obrigatórias: `SMOONB_LICENSE_KEY` (app desktop em [smoonb.com](https://www.smoonb.com)), `SUPABASE_POSTGRES_MAJOR` (ex.: 17; veja no Dashboard → Project Settings → Infrastructure → Service Versions). Opcionais: `SMOONB_TELEMETRY_ENABLED`, `SMOONB_OUTPUT_DIR` (padrão `./backups`).
|
|
144
|
+
|
|
145
|
+
#### 3. Mapeamento Interativo
|
|
146
|
+
|
|
147
|
+
Ao executar `backup` ou `restore` pela primeira vez, o **smoonb** irá:
|
|
148
|
+
|
|
149
|
+
1. **Ler** seu `.env.local` atual
|
|
150
|
+
2. **Identificar** as chaves que você já tem
|
|
151
|
+
3. **Perguntar interativamente** quais chaves correspondem às esperadas (se os nomes forem diferentes)
|
|
152
|
+
4. **Adicionar** chaves faltantes se necessário
|
|
153
|
+
5. **Criar backup** automático do `.env.local` antes de qualquer alteração
|
|
154
|
+
6. **Salvar mapeamento** para futuras execuções
|
|
155
|
+
|
|
156
|
+
**Exemplo de mapeamento:**
|
|
157
|
+
```
|
|
158
|
+
🔧 Mapeando variável: NEXT_PUBLIC_SUPABASE_URL
|
|
159
|
+
Valor atual: https://abc123.supabase.co
|
|
160
|
+
Este é o valor correto do projeto alvo? (S/n): S
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
## 🌐 Internacionalização (i18n)
|
|
164
|
+
|
|
165
|
+
O **smoonb** suporta múltiplos idiomas automaticamente. Atualmente, os idiomas suportados são:
|
|
166
|
+
|
|
167
|
+
- **Inglês (en)** - Idioma padrão
|
|
168
|
+
- **Português do Brasil (pt-BR)** - Suporte completo
|
|
169
|
+
|
|
170
|
+
### Detecção Automática de Idioma
|
|
171
|
+
|
|
172
|
+
O idioma é detectado automaticamente na seguinte ordem de precedência:
|
|
173
|
+
|
|
174
|
+
1. **Variável de ambiente `SMOONB_LANG`** (no `.env.local` ou no ambiente)
|
|
175
|
+
2. **Locale do sistema** (LANG, LC_ALL, LC_MESSAGES). Exemplo: `LANG=pt_BR.UTF-8` → pt-BR
|
|
176
|
+
3. **Fallback para inglês (en)** se nenhum dos anteriores for detectado
|
|
177
|
+
|
|
178
|
+
### Idiomas Suportados e Aliases
|
|
179
|
+
|
|
180
|
+
- `en` ou `en-US` → Inglês
|
|
181
|
+
- `pt-BR`, `pt_BR` ou `pt` → Português do Brasil
|
|
182
|
+
|
|
183
|
+
### Notas Importantes
|
|
184
|
+
|
|
185
|
+
- **Saídas "máquina"** (ex.: `--json` se implementado) **não** são traduzidas; campos e chaves permanecem em inglês
|
|
186
|
+
- Se uma chave de tradução estiver ausente em um idioma, o sistema faz **fallback automático para inglês**
|
|
187
|
+
- O idioma é detectado uma vez no início da execução e aplicado a todas as mensagens do CLI
|
|
188
|
+
|
|
189
|
+
## 🎯 Uso
|
|
190
|
+
|
|
191
|
+
### Backup Completo
|
|
192
|
+
|
|
193
|
+
```bash
|
|
194
|
+
npx smoonb backup
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
**Opções disponíveis:**
|
|
198
|
+
|
|
199
|
+
| Flag | Descrição |
|
|
200
|
+
|------|-----------|
|
|
201
|
+
| `--skip-supabase-version-check` | Pula a checagem de versão do Supabase CLI. Use quando seu gerenciador de pacotes (ex.: Scoop) instala com atraso. Um aviso é exibido e o usuário assume o risco. |
|
|
202
|
+
|
|
203
|
+
**Exemplo com a flag:**
|
|
204
|
+
```bash
|
|
205
|
+
npx smoonb backup --skip-supabase-version-check
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
**Fluxo interativo do backup:**
|
|
209
|
+
|
|
210
|
+
1. **Termo de uso** - Exibe e solicita aceitação dos termos
|
|
211
|
+
2. **Validação de licença** - Valida `SMOONB_LICENSE_KEY` (env ou prompt); sem cache; aborta se a validação falhar
|
|
212
|
+
3. **Validação Docker** - Verifica se o Docker está rodando
|
|
213
|
+
4. **Consentimento** - Pede permissão para ler/escrever `.env.local`
|
|
214
|
+
5. **Mapeamento de variáveis** - Mapeia suas variáveis de ambiente (primeira vez; a licença não entra no wizard—já validada)
|
|
215
|
+
6. **Backup do .env.local** - Cria backup automático antes de alterações
|
|
216
|
+
7. **Seleção de componentes** - Pergunta quais componentes incluir:
|
|
217
|
+
- ⚡ Edge Functions (explicação sobre reset de link e download)
|
|
218
|
+
- 📦 Storage (explicação sobre backup completo: download de arquivos + ZIP no padrão do Dashboard)
|
|
219
|
+
- 🔐 Auth Settings (explicação sobre configurações)
|
|
220
|
+
- 🔄 Realtime Settings (explicação sobre captura interativa de 7 parâmetros)
|
|
221
|
+
- 🗑️ Opções de limpeza (functions, .temp, migrations após backup)
|
|
222
|
+
8. **Resumo de configurações** - Mostra tudo que será feito
|
|
223
|
+
9. **Confirmação final** - Confirma antes de iniciar
|
|
224
|
+
10. **Execução das etapas:**
|
|
225
|
+
- 📊 1/10 - Backup Database via `pg_dumpall` (Docker)
|
|
226
|
+
- 📊 2/10 - Backup Database SQL separado (schema, dados, roles)
|
|
227
|
+
- 🔧 3/10 - Backup Database Extensions and Settings
|
|
228
|
+
- 🔐 4/10 - Backup Auth Settings (se selecionado)
|
|
229
|
+
- 🔄 5/10 - Backup Realtime Settings (se selecionado) - 7 parâmetros capturados interativamente
|
|
230
|
+
- 📦 6/10 - Backup Storage (se selecionado) - Download completo de arquivos + ZIP no padrão do Dashboard
|
|
231
|
+
- 👥 7/10 - Backup Custom Roles
|
|
232
|
+
- ⚡ 8/10 - Backup Edge Functions (se selecionado)
|
|
233
|
+
- 📁 9/10 - Backup Supabase .temp (se selecionado)
|
|
234
|
+
- 📋 10/10 - Backup Migrations (se selecionado)
|
|
235
|
+
|
|
236
|
+
**Resultado:** Uma pasta `backups/backup-YYYY-MM-DD-HH-MM-SS/` contendo, por exemplo:
|
|
237
|
+
|
|
238
|
+
```
|
|
239
|
+
backups/backup-2025-10-31-09-37-54/
|
|
240
|
+
├── backup-manifest.json
|
|
241
|
+
├── db_cluster-31-10-2025@09-38-57.backup.gz
|
|
242
|
+
├── schema.sql
|
|
243
|
+
├── data.sql
|
|
244
|
+
├── roles.sql
|
|
245
|
+
├── database-settings-*.json
|
|
246
|
+
├── auth-settings.json
|
|
247
|
+
├── realtime-settings.json
|
|
248
|
+
├── storage/
|
|
249
|
+
│ └── [bucket-name].json
|
|
250
|
+
├── [project-id].storage.zip
|
|
251
|
+
├── storage_temp/
|
|
252
|
+
│ └── [project-id]/
|
|
253
|
+
│ └── [bucket-name]/
|
|
254
|
+
├── edge-functions/
|
|
255
|
+
│ └── [nome-da-function]/
|
|
256
|
+
├── supabase-temp/
|
|
257
|
+
├── migrations/
|
|
258
|
+
└── env/
|
|
259
|
+
├── .env.local
|
|
260
|
+
└── env-map.json
|
|
261
|
+
```
|
|
262
|
+
|
|
263
|
+
### Restauração Interativa
|
|
264
|
+
|
|
265
|
+
**Restaurar backup existente:**
|
|
266
|
+
```bash
|
|
267
|
+
npx smoonb restore
|
|
268
|
+
```
|
|
269
|
+
|
|
270
|
+
**Opções disponíveis:**
|
|
271
|
+
|
|
272
|
+
| Flag | Descrição |
|
|
273
|
+
|------|-----------|
|
|
274
|
+
| `--skip-supabase-version-check` | Pula a checagem de versão do Supabase CLI. Use quando seu gerenciador de pacotes (ex.: Scoop) instala com atraso. Um aviso é exibido e o usuário assume o risco. |
|
|
275
|
+
|
|
276
|
+
**Exemplo com a flag:**
|
|
277
|
+
```bash
|
|
278
|
+
npx smoonb restore --skip-supabase-version-check
|
|
279
|
+
```
|
|
280
|
+
|
|
281
|
+
**Fluxo interativo do restore:**
|
|
282
|
+
|
|
283
|
+
1. **Termo de uso** - Exibe e solicita aceitação dos termos
|
|
284
|
+
2. **Validação de licença** - Valida `SMOONB_LICENSE_KEY` (env ou prompt); aborta se a validação falhar
|
|
285
|
+
3. **Validação Docker** - Verifica se o Docker está rodando
|
|
286
|
+
4. **Consentimento** - Pede permissão para ler/escrever `.env.local`
|
|
287
|
+
5. **Mapeamento de variáveis** - Mapeia variáveis para o projeto de destino (inclui `SUPABASE_POSTGRES_MAJOR`)
|
|
288
|
+
6. **Backup do .env.local** - Cria backup automático
|
|
289
|
+
7. **Seleção de backup** - Lista e permite escolher qual backup restaurar
|
|
290
|
+
8. **Seleção de componentes** - Pergunta quais componentes restaurar:
|
|
291
|
+
- 📊 Database (sempre disponível)
|
|
292
|
+
- ⚡ Edge Functions (se disponível no backup)
|
|
293
|
+
- 🔐 Auth Settings (se disponível no backup)
|
|
294
|
+
- 📦 Storage (se disponível no backup)
|
|
295
|
+
- 🔧 Database Extensions and Settings (se disponível no backup)
|
|
296
|
+
- 🔄 Realtime Settings (se disponível no backup)
|
|
297
|
+
9. **Resumo detalhado** - Mostra backup selecionado, projeto destino e componentes
|
|
298
|
+
10. **Confirmação final** - Confirma antes de iniciar
|
|
299
|
+
11. **Endereços do projeto** - Confirma se as URLs Supabase nos dados e arquivos devem apontar para o novo projeto
|
|
300
|
+
12. **Execução da restauração:**
|
|
301
|
+
- 📊 Database - Restaura via `psql` (suporta `.backup.gz` e `.backup`)
|
|
302
|
+
- ⚡ Edge Functions - Faz deploy de uma cópia temporária, preservando as fontes locais
|
|
303
|
+
- 🔐 Auth Settings - Aplica via API e verifica os valores recuperados
|
|
304
|
+
- 📦 Storage - Restaura buckets e arquivos do ZIP, preserva metadados e verifica cada download
|
|
305
|
+
- 🔧 Database Settings - Restaura extensões e configurações via SQL
|
|
306
|
+
- 🔄 Realtime Settings - Aplica e verifica o snapshot registrado no backup
|
|
307
|
+
|
|
308
|
+
### Restauração verificada (1.0.8)
|
|
309
|
+
|
|
310
|
+
Use um projeto de destino novo e vazio e Node.js 20 ou mais recente. O backup completo existente da versão 1.0.7 pode ser reutilizado, sem nova captura. A versão 1.0.8 usa o dump completo como snapshot único: recupera a estrutura da aplicação, dados de Auth, histórico de migrações, buckets e metadados. Os schemas internos e as migrações da plataforma são mantidos na versão do destino.
|
|
311
|
+
|
|
312
|
+
A carga do banco usa uma transação com interrupção em erro, suspende triggers apenas nessa conexão, compara todas as colunas recuperadas e verifica chaves estrangeiras antes de confirmar. Permissões herdadas dos defaults do destino são removidas antes da reaplicação dos grants do backup. SQL com falha nunca é classificado como sucesso. O arquivo compactado e a pasta local de funções são preservados.
|
|
313
|
+
|
|
314
|
+
O remapeamento opcional troca apenas o domínio Supabase do projeto em URLs, inclusive em JSON e arquivos de texto. Não troca IDs isolados nem nomes de arquivos. URLs históricas também podem ser afetadas; escolha preservar quando isso for necessário. URLs assinadas, domínios personalizados, integrações externas e chaves de API da aplicação precisam de validação específica. As chaves de plataforma do destino não são substituídas.
|
|
315
|
+
|
|
316
|
+
As configurações legíveis de Auth e Realtime são aplicadas pela Management API e conferidas por nova leitura. A **senha SMTP não é exportável**: o Supabase devolve um valor protegido, que não pode ser usado como senha em outro projeto. A partir da versão 1.0.9, o smoonb solicita a senha real do provedor em campo oculto **antes de restaurar os componentes**, inclusive ao usar backups antigos. Ela permanece somente na memória e é enviada ao Supabase de destino. O relatório distingue senha aceita pela API de configurações verificadas por leitura (`applied_with_unverified_secrets`). Teste o envio de e-mail de autenticação no destino; aceitar uma senha pela API não comprova sua validade junto ao provedor.
|
|
317
|
+
|
|
318
|
+
Se uma restauração 1.0.8 parou em `Configuration verification failed: smtp_pass` e o `report.json` confirmou Database e Edge Functions, use o mesmo backup e projeto: execute `npx smoonb@1.0.9 restore`, responda **não** para Database e Edge Functions e **sim** para Auth, Storage, Database Settings e Realtime que ficaram pendentes. Informe a senha SMTP do provedor quando solicitada. Não é necessário refazer o backup nem recarregar o banco nesse caso.
|
|
319
|
+
|
|
320
|
+
A captura antiga de Realtime pode conter valores desatualizados: a restauração reproduz os valores e a data registrados, não o estado atual do projeto original. Novos backups capturam Realtime diretamente pela API. Em backups antigos sem o sinalizador de JWT de Functions, o padrão seguro é exigir JWT; os novos backups guardam esse sinalizador.
|
|
321
|
+
|
|
322
|
+
Desde a versão 1.0.10, se o Supabase não aplicar limites numéricos de Realtime, o smoonb mostra **valor do backup × valor atual do destino** e pergunta se você aceita manter os valores do destino. A partir da versão 1.0.11, o padrão recomendado é **sim — `(S/n)`**. Ao aceitar, ele relê as configurações e registra `completed_with_accepted_differences`, com os valores exatos, sem afirmar que o destino é idêntico ao backup. Configurações de segurança, ativação do serviço e pools de conexão continuam exigindo correspondência. A ferramenta não altera seu plano nem o limite de gastos.
|
|
323
|
+
|
|
324
|
+
Se uma restauração anterior terminou apenas com `Configuration verification failed: max_presence_events_per_second, max_payload_size_in_kb`, consulte o relatório anterior e execute `npx smoonb@1.0.11 restore` selecionando **somente Realtime Settings**. Não repita componentes já concluídos. Se concordar com os limites mostrados, responda **sim** à nova pergunta. Recusar mantém a etapa pendente e registra as diferenças; alterações já aplicadas não são desfeitas.
|
|
325
|
+
|
|
326
|
+
O relatório é salvo durante cada etapa, inclusive em falhas. Serviços externos não participam da transação do banco: se uma etapa posterior falhar, as anteriores permanecem registradas como concluídas. Não repita a carga do banco em um destino já preenchido. Resolva a etapa indicada e selecione apenas os componentes pendentes, ou use outro projeto vazio.
|
|
327
|
+
|
|
328
|
+
Dados internos não suportados (por exemplo, Vault com segredos criptografados sem migração da chave) e configurações incompatíveis com o plano/versão do destino interrompem o processo. O status verificado cobre os componentes selecionados; ainda é necessário validar login, envio de e-mail e fluxos de negócio antes de usar o destino em produção.
|
|
329
|
+
|
|
330
|
+
**Formato de arquivos suportados:**
|
|
331
|
+
- ✅ `.backup.gz` (compactado) - Descompacta automaticamente antes de restaurar
|
|
332
|
+
- ✅ `.backup` (descompactado) - Restaura diretamente
|
|
333
|
+
|
|
334
|
+
### Importar Backup do Dashboard do Supabase
|
|
335
|
+
|
|
336
|
+
Se você baixou um backup diretamente do Dashboard do Supabase (formato `.backup.gz`), você pode importá-lo para o formato esperado pelo smoonb. O comando também suporta importar arquivos de storage (`.storage.zip`) opcionalmente.
|
|
337
|
+
|
|
338
|
+
**Importar apenas database:**
|
|
339
|
+
```bash
|
|
340
|
+
npx smoonb import --file "caminho/completo/para/db_cluster-04-03-2024@14-16-59.backup.gz"
|
|
341
|
+
```
|
|
342
|
+
|
|
343
|
+
**Importar database e storage juntos:**
|
|
344
|
+
```bash
|
|
345
|
+
npx smoonb import --file "backup.backup.gz" --storage "meu-projeto.storage.zip"
|
|
346
|
+
```
|
|
347
|
+
|
|
348
|
+
**O que o comando faz:**
|
|
349
|
+
1. Lê o arquivo `.backup.gz` do Dashboard (obrigatório)
|
|
350
|
+
2. Se fornecido, lê o arquivo `.storage.zip` do Dashboard (opcional)
|
|
351
|
+
3. Extrai informações do nome do arquivo de backup (data e hora)
|
|
352
|
+
4. Cria uma pasta de backup no formato esperado (`backup-YYYY-MM-DD-HH-MM-SS`)
|
|
353
|
+
5. Copia o arquivo de backup para a pasta criada
|
|
354
|
+
6. Se fornecido, copia o arquivo de storage para a mesma pasta
|
|
355
|
+
7. Deixa o backup pronto para ser encontrado pelo comando `restore`
|
|
356
|
+
|
|
357
|
+
**Exemplo completo - Apenas database (usando import + restore):**
|
|
358
|
+
|
|
359
|
+
1. Baixe o backup do Dashboard do Supabase (ex.: `db_cluster-04-03-2024@14-16-59.backup.gz`).
|
|
360
|
+
2. Importe o arquivo e depois restaure:
|
|
361
|
+
|
|
362
|
+
```bash
|
|
363
|
+
npx smoonb import --file "C:\Downloads\db_cluster-04-03-2024@14-16-59.backup.gz"
|
|
364
|
+
npx smoonb restore
|
|
365
|
+
```
|
|
366
|
+
|
|
367
|
+
O backup importado aparecerá na lista de backups disponíveis.
|
|
368
|
+
|
|
369
|
+
**Exemplo completo - Database e Storage (usando import + restore):**
|
|
370
|
+
|
|
371
|
+
1. Baixe backup e storage do Dashboard do Supabase (ex.: `db_cluster-04-03-2024@14-16-59.backup.gz` e `meu-projeto.storage.zip`).
|
|
372
|
+
2. Importe ambos os arquivos e depois restaure:
|
|
373
|
+
|
|
374
|
+
```bash
|
|
375
|
+
npx smoonb import --file "C:\Downloads\db_cluster-04-03-2024@14-16-59.backup.gz" --storage "C:\Downloads\meu-projeto.storage.zip"
|
|
376
|
+
npx smoonb restore
|
|
377
|
+
```
|
|
378
|
+
|
|
379
|
+
O backup importado aparecerá na lista de backups disponíveis.
|
|
380
|
+
|
|
381
|
+
**Importante:**
|
|
382
|
+
- O arquivo de backup é **obrigatório** e deve estar no formato do Dashboard: `db_cluster-DD-MM-YYYY@HH-MM-SS.backup.gz`
|
|
383
|
+
- O arquivo de storage é **opcional** e deve estar no formato: `*.storage.zip`
|
|
384
|
+
- O storage depende de um backup, mas o backup não depende do storage
|
|
385
|
+
- Ambos os arquivos serão copiados para a mesma pasta de backup
|
|
386
|
+
- O caminho pode ser absoluto ou relativo
|
|
387
|
+
- O comando criará a estrutura de pastas necessária automaticamente
|
|
388
|
+
|
|
389
|
+
Após executar `import`, execute `restore` para escolher o backup importado na lista e restaurar.
|
|
390
|
+
|
|
391
|
+
## 🔧 Comandos Disponíveis
|
|
392
|
+
|
|
393
|
+
| Comando | Descrição |
|
|
394
|
+
|---------|-----------|
|
|
395
|
+
| `npx smoonb backup` | Backup completo interativo usando Docker |
|
|
396
|
+
| `npx smoonb backup --skip-supabase-version-check` | Backup pulando a checagem de versão do Supabase CLI |
|
|
397
|
+
| `npx smoonb restore` | Restauração interativa usando psql (Docker) |
|
|
398
|
+
| `npx smoonb restore --skip-supabase-version-check` | Restore pulando a checagem de versão do Supabase CLI |
|
|
399
|
+
| `npx smoonb import --file <path> [--storage <path>]` | Importar arquivo .backup.gz e opcionalmente .storage.zip do Dashboard do Supabase |
|
|
400
|
+
|
|
401
|
+
## 🏗️ Arquitetura Técnica
|
|
402
|
+
|
|
403
|
+
### Estrutura Modular
|
|
404
|
+
|
|
405
|
+
O código foi refatorado para uma **arquitetura modular** com etapas independentes:
|
|
406
|
+
|
|
407
|
+
#### Backup (`src/commands/backup/`)
|
|
408
|
+
```
|
|
409
|
+
backup/
|
|
410
|
+
├── index.js
|
|
411
|
+
├── utils.js
|
|
412
|
+
└── steps/
|
|
413
|
+
├── 00-license.js
|
|
414
|
+
├── 01-docker-validation.js
|
|
415
|
+
├── 02-database.js
|
|
416
|
+
├── 03-database-separated.js
|
|
417
|
+
├── 04-database-settings.js
|
|
418
|
+
├── 05-auth-settings.js
|
|
419
|
+
├── 06-realtime-settings.js
|
|
420
|
+
├── 07-storage.js
|
|
421
|
+
├── 08-custom-roles.js
|
|
422
|
+
├── 09-edge-functions.js
|
|
423
|
+
├── 10-supabase-temp.js
|
|
424
|
+
└── 11-migrations.js
|
|
425
|
+
```
|
|
426
|
+
|
|
427
|
+
#### Restore (`src/commands/restore/`)
|
|
428
|
+
A validação de licença (mesmo step do backup, `00-license.js` em backup/steps) roda no início. Em seguida:
|
|
429
|
+
```
|
|
430
|
+
restore/
|
|
431
|
+
├── index.js
|
|
432
|
+
├── utils.js
|
|
433
|
+
└── steps/
|
|
434
|
+
├── 00-backup-selection.js
|
|
435
|
+
├── 01-components-selection.js
|
|
436
|
+
├── 02-confirmation.js
|
|
437
|
+
├── 03-database.js
|
|
438
|
+
├── 04-edge-functions.js
|
|
439
|
+
├── 05-auth-settings.js
|
|
440
|
+
├── 06-storage.js
|
|
441
|
+
├── 07-database-settings.js
|
|
442
|
+
└── 08-realtime-settings.js
|
|
443
|
+
```
|
|
444
|
+
|
|
445
|
+
### Estratégia de Backup
|
|
446
|
+
|
|
447
|
+
#### Database
|
|
448
|
+
- **Backup Principal**: `pg_dumpall` via Docker (idêntico ao Dashboard)
|
|
449
|
+
- Arquivo: `db_cluster-XX-XX-XXXX@XX-XX-XX.backup.gz`
|
|
450
|
+
- Compatível com restauração via Dashboard do Supabase
|
|
451
|
+
- **Backup Separado**: SQL em arquivos distintos via Supabase CLI
|
|
452
|
+
- `schema.sql` - Estrutura das tabelas
|
|
453
|
+
- `data.sql` - Dados (comandos COPY)
|
|
454
|
+
- `roles.sql` - Roles e permissões
|
|
455
|
+
|
|
456
|
+
#### Edge Functions
|
|
457
|
+
- **Download Automático**: Via Supabase CLI `supabase functions download`
|
|
458
|
+
- **Reset de Link**: Garante link limpo com o projeto antes do download
|
|
459
|
+
- **Backup Completo**: Código completo de cada function
|
|
460
|
+
|
|
461
|
+
#### Migrations
|
|
462
|
+
- **Download Automático**: Via `supabase migration fetch`
|
|
463
|
+
- **Reset de Link**: Garante link limpo com o projeto
|
|
464
|
+
- **Backup Completo**: Todas as migrations do servidor
|
|
465
|
+
|
|
466
|
+
#### Storage
|
|
467
|
+
- **Backup Completo**: Download de todos os arquivos de todos os buckets
|
|
468
|
+
- **Estrutura Temporária**: Cria `storage_temp/project-id/bucket-name/arquivos...` dentro do backupDir
|
|
469
|
+
- **ZIP no Padrão Dashboard**: Cria `{project-id}.storage.zip` com estrutura `project-id/bucket-name/arquivos...`
|
|
470
|
+
- **Compatível com Restore**: O ZIP criado é compatível com o processo de restore (mesmo formato do Dashboard)
|
|
471
|
+
- **Pergunta Interativa**: Após criar o ZIP, pergunta se deseja limpar a estrutura temporária
|
|
472
|
+
- **Fallback**: Se não houver credenciais do Supabase, faz backup apenas de metadados
|
|
473
|
+
- **Management API**: Usa Personal Access Token para listar buckets e objetos
|
|
474
|
+
- **Supabase Client**: Usa Service Role Key para download de arquivos
|
|
475
|
+
|
|
476
|
+
#### Auth, Realtime
|
|
477
|
+
- **Management API**: Usa Personal Access Token
|
|
478
|
+
- **JSON Export**: Configurações exportadas como JSON
|
|
479
|
+
- **Realtime Settings**: Captura atual pela API, incluindo:
|
|
480
|
+
1. Habilitar serviço Realtime
|
|
481
|
+
2. Permitir acesso público
|
|
482
|
+
3. Tamanho do pool de conexões do database
|
|
483
|
+
4. Máximo de clientes simultâneos
|
|
484
|
+
5. Máximo de eventos por segundo
|
|
485
|
+
6. Máximo de eventos de presença por segundo
|
|
486
|
+
7. Tamanho máximo do payload em KB
|
|
487
|
+
- **Senha SMTP**: Não exportável; solicitada em campo oculto durante a restauração.
|
|
488
|
+
|
|
489
|
+
### Estratégia de Restauração
|
|
490
|
+
|
|
491
|
+
#### Database
|
|
492
|
+
- **Suporte a Formatos**:
|
|
493
|
+
- `.backup.gz` - Lê o conteúdo compactado sem alterar o arquivo original
|
|
494
|
+
- `.backup` - Restaura diretamente via `psql` (Docker)
|
|
495
|
+
- **Destino Vazio**: Exige destino vazio para restaurar o banco; desmarque esse componente ao repetir etapas posteriores que falharam.
|
|
496
|
+
|
|
497
|
+
#### Edge Functions
|
|
498
|
+
- **Deploy Isolado**: Usa uma pasta temporária, preservando os arquivos locais de `supabase/functions`
|
|
499
|
+
- **Destino Explícito**: Passa a referência do projeto de destino ao CLI
|
|
500
|
+
- **Deploy Automático**: Usa `supabase functions deploy`
|
|
501
|
+
|
|
502
|
+
#### Outros Componentes
|
|
503
|
+
- **Database Settings**: Restaura via SQL
|
|
504
|
+
- **Storage**: Restaura buckets e arquivos do ZIP (se disponível) ou exibe informações para configuração manual
|
|
505
|
+
- **Auth/Realtime**: Aplica e confere as configurações pela API; registra os limites da verificação SMTP e diferenças de capacidade do Realtime aceitas explicitamente.
|
|
506
|
+
|
|
507
|
+
### Multiplataforma
|
|
508
|
+
|
|
509
|
+
- **Windows/macOS/Linux**: Detecção automática de binários
|
|
510
|
+
- **Multiplataforma**: Usa `fs.promises.cp`, `path.join`, Docker
|
|
511
|
+
- **Docker para Tudo**: Backup, restore e compressão via Docker (garante consistência)
|
|
512
|
+
|
|
513
|
+
## 📊 Fluxo Recomendado
|
|
514
|
+
|
|
515
|
+
1. **Configurar `.env.local`** (primeira vez) com as credenciais do projeto origem.
|
|
516
|
+
2. **Backup do projeto origem:**
|
|
517
|
+
```bash
|
|
518
|
+
npx smoonb backup
|
|
519
|
+
```
|
|
520
|
+
(Mapeia variáveis interativamente na primeira vez, seleciona componentes, executa backup completo.)
|
|
521
|
+
3. **Criar novo projeto Supabase** (via Dashboard ou Supabase CLI).
|
|
522
|
+
4. **Editar `.env.local`** com as credenciais do novo projeto (apontar variáveis para o projeto destino).
|
|
523
|
+
5. **Restaurar backup** (modo interativo):
|
|
524
|
+
```bash
|
|
525
|
+
npx smoonb restore
|
|
526
|
+
```
|
|
527
|
+
(Seleciona backup desejado, componentes a restaurar, executa restauração.)
|
|
528
|
+
6. **Conferir o resultado**: leia `backups/restore-*/report.json` e teste login, e-mail e os fluxos da aplicação no destino.
|
|
529
|
+
|
|
530
|
+
## 🎨 Experiência do Usuário
|
|
531
|
+
|
|
532
|
+
### Interface em Português
|
|
533
|
+
|
|
534
|
+
Todas as interações são em **Português do Brasil**:
|
|
535
|
+
- Perguntas claras e diretas
|
|
536
|
+
- Explicações antes de cada processo
|
|
537
|
+
- Resumos detalhados antes de confirmar
|
|
538
|
+
- Confirmações com `(S/n)` ou `(s/N)` em português
|
|
539
|
+
|
|
540
|
+
### Mapeamento Inteligente de Variáveis
|
|
541
|
+
|
|
542
|
+
- **Detecção Automática**: Se a chave já existe com o nome esperado, pula a seleção
|
|
543
|
+
- **Opção de Adicionar**: Permite adicionar novas chaves se não existirem
|
|
544
|
+
- **Validação de Valores**: Confirma valores antes de salvar
|
|
545
|
+
- **Backup Automático**: Sempre cria backup do `.env.local` antes de alterações
|
|
546
|
+
|
|
547
|
+
### Processo Guiado
|
|
548
|
+
|
|
549
|
+
- **Validação Prévia**: Verifica Docker antes de começar
|
|
550
|
+
- **Explicações Contextuais**: Explica cada processo antes de perguntar
|
|
551
|
+
- **Resumo Final**: Mostra tudo que será feito antes de executar
|
|
552
|
+
- **Feedback Visual**: Cores e ícones para melhor experiência
|
|
553
|
+
|
|
554
|
+
## 🐛 Solução de Problemas
|
|
555
|
+
|
|
556
|
+
### Avisos de chaves estrangeiras circulares na exportação dos dados
|
|
557
|
+
|
|
558
|
+
Tabelas podem referenciar umas às outras ou a si mesmas. O PostgreSQL avisa que um dump **somente de dados** nem sempre pode ser restaurado com a verificação normal de chaves estrangeiras. Esse aviso isolado não significa falha na exportação: confira o resultado do comando e o manifesto do backup.
|
|
559
|
+
|
|
560
|
+
O smoonb agrupa esses avisos conhecidos, lista as tabelas envolvidas e registra os diagnósticos originais em `backup-manifest.json`, em `components.database_separated.warnings`. Outros avisos e erros continuam visíveis. Se schema, dados ou roles falharem, esse componente será marcado como incompleto.
|
|
561
|
+
|
|
562
|
+
Atualmente, o Supabase CLI coloca `SET session_replication_role = replica;` no início de `data.sql`. O smoonb verifica a primeira linha antes de informar sua presença. Isso **não valida a restauração**: a role de destino precisa ter permissão para alterar essa configuração. Restaure o schema antes dos dados e interrompa ao encontrar erros SQL. Para uma restauração controlada em destino separado e adequado, siga o [guia de backup/restauração do Supabase](https://supabase.com/docs/guides/platform/migrating-within-supabase/backup-restore):
|
|
563
|
+
|
|
564
|
+
```bash
|
|
565
|
+
psql --dbname "$TARGET_DB_URL" --single-transaction --variable ON_ERROR_STOP=1 --file roles.sql --file schema.sql --command 'SET session_replication_role = replica' --file data.sql
|
|
566
|
+
```
|
|
567
|
+
|
|
568
|
+
A configuração afeta essa conexão de restauração; não altera o banco de origem. Confira contagens e referências no destino restaurado antes de depender do backup. Não remova chaves estrangeiras da aplicação para silenciar os avisos. O `.backup.gz` principal é um dump completo do cluster; os SQL separados são arquivos adicionais.
|
|
569
|
+
|
|
570
|
+
### Verificações de desenvolvimento
|
|
571
|
+
|
|
572
|
+
Use Node.js 22 para as verificações de desenvolvimento: `npm test`, `npm run lint` e `npm run build`. O teste explícito `npm run test:docker` exige Docker, imagem `postgres:17` e Supabase CLI. Ele cria somente dados fictícios em um PostgreSQL descartável próprio, testa restaurações com e sem proteção e remove esse contêiner ao terminar. Não usa credenciais do projeto nem banco remoto.
|
|
573
|
+
|
|
574
|
+
|
|
575
|
+
### Docker não encontrado ou não está rodando
|
|
576
|
+
|
|
577
|
+
Verifique se o Docker está instalado e em execução:
|
|
578
|
+
|
|
579
|
+
```bash
|
|
580
|
+
docker --version
|
|
581
|
+
docker ps
|
|
582
|
+
```
|
|
583
|
+
|
|
584
|
+
Se não estiver, inicie o Docker Desktop (Windows/macOS) ou execute `sudo systemctl start docker` (Linux).
|
|
585
|
+
|
|
586
|
+
### Supabase CLI não encontrado
|
|
587
|
+
```bash
|
|
588
|
+
npm install -g supabase
|
|
589
|
+
```
|
|
590
|
+
|
|
591
|
+
### Supabase CLI desatualizado (abaixo da versão mínima aceita)
|
|
592
|
+
|
|
593
|
+
O smoonb aceita versões até **1 minor atrás da latest**. Se sua versão instalada estiver abaixo desse limite, você verá uma mensagem como:
|
|
594
|
+
|
|
595
|
+
```
|
|
596
|
+
❌ Supabase CLI X.Y.Z está abaixo da versão mínima aceita (X.W.0). Versão latest: X.V.Z. Atualize para pelo menos a versão X.W.0.
|
|
597
|
+
```
|
|
598
|
+
|
|
599
|
+
**Opção 1 — Atualizar o Supabase CLI:**
|
|
600
|
+
```bash
|
|
601
|
+
npm install -g supabase@latest # instalação global
|
|
602
|
+
npm install supabase@latest # instalação local/projeto
|
|
603
|
+
```
|
|
604
|
+
|
|
605
|
+
**Opção 2 — Pular a checagem (temporariamente, risco do usuário):**
|
|
606
|
+
```bash
|
|
607
|
+
npx smoonb backup --skip-supabase-version-check
|
|
608
|
+
npx smoonb restore --skip-supabase-version-check
|
|
609
|
+
```
|
|
610
|
+
|
|
611
|
+
> **Nota para usuários de Scoop (Windows):** o repositório do Scoop pode levar alguns dias para atualizar após um release. Use `--skip-supabase-version-check` até que o Scoop disponibilize a versão atualizada.
|
|
612
|
+
|
|
613
|
+
### Personal Access Token inválido ou ausente
|
|
614
|
+
|
|
615
|
+
1. Verificar se `SUPABASE_ACCESS_TOKEN` está no `.env.local`
|
|
616
|
+
2. Gerar novo token: https://supabase.com/dashboard/account/tokens
|
|
617
|
+
3. Atualizar `.env.local` com o novo token
|
|
618
|
+
|
|
619
|
+
### Database URL incorreta
|
|
620
|
+
- Verificar senha na URL de conexão
|
|
621
|
+
- Usar string de conexão do Dashboard Supabase (Settings → Database)
|
|
622
|
+
- Testar conexão: `psql "sua-database-url" -c "SELECT 1"`
|
|
623
|
+
|
|
624
|
+
### Arquivo .backup.gz não pode ser restaurado
|
|
625
|
+
|
|
626
|
+
O smoonb suporta automaticamente:
|
|
627
|
+
- ✅ `.backup.gz` - Lê o conteúdo compactado sem modificar o arquivo original
|
|
628
|
+
- ✅ `.backup` - Restaura diretamente
|
|
629
|
+
|
|
630
|
+
Se houver problemas:
|
|
631
|
+
1. Verificar se Docker está rodando
|
|
632
|
+
2. Verificar permissões do arquivo
|
|
633
|
+
3. Verificar espaço em disco
|
|
634
|
+
|
|
635
|
+
### Erro ao baixar Edge Functions
|
|
636
|
+
|
|
637
|
+
1. Verificar se `SUPABASE_ACCESS_TOKEN` está configurado
|
|
638
|
+
2. Verificar se o projeto está linkado: `supabase link`
|
|
639
|
+
3. Verificar se as functions existem no servidor
|
|
640
|
+
|
|
641
|
+
### Erro ao baixar Migrations
|
|
642
|
+
|
|
643
|
+
1. Verificar se `SUPABASE_ACCESS_TOKEN` está configurado
|
|
644
|
+
2. Verificar se o projeto está linkado: `supabase link`
|
|
645
|
+
3. Verificar se há migrations no servidor
|
|
646
|
+
|
|
647
|
+
## 🔒 Segurança
|
|
648
|
+
|
|
649
|
+
- **Backup Automático**: Sempre cria backup do `.env.local` antes de alterações
|
|
650
|
+
- **Mapeamento Local**: Mapeamento de variáveis salvo apenas localmente
|
|
651
|
+
- **Sem Dados Sensíveis**: Nenhum dado sensível é enviado para fora do seu ambiente
|
|
652
|
+
- **Docker Isolado**: Operações de database via Docker (isolamento)
|
|
653
|
+
|
|
654
|
+
## 💼 Acesso e assinatura
|
|
655
|
+
|
|
656
|
+
O código do Supa Moonbase é disponibilizado sob licença MIT (ver `LICENSE`). Para usar o smoonb é obrigatório ter **licença ativa** e **assinatura válida**, ou estar em **período de trial**. A validação da licença ocorre no início do backup e do restore; sem licença e assinatura válidas (ou trial), o CLI não executa essas operações.
|
|
657
|
+
|
|
658
|
+
[smoonb.com/#price](https://www.smoonb.com/#price).
|
|
659
|
+
|
|
660
|
+
## 🔒 Privacidade e LGPD (resumo)
|
|
661
|
+
|
|
662
|
+
O Supa Moonbase adota o princípio de minimização de dados. Tratamos apenas as informações estritamente necessárias para controle de acesso e faturamento (por exemplo, identificador de conta e contato). Os propósitos, bases legais e direitos do titular estão descritos na [Política de Privacidade](https://www.smoonb.com/privacy).
|
|
663
|
+
|
|
664
|
+
## 📋 Termos de Serviço e uso de marca
|
|
665
|
+
|
|
666
|
+
A licença de código (MIT) não substitui os [Termos de Serviço](https://www.smoonb.com/terms) que regem o acesso operacional e a validação de assinatura.
|
|
667
|
+
|
|
668
|
+
"Supa Moonbase" e elementos de identidade visual são marcas da Goalmoon Tecnologia Ltda.; o uso de marca e assets de branding é restrito, conforme os [Termos de Serviço](https://www.smoonb.com/terms).
|
|
669
|
+
|
|
670
|
+
[FAQ](https://www.smoonb.com/#faq).
|
|
671
|
+
|
|
672
|
+
## 📝 Licença
|
|
673
|
+
|
|
674
|
+
O código do Supa Moonbase é disponibilizado sob licença MIT. Veja [LICENSE](LICENSE) para o texto completo da licença. Uma tradução em português está disponível em [LICENSE.pt-BR.md](LICENSE.pt-BR.md) apenas para conveniência.
|
|
675
|
+
|
|
676
|
+
## 🤝 Contribuição
|
|
677
|
+
|
|
678
|
+
Contribuições são bem-vindas. [www.smoonb.com/#price](https://www.smoonb.com/#price).
|
|
679
|
+
|
|
680
|
+
|
|
681
|
+
---
|
|
682
|
+
|
|
683
|
+
**Desenvolvido por:** Goalmoon Tecnologia LTDA
|
|
684
|
+
**Website:** https://www.smoonb.com
|
|
685
|
+
**GitHub:** https://github.com/almmello/smoonb
|
|
686
|
+
|
|
687
|
+
Teste adicional do caminho real de restore: `npm run test:restore:docker`. Usa PostgreSQL descartável, dados fictícios e transporte HTTP simulado para Storage; cobre Auth, permissões, ciclos, rollback, arquivos e metadados.
|
|
688
|
+
|
|
689
|
+
## Estabilidade a partir da 1.0.12
|
|
690
|
+
|
|
691
|
+
Use Node.js LTS 22, 24 ou 26 e Docker ativo. O pacote inclui Supabase CLI 2.122.1 e npm-shrinkwrap.json; não utiliza o CLI global nem exige acompanhar latest. O canal v2 recebe manutenção, sem promessa de prazo LTS. Atualizações de ferramentas devem ser homologadas em uma nova versão do smoonb. A primeira exportação pode precisar baixar a imagem PostgreSQL usada pelo CLI; confira conectividade e espaço em disco.
|
|
692
|
+
|
|
693
|
+
O backup usa diretórios temporários para SQL, roles, Functions e migrations, preserva os arquivos do projeto e retorna código 1/status incomplete quando um componente solicitado falha. Os arquivos concluídos ficam disponíveis, mas o conjunto não deve ser tratado como completo. Desde a 1.0.14, cada valor confirmado é salvo imediatamente em `.env.local`, antes da exportação, para não ser perdido em falhas ou cancelamentos. As demais configurações são preservadas. O backup guarda o arquivo anterior ao mapeamento em `env/.env.local.before` e a configuração usada em `env/.env.local`. A licença digitada também é salva antes da validação.
|
|
694
|
+
|
|
695
|
+
Após publicação, no Sicoop execute `npm install --save-exact smoonb@1.0.14`, confira `npx smoonb --version` e execute um novo backup. A versão 0.0.60 não consulta o validador e não pode ser bloqueada remotamente. Não reutilize um backup incompleto como se fosse completo.
|
|
696
|
+
|
|
697
|
+
Na 1.0.13, bancos sem histórico de migrations concluem essa etapa com zero arquivos. Falhas reais de conexão/permissão continuam produzindo backup incompleto, sempre com resumo de todas as etapas.
|