Ce qu'il faut sauvegarder
Une application Laravel tient en trois morceaux. Si l'un manque, la restauration échoue.
- La base de données, par un export complet et non par une copie de fichiers à chaud.
- Les fichiers envoyés par les utilisateurs, souvent dans storage/app.
- Le fichier d'environnement, qui porte les clés et les accès. Il ne se range jamais dans le dépôt Git.
Le code vit dans Git. Il n'a pas besoin d'une sauvegarde de plus, à condition que le dépôt soit hébergé ailleurs que sur le serveur.
Où ranger la copie
Une sauvegarde sur le même serveur disparaît avec lui. Elle doit partir ailleurs : un autre hébergeur, un stockage objet, un autre site.
Chiffrez la copie avant l'envoi. Elle contient les données de vos clients.
Gardez plusieurs générations. Une corruption découverte trois jours plus tard ne se répare pas avec la copie de la veille.
Automatiser et surveiller
Une sauvegarde manuelle finit par être oubliée. Planifiez-la avec le planificateur de Laravel ou une tâche cron, et gardez une trace de chaque exécution.
Le point que l'on oublie : l'alerte en cas d'échec. Une tâche qui plante en silence pendant des semaines est le scénario le plus courant des reprises de projet.
Le test de restauration
C'est le seul test qui prouve quelque chose. Sur une machine vide, restaurez la base, remettez les fichiers, recréez le fichier d'environnement, lancez l'application.
Notez le temps total et les étapes qui ont coincé. Refaites l'exercice après chaque changement d'hébergement ou de version majeure.
Si personne ne sait dire combien de temps prend votre restauration, c'est que personne ne l'a faite.
Conclusion
Une sauvegarde utile est complète, hors du serveur, surveillée et restaurée au moins une fois. Si vous reprenez une application dont personne ne connaît l'état des copies, commencez par là, avant toute évolution. Décrivez-moi votre projet : devis gratuit sous 48 h.