HDFS backup and restore avec des exemples pratiques : guide d'implémentation

Introduction

HDFS backup and restore with practical examples est indispensable, car démarrer des conteneurs de production est simple, mais les exploiter avec fiabilité l'est beaucoup moins. Un guide utile indique quoi configurer, quelle commande prouve que la configuration fonctionne, et à quoi ressemble l'échec quand le montage est incomplet.

Ce guide s'adresse aux développeurs, consultants DevOps et équipes techniques de startups. Il relie HDFS backup à HDFS restore, HDFS disaster recovery, HDFS rollback et HDFS validation pour passer de l'idée à la vérification locale. L'objectif est pratique : comprendre les pièces mobiles, les tester localement et éviter les surprises lors du passage en CI/CD ou en environnement proche de la production.

Vue d'ensemble du workflow

Pour HDFS backup, adoptez une boucle courte :

• Identifier la ressource visée (répertoire de données, métadonnées NameNode...).
• Décrire le changement de configuration (activer snapshot, paramètre de réplication...).
• Écrire la commande de preuve (ls, fsck, checksum, distcp...).
• Définir la sortie attendue et le signal d'échec (erreur d'autorisations, quotas, réseau...).

En pratique, c'est ici que surgissent les hypothèses cachées : chemins locaux, tags d'images, noms de réseaux, fichiers d'environnement, limites de ressources, permissions Linux. Ces hypothèses varient entre laptops, runners CI et hôtes de production. Énoncez-les explicitement avant de vous appuyer sur la configuration.

Les concepts clés sont HDFS backup, HDFS restore, HDFS disaster recovery, HDFS rollback et HDFS validation. Les domaines connexes comme Apache Spark, NiFi et Kafka comptent, car le comportement des conteneurs et des pipelines n'est jamais isolé : le stockage influence le déploiement, le débogage, la sauvegarde et les décisions de rollback.

Vérification pratique de la vue d'ensemble :

• Entrée : répertoire cible, politique de snapshot, destination de sauvegarde.
• Action : commande de snapshot ou distcp.
• Sortie attendue : snapshot listé, copie distante complète.
• Signal d'échec : "Operation not permitted", échec réseau, quotas dépassés, permissions manquantes.

Plan pilote local

Un test local doit être reproductible depuis un checkout propre, avec commandes et hypothèses consignées près des fichiers de configuration.

Pré-requis réalistes :

• Un cluster HDFS de test (nœud unique accepté) sur Linux.
• Accès superutilisateur HDFS pour activer les snapshots.
• Un répertoire critique d'exemple : /data/critical.
• Une destination de sauvegarde : un second cluster HDFS ou un chemin local (file:///backups) pour des tests.

Checklist avant de modifier l'environnement :

• Entrée attendue : exemple de données sous /data/critical.
• Commande : snapshot + distcp/copyToLocal.
• Sortie : snapshot visible, copie complète avec permissions.
• Échec : message explicite, journaux consultables, état réversible.

Exemples pratiques

1) Sauvegarde d'un répertoire via snapshots et DistCp

But : obtenir une sauvegarde cohérente et incrémentale d'un répertoire.

Étapes :

1. Rendre le répertoire éligible aux snapshots (une fois) :

hdfs dfsadmin -allowSnapshot /data/critical

1. Créer un snapshot nommé s1 :

hdfs dfs -createSnapshot /data/critical s1
hdfs dfs -ls /data/critical/.snapshot

1. Copier vers un cluster de sauvegarde (ou une autre instance) avec preservation des attributs :

hadoop distcp -p -update hdfs:///data/critical hdfs://backup-nn:8020/backups/critical

Alternative locale pour un test rapide :

hdfs dfs -copyToLocal -p /data/critical /backups/critical

1. Preuve de fonctionnement :

hdfs dfs -count -q /data/critical
hdfs fsck /data/critical -files -blocks -locations

1. Signaux d'échec typiques : "snapshot feature is not enabled", "permission denied", timeout réseau DistCp, espace disque insuffisant.

Astuce : créez un second snapshot s2 plus tard et utilisez les options incrémentales de DistCp avec listes ou comparez les diffs pour limiter le volume transféré.

2) Sauvegarde des métadonnées NameNode (fsimage et edits)

But : pouvoir reconstruire l'état du namespace.

Étapes exécutées sur l'hôte NameNode :

1. (Optionnel) Forcer un roll des journaux d'édition :

hdfs dfsadmin -rollEdits

1. Récupérer l'image du namespace :

hdfs dfsadmin -fetchImage /var/backups/hdfs/fsimage_$(date +%F)

1. (Optionnel) Convertir un fichier d'édition pour inspection offline :

hdfs oev -i /path/to/edits_current -o /var/backups/hdfs/edits.json -p json

1. Preuve : vérifier taille non nulle des artefacts et horodatage.

Signaux d'échec : permissions système insuffisantes, chemin local invalide, service NameNode inaccessible.

3) Restauration de fichiers à partir d'un snapshot

But : retourner rapidement à un état antérieur au niveau d'un répertoire.

Deux options :

• Restauration in-place (tous les fichiers du répertoire) :

hdfs dfs -restoreSnapshot /data/critical s1

• Restauration sélective (quelques fichiers) :

hdfs dfs -cp -ptopax \
  /data/critical/.snapshot/s1/sousrep/monfichier.parquet \
  /data/critical/sousrep/

Preuve : hdfs dfs -ls sur les chemins concernés, puis hdfs dfs -checksum sur les fichiers sensibles.

4) Restauration vers le cluster principal avec DistCp

But : réhydrater un cluster principal depuis la sauvegarde HDFS.

hadoop distcp -p -update -delete \
  hdfs://backup-nn:8020/backups/critical \
  hdfs:///data/critical

• -p préserve les attributs.
• -update copie uniquement les différences.
• -delete supprime côté destination ce qui n'existe pas côté source (à manier avec prudence, testez d'abord sans cette option).

Preuve : comparaisons hdfs dfs -count et hdfs fsck, contrôle d'un échantillon de checksums.

5) Restauration NameNode à partir d'un fsimage

But : redémarrer le namespace sur un nouveau nœud après incident.

Étapes génériques (sur environnement de test d'abord) :

1. Arrêter le NameNode.
2. Sauvegarder le contenu actuel des répertoires de métadonnées.
3. Remplacer fsimage (et, si nécessaire, edits) par les artefacts sauvegardés.
4. Redémarrer le NameNode et surveiller les journaux.
5. Valider :

hdfs fsck / -files -blocks -locations
hdfs dfs -ls /

Signaux d'échec : incompatibilités de version, fichiers manquants, corruption signalée par fsck.

Validation, rollback et disaster recovery

HDFS validation

Couvrir l'intégrité, les attributs et la visibilité applicative :

• Inventaire :

hdfs dfs -count -q -h /data/critical

• Intégrité des blocs :

hdfs fsck /data/critical -files -blocks -locations

• Checksums d'un échantillon :

hdfs dfs -checksum /data/critical/chemin/vers/fichier

• Permissions et propriétaires :

hdfs dfs -getfacl /data/critical | head -n 20
hdfs dfs -ls -R /data/critical | awk '{print $1,$3,$4}' | sort | uniq -c

• Comportement applicatif : exécuter une lecture Apache Spark, vérifier un flux NiFi ou une ingestion Kafka qui dépend du répertoire restauré.

Critères d'acceptation : comptages identiques, erreurs fsck absentes, checksums inchangés, permissions cohérentes, jobs applicatifs lisent sans erreur.

Plan de HDFS rollback

• Conserver au moins deux snapshots récents (sN-1, sN).
• Mesurer l'écart :

hdfs dfs -snapshotDiff /data/critical sN-1 sN

• Restauration complète :

hdfs dfs -restoreSnapshot /data/critical sN-1

• Restauration sélective : copier depuis .snapshot/sN-1 uniquement les fichiers fautifs.
• Documenter l'état attendu : propriétaires, groupes, permissions, réplication.

Schéma HDFS disaster recovery (inter-clusters)

• Stratégie : snapshots cohérents côté primaire, puis hadoop distcp -p -update vers un cluster de secours.
• Fenêtre de transfert : planifier pour limiter les conflits avec les écritures (Spark, NiFi).
• Objectif : RPO réduit via snapshots fréquents, RTO maîtrisé grâce à des procédures de restauration répétées en exercice.
• Validation DR : répéter régulièrement une restauration complète sur un environnement dédié, exécuter la checklist HDFS validation et comparer aux attentes.

Erreurs courantes et corrections

• Snapshots non activés : activer avec hdfs dfsadmin -allowSnapshot et auditer les répertoires critiques.
• Permissions non préservées : utiliser distcp -p ou -ptopax selon le besoin.
• Sauvegarde en pleine écriture : coordonner avec les producteurs (Spark, NiFi, Kafka) pour réduire les fichiers partiels.
• Aucune preuve post-backup : institutionnaliser hdfs fsck, -count, -checksum après chaque exécution.
• Confusion des chemins et noms de clusters : centraliser les variables d'environnement, documenter fs.defaultFS et les alias.
• Oublier la réplication des blocs : vérifier le facteur de réplication et corriger si nécessaire.
• Ne pas tester la restauration : ajouter un exercice mensuel de restore et de rollback dans le calendrier de l'équipe.

Conclusion

HDFS backup and restore with practical examples fonctionne mieux quand la configuration est testée, pas seulement copiée. Démarrez petit, exécutez les commandes localement et confirmez le comportement attendu avant d'ajouter d'autres services ou de l'automatisation. Pour la suite, choisissez un service et consignez les commandes exactes pour le construire, l'exécuter, l'inspecter, l'arrêter et le recréer. Comparez ensuite le résultat aux besoins connexes (Apache Spark, NiFi, Kafka) afin que la mise en œuvre serve le modèle opérationnel global. Un workflow fiable rend l'échec visible : journaux accessibles, données persistantes survivant aux reconstructions de conteneurs, et un comportement local suffisamment proche de la production pour détecter tôt les erreurs.