La question à se poser d'abord
Si votre serveur disparaissait maintenant, en combien de temps pourriez-vous le reconstruire, et combien de données perdreriez-vous ? La réponse définit votre stratégie : sauvegardes quotidiennes pour une boutique, hebdomadaires pour une vitrine.
La règle 3-2-1
Trois copies de vos données, sur deux supports différents, dont une hors site. Sur un VPS, cela signifie concrètement : le serveur en production, une sauvegarde locale sur un volume distinct, et une copie externalisée vers un stockage objet ou un autre serveur.
Ce qui doit être sauvegardé
- Les fichiers de l'application (code, médias, configurations).
- La base de données, avec un dump cohérent — copier les fichiers bruts d'une base active produit une sauvegarde corrompue.
- Les fichiers de configuration du serveur : nginx, certificats, tâches planifiées, comptes.
Une sauvegarde sans les configurations serveur vous oblige à tout reconstruire à la main : c'est là que passent les journées entières lors d'une restauration.
Exemple de sauvegarde de base
mysqldump --single-transaction --routines base > /sauvegardes/base-$(date +%F).sql
L'option --single-transaction évite de verrouiller les tables pendant l'export.
Automatisez, puis vérifiez
Placez la sauvegarde dans une tâche planifiée, mais surtout : testez la restauration. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie. Programmez un test une fois par trimestre sur un serveur jetable.
L'erreur la plus fréquente
Stocker la sauvegarde sur le serveur sauvegardé. C'est pratique, et c'est exactement ce qui disparaît en même temps que le serveur. Externalisez au moins une copie.
Et la haute disponibilité ?
Sauvegarder n'est pas la même chose que rester en ligne. Si votre activité ne supporte pas une interruption de quelques heures, la question n'est pas la sauvegarde mais l'architecture : plusieurs serveurs, répartition de charge, base répliquée. Parlons-en si c'est votre cas.
