Does Cipi work only with Amazon S3?

No. cipi backup configure accepts any S3-compatible endpoint: Hetzner Object Storage, DigitalOcean Spaces, Backblaze B2, MinIO, or a self-hosted store such as Johnny. Leave the endpoint empty for AWS; fill it for every other provider.

What is the difference between cipi db backup and cipi backup run?

cipi db backup writes a compressed SQL dump on the same VPS under /var/log/cipi/backups/. It is always available and needs no configuration. cipi backup run dumps the database and the app shared/ folder, then uploads both archives to your S3 bucket. Use the local dump for a fast rollback; use the S3 copy for a real off-site restore.

How often should I back up a Laravel VPS?

Daily is the sensible default for production. Add cipi backup run to the root crontab at a quiet hour, then prune older than four weeks. If the database changes constantly, run it twice a day. Always run a backup before a risky migration or a production deploy.

Can I restore a Cipi S3 backup onto a new VPS?

Yes — that is the point of an off-site copy. Install Cipi on a fresh Ubuntu VPS, recreate the app, download db.sql.gz and shared.tar.gz from the bucket, restore the database with cipi db restore, and extract shared/ into /home/ /.

Where does Cipi store S3 credentials?

cipi backup configure writes them to /etc/cipi/backup.conf. Keep that file root-only. The same credentials are used by cipi backup run, list and prune. Staging of large archives defaults to /var/tmp so a small RAM-backed /tmp does not abort the job.

Backups · S3 · VPS

Como fazer backup de um VPS para um S3 balde com Cipi

Por Andrea Pollastri · Última atualização: 22 de agosto de 2026 · grátis para ler, sem acesso pago

Um dump que reside no mesmo disco que o aplicativo é um instantâneo, não um backup. Este guia percorre todo o ciclo externo comCipi: crie um bucket, armazene credenciais uma vez, execute o primeiro upload, agende-o, remova os antigos e restaure em um VPS limpo para saber que o plano funciona.

Neste guia

Por que o dump do mesmo disco não é um backup
O que Cipi realmente carrega
O que você precisa
Crie o bucket
Configure Cipi uma vez
Primeiro faça backup e verifique
Cron, retenção e poda
Exercício de restore
Backup antes de cada lançamento
Erros que tornam os backups inúteis
Perguntas frequentes

Por que o dump do mesmo disco não é um backup

Instantâneos do provedor, um .sql.gz em /var/log, um tarball ao lado storage/ - todos morrem com a máquina. Disco cheio, ransomware, dedos gordos rm -rf, uma interrupção na região, um VPS roubado: a cópia que você precisa é aquela que já estava em outro lugar.

A regra que ainda vale é 3-2-1: três cópias, duas mídias, uma externa. Cipi cobre o último salto. cipi db backup oferece uma reversão local rápida; cipi backup run envia o banco de dados e o shared/ pasta para Amazon S3 ou qualquer bucket compatível com S3. Essa é a cópia que você restaura quando o VPS desaparece.

Um backup que você nunca restaurou é uma esperança, não um plano. Faça o orçamento 20 minutos após o primeiro upload bem-sucedido e faça o detalhamento Restaurar. Repita a cada trimestre.

O que Cipi realmente carrega

Cada execução cria um prefixo com carimbo de data/hora no bucket:

s3://your-bucket/cipi/myapp/2026-08-22_020015/

Dentro dessa pasta você obtém dois arquivos:

db.sql.gz — um dump compactado do banco de dados do aplicativo (mariadb-dump --single-transaction, ou o equivalente PostgreSQL se o aplicativo usar esse mecanismo).
shared.tar.gz - o inteiro /home/<app>/shared/ diretório: .env, storage/, arquivos carregados e qualquer outra coisa que sobreviva a uma troca de versão do Deployer.

O código não está no arquivo. Os lançamentos vivem no Git; se você precisar da última árvore boa, clone o repositório. O que você não pode clonar é o banco de dados e os arquivos carregados pelos usuários após a ativação – esses dois arquivos são o ponto de restauração.

Desde v4.7.14 o teste acontece no disco em /var/tmp, não em um suporte de RAM /tmp. Aplicativos grandes não morrem mais no meio porque os tmpfs ficam cheios. Substituir por tmpdir em backup.json ou o CIPI_BACKUP_TMPDIR variável de ambiente.

O que você precisa

Um VPS já gerenciado por Cipi. Se você está começando do zero, execute wget -O - https://cipi.sh/setup.sh | bash em uma nova caixa Ubuntu 24.04/26.04, então cipi app create. O guia de primeiros passos cobre a instalação.
Pelo menos um aplicativo nesse servidor. cipi backup run sem nome faz backup de todos os aplicativos; cipi backup run myapp tem como alvo um.
Um bucket compatível com S3 ou S3 e uma chave de acesso que pode gravar nele. Crie um usuário IAM dedicado — não reutilize suas credenciais raiz da nuvem.

Crie o bucket

Escolha um provedor, crie um bucket privado em uma região que seja não no mesmo datacenter que VPS e crie um par de chaves com escopo apenas para esse bucket. Habilite a criptografia do lado do servidor se o provedor oferecer. O controle de versão é um seguro opcional, mas barato contra substituição acidental.

Ações mínimas do IAM nesse bucket: s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject. O último só é necessário se você quiser cipi backup prune para limpar prefixos antigos.

Provedor	URL do terminal
AWS S3	deixe vazio
Armazenamento de objetos Hetzner	`https://<datacenter>.your-objectstorage.com`
Espaços DigitalOcean	`https://<region>.digitaloceanspaces.com`
Contra-chama B2	`https://s3.<region>.backblazeb2.com`
MinIO	`https://your-minio-host`
Johnny (self-hosted S3)	seu URL público do Johnny

Qualquer loja compatível com S3 funciona. Se você quiser a cópia externa em uma segunda VPS sua — e não em outra fatura de SaaS — Johnny é a opção open-source já mencionada no self-hosted pilha de desenvolvedores.

Configure Cipi uma vez

Faça login como usuário administrador, torne-se root e execute o assistente. Ele escreve /etc/cipi/backup.conf e você não deverá tocá-lo novamente, a menos que a chave ou o balde mudem.

# as root on the VPS
$ cipi backup configure
# → AWS Access Key ID
# → AWS Secret Access Key
# → Bucket name
# → Region
# → Endpoint URL (empty for AWS; required for everyone else)

Mantenha /etc/cipi/backup.conf modo 600 e de propriedade do root. Essas chaves abrem todos os backups que você fará. Se uma chave vazar, gire-a no provedor e execute cipi backup configure novamente – objetos antigos permanecem no balde; apenas novos uploads usam a nova chave.

cipi db backup funciona sem configuração. cipi backup run não. Se o comando S3 falhar com um erro de credenciais, você pulou esta etapa.

Primeiro faça backup e verifique

Não coloque nada em cron até que uma corrida manual caia no balde. Comece com um único aplicativo:

$ cipi backup run myapp
# → s3://your-bucket/cipi/myapp/2026-08-22_143015/db.sql.gz
# → s3://your-bucket/cipi/myapp/2026-08-22_143015/shared.tar.gz

$ cipi backup list myapp
$ cipi backup run
# no app name = every app on the server

Em seguida, confirme no console do provedor — ou com o AWS CLI, que também se comunica com endpoints compatíveis se você passar --endpoint-url:

$ aws s3 ls s3://your-bucket/cipi/myapp/
$ aws s3 ls s3://your-bucket/cipi/myapp/2026-08-22_143015/

Você deverá ver os dois objetos, com tamanhos que correspondem a um dump compactado mais o shared/ árvore. Um objeto de 200 bytes geralmente significa um despejo vazio ou uma falha no upload – corrija isso antes de agendar qualquer coisa.

Cron, retenção e poda

Diariamente às 02:00 é o padrão chato. Poda às 03:00 para que a corrida de ontem nunca seja excluída por uma corrida. Quatro semanas de histórico são suficientes para a maioria dos Laravel aplicativos; diminua para dois se a conta do balde doer, aumente para oito se precisar resolver um bug de dados de gravação lenta.

# crontab -e as root
0 2 * * * /usr/local/bin/cipi backup run myapp >> /var/log/cipi/backup.log 2>&1
0 3 * * * /usr/local/bin/cipi backup prune myapp --weeks=4 >> /var/log/cipi/backup-prune.log 2>&1

Para fazer backup de todos os aplicativos da caixa, remova o nome do aplicativo de ambos os comandos. cipi backup prune lê o mesmo /etc/cipi/backup.conf e funciona com qualquer provedor compatível.

$ cipi backup prune myapp --weeks=4
$ cipi backup prune myapp --weeks=2

Assistir /var/log/cipi/backup.log por uma semana. Um cron silencioso que falhou no primeiro dia é como as pessoas descobrem que não têm backups na manhã seguinte à morte de um disco.

Exercício de restore

Faça isso em um aplicativo de teste ou em um VPS sobressalente, e não no tráfego ao vivo na primeira vez. O caminho feliz de um prefixo S3 de volta para um aplicativo em execução:

$ cipi backup list myapp

$ aws s3 cp s3://your-bucket/cipi/myapp/2026-08-22_143015/db.sql.gz /tmp/db.sql.gz
$ cipi db restore myapp /tmp/db.sql.gz

$ aws s3 cp s3://your-bucket/cipi/myapp/2026-08-22_143015/shared.tar.gz /tmp/shared.tar.gz
$ tar -xzf /tmp/shared.tar.gz -C /home/myapp/

Se o VPS sumir, a sequência é: instale Cipi em uma nova caixa Ubuntu, cipi app create com o mesmo controle remoto Git, então as duas restaurações acima, então cipi ssl install e um corte de DNS. O documentos de infraestrutura liste os mesmos comandos; este exercício é a parte que a maioria das pessoas pula.

Para uma reversão no mesmo servidor — migração incorreta, implantação incorreta — o dump local é mais rápido:

$ ls -lh /var/log/cipi/backups/myapp_*.sql.gz
$ cipi db restore myapp /var/log/cipi/backups/myapp_20260822_143012.sql.gz
$ cipi deploy myapp --rollback

Despejos locais em /var/log/cipi/backups/ nunca são excluídos automaticamente. Em uma agenda de implantação ocupada, eles preenchem o disco. Mantenha os últimos cinco e descarte o resto: ls -t /var/log/cipi/backups/myapp_*.sql.gz | tail -n +6 | xargs rm -f.

Backup antes de cada lançamento

Webhook a implantação automática não pode pausar para um backup — o push é acionado cipi deploy imediatamente. Para produção, coloque um estágio de backup no CI para que um despejo com falha bloqueie a liberação. As GitHub ações completas e os exemplos GitLab estão em Implantação segura – backup antes do lançamento. Os dois comandos que você precisa nesse estágio:

$ cipi db backup myapp
# fast local rollback
$ cipi backup run myapp
# off-site copy of DB + shared/

Usados em conjunto, você obtém uma restauração na mesma caixa que leva segundos e um prefixo S3 que você ainda pode abrir se a caixa desaparecer. Se algum dos comandos falhar, não implemente.

Erros que tornam os backups inúteis

Mesma região que VPS, mesma conta de provedor, sem segunda cópia. Uma conta suspensa ou uma interrupção regional levam a ambos. Coloque o balde em outra região ou em outro fornecedor.
Chaves de nuvem raiz no servidor.Um usuário IAM dedicado com quatro ações S3 em um bucket é suficiente. Se o VPS estiver comprometido, o raio de explosão permanece naquele balde.
Nunca testando a restauração. Sinalizadores de compactação, dumps vazios, um shared/ extrato que substitui a árvore errada - você só encontra esses bugs durante um incidente, a menos que faça drill.
Sem ameixa, depois uma conta surpresa.Os despejos diários de 2 GB tornam-se 60 GB por mês. Definir --weeks no mesmo dia em que você definiu cron.
Confiar apenas nos instantâneos do provedor. Eles são convenientes. Eles também estão na mesma conta, geralmente na mesma região, e não oferecem um dispositivo portátil db.sql.gz.
Pular shared/. Um banco de dados sem arquivos carregados é meio aplicativo. cipi backup run já embala ambos; não invente um cron "para manter as coisas simples".

Execute-o em um Cipi VPS

Cipi é o open-source Laravel implantação gratuita CLI usada neste guia. Um comando transforma um novo Ubuntu VPS em um servidor de produção reforçado – e cipi backup configure é a etapa que torna o servidor sobrevivente.

wget -O - https://cipi.sh/setup.sh | bash

Comece gratuitamente Referência de backup CLI Estrela em GitHub

Perguntas frequentes

Cipi funciona apenas com Amazon S3?

Não. cipi backup configure aceita qualquer endpoint compatível com S3: Hetzner Object Storage, DigitalOcean Spaces, Backblaze B2, MinIO ou um armazenamento self-hosted como Johnny. Deixe o endpoint vazio para AWS; preencha-o para todos os outros provedores.

Qual é a diferença entre `cipi db backup` e `cipi backup run`?

cipi db backup grava um dump SQL compactado no mesmo VPS em /var/log/cipi/backups/. Está sempre disponível e não precisa de configuração. cipi backup run despeja o banco de dados e o aplicativo shared/ pasta e, em seguida, carrega ambos os arquivos para o seu bucket S3. Use o dump local para uma reversão rápida; use a cópia S3 para uma restauração externa real.

Com que frequência devo fazer backup de um Laravel VPS?

Diariamente é o padrão sensato para produção. Adicionar cipi backup run para o crontab da raiz em um horário tranquilo e, em seguida, podar com mais de quatro semanas. Se o banco de dados mudar constantemente, execute-o duas vezes por dia. Sempre execute um backup antes de uma migração arriscada ou implantação de produção.

Posso restaurar um backup Cipi S3 para um novo VPS?

Sim - esse é o objetivo de uma cópia externa. Instale Cipi em um novo Ubuntu VPS, recrie o aplicativo, baixe db.sql.gz e shared.tar.gz do bucket, restaure o banco de dados comcipi db restoree extrair shared/ em /home/<app>/.

Onde Cipi armazena credenciais S3?

cipi backup configure escreve-los para /etc/cipi/backup.conf. Mantenha esse arquivo apenas como root. As mesmas credenciais são usadas por cipi backup run, list e prune. O teste de arquivos grandes é padronizado como /var/tmp então um pequeno backup de RAM /tmp não aborta o trabalho.