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.

Sauvegardes · S3 · VPS

Comment sauvegarder un VPS sur un S3 seau avec Cipi

Par Andrea Pollastri · Dernière mise à jour : 22 août 2026 · lecture gratuite, pas de paywall

Un dump qui se trouve sur le même disque que l'application est un instantané et non une sauvegarde. Ce guide parcourt toute la boucle hors site avecCipi : créez un compartiment, stockez les informations d'identification une fois, exécutez le premier téléchargement, planifiez-le, élaguez les anciens et restaurez sur un VPS propre pour que vous sachiez que le plan fonctionne.

Dans ce guide

Pourquoi le dump sur le même disque n'est pas une sauvegarde
Ce que Cipi télécharge réellement
Ce dont vous avez besoin
Créer le bucket
Configurez Cipi une fois
Première sauvegarde et vérification
Cron, rétention et purge
Exercice de restauration
Sauvegarde avant chaque version
Des erreurs qui rendent les sauvegardes inutiles
FAQ

Pourquoi le dump sur le même disque n'est pas une sauvegarde

Instantanés du fournisseur, un .sql.gz dans /var/log, une archive tar à côté storage/ — ils meurent tous avec la machine. Disque plein, ransomware, un gros doigt rm -rf, une panne de région, un VPS volé : la copie dont vous avez besoin est celle qui se trouvait déjà ailleurs.

La règle qui tient toujours est 3-2-1: trois exemplaires, deux supports, un hors site. Cipi couvre le dernier saut. cipi db backup vous donne une restauration locale rapide ; cipi backup run expédie la base de données et le shared/ vers Amazon S3 ou tout compartiment compatible S3. C'est la copie à partir de laquelle vous restaurez lorsque le VPS a disparu.

Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un plan. Prévoyez 20 minutes après le premier téléchargement réussi et effectuez l'exploration Restaurer. Répétez-le tous les trimestres.

Ce que Cipi télécharge réellement

Chaque exécution crée un préfixe horodaté sur le bucket :

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

Dans ce dossier, vous obtenez deux archives :

db.sql.gz — un dump compressé de la base de données de l'application (mariadb-dump --single-transaction, ou l'équivalent PostgreSQL si l'application utilise ce moteur).
shared.tar.gz — l'intégralité /home/<app>/shared/ répertoire : .env, storage/, les fichiers téléchargés et tout ce qui survit à un échange de version de Deployer.

Le code n'est pas dans les archives. Les versions sont en direct dans Git ; si vous avez besoin du dernier bon arbre, clonez le dépôt. Ce que vous ne pouvez pas cloner, c'est la base de données et les fichiers téléchargés par les utilisateurs après la mise en ligne : ces deux fichiers constituent le point de restauration.

Depuis v4.7.14 la mise en scène se produit sur le disque dans /var/tmp, pas dans un support RAM /tmp. Les grandes applications ne meurent plus à mi-chemin parce que les tmpfs sont remplis. Remplacer par tmpdir dans backup.json ou le CIPI_BACKUP_TMPDIR variable d'environnement.

Ce dont vous avez besoin

Un VPS déjà géré par Cipi. Si vous partez de zéro, exécutez wget -O - https://cipi.sh/setup.sh | bash sur une nouvelle boîte Ubuntu 24.04/26.04, puis cipi app create. Le guide de démarrage couvre l'installation.
Au moins une application sur ce serveur. cipi backup run sans nom, sauvegarde chaque application ; cipi backup run myapp en cible un.
Un bucket compatible S3 ou S3 et une clé d'accès permettant d'y écrire. Créez un utilisateur IAM dédié : ne réutilisez pas vos informations d'identification cloud racine.

Créer le bucket

Choisissez un fournisseur, créez un bucket privé dans une région pas le même centre de données que le VPS, et créez une paire de clés limitée à ce compartiment uniquement. Activez le cryptage côté serveur si le fournisseur le propose. La gestion des versions est une assurance facultative mais bon marché contre un écrasement accidentel.

Actions IAM minimales sur ce bucket : s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject. Le dernier n'est obligatoire que si vous le souhaitez cipi backup prune pour nettoyer les anciens préfixes.

Fournisseur	URL du point de terminaison
AWS S3	laisser vide
Stockage d'objets Hetzner	`https://<datacenter>.your-objectstorage.com`
Espaces DigitalOcean	`https://<region>.digitaloceanspaces.com`
Backblaze B2	`https://s3.<region>.backblazeb2.com`
MinIO	`https://your-minio-host`
Johnny (self-hosted S3)	votre URL publique Johnny

N'importe quel magasin compatible S3 fonctionne. Si vous souhaitez la copie hors site sur un deuxième VPS que vous possédez – et non sur une autre facture SaaS – Johnny est l'option open-source déjà mentionnée dans le self-hosted pile de développeurs.

Configurez Cipi une fois

Connectez-vous en SSH en tant qu'utilisateur administrateur, devenez root et exécutez l'assistant. Il écrit/etc/cipi/backup.conf et vous ne devriez plus avoir à y toucher à moins que la clé ou le seau ne change.

# 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)

Garder /etc/cipi/backup.conf mode 600 et appartenant à root. Ces clés ouvrent toutes les sauvegardes que vous effectuerez. Si une clé fuit, faites-la pivoter chez le fournisseur et exécutez cipi backup configure encore une fois, les vieux objets restent dans le seau ; seuls les nouveaux téléchargements utilisent la nouvelle clé.

cipi db backup fonctionne sans configuration. cipi backup run ce n'est pas le cas. Si la commande S3 échoue avec une erreur d’informations d’identification, vous avez ignoré cette étape.

Première sauvegarde et vérification

Ne mettez rien dans le cron jusqu'à ce qu'un passage manuel ait atterri dans le seau. Commencez avec une seule application :

$ 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

Confirmez ensuite depuis la console du fournisseur – ou avec AWS CLI, qui communique également avec les points de terminaison compatibles si vous réussissez --endpoint-url:

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

Vous devriez voir les deux objets, avec des tailles qui correspondent à un dump compressé plus le shared/ arbre. Un objet de 200 octets signifie généralement un vidage vide ou un échec de téléchargement – corrigez ce problème avant de planifier quoi que ce soit.

Cron, rétention et purge

Tous les jours à 02h00 est la valeur par défaut ennuyeuse. Taillez à 03h00 pour que la course d'hier ne soit jamais supprimée par une course. Quatre semaines d'historique suffisent pour la plupart des Laravel applications ; passez à deux si la facture du seau fait mal, augmentez à huit si vous devez résoudre un bug de données à combustion lente.

# 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

Pour sauvegarder chaque application sur la boîte, supprimez le nom de l'application des deux commandes. cipi backup prune lit la même chose /etc/cipi/backup.conf et fonctionne avec n'importe quel fournisseur compatible.

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

Regarder /var/log/cipi/backup.log pendant une semaine. C'est grâce à une opération silencieuse qui a échoué dès le premier jour que les utilisateurs découvrent qu'ils n'ont aucune sauvegarde le lendemain d'une panne de disque.

Exercice de restauration

Faites-le sur une application intermédiaire ou sur un VPS de rechange, pas sur le trafic en direct la première fois. Le chemin heureux depuis un préfixe S3 vers une application en cours d’exécution :

$ 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/

Si le VPS lui-même a disparu, la séquence est la suivante : installer Cipi sur une nouvelle boîte Ubuntu, cipi app create avec la même télécommande Git, puis les deux restaurations ci-dessus, puis cipi ssl install et une coupe DNS. Le documents d'infrastructure lister les mêmes commandes ; cet exercice est la partie que la plupart des gens sautent.

Pour un rollback sur le même serveur (mauvaise migration, mauvais déploiement), le dump local est plus rapide :

$ 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

Décharges locales dans /var/log/cipi/backups/ ne sont jamais supprimés automatiquement. Lors d'un calendrier de déploiement chargé, ils remplissent le disque. Gardez les cinq derniers et supprimez le reste : ls -t /var/log/cipi/backups/myapp_*.sql.gz | tail -n +6 | xargs rm -f.

Sauvegarde avant chaque version

Le déploiement automatique Webhook ne peut pas être interrompu pour une sauvegarde : le push se déclenche cipi deploy immédiatement. Pour la production, placez une étape de sauvegarde dans CI afin qu'un échec de vidage bloque la version. Les GitHub actions et GitLab exemples complets sont disponibles dans Déploiement sécurisé : sauvegarde avant la publication. Les deux commandes dont vous avez besoin à cette étape :

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

Utilisés ensemble, vous obtenez une restauration dans la même boîte qui prend quelques secondes et un préfixe S3 que vous pouvez toujours ouvrir si la boîte a disparu. Si l’une des commandes échoue, ne déployez pas.

Des erreurs qui rendent les sauvegardes inutiles

Même région que le VPS, même compte fournisseur, pas de deuxième copie. Un compte suspendu ou une panne régionale prend les deux. Placez le bucket dans une autre région ou chez un autre fournisseur.
Clés cloud racine sur le serveur. Un utilisateur IAM dédié avec quatre S3 actions sur un bucket suffit. Si le VPS est compromis, le rayon de souffle reste celui du seau.
Ne jamais tester la restauration. Drapeaux de compression, décharges vides, un shared/ extrait qui écrase le mauvais arbre - vous ne rencontrez ces bogues que lors d'un incident, à moins que vous ne foriez.
Pas de pruneau, donc une facture surprise. Les vidages quotidiens de 2 Go deviennent 60 Go par mois. Ensemble --weeks le jour même où vous réglez cron.
Faire confiance aux instantanés du fournisseur uniquement. Ils sont pratiques. Ils sont également sur le même compte, souvent dans la même région, et ils ne vous donnent pas de téléphone portable. db.sql.gz.
Sauter shared/. Une base de données sans fichiers téléchargés est la moitié d'une application. cipi backup run contient déjà les deux ; n'inventez pas un cron de dump uniquement "pour faire simple".

Exécutez-le sur un Cipi VPS

Cipi est le déploiement gratuit open-source Laravel CLI utilisé tout au long de ce guide. Une seule commande transforme un nouveau Ubuntu VPS en un serveur de production renforcé — et cipi backup configure est l'étape qui permet au serveur de survivre.

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

Commencez gratuitement Référence de sauvegarde CLI Étoile sur GitHub

Questions fréquemment posées

Est-ce que Cipi fonctionne uniquement avec Amazon S3 ?

Non. cipi backup configure accepte tout point de terminaison compatible S3 : Hetzner Object Storage, DigitalOcean Spaces, Backblaze B2, MinIO ou un magasin self-hosted tel que Johnny. Laissez le point de terminaison vide pour AWS ; remplissez-le pour tous les autres fournisseurs.

Quelle est la différence entre `cipi db backup` et `cipi backup run`?

cipi db backup écrit un dump SQL compressé sur le même VPS sous /var/log/cipi/backups/. Il est toujours disponible et ne nécessite aucune configuration. cipi backup run vide la base de données et l'application shared/ dossier, puis télécharge les deux archives dans votre compartiment S3. Utilisez le dump local pour une restauration rapide ; utilisez la copie S3 pour une véritable restauration hors site.

À quelle fréquence dois-je sauvegarder un Laravel VPS ?

Quotidiennement est la valeur par défaut raisonnable pour la production. Ajouter cipi backup run à la racine crontab à une heure calme, puis taillez plus de quatre semaines. Si la base de données change constamment, exécutez-la deux fois par jour. Exécutez toujours une sauvegarde avant une migration risquée ou un déploiement de production.

Puis-je restaurer une sauvegarde Cipi S3 sur une nouvelle sauvegarde VPS ?

Oui, c'est l'intérêt d'une copie hors site. Installez Cipi sur un nouveau Ubuntu VPS, recréez l'application, téléchargez db.sql.gz et shared.tar.gz à partir du bucket, restaurez la base de données avec cipi db restore, et extraire shared/ dans /home/<app>/.

Où Cipi stocke-t-il les identifiants S3 ?

cipi backup configure leur écrit /etc/cipi/backup.conf. Conservez ce fichier en racine uniquement. Les mêmes informations d'identification sont utilisées par cipi backup run, list et prune. La mise en scène des archives volumineuses est par défaut /var/tmp donc une petite RAM sauvegardée /tmp n'abandonne pas le travail.