Sauvegarde automatique VPS : mettre en place rsync, cron et snapshots en 2026

Gérer un VPS en production sans stratégie de sauvegarde claire expose votre site, votre application ou votre base de données à un risque majeur : la perte de données. ⚡Une mauvaise commande SSH, une mise à jour système qui échoue, une suppression accidentelle ou une intrusion peuvent suffire à rendre un serveur inutilisable. 💥Beaucoup d’administrateurs pensent être protégés parce que leur hébergeur propose des sauvegardes, mais ils ne savent pas toujours ce qui est sauvegardé, à quelle fréquence, ni comment restaurer rapidement.

Pour sécuriser réellement un serveur Linux, il est préférable de combiner plusieurs niveaux de protection : les sauvegardes automatiques, les snapshots et une sauvegarde rsync automatisée vers une destination distante. ✨C’est cette approche complète que nous allons mettre en place dans ce tutoriel.

Objectif

👇L’objectif de ce guide est de vous aider à mettre en place une sauvegarde automatique VPS fiable, compréhensible et adaptée à un usage réel. Vous allez apprendre à sauvegarder des répertoires importants avec rsync, à planifier l’exécution du script avec cron, puis à compléter cette stratégie avec les snapshots LWS Panel. 😊À la fin du tutoriel, vous disposerez d’un script fonctionnel, d’une tâche cron automatisée, d’une méthode pour exporter vos bases MySQL/MariaDB et d’une vision claire de la différence entre une sauvegarde distante et un snapshot serveur.🎉 L’objectif n’est pas seulement de copier des fichiers, mais de construire une stratégie de restauration réaliste, testable et adaptée à un VPS Debian ou Ubuntu.

Les trois niveaux de protection d’un VPS : ce qu’il faut comprendre avant de commencer

Un VPS bien protégé ne repose pas sur une seule méthode de sauvegarde. En pratique, il faut combiner plusieurs couches, car elles ne répondent pas au même besoin. Une sauvegarde automatique fournie par l’hébergeur permet de revenir à un état global du serveur. Un snapshot sert plutôt à figer le VPS avant une opération risquée. Une sauvegarde rsync, elle, permet de copier des fichiers ciblés vers une destination externe, avec une fréquence personnalisée.

Ces trois niveaux doivent être vus comme complémentaires. Par exemple, avant une mise à jour système importante, un snapshot permet de revenir rapidement en arrière si le serveur ne redémarre pas correctement. En revanche, pour conserver des fichiers sur plusieurs jours ou semaines, il faut prévoir une sauvegarde distante avec rotation.

Cette approche rejoint la règle de sauvegarde 3-2-1, recommandée comme bonne pratique de protection des données : conserver 3 copies des données, sur 2 supports différents, avec au moins 1 copie hors site. La CISA présente cette règle comme une base fiable pour protéger les fichiers importants, notamment en cas d’incident ou de compromission.

Appliquée à un VPS Linux, cette logique peut se traduire ainsi : vos données de production restent sur le serveur, les sauvegardes automatiques LWS constituent un filet de sécurité côté infrastructure, et une copie rsync distante ajoute une protection supplémentaire hors du VPS source. Il ne faut donc pas opposer ces outils, mais les organiser dans une stratégie cohérente.

Les sauvegardes automatiques LWS : ce qui est inclus et comment en profiter

Sur les offres VPS, LWS met à disposition des mécanismes de protection utiles pour limiter les risques de perte de données. La page des serveurs VPS LWS mentionne des sauvegardes complètes automatiques journalières du serveur sur un NAS sécurisé, ainsi qu’un outil de snapshot accessible pour les serveurs VPS.

Pour les VPS KVM LWS, les sauvegardes automatiques incluses sont réalisées chaque matin et stockées sur un NAS dédié. Ces sauvegardes peuvent être conservées après les 30 jours offerts pour 20 % du tarif du VPS. Il existe aussi des snapshots gratuits, jusqu’à 3 instantanés simultanés, utiles pour figer l’état d’un VPS KVM avant un test, une mise à jour ou un changement de configuration.

Concrètement, ces sauvegardes hébergeur sont précieuses parce qu’elles permettent de restaurer un serveur depuis l’interface LWS, sans avoir à reconstruire manuellement tout l’environnement. Elles sont particulièrement utiles en cas de suppression massive, d’erreur de configuration ou de problème système. En revanche, elles ne doivent pas remplacer votre propre plan de sauvegarde applicatif. Pour un serveur critique, il reste recommandé d’ajouter une copie distante de vos fichiers, de vos exports SQL et de vos configurations importantes.

Les snapshots LWS répondent à un autre usage. LWS explique qu’un snapshot est une capture de l’état d’un serveur VPS à un instant donné, incluant les fichiers, les configurations et les données présentes au moment de sa création. Il précise aussi qu’un snapshot ne remplace pas une sauvegarde, car il n’est pas conservé physiquement sur un NAS comme les sauvegardes disponibles dans l’espace client.

La documentation indique également une limite de 10 snapshots maximum, une conservation de 48 heures maximum, et signale qu’en cas de réinstallation du VPS, les snapshots existants sont supprimés et ne peuvent plus être restaurés.

Le bon réflexe consiste donc à utiliser les snapshots pour les opérations ponctuelles à risque, et les sauvegardes automatiques comme sécurité d’infrastructure. Pour les données que vous devez maîtriser finement, comme les fichiers d’un site web, les exports de base de données ou les configurations personnalisées, la solution la plus souple reste une sauvegarde rsync automatique.

Pour accéder aux snapshots, rendez-vous dans la section « Panel KVM > Snapshots ».

Ensuite, cliquez sur le bouton « Créer un snapshot ».

Vous pouvez alors gérer les snapshots crées depuis la même page.

Préparer l’environnement : pré-requis

Avant de créer votre script de sauvegarde VPS, vous devez vérifier que l’environnement est prêt. Ce tutoriel s’adresse principalement à un VPS Linux sous Debian 11/12 ou Ubuntu 22.04/24.04, avec un accès root SSH ou un utilisateur disposant des droits nécessaires. Les commandes peuvent aussi être adaptées à d’autres distributions Linux, mais les chemins de logs et certains paquets peuvent varier.

Le premier outil indispensable est rsync. Il est généralement présent sur de nombreuses distributions Linux, mais il est préférable de vérifier sa disponibilité avant de continuer :

rsync --version

apt update
apt install rsync

Vous devez ensuite disposer d’une destination distante pour recevoir les sauvegardes. Il peut s’agir d’un second VPS, d’un serveur de stockage, d’un NAS accessible en SSH ou d’un espace compatible SFTP/SCP. L’important est de ne pas stocker vos seules sauvegardes sur le même VPS que la source. Si le serveur est compromis, supprimé ou inaccessible, les sauvegardes locales risquent de l’être également.

Pour automatiser la sauvegarde avec cron, l’authentification entre le VPS source et la destination doit se faire par clé SSH, sans mot de passe interactif. Vous pouvez générer une clé dédiée aux sauvegardes avec la commande suivante :

ssh-keygen -t ed25519 -f ~/.ssh/backup_key -N ""

Cette commande crée une paire de clés : une clé privée backup_key et une clé publique backup_key.pub. Copiez ensuite la clé publique sur le serveur de destination :

ssh-copy-id -i ~/.ssh/backup_key.pub user@serveur-destination

ssh -i ~/.ssh/backup_key user@serveur-destination

Si la connexion fonctionne sans demande de mot de passe, votre environnement est prêt pour une sauvegarde rsync automatique.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Créer un script de sauvegarde rsync

rsync est un utilitaire de synchronisation très utilisé sous Linux. Il permet de copier des fichiers d’un serveur vers un autre en transférant uniquement les différences entre la source et la destination. Cette approche le rend particulièrement adapté à une sauvegarde automatique VPS, car elle évite de recopier l’intégralité des données à chaque exécution.

Dans ce tutoriel, nous allons créer un script qui sauvegarde des répertoires importants comme /var/www, /etc et /home vers un serveur distant. Le script écrira également ses actions dans un fichier de log afin de vérifier facilement si la sauvegarde s’est bien déroulée.

1. Comprendre les options rsync essentielles

Avant d’écrire le script complet, il est utile de comprendre les principales options de rsync. Elles déterminent la manière dont les fichiers sont copiés, compressés, supprimés ou exclus de la sauvegarde.

L’option la plus sensible est --delete. Elle garde la destination parfaitement synchronisée avec la source, mais peut aussi supprimer des fichiers sur le serveur distant si la source est mal définie. Avant une première exécution réelle, il est recommandé de tester la commande avec --dry-run, qui simule la sauvegarde sans modifier les fichiers.

2. Script de sauvegarde complet

Nous allons maintenant créer un script de sauvegarde dans le dossier /root/scripts/. Si ce dossier n’existe pas encore, créez-le :

mkdir -p /root/scripts

Créez ensuite le fichier /root/scripts/backup.sh :

nano /root/scripts/backup.sh

Ajoutez le contenu suivant dans le fichier :

#!/bin/bash
# ================================================
# Script de sauvegarde rsync — VPS LWS
# ================================================

# Configuration
SOURCE_DIRS="/var/www /etc /home"          # Répertoires à sauvegarder
DEST_USER="user"                           # Utilisateur SSH destination
DEST_HOST="serveur-destination.exemple.fr" # Serveur de destination
DEST_PATH="/mnt/backups/vps-$(hostname)"   # Chemin distant
SSH_KEY="/root/.ssh/backup_key"            # Clé SSH dédiée
LOG_FILE="/var/log/backup-rsync.log"       # Fichier de log

# Date pour les logs
DATE=$(date +"%Y-%m-%d %H:%M:%S")

echo "[$DATE] Début de la sauvegarde" >> "$LOG_FILE"

# Exécution rsync
rsync -azv \
  --delete \
  --exclude="*.log" \
  --exclude="*.tmp" \
  --exclude="/var/www/*/wp-content/cache/" \
  --exclude="/tmp/" \
  -e "ssh -i $SSH_KEY -o StrictHostKeyChecking=no" \
  $SOURCE_DIRS \
  "$DEST_USER@$DEST_HOST:$DEST_PATH" \
  >> "$LOG_FILE" 2>&1

# Vérification du code de retour
if [ $? -eq 0 ]; then
  echo "[$DATE] Sauvegarde terminée avec succès" >> "$LOG_FILE"
else
  echo "[$DATE] ERREUR — sauvegarde échouée (code $?)" >> "$LOG_FILE"
fi

Ce script commence par définir les répertoires à sauvegarder, l’utilisateur distant, le serveur de destination, le chemin de stockage, la clé SSH et le fichier de log. La commande rsync copie ensuite les données vers le serveur distant en excluant certains fichiers inutiles, comme les logs, les fichiers temporaires et les caches WordPress.

Le chemin /var/www contient généralement les fichiers des sites web. Le dossier /etc regroupe de nombreuses configurations système importantes. Le dossier /home peut contenir des fichiers utilisateurs, des scripts ou des données applicatives. Vous pouvez ajuster cette liste selon votre serveur.

Rendez ensuite le script exécutable :

chmod +x /root/scripts/backup.sh

Lancez une première exécution manuelle :

/root/scripts/backup.sh

Puis consultez le fichier de log :

tail -n 50 /var/log/backup-rsync.log

Si le message “Sauvegarde terminée avec succès” apparaît, votre script rsync est fonctionnel. Il pourra ensuite être automatisé avec cron.

3. Sauvegarder une base de données MySQL/MariaDB

rsync est très efficace pour copier des fichiers, mais il ne suffit pas toujours pour sauvegarder correctement une base de données MySQL ou MariaDB en fonctionnement. Une base active peut écrire des données au moment de la copie. Pour obtenir une sauvegarde propre, il faut d’abord générer un dump SQL, puis inclure ce fichier dans la sauvegarde rsync.

Commencez par créer un dossier dédié aux exports :

mkdir -p /root/db_backups

Créez ensuite un script spécifique :

nano /root/scripts/mysql_dump.sh

Ajoutez le contenu suivant :

#!/bin/bash
# ================================================
# Export MySQL/MariaDB — VPS LWS
# ================================================

DB_USER="root"
DUMP_DIR="/root/db_backups"
DATE=$(date +%F)

mkdir -p "$DUMP_DIR"

# Exporter toutes les bases de données
mysqldump --user="$DB_USER" \
  --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  > "$DUMP_DIR/all_databases_$DATE.sql"

# Compresser le dump SQL
gzip "$DUMP_DIR/all_databases_$DATE.sql"

# Supprimer les dumps de plus de 7 jours
find "$DUMP_DIR" -name "*.sql.gz" -mtime +7 -delete

Rendez le script exécutable :

chmod +x /root/scripts/mysql_dump.sh

Puis testez-le manuellement :

/root/scripts/mysql_dump.sh
ls -lh /root/db_backups

L’option --single-transaction est importante pour les bases utilisant le moteur InnoDB : elle permet de réaliser un export cohérent sans bloquer inutilement les tables pendant toute la durée de la sauvegarde. Les options --routines et --triggers permettent d’inclure les procédures stockées et les déclencheurs, souvent oubliés dans les sauvegardes basiques.

Pour éviter de stocker un mot de passe MySQL en clair dans le script, il est préférable d’utiliser un fichier /root/.my.cnf :

nano /root/.my.cnf

Ajoutez par exemple :

[client]
user=root
password=votre_mot_de_passe_mysql

Sécurisez ensuite le fichier :

chmod 600 /root/.my.cnf

Avec cette méthode, mysqldump peut s’authentifier automatiquement sans exposer le mot de passe dans la commande ou dans l’historique du terminal. Le dossier /root/db_backups pourra ensuite être ajouté aux répertoires sauvegardés par votre script rsync.

Automatiser avec cron

Une fois le script de sauvegarde créé et testé manuellement, l’étape suivante consiste à l’exécuter automatiquement. Pour cela, Linux dispose d’un outil natif : cron. Il permet de lancer une commande ou un script selon un calendrier précis, par exemple tous les jours à 3 h, toutes les 6 heures ou chaque dimanche.

Dans le cadre d’une sauvegarde automatique VPS, cron est particulièrement adapté : il fonctionne en arrière-plan, ne nécessite pas d’interface graphique et peut exécuter vos scripts avec les droits de l’utilisateur configuré. Ici, nous allons l’utiliser pour lancer l’export MySQL/MariaDB, puis la synchronisation rsync vers le serveur distant.

1. Syntaxe cron rappel

Une ligne cron suit une syntaxe composée de 5 champs de planification, suivis de la commande à exécuter :

# ┌───────────── minute (0-59)
# │ ┌───────────── heure (0-23)
# │ │ ┌───────────── jour du mois (1-31)
# │ │ │ ┌───────────── mois (1-12)
# │ │ │ │ ┌───────────── jour de la semaine (0-7, 0 et 7 = dimanche)
# │ │ │ │ │
# * * * * * commande

Par exemple, cette ligne signifie : exécuter le script tous les jours à 3 h 00 :

0 3 * * * /root/scripts/backup.sh

2. Ajouter la tâche cron

Pour modifier la crontab de l’utilisateur root, utilisez :

crontab -e

Ajoutez ensuite les lignes adaptées à votre stratégie de sauvegarde. Pour lancer une sauvegarde rsync quotidienne à 3 h du matin :

# Sauvegarde rsync tous les jours à 3h00
0 3 * * * /root/scripts/backup.sh

Pour une sauvegarde plus fréquente, par exemple toutes les 6 heures :

# Sauvegarde rsync toutes les 6 heures
0 */6 * * * /root/scripts/backup.sh

Si votre VPS héberge une base MySQL/MariaDB, il est préférable de générer le dump SQL avant de lancer rsync. Par exemple, vous pouvez exporter les bases à 2 h 30, puis synchroniser les fichiers à 3 h 00 :

# Export MySQL tous les jours à 2h30
30 2 * * * /root/scripts/mysql_dump.sh

# Sauvegarde rsync tous les jours à 3h00
0 3 * * * /root/scripts/backup.sh

# Sauvegarde hebdomadaire le dimanche à 2h00
0 2 * * 0 /root/scripts/backup.sh

MAILTO=votre@email.fr

Cette configuration est utile pour détecter rapidement une sauvegarde échouée, un problème de connexion SSH ou un espace disque saturé sur le serveur distant. Une fois la crontab enregistrée, cron prendra automatiquement en compte les nouvelles tâches.

3. Vérifier que la tâche est bien enregistrée

Après avoir ajouté vos lignes dans cron, il est important de vérifier qu’elles ont bien été enregistrées. Une erreur de sauvegarde peut simplement venir d’une crontab vide, mal sauvegardée ou modifiée avec le mauvais utilisateur.

Pour lister les tâches cron de l’utilisateur courant, utilisez :

crontab -l

Si vous avez configuré les sauvegardes avec l’utilisateur root, la commande doit afficher vos lignes de planification, par exemple :

30 2 * * * /root/scripts/mysql_dump.sh
0 3 * * * /root/scripts/backup.sh

Vérifiez attentivement les chemins des scripts, les heures d’exécution et l’ordre des tâches. L’export MySQL/MariaDB doit être lancé avant la sauvegarde rsync, afin que le dump SQL récent soit bien copié vers la destination distante.

4. Surveiller les logs cron

Une tâche cron peut être correctement enregistrée, mais échouer au moment de son exécution. Pour le vérifier, consultez les logs système et le fichier de log de votre script.

Sur Debian ou Ubuntu, les traces cron se trouvent généralement dans /var/log/syslog :

grep CRON /var/log/syslog | tail -20

Sur CentOS, Rocky Linux ou AlmaLinux, utilisez plutôt :

grep CRON /var/log/cron | tail -20

Vous pouvez aussi suivre directement le log du script rsync :

tail -f /var/log/backup-rsync.log

Le message attendu est :

Sauvegarde terminée avec succès

Si vous voyez une erreur de type Permission denied, No such file or directory ou Connection timed out, la tâche cron se lance bien, mais le script rencontre un problème d’accès, de chemin ou de connexion réseau. Une capture d’écran utile pour l’article pourrait montrer la sortie de crontab -l avec les tâches configurées, puis un extrait du fichier /var/log/backup-rsync.log indiquant une sauvegarde réussie.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Rotation et rétention des sauvegardes

Une sauvegarde automatique VPS ne doit pas seulement copier les fichiers : elle doit aussi gérer leur durée de conservation. Sans stratégie de rotation, les sauvegardes s’accumulent jour après jour et peuvent saturer l’espace disque du serveur distant. Lorsque le stockage est plein, les nouvelles sauvegardes échouent, parfois sans que l’administrateur s’en rende compte immédiatement.

L’objectif est donc de définir une rétention claire : combien de jours, semaines ou mois souhaitez-vous conserver vos données ? Pour un site web classique, une sauvegarde quotidienne sur 7 jours peut suffire. Pour un serveur plus critique, il peut être utile de conserver des versions hebdomadaires et mensuelles.

La rétention doit être adaptée à trois critères : le volume de données, la fréquence des modifications et le niveau de risque acceptable. Un site vitrine peu modifié n’a pas les mêmes besoins qu’une boutique WooCommerce, une application métier ou une plateforme avec de nombreux utilisateurs.

1. Stratégie de rétention recommandée

Voici une base simple pour organiser la rétention des sauvegardes sur un VPS. Elle peut être ajustée selon l’espace disponible sur la destination et l’importance des données.

La commande find supprime les fichiers plus anciens que le nombre de jours indiqué avec -mtime. Par exemple :

find /backups/ -mtime +7 -delete

Cette commande supprime les fichiers de plus de 7 jours dans le dossier /backups/. Avant de l’utiliser en production, testez-la sans -delete afin de voir les fichiers qui seraient concernés :

find /backups/ -mtime +7

Vous pouvez intégrer cette logique dans votre script de sauvegarde, mais avec prudence. Assurez-vous que le chemin indiqué correspond bien au dossier de sauvegarde distant, et non à un répertoire important du VPS source. Une erreur sur une commande de suppression peut provoquer une perte de données.

Pour plus de sécurité, vous pouvez aussi prévoir plusieurs niveaux : des sauvegardes quotidiennes courtes, quelques sauvegardes hebdomadaires, puis des archives mensuelles pour les données sensibles. Cette organisation évite d’avoir uniquement la dernière version disponible, ce qui peut être problématique si une corruption ou une intrusion est découverte plusieurs jours après l’incident.

2. Sauvegardes horodatées avec rsync

La méthode la plus simple avec rsync consiste à synchroniser les fichiers vers un même dossier distant. Cette approche est efficace, mais elle conserve surtout l’état le plus récent. Pour disposer de plusieurs versions, vous pouvez créer des sauvegardes horodatées, avec un dossier différent pour chaque date.

Par exemple :

DEST_PATH="/mnt/backups/vps/$(date +%F)"

Avec cette variable, rsync crée un dossier daté, par exemple :

/mnt/backups/vps/2026-06-09

Cette méthode permet de revenir à une version précédente si un fichier a été supprimé ou modifié par erreur. Elle est particulièrement utile pour un site WordPress, une application web ou un serveur qui change souvent.

Pour éviter de dupliquer tous les fichiers à chaque sauvegarde, vous pouvez utiliser l’option --link-dest. Elle permet de créer des sauvegardes incrémentales en réutilisant les fichiers inchangés depuis une sauvegarde précédente :

rsync -az \
  --link-dest="/mnt/backups/vps/latest" \
  $SOURCE_DIRS \
  "$DEST_USER@$DEST_HOST:/mnt/backups/vps/$(date +%F)/"

Cette approche demande une organisation plus rigoureuse côté destination, mais elle offre un bon compromis entre historique de restauration et optimisation de l’espace disque. Pour un VPS en production, elle peut compléter efficacement les sauvegardes automatiques LWS et les snapshots ponctuels. Par ailleurs, n’hésitez pas à consulter notre tuto : comment mettre en place une sauvegarde rsync distante pour vos dépôts GitLab.

Tester et vérifier ses sauvegardes

Une sauvegarde non testée ne doit jamais être considérée comme fiable. Le script peut s’exécuter sans afficher d’erreur visible, mais copier des fichiers incomplets, ignorer une base de données ou échouer silencieusement à cause d’un problème de droits. La vérification est donc une étape essentielle de toute stratégie de sauvegarde automatique VPS.

Commencez par exécuter le script manuellement, avant de le confier à cron :

/root/scripts/backup.sh

Consultez ensuite le fichier de log :

tail -n 50 /var/log/backup-rsync.log

Vous devez y retrouver un message indiquant que la sauvegarde est terminée avec succès. Vérifiez ensuite que les fichiers sont bien présents sur le serveur de destination :

ls -lh /mnt/backups/vps/

Pour aller plus loin, restaurez un fichier simple depuis la sauvegarde vers un dossier temporaire. Par exemple, copiez un fichier de test depuis la destination, puis comparez-le avec la version source. Cette vérification permet de confirmer que la sauvegarde n’est pas seulement présente, mais aussi exploitable.

Pour les bases MySQL/MariaDB, vérifiez que le dump SQL compressé est lisible :

gunzip -c all_databases_YYYY-MM-DD.sql.gz | head -20

Cette commande affiche les premières lignes du fichier SQL sans le décompresser définitivement. Si le fichier est corrompu, vide ou illisible, vous le verrez immédiatement.

Contrôlez aussi la taille des sauvegardes après quelques jours :

du -sh /mnt/backups/vps/

Cette commande permet d’anticiper une saturation du stockage distant. Une croissance anormale peut indiquer que certains dossiers inutiles sont sauvegardés, comme des caches, des fichiers temporaires ou des logs volumineux.

Après la première exécution automatique, vérifiez les traces cron :

grep CRON /var/log/syslog | tail -20

Les critères objectifs de réussite sont simples : le fichier /var/log/backup-rsync.log affiche un succès, les fichiers distants ont un timestamp récent, le dump SQL a une taille cohérente et une restauration de test fonctionne sans erreur. Ce dernier point est le plus important : savoir restaurer rapidement est aussi essentiel que savoir sauvegarder.

Erreurs fréquentes et cas de blocage

Même avec un script bien préparé, certaines erreurs peuvent apparaître lors de la mise en place d’un cron backup VPS. La plupart viennent d’un problème de droits, de chemin, de clé SSH ou de mauvaise compréhension du fonctionnement de rsync. Voici les cas les plus courants.

L’erreur la plus dangereuse reste une mauvaise utilisation de --delete. Cette option est utile pour garder une destination propre, mais elle peut supprimer des fichiers valides si la source est mal définie. Pour un premier test, utilisez toujours :

rsync -azv --dry-run source/ destination/

Le mode --dry-run affiche ce que rsync ferait, sans copier ni supprimer de fichiers. C’est une étape simple, mais très utile pour éviter une suppression involontaire.

Autre point fréquent : cron n’utilise pas toujours le même environnement que votre session SSH. Une commande qui fonctionne manuellement peut échouer en tâche planifiée si elle dépend d’un chemin non défini, d’une variable d’environnement ou d’un binaire introuvable. Dans un script automatisé, privilégiez donc les chemins absolus, les logs détaillés et les tests manuels avant activation.

Bonnes pratiques à suivre

Une bonne stratégie de sauvegarde VPS Linux ne se limite pas à un script fonctionnel. Elle doit aussi tenir compte de la sécurité, de la fréquence des sauvegardes, de la restauration et du risque de compromission.

La première règle est de ne jamais stocker vos seules sauvegardes sur le même VPS que la source. En cas de panne, de suppression accidentelle ou d’intrusion, vous pourriez perdre à la fois les données de production et les copies de secours. Une sauvegarde distante vers un second serveur, un NAS ou un espace de stockage séparé apporte une protection beaucoup plus solide.

Pour les données sensibles, pensez aussi au chiffrement avant transfert. Par exemple, un dump SQL peut contenir des informations clients, des emails, des mots de passe hachés ou des données de commande. Vous pouvez chiffrer une archive avec gpg :

gpg --symmetric fichier.sql.gz

Il est également recommandé de recevoir une alerte en cas d’échec. Avec cron, vous pouvez ajouter une adresse email en haut de la crontab :

MAILTO=votre@email.fr

Documentez aussi votre plan de restauration. Notez où se trouvent les sauvegardes, comment restaurer un fichier, comment réimporter un dump SQL et dans quel ordre redémarrer les services. Le jour d’un incident, cette documentation vous évitera de perdre du temps.

Avant toute intervention majeure, comme une mise à jour système, une modification de configuration critique ou une migration, créez un snapshot LWS depuis le panel. Pour un serveur de production, combinez ce snapshot avec une sauvegarde distante récente. Vous pouvez également sécuriser votre VPS avant de mettre en place votre stratégie de sauvegarde en renforçant l’accès SSH, le pare-feu et les services exposés.

Pour les utilisateurs avancés, il peut être intéressant d’automatiser l’analyse de vos scripts de sauvegarde avec Claude Code, notamment pour détecter des erreurs de logique, des chemins dangereux ou des variables mal définies. Enfin, pour un serveur critique, pensez à conserver les sauvegardes automatiques LWS au-delà de la période incluse si votre offre le permet, afin de disposer d’un filet de sécurité supplémentaire côté infrastructure.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Vérification du bon fonctionnement : checklist finale

Avant de considérer votre sauvegarde automatique VPS comme opérationnelle, prenez le temps de valider chaque point de contrôle. Cette checklist permet de confirmer que le script fonctionne, que cron l’exécute correctement et que vos données peuvent réellement être restaurées.

• Le script rsync a été exécuté manuellement sans erreur.
• La tâche cron est visible avec la commande crontab -l.
• Le fichier /var/log/backup-rsync.log indique une sauvegarde réussie.
• Les fichiers sauvegardés sont présents et lisibles sur la destination distante.
• Le dump MySQL/MariaDB est généré, compressé et lisible.
• Une restauration de test a été effectuée avec succès.
• La rotation des anciennes sauvegardes est active.
• Un snapshot LWS Panel a été créé avant une opération sensible.
• Le plan de restauration est documenté et compréhensible.

Cette vérification doit être répétée régulièrement, surtout après une migration, une mise à jour système ou une modification du script.

FAQ

Quelle est la différence entre un snapshot et une sauvegarde sur VPS LWS ?

Un snapshot est une image temporaire de l’état du VPS à un instant précis. Il est utile avant une opération risquée, comme une mise à jour système ou une modification de configuration. Une sauvegarde, elle, sert à conserver une copie exploitable des données pour une restauration ultérieure. Sur un VPS, les deux sont complémentaires : le snapshot facilite un retour rapide en arrière, tandis qu’une sauvegarde distante permet une meilleure protection dans le temps.

Les sauvegardes automatiques LWS sont-elles suffisantes pour protéger mon VPS ?

Les sauvegardes automatiques LWS constituent un filet de sécurité important côté infrastructure, mais elles ne remplacent pas une stratégie complète. Pour un serveur de production, il est recommandé d’ajouter une sauvegarde rsync distante, des exports MySQL/MariaDB réguliers et des tests de restauration. Cela permet de mieux maîtriser les fichiers sauvegardés, la fréquence, la rétention et la restauration.

Comment automatiser rsync sans entrer de mot de passe ?

Pour automatiser rsync avec cron, il faut configurer une authentification SSH par clé entre le VPS source et le serveur de destination. Le script utilise ensuite cette clé privée pour se connecter sans mot de passe interactif. Cette méthode est indispensable pour exécuter une sauvegarde automatiquement, par exemple chaque nuit, sans intervention humaine.

Combien de temps sont conservées les sauvegardes automatiques LWS ?

La durée de conservation dépend de l’offre VPS et des options activées. D’après le brief, les sauvegardes automatiques des VPS KVM LWS sont incluses pendant 30 jours, avec possibilité de renouvellement au-delà selon les conditions de l’offre. Ce point doit toujours être vérifié depuis la page de l’offre ou le LWS Panel, car les modalités peuvent évoluer.

Que se passe-t-il si mon VPS est compromis : les sauvegardes sont-elles protégées ?

Si les sauvegardes sont stockées uniquement sur le même VPS, elles peuvent être supprimées ou altérées en cas de compromission. C’est pourquoi il est essentiel de prévoir une copie distante, idéalement sur un autre serveur ou un espace de stockage séparé. Pour les données sensibles, le chiffrement avant transfert ajoute une protection supplémentaire.

rsync sauvegarde-t-il les bases de données MySQL ?

rsync peut copier des fichiers, mais il ne garantit pas une sauvegarde cohérente d’une base MySQL/MariaDB active. Il faut d’abord générer un dump SQL avec mysqldump, puis sauvegarder ce fichier avec rsync. Cette méthode permet d’obtenir une copie restaurable des bases de données.

Conclusion

Mettre en place une sauvegarde automatique VPS demande un peu de méthode, mais c’est l’une des meilleures protections contre la perte de données. ✨En combinant rsync, cron, les exports MySQL/MariaDB, les snapshots LWS et les sauvegardes automatiques de l’hébergeur, vous construisez une stratégie solide et réaliste. ⚡Le plus important n’est pas seulement de sauvegarder, mais de vérifier régulièrement que vos fichiers, vos bases et vos configurations peuvent être restaurés. ☑Pour un serveur en production, cette approche hybride permet de limiter les interruptions, de réagir plus vite en cas d’incident et de garder le contrôle sur vos données. Pour héberger vos projets avec un socle sécurisé, vous pouvez vous appuyer sur un VPS KVM LWS avec sauvegardes automatiques incluses.💯

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Avez-vous des questions, des ajouts ou des suggestions sur la facon de créer des sauvegardes automatiques sur votre VPS ? N’hésitez pas à nous contacter depuis la section Commentaires.