Snapshots et sauvegardes

Cette page s’adresse à toute personne qui administre un VPS CloudFive et qui veut pouvoir revenir en arrière : avant une mise à jour majeure, avant de toucher à la configuration du serveur web, ou simplement pour ne pas perdre des mois de travail. Elle explique la différence entre un snapshot et une sauvegarde, et comment mettre les deux en place.

Un VPS vous donne un accès root complet. Vous en êtes donc aussi l’administrateur : CloudFive héberge la machine, lui fournit son réseau et la protège des attaques, mais le contenu du disque relève de vous. C’est la différence principale avec un serveur de jeu, où le panel propose ses propres sauvegardes (voir le guide), et avec l’hébergement web (voir le guide).

Snapshot ou sauvegarde : que choisir

Les deux mots sont souvent employés l’un pour l’autre. Ce ne sont pas les mêmes outils, et ils ne protègent pas des mêmes accidents.

	Snapshot	Sauvegarde
Ce que c’est	une photo de l’état de la machine à un instant donné	une copie de vos données rangée ailleurs
Vitesse	quasi immédiat à créer, rapide à restaurer	long à créer, long à restaurer
Granularité	tout ou rien : vous revenez à l’instant T	fichier par fichier, base par base
Protège de	une manipulation qui a mal tourné	une perte du serveur, une suppression ancienne, un piratage
Ne protège pas de	la perte de la machine elle-même	une erreur faite juste après la dernière copie
Durée de vie utile	quelques heures à quelques jours	plusieurs semaines, plusieurs versions

La règle tient en une phrase : le snapshot est un filet pour les trente prochaines minutes, la sauvegarde est votre assurance.

Attention

Un snapshot stocké sur la même infrastructure que votre VPS n’est pas une sauvegarde. Si vous n’avez qu’une seule copie de vos données, et qu’elle se trouve au même endroit que l’original, vous n’avez pas de sauvegarde. Gardez au moins une copie en dehors de votre VPS.

Créer un snapshot avant une opération risquée

Le réflexe à prendre : avant une montée de version de distribution, un changement de version de PHP, une migration de base de données ou une modification du pare-feu, figez l’état de la machine.

1. Notez par écrit ce que vous allez modifier, et comment vous saurez que ça a marché. Un snapshot ne sert à rien si vous ne savez plus quel était l’état correct.

2. Arrêtez proprement les services qui écrivent des données, en particulier les bases. Un snapshot pris pendant une écriture peut contenir une base incohérente.

   systemctl stop mariadb

3. Créez le snapshot depuis la fiche de votre service dans l’espace client, dans la section qui liste les actions disponibles sur le VPS (comment la retrouver). Donnez-lui un nom qui dit la date et la raison, par exemple avant-maj-php-2026-11-09.

4. Relancez vos services, puis faites votre modification.

   systemctl start mariadb

5. Vérifiez que tout fonctionne. Si oui, supprimez le snapshot : un snapshot qu’on garde « au cas où » occupe du stockage et finit par poser plus de problèmes qu’il n’en résout.

Note

La disponibilité des snapshots en libre-service, leur nombre et leur durée de conservation dépendent de votre offre et de la technologie employée : les VPS NVMe reposent sur des conteneurs LXC, les VPS KVM sur de la virtualisation complète. Si vous ne trouvez pas l’action sur la fiche de votre service, demandez un snapshot par ticket avant l’opération, pas après.

Restaurer un snapshot

Restaurer, c’est revenir à l’instant de la prise. Tout ce qui a été écrit depuis disparaît : commandes passées, fichiers déposés, commandes enregistrées par vos utilisateurs, emails reçus.

1. Mesurez d’abord ce que vous allez perdre. Si des données utiles sont arrivées depuis le snapshot, copiez-les hors du VPS tant qu’il est encore accessible.

2. Arrêtez les services pour ne pas restaurer par-dessus une machine en train d’écrire.

3. Lancez la restauration depuis la fiche du service, en vérifiant la date du snapshot sélectionné. Deux snapshots mal nommés se ressemblent beaucoup.

4. Attendez la fin de l’opération sans redémarrer la machine entre-temps.

5. Reconnectez-vous en SSH et vérifiez dans l’ordre : les services actifs (systemctl --failed), l’espace disque (df -h), et le fonctionnement réel de votre application.

Danger

Une restauration est irréversible : l’état actuel du disque est remplacé. Si vous hésitez entre « restaurer » et « réparer », tentez d’abord la réparation, console à l’appui. On peut toujours restaurer après ; on ne peut pas dé-restaurer.

Automatiser ses sauvegardes

Une sauvegarde qu’il faut penser à lancer n’est pas lancée. Voici un script minimal qui sauvegarde les bases, les fichiers et la configuration, puis les envoie sur une autre machine.

/usr/local/bin/sauvegarde.sh

#!/bin/sh
set -eu
DATE=$(date +%F)
DEST=/var/backups/cloudfive
mkdir -p "$DEST"

# Bases MySQL / MariaDB, à chaud et cohérentes
mysqldump --all-databases --single-transaction | gzip > "$DEST/bases-$DATE.sql.gz"

# Fichiers du site, comptes et configuration système
tar -czf "$DEST/fichiers-$DATE.tar.gz" /etc /var/www /home

# Copie vers une machine extérieure au VPS
rsync -az --delete "$DEST/" sauvegarde@203.0.113.20:/srv/vps-exemple/

# Rotation locale : on ne garde pas plus de 14 jours sur le VPS
find "$DEST" -type f -mtime +14 -delete

Rendez-le exécutable, puis programmez-le :

chmod 700 /usr/local/bin/sauvegarde.sh
crontab -e

crontab de root

20 3 * * * /usr/local/bin/sauvegarde.sh >> /var/log/sauvegarde.log 2>&1

Quelques points qui font la différence entre un script qui tourne et un script qui protège :

• Les identifiants MySQL vont dans /root/.my.cnf avec les droits 600, pas dans la ligne de commande. Voir aussi Bases de données MySQL pour la logique des accès.
• La destination doit être ailleurs. Un autre VPS, un NAS chez vous, un espace de stockage externe. Une copie dans /var/backups ne survit pas à la perte du disque.
• Chiffrez si les données sont sensibles. Des outils comme restic ou borg font l’incrémental et le chiffrement, pour un coût d’apprentissage d’une soirée.
• Surveillez le journal. Un cron silencieux qui échoue depuis trois mois est le scénario classique. Voir Surveiller les ressources pour poser une alerte simple.

Testez la restauration, pas la sauvegarde

Une sauvegarde n’existe vraiment que le jour où vous avez réussi à en extraire un fichier. Une fois par trimestre, prenez une archive au hasard et restaurez-la ailleurs, dans un répertoire temporaire. C’est dix minutes qui changent la nature de votre sauvegarde.

Limites et durée de conservation

Trois choses à garder en tête :

1. Un snapshot occupe du stockage. Le disque de votre VPS est celui de votre palier — 64 Go sur un VPS Start, 200 Go sur un VPS Ultra, voir la page de l’offre. Empiler les snapshots sur un disque presque plein mène à un VPS qui ne démarre plus.
2. Un snapshot n’est pas une archive. Il n’est pas prévu pour retrouver un fichier supprimé il y a six semaines. Cela, c’est le travail des sauvegardes versionnées.
3. Le nombre de snapshots et leur conservation dépendent de votre offre. Nous ne publions pas de durée garantie ici : fiez-vous à ce qu’affiche la fiche de votre service, ou posez la question par ticket. Ne construisez pas votre plan de reprise sur une hypothèse.

Si votre plan de sauvegarde commence à peser sur les ressources du VPS, c’est souvent le signe que la machine est juste dimensionnée : voyez Changer de formule et VPS ou serveur dédié.

Si ça ne marche pas

L’action de snapshot n’apparaît pas sur la fiche du service. Elle dépend de l’offre. Ouvrez un ticket en indiquant l’identifiant du service et l’opération que vous préparez : c’est plus rapide que de chercher, et le support peut la prendre pour vous.

Le snapshot échoue avec une erreur d’espace. Le disque est trop plein pour figer son état. Faites de la place d’abord : df -h pour voir, journalctl --vacuum-size=200M et le nettoyage du cache de paquets libèrent souvent plusieurs gigaoctets. La méthode complète est dans Surveiller les ressources.

Après restauration, un service refuse de démarrer. Regardez son journal avec journalctl -u nom-du-service -n 50. Le cas classique est une base restaurée dans un état incohérent parce que le snapshot a été pris machine allumée, sans arrêt des services. Restaurez alors le dernier export mysqldump par-dessus.

Le serveur ne répond plus après l’opération. Passez par la console, qui fonctionne même sans SSH, puis suivez Dépannage : mon VPS est inaccessible.

Vous n’avez ni snapshot ni sauvegarde et les données ont disparu. Arrêtez toute écriture sur le disque immédiatement et ouvrez un ticket en décrivant précisément ce qui s’est passé et à quelle heure. Les chances dépendent du cas, mais elles diminuent à chaque minute d’écriture supplémentaire.