Sauvegarde VPS Ubuntu : vérifier une restauration
Une sauvegarde doit pouvoir être récupérée hors du VPS puis restaurée avec les fichiers attendus. Cet exercice archive une page statique et une configuration Nginx, les copie vers un autre ordinateur et vérifie leurs octets dans un dossier vide. Il ne modifie pas le site en fonctionnement.
Dans ce guide
Définir le périmètre de l’exercice
Utilisez Bash, GNU tar, sha256sum et OpenSSH sur Ubuntu ou un client Linux/WSL. Gardez un terminal serveur et un terminal sur l’autre ordinateur ouverts pour conserver leurs variables. Arrêtez-vous à toute erreur de commande.
Les deux fichiers de test se trouvent dans votre répertoire personnel. Aucune configuration Nginx, règle réseau ou donnée publiée n’est remplacée. L’extraction ne s’exécute pas comme root. Un site complet peut nécessiter d’autres ressources : fichiers, redirections, DNS, certificats et dépendances.
Préparer deux fichiers sans toucher au site
Sur le serveur, créez le dossier privé et les exemples. La configuration Nginx est ici un texte à archiver, pas un service à activer.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="fr"><title>Exercice de restauration</title><h1>Page statique restaurée</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Dossier de test : %s\n' "$backup_lab"Option facultative : pour copier les deux vrais fichiers du déploiement statique, utilisez le bloc suivant seulement si les sources sont lisibles et connues. Inspectez la configuration pour les secrets et suspendez les déploiements pendant la collecte. Ignorez ce bloc si vous gardez les fichiers fictifs.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"Seules les copies jetables sont remplacées ; les sources restent inchangées. Les clés privées TLS et les répertoires système ne sont pas copiés. Ajoutez tout fichier supplémentaire à l’inventaire et au manifeste de contrôle.
Créer l’archive et les deux contrôles
Toujours sur le serveur, gardez les fichiers stables, créez le manifeste de leurs empreintes puis l’archive à chemins relatifs et son empreinte propre.
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Dossier à exporter : %s\n' "$backup_lab/export"La liste doit contenir site/, nginx/, les deux fichiers et SHA256SUMS. Le contrôle externe détecte une modification de l’archive transférée ; le manifeste interne vérifie les fichiers extraits. Si quelqu’un peut remplacer données et empreinte attendue, ces sommes seules ne prouvent pas l’authenticité.
Copier vers un ordinateur distinct
Dans le terminal client, remplacez remote_backup par le chemin exporté affiché sur le serveur. REPLACE est un repère à remplacer, pas le suffixe créé par mktemp. Adaptez compte, clé et adresse documentaire 203.0.113.10.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"Vérifiez la clé d’hôte avant toute première connexion. Si SCP échoue à cause de SSH, utilisez le diagnostic d’accès ; ne désactivez pas le contrôle d’identité.
SCP protège le transport par SSH. L’archive tar.gz est compressée, pas chiffrée : protégez le compte et le stockage de destination, et chiffrez au repos si les données le demandent. Un deuxième dossier sur le même VPS n’est pas une copie indépendante.
Vérifier avant d’extraire dans un dossier neuf
Sur le client, contrôlez l’archive et sa liste. Continuez uniquement après le résultat OK et avec les chemins relatifs attendus. N’écrasez pas l’empreinte de référence pour faire passer une erreur.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Extrayez cette archive de confiance dans un nouveau dossier. keep-old-files refuse d’écraser un fichier existant ; no-same-owner évite de reprendre le propriétaire archivé. Ne remplacez jamais la destination par / et n’utilisez pas sudo pour extraire.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"Vous devez obtenir OK pour les deux fichiers et retrouver le titre de la page. Cela valide les octets sélectionnés, pas les ACL, propriétaires de production, services ou dépendances absentes de l’archive.
Séparer récupération de fichiers et retour du service
La configuration restaurée reste inactive. Sur une machine de remplacement séparée, vérifiez chemins, inclusions, modules, permissions et certificats. Validez la configuration assemblée avant rechargement puis HTTP/HTTPS depuis l’extérieur. Tester la syntaxe du serveur d’origine ne valide pas cette copie.
L’archive exclut les clés TLS. Prévoyez une réémission des certificats ou une sauvegarde protégée distincte. Ne copiez pas une base active avec cette recette tar : utilisez sa méthode de sauvegarde cohérente et de restauration.
Les snapshots peuvent aider, mais vérifiez rétention, domaine de panne et procédure. Leur présence ne démontre pas qu’un site exporté peut être remis en service ailleurs.
Noter les objectifs et le résultat réel
Le RPO décrit la perte de données acceptable en durée ; le RTO vise le délai de remise en service. Pour un petit site statique, 24 heures de RPO et 60 minutes de RTO sont des exemples d’objectifs, pas des résultats mesurés ici.
Faites défiler le tableau pour voir toutes les colonnes →
| Élément noté | Ce qu’il permet de vérifier |
|---|---|
| Heure et version sauvegardées | État récupérable |
| Destination indépendante et rétention | Où et combien de temps la copie survit |
| Contrôles archive et fichiers | Conformité des octets sélectionnés |
| Début et fin de restauration | Durée des étapes définies |
| Éléments manquants | Travail restant pour revenir en service |
| Contrôle HTTPS du remplacement | Retour effectif du site |
Mesurez tout le remplacement avant d’annoncer un RTO : accès, provisionnement, configuration, certificats et éventuellement DNS. Une extraction locale rapide ne constitue pas un benchmark de récupération après panne. Gardez plusieurs points de restauration adaptés et surveillez les tâches échouées.
Questions et réponses
Dois-je supprimer l’original pour tester ?
Non. Un dossier séparé et le manifeste vérifient la copie sans provoquer d’interruption. Testez le service complet sur un environnement de remplacement.
Une somme correcte signifie-t-elle que tout est sauvegardé ?
Elle confirme uniquement les fichiers du manifeste. Elle ne découvre pas un fichier, une base, un secret ou un réglage DNS oublié.
Puis-je employer cette archive pour une base de données ?
Pas comme méthode de sauvegarde d’une base active. Utilisez les outils de sauvegarde cohérente et de restauration documentés pour votre base.