Come impostare i backup di una VPS su un bucket S3 con Cipi
Di Andrea Pollastri · Ultimo aggiornamento: · lettura gratuita, nessun paywall
Un dump che vive sullo stesso disco dell'app è uno snapshot, non un backup. Questa guida percorre l'intero giro off-site con Cipi: crei il bucket, salvi le credenziali una volta, lanci il primo upload, lo scheduli, pulisci i vecchi e ripristini su una VPS pulita così sai che il piano funziona.
Perché il dump sullo stesso disco non è un backup
Snapshot del provider, un .sql.gz in /var/log, un tarball accanto a storage/ — muoiono tutti con la macchina. Disco pieno, ransomware, un rm -rf di troppo, un'outage di regione, una VPS rubata: la copia che ti serve è quella che era già da un'altra parte.
La regola che tiene ancora è 3-2-1: tre copie, due supporti, una off-site. Cipi copre l'ultimo salto. cipi db backup ti dà un rollback locale veloce; cipi backup run spedisce database e cartella shared/ su Amazon S3 o qualsiasi bucket compatibile S3. Quella è la copia da cui riparti quando la VPS non c'è più.
Un backup che non hai mai ripristinato è una speranza, non un piano. Dopo il primo upload andato a buon fine, dedicati 20 minuti e fai il drill in Restore. Ripetilo ogni trimestre.
Cosa carica davvero Cipi
Ogni run crea un prefisso con timestamp sul bucket:
Dentro quella cartella trovi due archivi:
db.sql.gz— dump compresso del database dell'app (mariadb-dump --single-transaction, o l'equivalente PostgreSQL se l'app usa quel motore).shared.tar.gz— l'intera directory/home/<app>/shared/:.env,storage/, file caricati dagli utenti e tutto ciò che sopravvive a uno swap di release Deployer.
Il codice non sta nell'archivio. Le release vivono in Git; se ti serve l'ultimo albero buono, cloni il repo. Quello che non puoi clonare è il database e i file che gli utenti hanno caricato dopo il go-live — quei due file sono il restore point.
Da v4.7.14 lo staging avviene su disco in /var/tmp, non in un /tmp montato in RAM. Le app grandi non muoiono a metà perché il tmpfs si è riempito. Override con tmpdir in backup.json o la variabile d'ambiente CIPI_BACKUP_TMPDIR.
Cosa ti serve
- Una VPS già gestita da Cipi. Se parti da zero, esegui
wget -O - https://cipi.sh/setup.sh | bashsu un box Ubuntu 24.04/26.04 fresco, poicipi app create. La guida Primi passi copre l'installazione. - Almeno un'app su quel server.
cipi backup runsenza nome fa il backup di tutte le app;cipi backup run myappne prende una. - Un bucket S3 o compatibile S3 e una access key che possa scriverci. Crea un utente IAM dedicato — non riusare le credenziali root del cloud.
Crea il bucket
Scegli un provider, crea un bucket privato in una regione che non è lo stesso datacenter della VPS, e genera una coppia di chiavi limitata a quel bucket. Abilita la cifratura server-side se il provider la offre. Il versioning è opzionale ma è un'assicurazione economica contro una sovrascrittura accidentale.
Azioni IAM minime su quel bucket: s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject. L'ultima serve solo se vuoi che cipi backup prune pulisca i prefissi vecchi.
| Provider | URL endpoint |
|---|---|
| AWS S3 | lascia vuoto |
| Hetzner Object Storage | https://<datacenter>.your-objectstorage.com |
| DigitalOcean Spaces | https://<region>.digitaloceanspaces.com |
| Backblaze B2 | https://s3.<region>.backblazeb2.com |
| MinIO | https://your-minio-host |
| Johnny (S3 self-hosted) | l'URL pubblico del tuo Johnny |
Qualsiasi store compatibile S3 va bene. Se vuoi la copia off-site su una seconda VPS che possiedi — non un altro abbonamento SaaS — Johnny è l'opzione open source già citata nello stack da sviluppatore self-hosted.
Configura Cipi una volta
Entra in SSH come utente admin, diventa root ed esegui il wizard. Scrive /etc/cipi/backup.conf e non dovresti più toccarlo finché non cambiano chiave o bucket.
# come root sulla VPS
$ cipi backup configure
# → AWS Access Key ID
# → AWS Secret Access Key
# → Bucket name
# → Region
# → Endpoint URL (vuoto per AWS; obbligatorio per tutti gli altri)Tieni /etc/cipi/backup.conf in modalità 600 e di proprietà di root. Quelle chiavi aprono ogni backup che farai. Se una chiave vaga, ruotala dal provider e rilancia cipi backup configure — gli oggetti vecchi restano nel bucket; solo i nuovi upload usano la chiave nuova.
cipi db backup funziona senza configurazione. cipi backup run no. Se il comando S3 fallisce per credenziali, hai saltato questo passo.
Primo backup e verifica
Non mettere nulla in cron finché un run manuale non è atterrato nel bucket. Parti da una singola app:
$ 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
# senza nome app = tutte le app sul serverPoi conferma dalla console del provider — o con AWS CLI, che parla anche con endpoint compatibili se passi --endpoint-url:
$ aws s3 ls s3://your-bucket/cipi/myapp/
$ aws s3 ls s3://your-bucket/cipi/myapp/2026-08-22_143015/Devi vedere entrambi gli oggetti, con dimensioni coerenti con un dump compresso più l'albero di shared/. Un oggetto da 200 byte di solito è un dump vuoto o un upload fallito — sistema quello prima di schedulare qualsiasi cosa.
Cron, retention e prune
Ogni giorno alle 02:00 è il default noioso. Prune alle 03:00 così il run di ieri non viene cancellato da una race. Quattro settimane di storia bastano per la maggior parte delle app Laravel; scendi a due se la bolletta del bucket fa male, sali a otto se ti serve srotolare un bug sui dati arrivato in sordina.
# crontab -e come 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>&1Per fare il backup di tutte le app sulla macchina, togli il nome app da entrambi i comandi. cipi backup prune legge lo stesso /etc/cipi/backup.conf e funziona con qualsiasi provider compatibile.
$ cipi backup prune myapp --weeks=4
$ cipi backup prune myapp --weeks=2Tieni d'occhio /var/log/cipi/backup.log per una settimana. Un cron silenzioso che è fallito il primo giorno è il modo in cui la gente scopre di non avere backup il mattino dopo un disco morto.
Drill di restore
Fallo su un'app di staging, o su una VPS di scorta, non sul traffico live la prima volta. Il percorso felice da un prefisso S3 a un'app che gira:
$ 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 la VPS stessa non c'è più, la sequenza è: installa Cipi su un box Ubuntu nuovo, cipi app create con lo stesso remote Git, poi i due restore sopra, poi cipi ssl install e il taglio DNS. I docs di infrastruttura elencano gli stessi comandi; questo drill è la parte che la maggior parte delle persone salta.
Per un rollback sulla stessa macchina — migration sbagliata, deploy sbagliato — il dump locale è più veloce:
$ 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 --rollbackI dump locali in /var/log/cipi/backups/ non vengono mai cancellati automaticamente. Con un ritmo di deploy alto riempiono il disco. Tieni gli ultimi cinque e butta il resto: ls -t /var/log/cipi/backups/myapp_*.sql.gz | tail -n +6 | xargs rm -f.
Backup prima di ogni release
Il deploy da webhook non può fermarsi per un backup — il push lancia cipi deploy subito. In produzione metti uno stage di backup in CI così un dump fallito blocca la release. Gli esempi completi per GitHub Actions e GitLab sono in Safe deploy — backup prima della release. I due comandi che ti servono in quello stage:
$ cipi db backup myapp
# rollback locale veloce
$ cipi backup run myapp
# copia off-site di DB + shared/Usati insieme hai un restore sulla stessa macchina che impiega secondi e un prefisso S3 che puoi ancora aprire se il box non c'è più. Se uno dei due comandi fallisce, non fare deploy.
Errori che rendono inutili i backup
- Stessa regione della VPS, stesso account del provider, nessuna seconda copia. Un account sospeso o un'outage regionale porta via entrambi. Metti il bucket in un'altra regione, o da un altro vendor.
- Chiavi root del cloud sul server. Un utente IAM dedicato con quattro azioni S3 su un solo bucket basta. Se la VPS è compromessa, il raggio d'azione resta quel bucket.
- Non testare mai il restore. Flag di compressione, dump vuoti, un extract di
shared/che sovrascrive l'albero sbagliato — li incontri solo durante un incidente, se non fai drill. - Nessun prune, poi la bolletta a sorpresa. Dump da 2 GB al giorno diventano 60 GB al mese. Imposta
--weekslo stesso giorno in cui imposti il cron. - Fidarsi solo degli snapshot del provider. Sono comodi. Sono anche sullo stesso account, spesso nella stessa regione, e non ti danno un
db.sql.gzportabile. - Saltare
shared/. Un database senza i file caricati è mezza app.cipi backup runimpacchetta già entrambi; non inventare un cron solo-dump «per tenere le cose semplici».
Fallo su una VPS Cipi
Cipi è la CLI di deploy Laravel gratuita e open source usata in tutta questa guida. Un comando trasforma una VPS Ubuntu fresca in un server di produzione hardened — e cipi backup configure è il passo che rende il server sopravvivibile.
Domande frequenti
Cipi funziona solo con Amazon S3?
No. cipi backup configure accetta qualsiasi endpoint compatibile S3: Hetzner Object Storage, DigitalOcean Spaces, Backblaze B2, MinIO o uno store self-hosted come Johnny. Lascia l'endpoint vuoto per AWS; compilalo per tutti gli altri provider.
Qual è la differenza tra cipi db backup e cipi backup run?
cipi db backup scrive un dump SQL compresso sulla stessa VPS in /var/log/cipi/backups/. È sempre disponibile e non richiede configurazione. cipi backup run fa il dump del database e della cartella shared/ dell'app, poi carica entrambi gli archivi sul bucket S3. Usa il dump locale per un rollback veloce; usa la copia S3 per un restore off-site vero.
Quanto spesso dovrei fare il backup di una VPS Laravel?
Una volta al giorno è il default sensato in produzione. Aggiungi cipi backup run al crontab di root in un orario tranquillo, poi elimina i backup più vecchi di quattro settimane. Se il database cambia in continuazione, eseguilo due volte al giorno. Fai sempre un backup prima di una migration rischiosa o di un deploy in produzione.
Posso ripristinare un backup S3 di Cipi su una VPS nuova?
Sì — è il senso di una copia off-site. Installa Cipi su una VPS Ubuntu fresca, ricrea l'app, scarica db.sql.gz e shared.tar.gz dal bucket, ripristina il database con cipi db restore ed estrai shared/ in /home/<app>/.
Dove salva Cipi le credenziali S3?
cipi backup configure le scrive in /etc/cipi/backup.conf. Tieni quel file accessibile solo a root. Le stesse credenziali servono a cipi backup run, list e prune. Lo staging degli archivi grandi usa di default /var/tmp, così un /tmp piccolo in RAM non interrompe il job.
