Sauvegarde et restauration HDFS avec des exemples pratiques : guide de référence pour la production

Introduction

Dans un cluster Hadoop en production, beaucoup confondent réplication HDFS et sauvegarde. La réplication HDFS protège contre la perte de blocs dus à des défaillances matérielles locales, mais elle ne vous protège pas contre les risques logiques et opérationnels. Elle ne couvre notamment pas les cas suivants :

• Suppression accidentelle d’un répertoire ou d’un fichier
• Corruption logique ou applicative (ingestion erronée, écriture partielle)
• Ransomware et chiffrement malveillant des données
• Erreurs humaines ou de scripts d’exploitation
• Panne de site ou de datacenter
• Bugs dans les jobs Spark, Hive ou NiFi qui altèrent des données

Une stratégie de continuité d’activité robuste combine réplication, snapshots, sauvegardes, réplication inter-cluster et procédures de reprise après sinistre (DR) avec des objectifs RPO et RTO clairement définis. Ce guide, conçu pour des administrateurs Hadoop, ingénieurs Big Data, équipes DevOps et architectes plateformes, présente une démarche complète et testable en production.

Pour aller plus loin sur l’écosystème, consultez aussi nos ressources Hadoop, HDFS, YARN, Spark, Hive, Kafka, Airflow, NiFi, MinIO, Kubernetes, stockage objet et Data Lake.

Les notions à ne pas confondre

• Réplication HDFS
• Ce que c’est : stockage de chaque bloc avec un facteur de réplication (par défaut 3) sur plusieurs DataNodes.
• Ce que ça couvre : panne disque ou serveur isolé, remplacement d’un DataNode.
• Ce que ça ne couvre pas : suppression, corruption logique, ransomware, panne de site.

• Snapshots HDFS
• Ce que c’est : points figés en lecture seule au niveau d’un répertoire HDFS.
• Atouts : retour arrière rapide, vue cohérente, base d’incrémentaux DistCp.
• Limites : même cluster, pas une copie hors site par défaut.

• Sauvegarde
• Ce que c’est : copie indépendante, durable, idéalement immuable, souvent hors cluster ou hors site.
• Atouts : résistance aux erreurs humaines, ransomware, sinistres.
• Limites : coûts de stockage, bande passante, gestion du cycle de vie.

• Réplication inter-cluster
• Ce que c’est : synchronisation entre deux clusters distincts (ex. via DistCp), potentiellement géographiquement séparés.
• Atouts : base d’un PRA, migration contrôlée, dissociation des environnements.
• Limites : cohérence à orchestrer, coûts réseau, sécurité/kerberos.

• Reprise après sinistre (Disaster Recovery, DR)
• Ce que c’est : ensemble de mécanismes et procédures pour restaurer un service après perte majeure (site, cluster).
• Atouts : RTO maîtrisé, continuité d’activité.
• Limites : complexité, coûts, tests réguliers indispensables.

Architecture HDFS et métadonnées à protéger

Composants clés

• NameNode (actif/standby en HA) : maintient l’espace de noms, les répertoires, fichiers, blocs et emplacements
• DataNode : stocke physiquement les blocs et répond aux lectures/écritures
• JournalNode (QJM, Quorum Journal Manager) : quorum d’écriture des EditLogs en HA
• ZKFC (ZooKeeper Failover Controller) : détecte et orchestre le basculement NN actif/standby

Schéma ASCII simplifié

            +------------------+            +------------------+
            |  NameNode Actif  |<--QJM----->| NameNode Standby |
            |  FSImage/Edits   |            |  Checkpoint      |
            +---------^--------+            +---------^--------+
                      |                             |
                 ZKFC |                             | ZKFC
              +-------+-------+               +-----+-------+
              |   ZooKeeper   |               |  JournalNodes|
              +-------+-------+               +------+-------+
                      |                               |
          +-----------+-------------+      +----------+-------------+
          |         DataNodes       |      |        DataNodes       |
          +-------------------------+      +------------------------+

Métadonnées critiques

• FSImage : image point-in-time de l’espace de noms HDFS
• EditLog : journal des opérations appliquées depuis la dernière FSImage
• Répertoires locaux à sauvegarder sur les NameNodes
• dfs.namenode.name.dir
• dfs.namenode.edits.dir

Note : en HA avec QJM, la Standby réalise des checkpoints réguliers. Vous devez tout de même extraire et sauvegarder ces artefacts de façon indépendante.

Stratégie de sauvegarde HDFS en production

• Viser la règle 3-2-1
• 3 copies des données, 2 supports différents, 1 copie hors site/immuable
• Définir les objectifs RPO et RTO réalistes en fonction des SLA métiers
• Séparer clairement
• Sauvegarde de métadonnées (NameNode)
• Sauvegarde des données utilisateur
• Combiner snapshots HDFS + DistCp pour des incrémentaux efficaces
• Externaliser vers stockage objet (S3/MinIO/Azure Blob/GCS) ou NAS/NFS
• Appliquer chiffrement au repos et en transit, contrôle d’accès fort (Kerberos, Ranger)
• Tester régulièrement les restaurations et documenter des procédures pas à pas

Tableaux comparatifs

Réplication vs sauvegarde

Snapshots vs DistCp

Sauvegarde locale vs distante

Complète vs incrémentale

Stockage HDFS vs stockage objet

PRA chaud vs PRA froid

Procédures détaillées et exemples

1) Snapshots HDFS pour cohérence et rollback

Fonctionnement

• Activation par répertoire, points en lecture seule

Avantages

• Cohérence, rollback rapide, base d’incrémentaux

Limites

• Même cluster, consommation d’inodes/blocs si nombreuses modifications

Cas d’usage

• Protection contre suppression accidentelle, base DistCp incrémentale

Exemples

# Activer les snapshots sur un répertoire critique
hdfs dfsadmin -allowSnapshot /data/critical

# Créer un snapshot s1
hdfs dfs -createSnapshot /data/critical s1

# Lister les snapshots
hdfs dfs -ls /data/critical/.snapshot

# Diff entre deux snapshots
hdfs dfs -snapshotDiff /data/critical s1 s2

Tester la restauration

# Restauration complète à partir de s1
hdfs dfs -restoreSnapshot /data/critical s1

# Restauration sélective
hdfs dfs -cp -ptopax \
  /data/critical/.snapshot/s1/sousrep/f.parquet \
  /data/critical/sousrep/

2) Sauvegarde des métadonnées NameNode (FSImage/EditLog)

Fonctionnement

• Extraire FSImage et EditLogs pour reconstruire l’espace de noms

Avantages

• Restauration du NameNode après corruption/perte

Limites

• Nécessite cohérence et compatibilité de versions

Cas d’usage

• PRA, migration, audit de sécurité

Exemples

# Facultatif : forcer un roll des EditLogs
hdfs dfsadmin -rollEdits

# Récupérer la FSImage côté NameNode
hdfs dfsadmin -fetchImage /var/backups/hdfs/fsimage_$(date +%F)

# Inspection offline des EditLogs (JSON)
hdfs oev -i /path/to/edits_current -o /var/backups/hdfs/edits.json -p json

# Inspection offline de la FSImage (CSV)
hdfs oiv -i /var/backups/hdfs/fsimage_$(date +%F) -o /var/backups/hdfs/fsimage.csv -p Delimited

Tester la restauration du NameNode

# Arrêter le NameNode, mettre en sécurité
hdfs dfsadmin -safemode enter

# Sauvegarder les répertoires locaux actuels
cp -a /hadoop/nn/name /hadoop/nn/name.bak_$(date +%s)
cp -a /hadoop/nn/edits /hadoop/nn/edits.bak_$(date +%s)

# Remplacer par les artefacts sauvegardés
# (adapter les chemins selon votre infrastructure)

# Démarrer et surveiller les journaux
systemctl start hadoop-hdfs-namenode
hdfs fsck / -files -blocks -locations
hdfs dfs -ls /

Astuce HA : la Standby réalise les checkpoints. En cas de corruption sur l’Active, vous pouvez promouvoir la Standby puis réparer l’instance défaillante. Outils utiles

# Réparation/diagnostic
hdfs namenode -recover
hdfs namenode -bootstrapStandby
hdfs namenode -importCheckpoint

3) DistCp pour sauvegarde et réplication inter-cluster

Fonctionnement

• Copie parallèle MapReduce entre systèmes de fichiers Hadoop-compatibles (HDFS, s3a://, wasb://, gs://)

Avantages

• Massivement parallèle, reprise sur erreur, préservation des attributs

Limites

• Orchestration Kerberos/ACL, bande passante, cohérence à gérer (snapshots)

Cas d’usage

• Sauvegarde distante, migration de cluster, PRA

Exemples

# Complet avec préservation d’attributs
hadoop distcp -p -m 50 hdfs:///data/critical hdfs://backup-ns:8020/backups/critical

# Incrémental basé sur snapshots s1->s2
hadoop distcp -update -delete -diff s1 s2 \
  hdfs://primary-ns:8020/data/critical \
  hdfs://backup-ns:8020/backups/critical

# Restauration vers le cluster principal
hadoop distcp -p -update -delete \
  hdfs://backup-ns:8020/backups/critical \
  hdfs:///data/critical

Validation post-DistCp

hdfs dfs -count -q /data/critical
hdfs fsck /data/critical -files -blocks -locations
hdfs dfs -checksum /data/critical/échantillon.parquet

4) Sauvegarde vers stockage objet (S3, MinIO, Azure Blob, GCS)

Fonctionnement

• Utiliser le connecteur s3a:// (ou équivalent) avec DistCp pour envoyer les données vers un bucket objet

Avantages

• Coût optimisé, immutabilité et versioning, hors site naturel

Limites

• Sémantique objet, latences, coûts d’egress et de requêtes

Cas d’usage

• Archivage, PRA froid/tiède, protection ransomware via Object Lock

Exemples

# Pré-requis : configurer core-site.xml (IAM, rôle, instance profile)
# Sauvegarde complète
hadoop distcp -p -m 50 hdfs:///data/critical s3a://entreprise-backups/hdfs/critical/

# Incrémental avec -update (sans -delete pour éviter les suppressions accidentelles)
hadoop distcp -p -update -m 50 hdfs:///data/critical s3a://entreprise-backups/hdfs/critical/

Tester la restauration

# Récupération depuis le bucket
hadoop distcp -p -update -m 50 s3a://entreprise-backups/hdfs/critical/ hdfs:///data/critical

Immutabilité et versioning côté objet

• Activer le versioning du bucket
• Activer Object Lock (mode Compliance ou Governance) si applicable
• Définir des politiques de rétention (par ex. 30/90/365 jours selon la criticité)

5) Sauvegarde vers NAS/NFS

Fonctionnement

• Export local avec copyToLocal puis sauvegarde via outils système (rsync, snapshots NAS)

Avantages

• Simplicité, réutilisation des outils d’infra

Limites

• Débit limité par la passerelle, nécessite dimensionnement du NAS

Exemples

# Copie locale de test
hdfs dfs -copyToLocal -p /data/critical /mnt/nas/backups/critical

# Synchronisation incrémentale côté OS
rsync -a --delete /mnt/nas/backups/critical/ /mnt/nas/snapshots/critical_$(date +%F)/

Sauvegardes incrémentales et politiques de rétention

• Incrémental par snapshots HDFS + DistCp -diff
• Rétention adaptée aux besoins métiers
• Courts termes fréquents (heures/jours)
• Moyens termes hebdo/mensuels
• Longs termes annuels, archivage à froid
• Versionnage et immutabilité sur stockage objet
• Étiquetage clair (préfixes, datation ISO 8601)

Sécurité et conformité

• Contrôle des accès
• ACL HDFS, POSIX, politiques via Apache Ranger
• Authentification
• Kerberos : tickets de service et keytabs dédiés, krb5 renouvelables
• Exemple

kinit -kt /etc/security/keytabs/hdfs.service.keytab hdfs/[email protected]

• Chiffrement en transit
• dfs.encrypt.data.transfer=true, TLS sur endpoints
• Chiffrement au repos
• HDFS TDE avec zones de chiffrement

# Créer une zone de chiffrement
hdfs crypto -createZone -keyName clé_hdfs_prod -path /data/critical

# Lister les zones
hdfs crypto -listZones

• Protection ransomware
• Copies immuables (Object Lock), comptes de sauvegarde séparés, principes du moindre privilège
• Journalisation et audit
• Intégration avec Apache Ranger et Apache Atlas pour la traçabilité

Haute disponibilité (HA) et fédération HDFS

• HA
• Deux NameNodes (actif/standby), QJM, ZKFC, checkpoints côté Standby
• Sauvegarder métadonnées sur les deux nœuds
• Fédération HDFS
• Plusieurs espaces de noms indépendants
• Plan de sauvegarde par namespace, router-based federation possible

Reprise après sinistre (DR)

Schéma ASCII d’un flux DR

[Cluster primaire] --snapshots--> [DistCp -diff] ----> [Cluster DR/Objet]
         |                                               |
         |<---------- exercices de restauration ---------|

Étapes type

• Geler fonctionnellement la fenêtre d’écriture si possible
• Créer un snapshot cohérent
• DistCp -diff vers DR
• Tester une restauration complète sur un environnement DR isolé

Mesurer

• RPO visé (intervalle entre snapshots)
• RTO mesuré (temps de réhydratation + validation)

Scénarios réalistes et procédures

Suppression accidentelle d’un répertoire

• Détection : alertes d’activité anormale, job en échec
• Restauration

hdfs dfs -restoreSnapshot /data/critical sN
# ou restauration sélective depuis .snapshot/sN

• Validation : fsck, checksum, jobs applicatifs de lecture

Corruption du NameNode

• Bascule HA si disponible (promouvoir Standby)
• Réparer l’instance corrompue

hdfs namenode -recover
hdfs dfsadmin -fetchImage /var/backups/hdfs/fsimage_restaurée
hdfs namenode -importCheckpoint

• Validation : fsck global, état du cluster vert dans Cloudera Manager/Ambari

Perte d’un DataNode

• Laisser HDFS répliquer automatiquement
• Vérifier le facteur de réplication et l’équilibrage

hdfs dfsadmin -report
hdfs dfsadmin -setrep -R -w 3 /data/critical
hdfs balancer -threshold 10

Perte de plusieurs DataNodes

• Prioriser la santé du cluster, ajouter des nœuds, déclencher réplication
• Restaurer à partir d’une sauvegarde si blocs irrécupérables

Panne complète d’un cluster

• Activer le plan DR
• Réhydrater depuis cluster DR ou stockage objet

hadoop distcp -p -update -m 100 s3a://entreprise-backups/hdfs/critical/ hdfs:///data/critical

Migration vers un nouveau cluster Hadoop

• Préparer namespaces et sécurité (Kerberos, Ranger)
• Réplication continue par DistCp -diff jusqu’au cutover

hadoop distcp -update -delete -diff sN-1 sN \
  hdfs://old-ns:8020/data \
  hdfs://new-ns:8020/data

Restauration après attaque ransomware

• Isoler le cluster, invalider les identifiants compromis
• Restaurer depuis copies immuables antérieures à l’attaque
• Valider intégrité, réinitialiser les secrets et clés KMS

Restauration d’un environnement de développement

• Masquer/anonymiser les données si requis
• Restauration sélective vers un préfixe dev

hadoop distcp -p -update hdfs://backup-ns:8020/backups/critical \
  hdfs:///data_dev/critical

Flux d’une sauvegarde type

[Applications] -> [Répertoire HDFS] -> [Snapshot sN] -> [DistCp -diff] -> [Cible (HDFS DR / S3)]
                                            |                                     |
                                     [Vérifications] <------ [Rapports et KPI]

KPI (Key Performance Indicator) : indicateur clé de performance à suivre

• Taux de succès des jobs de sauvegarde
• Débit moyen DistCp
• Temps de validation post-restauration

Checklists opérationnelles

Avant une sauvegarde

• Fenêtre d’exécution planifiée, producteurs informés (Spark, NiFi, Kafka)
• Espace disque disponible côté source et destination
• Kerberos valide, keytabs à jour
• Snapshots activés et quotas vérifiés
• Tests de connectivité réseau et bande passante

Avant une restauration

• Identifier précisément le point cible (snapshot, datation S3)
• Documenter l’impact et le périmètre (in-place vs sélectif)
• Vérifier l’espace disponible et la sécurité (ACL, zones chiffrées)
• Préparer un plan de retour arrière

Validation post-restauration

• hdfs fsck sans anomalies
• hdfs dfs -checksum sur un échantillon représentatif
• Droits, propriétaires, ACL et réplication conformes
• Jobs applicatifs de lecture OK (Spark, Hive, NiFi)

Audit de sécurité

• Journaux Ranger/Atlas passés en revue
• Aucune élévation de privilège inutile
• Accès aux buckets objet limités par politique

Préparation DR

• Exercices réguliers de restauration bout en bout
• Mesure et mise à jour des RPO/RTO
• Documentation à jour, contacts d’astreinte

Erreurs fréquentes à éviter

• Penser que la réplication HDFS couvre tout
• Oublier de sauvegarder FSImage/EditLogs du NameNode
• Ne jamais tester les restaurations en conditions réelles
• Sauvegarder sur le même cluster sans copie distante
• Ne pas superviser l’état des sauvegardes et ignorer les alertes
• Sous-estimer la croissance des données et saturer le stockage
• Utiliser distcp -delete sans test préalable

Performance et optimisation

• Impact des sauvegardes sur le cluster
• Planifier hors pics, limiter la contention réseau et disque
• DistCp parallèle
• -m pour augmenter le nombre de map tasks, tuning du block size
• Optimisation réseau
• Réplication depuis des racks proches, QoS réseau, compression à la source
• Compression
• Parquets/ORC déjà colonnes et compressés, sinon envisager LZ4/ZSTD avant transfert
• Planification
• Fenêtres nocturnes/week-end, coordination avec YARN
• Très grands volumes (centaines de To/Po)
• Transferer par lots logiques, paralléliser par préfixe, vérifier la stabilité Kerberos

Bonnes pratiques de production

• Stratégie 3-2-1 appliquée à l’échelle du Data Lake
• Automatisation
• Orchestrer avec Airflow ou Cron, notifications proactives
• Supervision des sauvegardes
• Tableaux de bord avec KPI (Key Performance Indicator) : taux de succès, latence, débit
• Validation automatique
• Jobs de vérification (fsck, checksum, échantillonnage applicatif)
• Surveillance de l’espace
• Alertes de seuil, rétention automatique sur buckets objet
• Documentation vivante et revues régulières
• Amélioration continue selon PDCA (Plan-Do-Check-Act) : planifier, exécuter, contrôler, ajuster
• Rester pragmatique selon KISS (Keep It Simple, Stupid) : préférer des chaînes de sauvegarde lisibles et faciles à dépanner

Outils fréquemment utilisés avec HDFS

• Apache Ozone : stockage objet compatible S3, alternative ou complément à HDFS
• Apache Ranger : gouvernance des accès et audits
• Apache Atlas : catalogue et traçabilité des données
• MinIO : stockage objet sur site, Object Lock
• Amazon S3, Azure Blob Storage, Google Cloud Storage : cibles de sauvegarde managées
• Apache Airflow : orchestration et planification des jobs
• Apache NiFi : flux d’ingestion et transferts contrôlés
• Cloudera Manager, Ambari : supervision et opérations du cluster

Plan de restauration complet, pas à pas

Schéma ASCII

[Identifier le point cible] -> [Isoler la zone] -> [Restauration (DistCp/hdfs cp)]
           |                            |                |
      [Vérifier ACL/crypto]       [Valider fsck]     [Tests applicatifs]

Étapes

• Choisir le point de restauration (snapshot sN, version objet datée)
• Restauration sélective d’abord, puis in-place si validée
• Contrôle des attributs (propriétaires, ACL), zones chiffrées
• fsck et checksums, tests applicatifs
• Documentation et retour d’expérience

Annexes commandes utiles

# Santé globale
hdfs dfsadmin -report

# Facteur de réplication
hdfs dfs -stat %r /data/critical/fichier
hdfs dfsadmin -setrep -R -w 3 /data/critical

# Équilibrage
hdfs balancer -threshold 10

# Safe mode
hdfs dfsadmin -safemode get
hdfs dfsadmin -safemode enter
hdfs dfsadmin -safemode leave

# Vérification d’intégrité
hdfs fsck / -files -blocks -locations

# Sauvegarde du namespace
hdfs dfsadmin -saveNamespace
hdfs dfsadmin -rollEdits

# Snapshots
hdfs dfsadmin -allowSnapshot /data/critical
hdfs dfs -createSnapshot /data/critical sN
hdfs dfs -restoreSnapshot /data/critical sN
hdfs dfs -snapshotDiff /data/critical sN-1 sN

Conclusion

Une stratégie HDFS fiable associe plusieurs couches complémentaires : réplication HDFS pour la résilience matérielle, snapshots pour des points cohérents et des retours rapides, sauvegardes incrémentales vers un stockage indépendant (cluster DR ou objet) et procédures DR éprouvées. Le succès repose sur des objectifs RPO/RTO clairs, une automatisation soignée, une sécurité robuste (Kerberos, chiffrement, immutabilité), une supervision par KPI et surtout des restaurations régulièrement testées en conditions proches de la production. Cette approche outille efficacement les équipes Hadoop, Big Data et DevOps pour protéger les plateformes de données et éviter les surprises lors des incidents majeurs.