Bash Backup and Restore : commandes pratiques et exemples réels

Bash est le cheval de bataille de l'administration système, et savoir comment sauvegarder et restaurer des données avec Bash est une compétence critique pour les développeurs, les ingénieurs DevOps et les équipes techniques. Ce guide va au-delà des concepts théoriques pour entrer dans des commandes concrètes et actionnables. Nous nous concentrerons sur des scénarios pratiques : sauvegarder des fichiers de configuration, des données d'application et des répertoires entiers, puis les restaurer proprement.

L'objectif est la sécurité opérationnelle. Nous verrons comment observer avant de modifier quoi que ce soit, comment limiter le rayon d'impact de toute opération, comment utiliser des espaces réservés au lieu de vrais secrets, comment vérifier vos sauvegardes et restaurations, et comment documenter les étapes de récupération. À la fin, vous disposerez d'une boîte à outils solide pour gérer les sauvegardes et restaurations Bash avec confiance.

Inventaire des versions et de l'environnement

Avant d'écrire une seule commande de sauvegarde, vous devez savoir exactement avec quoi vous travaillez. C'est la phase d'« inventaire des versions et de l'environnement ».

Identifiez le composant : sauvegardez-vous un fichier de configuration système, un script au niveau utilisateur ou un dump de base de données ? L'approche diffère significativement pour chacun.

Vérifiez la version de Bash : différentes versions de Bash peuvent avoir des fonctionnalités légèrement différentes. Utilisez bash --version pour confirmer. C'est crucial si votre script de sauvegarde repose sur des fonctionnalités plus récentes comme les tableaux associatifs ou les comparaisons .

Vérifiez le système d'exploitation et l'environnement : Linux, macOS ou WSL ? Gestionnaires de paquets ? Emplacements des fichiers ? Par exemple, /etc/ est généralement pour les configurations système, tandis que ~/.config est spécifique à l'utilisateur.

Prérequis : avez-vous les permissions nécessaires ? sudo pour les fichiers système ? Accès en lecture aux données sources ? Accès en écriture à la destination de sauvegarde ? Assurez-vous d'avoir les outils requis — tar, gzip, rsync, cp, etc. — installés.

Observation en lecture seule d'abord : exécutez des commandes qui ne lisent que l'état actuel. Par exemple, listez les fichiers que vous prévoyez de sauvegarder avec ls -la /etc/myapp/. Vérifiez l'espace disque avec df -h. Enregistrez les horodatages avec date.

Protégez les identifiants : ne mettez jamais de vrais mots de passe ou jetons dans vos scripts de sauvegarde ou exemples d'articles. Utilisez des variables d'environnement ou des espaces réservés comme YOUR_BACKUP_DIR.

Chemin de configuration sécurisé

Maintenant que vous avez inventorié votre environnement, il est temps de concevoir un chemin sûr pour effectuer des changements. L'idée centrale : séparer l'observation de l'intervention, et faire le plus petit changement possible.

Étape 1 : Capturer l'état actuel. Avant de modifier quoi que ce soit, créez une sauvegarde de la configuration ou des données que vous êtes sur le point de changer. C'est votre filet de sécurité.

Étape 2 : Faire un seul changement ciblé. Ne réécrivez pas un script entier si vous n'avez besoin de mettre à jour qu'une seule fonction. Changez une petite chose, testez-la, puis passez à la suivante.

Étape 3 : Comprendre le rayon d'impact. Si vous modifiez un fichier de configuration partagé, qui d'autre sera affecté ? Pouvez-vous limiter l'impact ? Par exemple, si vous éditez /etc/nginx/nginx.conf, testez d'abord avec nginx -t.

Étape 4 : Avoir un chemin de récupération. Sachez exactement comment annuler votre changement. Si vous avez une sauvegarde, vous pouvez la restaurer. Si vous utilisez le contrôle de version (comme git), vous pouvez faire git revert ou git checkout.

Voici un exemple pratique. Supposons que vous deviez modifier un fichier de configuration pour une application, disons /etc/myapp/config.ini. Une approche sûre :

# Étape 1 : Créer une sauvegarde horodatée
cp /etc/myapp/config.ini /etc/myapp/config.ini.bak.$(date +%Y%m%d%H%M%S)

# Étape 2 : Éditer le fichier (avec un éditeur de texte ou sed)
sed -i 's/^debug=false/debug=true/' /etc/myapp/config.ini

# Étape 3 : Tester la configuration
# (la commande de test spécifique dépend de l'application)
# myapp --test-config

# Étape 4 : Si le test échoue, restaurer la sauvegarde
cp /etc/myapp/config.ini.bak.$(ls -t /etc/myapp/config.ini.bak.* | head -1) /etc/myapp/config.ini

Ce motif — sauvegarder, changer, tester, restaurer si nécessaire — est le cœur de la gestion de configuration sécurisée.

Vérification et diagnostics

La sauvegarde et la restauration ne sont utiles que si vous vérifiez qu'elles fonctionnent. C'est là qu'interviennent la « vérification et les diagnostics ».

Vérifiez la sauvegarde : après avoir créé une sauvegarde, confirmez qu'elle n'est pas corrompue et qu'elle contient ce que vous attendez. Pour les archives tar, utilisez tar -tzf backup.tar.gz pour lister le contenu. Pour rsync, vérifiez le code de sortie ($?) et utilisez peut-être --dry-run d'abord.

Vérifiez la restauration : c'est critique. N'attendez pas une catastrophe pour tester votre procédure de restauration. Restaurez périodiquement vers un répertoire temporaire ou un serveur de test pour vous assurer que le processus fonctionne.

Vérifiez les données restaurées : après la restauration, exécutez des vérifications pour garantir que les données sont valides. S'il s'agit d'un dump de base de données, restaurez-le vers une base de test et lancez des requêtes. S'il s'agit de configuration, démarrez l'application et voyez si elle lit la configuration restaurée.

Diagnostiquez les échecs : si une sauvegarde ou une restauration échoue, utilisez les messages d'erreur et les codes de sortie pour dépanner. Par exemple, tar sortira avec un code non-zéro en cas de problème. Vérifiez l'erreur spécifique — permission refusée, fichier introuvable, etc.

Regardons un exemple complet : sauvegarder un répertoire avec rsync.

# Créer une sauvegarde avec rsync, incluant un dry-run d'abord
rsync -av --dry-run /path/to/source/ /path/to/backup/

# Si le dry-run semble bon, lancer la vraie sauvegarde
rsync -av /path/to/source/ /path/to/backup/

# Vérifier le code de sortie
if [ $? -eq 0 ]; then
  echo "Sauvegarde réussie"
else
  echo "Sauvegarde échouée"
fi

# Lister le contenu de la sauvegarde pour vérifier
ls -la /path/to/backup/

Pour une sauvegarde tar avec compression gzip :

# Créer une sauvegarde tar.gz
tar -czf backup_$(date +%Y%m%d).tar.gz /path/to/data

# Lister le contenu pour vérifier
tar -tzf backup_$(date +%Y%m%d).tar.gz | head -20

Exemple de restauration :

# Restaurer une sauvegarde tar.gz vers un répertoire cible
tar -xzf backup_20250101.tar.gz -C /path/to/restore/

# Vérifier si la restauration a fonctionné
ls /path/to/restore/path/to/data

Modes de défaillance et récupération

Même avec la meilleure planification, les choses tournent mal. Voici les modes de défaillance courants et comment récupérer.

Défaillance : Le fichier de sauvegarde est corrompu.

Cause : Disque plein, écriture interrompue ou problème matériel.
Récupération : Ayez toujours plusieurs sauvegardes (par exemple, une sur site, une hors site). Testez vos fichiers de sauvegarde périodiquement. Si vous avez une sauvegarde précédente valide, utilisez-la.

Défaillance : La restauration échoue à cause des permissions.

Cause : Vous lancez la restauration sans sudo et le répertoire cible nécessite des privilèges plus élevés.
Récupération : Lancez la restauration avec sudo ou changez la propriété du répertoire cible. Connaissez toujours les bonnes permissions.

Défaillance : L'application ne démarre pas après la restauration de la configuration.

Cause : La configuration restaurée est incompatible avec la version actuelle de l'application ou l'environnement.
Récupération : Consultez les logs de l'application pour les erreurs spécifiques. Comparez la configuration restaurée avec la sauvegarde que vous avez faite avant le changement. Utilisez le contrôle de version si possible pour voir ce qui a changé.

Défaillance : La sauvegarde est incomplète (par exemple, fichiers manquants).

Cause : Le répertoire source a changé pendant la sauvegarde, ou vous avez exclu des fichiers involontairement.
Récupération : Utilisez rsync avec --delete pour garder la sauvegarde synchronisée, ou utilisez tar avec une liste de fichiers. Vérifiez toujours la taille et le nombre de fichiers de la sauvegarde.

Plan de récupération : Documentez un plan de récupération étape par étape pour vos systèmes critiques. Incluez les commandes pour vérifier la sauvegarde, restaurer et vérifier le système. Testez ce plan régulièrement.

Liste de contrôle opérationnelle

Avant, pendant et après toute opération de sauvegarde ou de restauration, utilisez cette liste de contrôle pour garantir votre sécurité.

Avant :

[ ] Identifier le composant et la version (ex. : Bash 5.2, Ubuntu 22.04).
[ ] S'assurer que vous avez les permissions et prérequis nécessaires.
[ ] Enregistrer l'état actuel : date, ls -la, df -h.
[ ] Confirmer que vous avez assez d'espace disque pour la sauvegarde.
[ ] Utiliser un dry-run si disponible (ex. : rsync --dry-run, tar -t).

Pendant :

[ ] Faire un seul changement ciblé ou une seule opération de sauvegarde.
[ ] Surveiller la sortie de la commande et son code de sortie.
[ ] Capturer un horodatage et noter toute erreur.

Après :

[ ] Vérifier la sauvegarde ou la restauration (ex. : lister le contenu, lancer une requête de test).
[ ] Tester l'artefact restauré dans un environnement non-production si possible.
[ ] Documenter ce que vous avez fait et le résultat.
[ ] Mettre à jour votre plan de récupération si quelque chose a changé.

Conclusion

La sauvegarde et la restauration Bash sont des compétences critiques, mais elles ne sont efficaces que lorsqu'elles sont abordées méthodiquement. Ce guide vous a montré comment inventorier votre environnement, faire des changements sécurisés, vérifier vos sauvegardes, gérer les défaillances et suivre une liste de contrôle claire. La différence entre une sauvegarde qui existe et une sauvegarde qui fonctionne, c'est la vérification — testez vos restaurations selon un calendrier, pas pendant une panne.

Passez à l'étape suivante : choisissez une tâche de sauvegarde à faible risque, comme la sauvegarde d'un répertoire de configuration. Appliquez les principes ici — observez d'abord, utilisez une sauvegarde horodatée, vérifiez et documentez vos étapes de récupération. En pratiquant, vous gagnerez la confiance nécessaire pour gérer des scénarios plus complexes comme les dumps de base de données, la synchronisation multi-serveurs et les politiques de rotation automatisées.

Rappelez-vous, un flux de travail fiable rend l'échec visible, protège les données sensibles, limite les changements à la cible visée et définit la vérification de récupération avant qu'un incident ne se produise. Commencez petit, documentez tout, et vous serez prêt pour l'imprévu.