SQL Backup: .dump e .backup

Todo o cadastro da Loja Aurora (clientes, produtos, 90 pedidos) mora num arquivo só: ~/loja.db. Se o notebook da Ana quebrar, ou se alguém rodar um DELETE sem WHERE, a loja perde tudo. A proteção é uma cópia de segurança, o backup. Nesta aula você vai ver os dois jeitos que o sqlite3 oferece: o .dump, que transforma o banco num arquivo de SQL que qualquer pessoa consegue ler, e o .backup, que faz uma cópia exata do arquivo do banco. E vai ver como trazer os dados de volta.

Como a aula anterior, Importar e Exportar CSV, esta é uma aula de terminal: backup é gravar arquivos, e o editor do guia não grava arquivos no seu computador. As sessões saíram do terminal da Ana, na pasta pessoal dela (~), onde está o loja.db. O editor entra para mostrar que um dump é SQL comum, que roda em qualquer lugar.

A ideia: a foto e a receita

Imagine que a Ana quer guardar uma cópia de um bolo que deu muito certo. Ela tem dois jeitos:

A receita é ótima para ler, comparar e levar para outro banco. O congelador é mais rápido de fazer e de usar. Muita gente guarda os dois.

1. O .dump: o banco virado SQL

Comece por uma tabela pequena. Com o nome de uma tabela, o .dump mostra só ela:

$ sqlite3 loja.db
SQLite version 3.50.4 2025-07-30 19:33:53
Enter ".help" for usage hints.
sqlite> .dump categorias
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE categorias (
    id        INTEGER PRIMARY KEY,
    nome      TEXT NOT NULL,
    descricao TEXT
);
INSERT INTO categorias VALUES(1,'Papelaria','Material escolar e de escritório');
INSERT INTO categorias VALUES(2,'Eletrônicos','Acessórios e dispositivos eletrônicos');
INSERT INTO categorias VALUES(3,'Casa e Cozinha','Utensílios para o lar');
INSERT INTO categorias VALUES(4,'Livros','Livros, dicionários e guias');
INSERT INTO categorias VALUES(5,'Brinquedos','Brinquedos e jogos para todas as idades');
INSERT INTO categorias VALUES(6,'Esporte e Lazer','Artigos esportivos e de lazer');
INSERT INTO categorias VALUES(7,'Alimentos','Alimentos não perecíveis e regionais');
INSERT INTO categorias VALUES(8,'Jardim','Ferramentas e artigos de jardinagem');
COMMIT;
sqlite> .quit

Tudo o que saiu é SQL que você já conhece (ou vai conhecer). Leia de cima para baixo:

PRAGMA foreign_keys=OFF;

Desliga a conferência de chaves estrangeiras durante a restauração. Assim a ordem das tabelas não importa: um produto pode entrar antes da sua categoria. (PRAGMAs têm aula própria: PRAGMAs Úteis.)

BEGIN TRANSACTION;

Abre uma transação: tudo até o COMMIT vale como uma coisa só, e fica muito mais rápido. Você vai ver isso em Transações.

CREATE TABLE categorias (…);

A estrutura da tabela, do jeito que foi escrita quando ela foi criada, com os espaços e tudo (veja CREATE TABLE).

INSERT INTO categorias VALUES(…);

Uma linha da tabela por INSERT, com os valores na ordem das colunas. Os textos vêm em aspas simples, como manda o SQL.

COMMIT;

Fecha a transação e grava tudo.

Rodar esse texto num banco vazio recria a tabela categorias exatamente como ela é. Essa é toda a ideia do dump.

2. O dump do banco inteiro num arquivo

Sem nome de tabela, o .dump escreve o banco inteiro. Em vez de jogar tudo na tela, a Ana manda para um arquivo, numa linha só do terminal:

$ sqlite3 loja.db .dump > backup.sql
$ ls -l loja.db backup.sql
-rw-rw-r-- 1 ana ana 30423 out 18 11:18 backup.sql
-rw-r--r-- 1 ana ana 45056 out 18 11:14 loja.db
$ head -4 backup.sql
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE categorias (
    id        INTEGER PRIMARY KEY,
$ tail -3 backup.sql
INSERT INTO itens_pedido VALUES(90,15,2,54.29999999999999716);
INSERT INTO itens_pedido VALUES(90,16,1,39.99000000000000198);
COMMIT;
$ grep -c '^INSERT' backup.sql
407                              « 8+6+45+30+8+90+220: todas as linhas de todas as tabelas

sqlite3 loja.db

Abre o banco.

.dump

O comando de ponto, passado direto na linha de comando: o sqlite3 roda, escreve e sai.

> backup.sql

O shell grava tudo o que sairia na tela no arquivo backup.sql. O .sql no fim do nome é só um costume, para lembrar que o arquivo é SQL.

O grep -c '^INSERT' conta as linhas que começam com INSERT: 407, exatamente o total de linhas das sete tabelas da loja. O dump ficou menor que o banco (30 KB contra 44 KB): é só texto, sem os índices nem o espaço livre que o arquivo do banco guarda por dentro. Num banco grande, ele também comprime muito bem com gzip.

Que números são esses: 54.29999999999999716?

No banco, o preço desse item é 54.3. O dump escreve o número com todas as casas que o computador guarda de verdade. Números com vírgula (o tipo REAL) são guardados em binário, e 54.3 não tem representação exata em binário, assim como 1/3 não tem em decimal (0,333…). O dump escreve a versão longa para que, ao restaurar, volte exatamente o mesmo número, sem nenhuma diferença:

SELECT preco_unitario
FROM itens_pedido
WHERE pedido_id = 90 AND produto_id = 15;

SELECT 54.29999999999999716 = 54.3 AS igual;

O 1 quer dizer "verdadeiro": para o SQLite, os dois números são o mesmo. Mais sobre essas casas "feias" em Funções Numéricas.

3. Restaurar um dump

Para recriar o banco a partir da "receita", basta dar o arquivo de SQL para um sqlite3 com um banco novo. O < do shell faz o caminho contrário do >: lê o arquivo e entrega ao programa, como se você digitasse tudo:

$ sqlite3 restaurado.db < backup.sql
$ ls -l restaurado.db
-rw-r--r-- 1 ana ana 45056 out 18 11:18 restaurado.db
$ sqlite3 restaurado.db "SELECT count(*) FROM produtos; SELECT count(*) FROM itens_pedido;"
45
220

O restaurado.db não existia: o sqlite3 criou o arquivo vazio, rodou os 407 INSERT e os sete CREATE TABLE, e pronto. As contagens batem com o original, e até o tamanho bateu: 45056 bytes, igual ao loja.db. Faz sentido, porque o loja.db da Ana foi criado exatamente assim, rodando um arquivo de SQL num banco vazio. O tamanho nem sempre bate (um banco que já teve muitos DELETE guarda espaço vazio que o dump não leva, como você vai ver em VACUUM e ANALYZE), e não precisa: o que importa é que os dados são os mesmos.

De dentro do sqlite3, o mesmo efeito vem do .read, que lê e roda um arquivo de SQL:

$ sqlite3 novo.db
SQLite version 3.50.4 2025-07-30 19:33:53
Enter ".help" for usage hints.
sqlite> .read backup.sql
sqlite> SELECT count(*) FROM clientes;
30
sqlite> .quit

E é SQL de verdade: o editor do guia roda um trecho de dump. Aqui, uma tabela que não existe na loja, cupons, escrita no formato do dump:

PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE cupons (codigo TEXT PRIMARY KEY, desconto REAL);
INSERT INTO cupons VALUES('AURORA10',0.1);
INSERT INTO cupons VALUES('FRETEGRATIS',0.0);
COMMIT;

SELECT * FROM cupons;

4. O .backup: a cópia exata

O "congelador" é o .backup. Dentro do sqlite3, ele grava uma cópia idêntica do banco aberto em outro arquivo:

$ sqlite3 loja.db
SQLite version 3.50.4 2025-07-30 19:33:53
Enter ".help" for usage hints.
sqlite> .backup copia.db
sqlite> SELECT count(*) FROM clientes;
30

.backup

Copia o banco aberto, página por página, usando a "API de backup" do SQLite: enquanto copia, nenhum outro programa consegue deixar o banco pela metade.

copia.db

O arquivo de destino. Se já existir, é substituído sem perguntar.

Logo depois, um acidente: a Ana apaga a cliente 30 sem querer. Como ela tinha acabado de fazer a cópia, o .restore traz tudo de volta:

sqlite> DELETE FROM clientes WHERE id = 30;
sqlite> SELECT count(*) FROM clientes;
29
sqlite> .restore copia.db
sqlite> SELECT count(*) FROM clientes;
30
sqlite> SELECT nome FROM clientes WHERE id = 30;
Rosângela Dias
sqlite> .quit

.restore copia.db

O caminho contrário: substitui o banco aberto pelo conteúdo de copia.db. Tudo o que o banco tinha antes do .restore some, inclusive o que mudou depois do backup.

A Rosângela voltou. Fora do sqlite3, os dois arquivos têm o mesmo tamanho, e o PRAGMA integrity_check ("conferência de integridade") confirma que a cópia está saudável:

$ ls -l loja.db copia.db
-rw-r--r-- 1 ana ana 45056 out 18 11:18 copia.db
-rw-r--r-- 1 ana ana 45056 out 18 11:19 loja.db
$ sqlite3 copia.db "PRAGMA integrity_check;"
ok

Um backup que nunca foi conferido é uma esperança, não um backup. De tempos em tempos, abra a cópia e rode o integrity_check e uma ou duas contagens.

Um backup por dia, com a data no nome

O .backup também funciona numa linha só do terminal. Com o $(date +%F) do shell, que vira a data de hoje no formato ano-mês-dia, cada dia ganha o seu arquivo:

$ sqlite3 loja.db ".backup backup-$(date +%F).db"
$ ls -l backup-*
-rw-r--r-- 1 ana ana 45056 out 18 11:19 backup-2026-10-18.db

As aspas em volta de .backup … fazem o sqlite3 receber o comando inteiro como uma coisa só. Essa linha pode ir para um agendador de tarefas (como o cron, no Linux) e rodar sozinha toda noite.

5. VACUUM INTO: a cópia com SQL

O .backup é um comando de ponto, que só o programa sqlite3 entende. Um programa em Python ou PHP que usa o SQLite precisa de um jeito em SQL. É o VACUUM INTO ("aspire para dentro de"):

$ sqlite3 loja.db "VACUUM INTO 'compacta.db';"
$ ls -l compacta.db
-rw-r--r-- 1 ana ana 45056 out 18 11:19 compacta.db

VACUUM

O comando que reorganiza o banco por dentro e joga fora o espaço vazio (aula VACUUM e ANALYZE).

INTO 'compacta.db'

Em vez de reorganizar o próprio banco, grava o resultado num arquivo novo. O original não é tocado. O nome do arquivo vai entre aspas simples, como um texto.

A cópia sai já "aspirada", sem espaço desperdiçado. Aqui ela ficou do mesmo tamanho do original porque o loja.db está arrumado; num banco que já teve muitos DELETE, a cópia sai menor. Diferente do .backup, o VACUUM INTO não substitui um arquivo que já existe (veja em Quando dá errado).

6. Um backup dentro do próprio banco

Antes de uma mudança arriscada numa tabela só, como um aumento de preços, existe um truque rápido: copiar a tabela para outra tabela no mesmo banco, com CREATE TABLE … AS SELECT (veja Criar Tabela a partir de Consulta). Não substitui o backup em outro arquivo (se o notebook quebrar, as duas tabelas vão junto), mas salva de um UPDATE errado.

CREATE TABLE produtos_backup AS SELECT * FROM produtos;

UPDATE produtos SET preco = 0;   -- o acidente

-- escreva aqui o UPDATE que traz os preços de volta

SELECT nome, preco FROM produtos WHERE id IN (1, 2, 3);

CREATE TABLE produtos_backup AS SELECT * FROM produtos;

UPDATE produtos SET preco = 0;   -- o acidente

UPDATE produtos
SET preco = (SELECT b.preco FROM produtos_backup AS b WHERE b.id = produtos.id);

SELECT nome, preco FROM produtos WHERE id IN (1, 2, 3);

7. Formas diferentes de fazer

Qual usar? Para o dia a dia, um .backup com a data no nome, todo dia, guardado em outro lugar (um pendrive, outro computador, a nuvem). De vez em quando, um .dump, que você consegue ler mesmo daqui a dez anos, com qualquer programa.

Quando dá errado

$ sqlite3 loja.db < backup.sql 2>&1 | head -6
Parse error near line 3: table categorias already exists
  CREATE TABLE categorias (     id        INTEGER PRIMARY KEY,     nome      TEX
               ^--- error here
Runtime error near line 8: UNIQUE constraint failed: categorias.id (19)
Runtime error near line 9: UNIQUE constraint failed: categorias.id (19)
Runtime error near line 10: UNIQUE constraint failed: categorias.id (19)
$ sqlite3 loja.db < backup.sql 2>&1 | wc -l
428

No editor acontece o mesmo: a Loja Aurora já está carregada, então o CREATE TABLE do dump bate na tabela que existe:

CREATE TABLE categorias (
    id        INTEGER PRIMARY KEY,
    nome      TEXT NOT NULL,
    descricao TEXT
);

$ sqlite3 loja.db
SQLite version 3.50.4 2025-07-30 19:33:53
Enter ".help" for usage hints.
sqlite> .restore nao-existe.db
sqlite> .tables
sqlite> SELECT count(*) FROM clientes;
Parse error: no such table: clientes

sqlite> .restore copia.db
sqlite> SELECT count(*) FROM clientes;
30
sqlite> .quit
$ ls -l loja.db nao-existe.db
-rw-r--r-- 1 ana ana 45056 out 18 11:19 loja.db
-rw-r--r-- 1 ana ana     0 out 18 11:19 nao-existe.db
$ rm nao-existe.db

$ sqlite3 loja.db "VACUUM INTO 'compacta.db';"
Error: stepping, output file already exists

sqlite> .backup pasta-que-nao-existe/copia.db
Error: cannot open "pasta-que-nao-existe/copia.db"

$ sqlite3 backup.sql ".tables"
Error: file is not a database

Nos outros bancos

mysqldump loja > backup.sql      # MySQL: o "dump" do banco loja
mysql loja < backup.sql          # MySQL: restaurar (o banco loja precisa existir)

pg_dump loja > backup.sql        # PostgreSQL: o "dump" em SQL
psql -X loja < backup.sql        # PostgreSQL: restaurar num banco já criado

-- SQL Server: o backup é um comando SQL, gravado pelo servidor
BACKUP DATABASE loja TO DISK = 'C:\backups\loja.bak';
RESTORE DATABASE loja FROM DISK = 'C:\backups\loja.bak';

Referência rápida

Exercícios

Missão final: a tabela que sumiu

PRAGMA foreign_keys = OFF;
DROP TABLE categorias;   -- o acidente

-- cole aqui o dump da tabela categorias

SELECT count(*) AS categorias FROM categorias;

PRAGMA foreign_keys = OFF;
DROP TABLE categorias;   -- o acidente

PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE categorias (
    id        INTEGER PRIMARY KEY,
    nome      TEXT NOT NULL,
    descricao TEXT
);
INSERT INTO categorias VALUES(1,'Papelaria','Material escolar e de escritório');
INSERT INTO categorias VALUES(2,'Eletrônicos','Acessórios e dispositivos eletrônicos');
INSERT INTO categorias VALUES(3,'Casa e Cozinha','Utensílios para o lar');
INSERT INTO categorias VALUES(4,'Livros','Livros, dicionários e guias');
INSERT INTO categorias VALUES(5,'Brinquedos','Brinquedos e jogos para todas as idades');
INSERT INTO categorias VALUES(6,'Esporte e Lazer','Artigos esportivos e de lazer');
INSERT INTO categorias VALUES(7,'Alimentos','Alimentos não perecíveis e regionais');
INSERT INTO categorias VALUES(8,'Jardim','Ferramentas e artigos de jardinagem');
COMMIT;

SELECT count(*) AS categorias FROM categorias;

Rode primeiro o código como está: o SELECT do fim dá no such table: categorias, porque a tabela foi apagada. Depois de colar o dump, as 8 categorias voltam. Por que o PRAGMA foreign_keys = OFF no começo? Com ele ligado, o SQLite não deixa apagar uma tabela que outras tabelas usam (os produtos apontam para as categorias), e o "acidente" nem aconteceria. Você vai ver esse pragma em PRAGMAs Úteis.

Resumo

• O banco SQLite é um arquivo só: perder o arquivo é perder tudo. Faça backup e guarde em outro lugar.
• .dump escreve o banco como SQL (CREATE TABLE + INSERT, numa transação). sqlite3 loja.db .dump > backup.sql salva; sqlite3 novo.db < backup.sql restaura, sempre num banco novo.
• .backup copia.db grava uma cópia exata e consistente; .restore copia.db troca o banco aberto pela cópia. Os dois substituem o destino sem perguntar.
• VACUUM INTO 'copia.db' é a cópia em SQL, já compactada, e não sobrescreve arquivo existente.
• cp só com o banco fechado. Confira os backups com PRAGMA integrity_check.
• Cuidado com o .restore de um nome errado: ele restaura um banco vazio, sem aviso. Faça um .backup antes de qualquer .restore.