Intermédiaire ⏱ 12 min Mis à jour le 29 juillet 2026

Mettre en place une stratégie de sauvegarde pour votre serveur

Une sauvegarde qu'on n'a jamais testée n'est pas une sauvegarde. Voici comment bâtir une vraie stratégie : la règle 3-2-1, l'automatisation, et surtout la restauration.

Pourquoi une vraie stratégie de sauvegarde serveur est indispensable

Une stratégie de sauvegarde serveur protège vos données contre les incidents techniques, mais aussi contre les erreurs humaines. Une suppression accidentelle, une mauvaise mise à jour ou une commande exécutée dans le mauvais dossier peut suffire à rendre une application inutilisable.

Les causes de perte de données comprennent notamment :

une suppression involontaire ;
une panne matérielle ;
une base de données corrompue ;
une mise à jour défectueuse ;
une mauvaise manipulation ;
une compromission ou un rançongiciel ;
la suppression d’un conteneur sans volume persistant ;
une erreur de synchronisation avec rsync --delete.

Une sauvegarde doit permettre de revenir à un état exploitable dans un délai compatible avec votre activité. Copier quelques fichiers de temps en temps ne constitue donc pas une stratégie complète.

Vous devez définir :

les données à protéger ;
la fréquence des sauvegardes ;
leur durée de conservation ;
leur emplacement ;
la procédure de restauration ;
la personne chargée des contrôles.

Vous restez responsable de vos données, de vos exports et de la validation de leur restauration.

Appliquer la règle de sauvegarde 3-2-1

La règle 3-2-1 constitue une base simple pour organiser vos copies :

3 copies des données
2 supports ou emplacements différents
1 copie conservée hors site

Élément	Exemple
Copie principale	Données actives sur le VPS
Deuxième copie	Archive locale ou sauvegarde gérée
Copie hors site	Stockage distant ou second serveur indépendant

Une organisation possible serait :

Application et base sur le VPS
            ↓
Export quotidien local
            ↓
Copie chiffrée vers un stockage distant

La copie hors site est importante. Une sauvegarde conservée uniquement sur le même VPS peut disparaître avec le serveur, le compte ou une compromission affectant l’ensemble de la machine.

Des sauvegardes automatiques sont incluses pour vous aider à restaurer. Conservez aussi vos propres exports réguliers : vous restez responsable de vos données.

Adaptez également la fréquence au rythme des changements. Une base de données mise à jour toutes les minutes nécessite généralement des sauvegardes plus fréquentes qu’un site statique modifié une fois par mois.

Déterminer quoi sauvegarder

Sauvegardez les éléments impossibles ou coûteux à recréer.

Fichiers applicatifs

Conservez notamment :

les contenus envoyés par les utilisateurs ;
les fichiers de configuration ;
les scripts personnalisés ;
les thèmes et extensions modifiés ;
les certificats ou fichiers nécessaires au service ;
les fichiers non présents dans Git.

Si le code est correctement versionné dans un dépôt distant, il n’est pas toujours nécessaire de sauvegarder chaque copie de node_modules, .venv ou des dépendances téléchargeables.

Configurations système

Selon le serveur, sauvegardez les configurations importantes :

/etc/nginx/
/etc/systemd/system/
/etc/fail2ban/
/etc/ufw/
/etc/cron.d/

Pour FiveM ou un serveur de jeu, cela peut aussi inclure :

server.cfg
resources/
permissions.cfg

Bases de données

Une simple copie des fichiers internes de MySQL ou PostgreSQL pendant que le service fonctionne n’est pas toujours cohérente. Utilisez les outils d’export prévus par le moteur.

Secrets

Les fichiers .env, clés privées et identifiants doivent être sauvegardés séparément et chiffrés. Ils ne doivent jamais être placés dans une archive publique ou un dépôt Git.

Volumes Docker

Les données persistantes d’un conteneur se trouvent souvent dans un volume Docker ou un bind mount. Sauvegarder uniquement le fichier compose.yaml ne sauvegarde pas le contenu de la base ou des fichiers applicatifs.

Sauvegarder une base de données

Exporter une base MySQL ou MariaDB

Utilisez mysqldump :

mysqldump \
  --defaults-extra-file=/etc/backup/mysql.cnf \
  --single-transaction \
  --databases mon_application \
  | gzip > /var/backups/mon_application.sql.gz

Le fichier /etc/backup/mysql.cnf peut contenir :

[client]
user=backup_user
password=VOTRE_MOT_DE_PASSE
host=127.0.0.1

Protégez-le :

sudo chown root:root /etc/backup/mysql.cnf
sudo chmod 600 /etc/backup/mysql.cnf

N’écrivez pas le mot de passe directement dans la commande. Il pourrait apparaître dans l’historique du terminal ou dans la liste des processus.

Exporter une base PostgreSQL

Utilisez pg_dump :

sudo -u postgres pg_dump \
  --format=custom \
  mon_application \
  > /var/backups/mon_application.dump

Le format custom facilite une restauration sélective avec pg_restore.

Vous pouvez aussi compresser un export SQL classique :

sudo -u postgres pg_dump mon_application \
  | gzip > /var/backups/mon_application.sql.gz

Vérifiez toujours que l’archive a bien été créée :

ls -lh /var/backups/
gzip -t /var/backups/mon_application.sql.gz

Un fichier présent mais vide ou corrompu n’est pas une sauvegarde exploitable.

Automatiser les sauvegardes avec un script et cron

Créez un script réservé aux sauvegardes :

sudo nano /usr/local/sbin/sauvegarde-serveur.sh

Exemple pour une application et une base MySQL :

#!/usr/bin/env bash

set -Eeuo pipefail
umask 077

DATE="$(date +'%Y-%m-%d_%H-%M-%S')"
BACKUP_DIR="/var/backups/mon-app"
APP_DIR="/var/www/mon-app"
MYSQL_CONFIG="/etc/backup/mysql.cnf"
DATABASE="mon_application"

mkdir -p "$BACKUP_DIR"

mysqldump \
  --defaults-extra-file="$MYSQL_CONFIG" \
  --single-transaction \
  --databases "$DATABASE" \
  | gzip > "$BACKUP_DIR/database_${DATE}.sql.gz"

tar \
  --exclude="node_modules" \
  --exclude=".git" \
  -czf "$BACKUP_DIR/fichiers_${DATE}.tar.gz" \
  "$APP_DIR"

find "$BACKUP_DIR" \
  -type f \
  -mtime +14 \
  -delete

echo "Sauvegarde terminée : $DATE"

Rendez-le exécutable :

sudo chmod 700 /usr/local/sbin/sauvegarde-serveur.sh

Testez-le manuellement :

sudo /usr/local/sbin/sauvegarde-serveur.sh

Vérifiez les archives avant de planifier l’exécution.

Ajoutez ensuite une tâche cron root :

sudo crontab -e

Pour une sauvegarde quotidienne à 03 h 00 :

0 3 * * * /usr/local/sbin/sauvegarde-serveur.sh >> /var/log/sauvegarde-serveur.log 2>&1

Le guide sur les tâches planifiées avec cron explique la syntaxe, les chemins absolus et la gestion des logs.

La rotation avec find ... -delete supprime réellement les anciennes archives. Testez d’abord la commande sans -delete pour contrôler les fichiers concernés.

Externaliser une copie hors site

Une archive locale protège contre certaines erreurs, mais pas contre la perte complète du VPS. Copiez donc les sauvegardes vers un emplacement indépendant.

Avec rsync :

rsync -avz \
  /var/backups/mon-app/ \
  sauvegarde@SERVEUR_DISTANT:/archives/mon-app/

Avec un port SSH personnalisé :

rsync -avz \
  -e "ssh -p 2222" \
  /var/backups/mon-app/ \
  sauvegarde@SERVEUR_DISTANT:/archives/mon-app/

Vous pouvez aussi utiliser SFTP ou SCP. Le guide pour transférer des fichiers vers un VPS compare ces méthodes.

Pour des données sensibles :

chiffrez les archives avant l’envoi ;
protégez les clés de chiffrement séparément ;
limitez le compte distant à son dossier de sauvegarde ;
utilisez une clé SSH dédiée ;
ne rendez pas le stockage publiquement accessible.

Une synchronisation n’est pas toujours une sauvegarde. Si une suppression est immédiatement reproduite sur la destination, vous perdez aussi la copie distante. Conservez plusieurs versions ou archives datées.

Tester régulièrement la restauration

Le test de restauration est l’étape la plus importante. Une sauvegarde jamais restaurée peut contenir une base incomplète, une archive corrompue ou des fichiers inutilisables.

Effectuez le test sur un environnement isolé :

créez une machine ou un dossier de test ;
récupérez une archive hors site ;
extrayez les fichiers ;
restaurez la base de données ;
démarrez l’application ;
vérifiez les fonctions principales ;
notez le temps nécessaire ;
documentez les commandes utilisées.

Pour PostgreSQL :

createdb mon_application_test

pg_restore \
  --dbname=mon_application_test \
  /chemin/mon_application.dump

Pour un export MySQL compressé :

gunzip -c mon_application.sql.gz \
  | mysql \
      --defaults-extra-file=/etc/backup/mysql.cnf \
      mon_application_test

Contrôlez ensuite :

le nombre d’enregistrements ;
les comptes utilisateurs ;
les fichiers envoyés ;
les permissions ;
les relations entre les données ;
le démarrage des services.

Planifiez ce test régulièrement et après toute modification importante de l’architecture.

Pour compléter la protection du VPS, consultez le guide pour sécuriser votre serveur Linux.

En résumé

Une stratégie de sauvegarde serveur protège contre les pannes, erreurs humaines, suppressions et compromissions.
Appliquez la règle 3-2-1 : trois copies, deux supports, une copie hors site.
Sauvegardez les fichiers applicatifs, configurations, bases de données et volumes Docker.
Excluez les caches et dépendances facilement régénérables.
Conservez les secrets séparément et sous forme chiffrée.
Utilisez mysqldump ou pg_dump pour obtenir des exports cohérents.
Ne placez jamais un mot de passe de base de données directement dans une commande.
Automatisez les exports avec un script testé manuellement.
Planifiez le script avec cron et conservez ses logs.
Ajoutez une rotation prudente pour éviter de remplir le disque.
Externalisez une copie vers un stockage indépendant.
Ne confondez pas synchronisation et sauvegarde versionnée.
Testez régulièrement une restauration complète sur un environnement isolé.
Pour déployer votre stratégie de sauvegarde serveur sur un VPS hébergé en France avec stockage NVMe, Anti-DDoS L3/L4/L7 inclus, panel de gestion et support francophone, découvrez les offres VPS TalCloud.