Sauvegarde et restauration NiFi : guide pratique d'implémentation avec commandes

Les sauvegardes sont faciles à promettre et surprenamment simples à rater lorsque l'état des flux de données, les référentiels et le matériel de sécurité entrent en jeu. Ce guide montre comment sauvegarder et restaurer Apache NiFi avec des commandes concrètes, des étapes de validation, une planification de restauration rapide et les écueils courants à éviter. Les exemples se concentrent sur NiFi mono-nœud et en cluster, et mentionnent les points de contact avec des systèmes comme Kafka, HDFS, Spark et Airflow qui se trouvent souvent en amont ou en aval de NiFi.

Vue d'ensemble du flux de travail

Une sauvegarde et une restauration NiFi de niveau production se décomposent en étapes reproductibles :

Identifier ce qu'il faut protéger.
Mettre en pause et capturer un instantané en toute sécurité.
Automatiser les sauvegardes.
Stocker hors site et définir une rétention.
Restaurer dans un environnement de test.
Valider le fonctionnement et l'intégrité des données.
Prévoir un retour arrière rapide si nécessaire.
Effectuer des exercices de sinistre et mesurer le RPO (Recovery Point Objective) : objectif de point de récupération et le RTO (Recovery Time Objective) : objectif de temps de récupération.

Éléments à sauvegarder

Éléments NiFi essentiels à protéger :

Configuration : conf/nifi.properties, authorizers.xml, login-identity-providers.xml, users.xml, bootstrap.conf, et le fichier de définition du flux (flow.json.gz pour NiFi 1.15+ ou flow.xml.gz pour les versions antérieures).
Référentiels et état : flowfile_repository, content_repository, provenance_repository, et le répertoire d'état configuré dans nifi.properties (par exemple nifi.state.directory).
Matériel de sécurité : fichiers keystore et truststore (généralement keystore.jks, truststore.jks ou .p12), et la clé de propriétés sensibles stockée dans nifi.properties (nifi.sensitive.props.key).
NiFi Registry (si utilisé) : sa configuration et son backend de stockage — par exemple, le répertoire Git pour le stockage des flux (providers.xml y fait référence) et la base de données du Registry (H2, Postgres ou MySQL), car les flux versionnés font partie de votre scénario de reprise.
Coordination de cluster : si vous utilisez un ensemble ZooKeeper externe, incluez ses répertoires de données (dataDir et dataLogDir depuis zoo.cfg) ; si vous utilisez ZooKeeper embarqué, sauvegardez le répertoire state/zookeeper de chaque nœud.
Journaux opérationnels : non strictement requis pour la restauration, mais précieux pour l'analyse post-incident.

Capturez également les configurations d'intégration externes dont NiFi dépend, comme les topics Kafka et leurs ACL, les chemins HDFS et permissions, et les identifiants pour les déclencheurs Spark ou Airflow.

Stratégies de sauvegarde et automatisation

Choisissez une stratégie alignée sur le RPO (Recovery Point Objective) : objectif de point de récupération et le RTO (Recovery Time Objective) : objectif de temps de récupération :

Sauvegardes à froid : arrêter NiFi, puis archiver la configuration, les référentiels et l'état. Approche la plus sûre et la plus simple.
Instantanés au niveau système de fichiers : laisser NiFi en marche, mettre les flux en pause, prendre des instantanés LVM/ZFS instantanés des volumes de référentiels et d'état. Rapide et cohérent avec la bonne pile de stockage.
Approche mixte : sauvegarde à froid de conf et de la définition du flux ; instantanés séparés pour les référentiels.

Astuces d'automatisation :

Planifier avec cron ou votre ordonnanceur préféré ; pousser les artefacts vers un stockage hors site (S3, NFS, objet store).
Conserver au minimum des points de reprise quotidiens, avec des instantanés plus fréquents (par exemple toutes les 4 heures) pour les clusters très sollicités.
Étiqueter les sauvegardes avec la version NiFi, le nom d'hôte du nœud et l'horodatage (ex. nifi-node01-1.23.0-2025-01-15-0300.tgz).
Chiffrer les sauvegardes au repos (GPG ou SSE-S3) et en transit (TLS).

Exemples pratiques de sauvegarde

Exemple 1 : Sauvegarde à froid mono-nœud sous Linux

1. Mettre en pause et arrêter

$NIFI_HOME/bin/nifi.sh status
$NIFI_HOME/bin/nifi.sh stop

2. Créer une archive

cd "$NIFI_HOME"
BACKUP_DIR=/backups
STAMP=$(date +%F-%H%M)
NAME="nifi-$(hostname)-$STAMP.tgz"
mkdir -p "$BACKUP_DIR"
tar czf "$BACKUP_DIR/$NAME" \
  conf \
  flowfile_repository \
  content_repository \
  provenance_repository \
  state \
  keystore* truststore* 2>/dev/null || true
sha256sum "$BACKUP_DIR/$NAME" > "$BACKUP_DIR/$NAME.sha256"

3. Redémarrer et vérifier

$NIFI_HOME/bin/nifi.sh start
$NIFI_HOME/bin/nifi.sh status

Exemple 2 : Sauvegarde de cluster avec orchestration

Exécuter la même étape d'archivage sur chaque nœud. Conserver les archives spécifiques à chaque nœud ; ne pas les fusionner.
Sauvegarder les données ZooKeeper externes selon votre guide d'exploitation ZK (instantané dataDir/dataLogDir).
Sauvegarder le stockage NiFi Registry (répertoire Git) et la base de données si utilisée.
Stocker tous les artefacts ensemble avec un préfixe d'horodatage cohérent (ex. 2025-01-15-0300_).

Exemple 3 : Sauvegarde par instantané (NiFi reste actif)

Arrêter ou désactiver les processeurs qui modifient des données critiques (ex. PutHDFS, PutKafka) ; laisser les files d'attente se vider jusqu'à un niveau sûr (surveiller via l'UI ou les métriques de file d'attente de nifi.sh status).
Figer les volumes de référentiels avec des instantanés LVM ou ZFS :

  lvcreate -L 10G -s -n nifi_snap_$(date +%F) /dev/vg0/nifi_repos
  zfs snapshot pool/nifi_repos@$(date +%F-%H%M)

Capturer conf et la définition du flux ou les copier de façon atomique (cp -a conf conf.snap).
Réactiver les processeurs une fois les instantanés terminés.

Procédures de restauration

Restauration mono-nœud

1. Préparer l'hôte

Installer la même version de NiFi et le même runtime Java que la sauvegarde (ex. NiFi 1.23.0 + OpenJDK 11.0.20).
Créer les chemins de système de fichiers pour les référentiels avec l'espace nécessaire (reproduire les points de montage d'origine si possible).

2. Arrêter NiFi

$NIFI_HOME/bin/nifi.sh stop || true

3. Restaurer les fichiers

cd "$NIFI_HOME"
tar xzf /backups/nifi-HOST-YYYY-MM-DD-HHMM.tgz -C "$NIFI_HOME"
chown -R nifi:nifi conf content_repository flowfile_repository provenance_repository state

4. Vérifications de bon sens

Vérifier que conf/nifi.properties contient votre nifi.sensitive.props.key d'origine.
Vérifier que les chemins et mots de passe du keystore et truststore correspondent aux entrées de nifi.properties (nifi.security.keystore, nifi.security.keystorePasswd, etc.).
Optionnellement démarrer avec des référentiels vides pour un démarrage plus rapide (vous perdrez les FlowFiles en file d'attente et la provenance) :

  rm -rf flowfile_repository/* content_repository/* provenance_repository/*

5. Démarrer et observer

$NIFI_HOME/bin/nifi.sh start
$NIFI_HOME/bin/nifi.sh status

Surveiller logs/app.log pour d'éventuelles erreurs. Ouvrir l'UI et confirmer que le flux apparaît comme prévu.

Restauration de cluster

Effectuer les étapes mono-nœud sur chaque nœud en utilisant la sauvegarde propre à chaque nœud.
Restaurer ZooKeeper externe depuis sa sauvegarde si l'état de coordination a été perdu.
Démarrer les nœuds un par un, confirmer l'adhésion au cluster (UI → menu Cluster), et vérifier que les UUID des nœuds et la configuration du cluster sont alignés.

Utilisation de NiFi Registry

Si vous gérez les flux avec Registry, vous pouvez restaurer NiFi avec un conf minimal puis réimporter les versions de flux souhaitées. Sauvegarder et restaurer d'abord le stockage Registry (répertoire Git) et la base de données, puis connecter NiFi à celui-ci et déployer les flux versionnés.

Contrôles de validation

Contrôles fonctionnels après restauration

Santé du service : nifi.sh status renvoie running ; aucune erreur fatale dans logs/app.log.
Définition du flux : le canevas se charge ; aucun composant ou service de contrôle manquant (pas d'icônes d'avertissement jaunes).
Propriétés sensibles : les processeurs avec mots de passe ou clés démarrent sans demande ; aucune erreur de déchiffrement dans les logs.
Connecteurs : tester les points de terminaison pour les intégrations Kafka, HDFS, Spark et Airflow ; confirmer les identifiants et la reachabilité réseau (ex. kafka-broker-api-versions --bootstrap-server <host>:9092).
Files d'attente et back pressure : compteurs et tailles attendus ; pas de croissance incontrôlée.
Provenance : les événements sont enregistrés ; la relecture fonctionne sur un événement d'échantillon.
Site-to-site et HTTPS : les certificats sont valides ; les pairs se connectent avec succès.

Contrôles de données

Exécuter un petit flux de test de bout en bout à partir d'une entrée connue jusqu'à la sortie, et comparer le payload et les compteurs.
Valider le schéma et le placement des partitions pour HDFS ou les systèmes en aval (ex. hdfs dfs -ls /data/output/date=2025-01-15).

Contrôles opérationnels

Confirmer que les bulletins sont silencieux ; que les états de planification et d'exécution correspondent aux attentes.
Vérifier que les tableaux de bord de métriques et les alertes sont de nouveau en ligne (Prometheus/Grafana, Datadog, etc.).

Planification du retour arrière

Préparer une sortie rapide si la restauration se passe mal :

Conserver l'instance NiFi précédente ou sa sauvegarde prête. Si vous avez restauré par-dessus une installation existante, garder l'archive pré-restauration pour pouvoir revenir rapidement.
Bleu/vert : restaurer dans un environnement parallèle, le chauffer, puis basculer l'entrée (ex. reverse proxy ou load balancer) une fois validé.
Verrouillage de version : documenter les versions exactes de NiFi et Java associées à chaque jeu de sauvegarde (ex. dans un manifest.txt à côté de l'archive).
Tampons de données : utiliser les files d'attente en amont (Kafka) pour mettre en pause et rejouer si vous devez revenir en arrière — définir la rétention d'offset consumer.group.id pour couvrir votre fenêtre de RTO.
Exercice de retour arrière : pratiquer un retour arrière chronométré chaque trimestre pour prouver vos hypothèses de RTO.

Scénarios de reprise après sinistre

Planifier les pannes majeures :

Perte de nœud : remplacer le nœud, installer la même version de NiFi, restaurer la sauvegarde de ce nœud, et le réintégrer au cluster.
Corruption de référentiel : restaurer uniquement le référentiel affecté (ex. content_repository) ou repartir sur des référentiels neufs tout en conservant conf et le flux ; accepter la perte des données en file d'attente si nécessaire.
Perte du Registry : restaurer le stockage Registry (répertoire Git) et la base de données, puis redéployer les flux.
Perte de site : conserver des copies hors site de toutes les sauvegardes de nœuds, des données Registry et des données ZooKeeper. Pré-provisionner un environnement de secours dans une autre région. Documenter un plan de démarrage séquencé et un RTO cible.
Alignement du RPO : régler la fréquence des sauvegardes et la cadence des instantanés pour respecter les fenêtres de perte de données acceptables (ex. instantanés toutes les 4 heures → RPO ≤ 4 heures).

Erreurs fréquentes

Éviter ces pièges :

Sauvegarder pendant que NiFi modifie l'état, sans instantané de stockage.
Oublier la clé de propriétés sensibles dans nifi.properties ; les processeurs restaurés échoueront au déchiffrement.
Ne pas sauvegarder les fichiers keystore/truststore et la configuration TLS.
Ne pas sauvegarder NiFi Registry lorsqu'on utilise des flux versionnés.
Mélanger les versions à la restauration ; toujours faire correspondre les versions NiFi et Java en premier.
Restaurer les nœuds de cluster à partir d'une seule sauvegarde de nœud ; chaque nœud a besoin de la sienne.
Ignorer les dépendances externes comme les ACL Kafka ou les permissions HDFS.
Ne pas mettre les processeurs en pause ni vider les files d'attente avant les instantanés, ce qui entraîne des états partiels.

Plan pilote local

Commencer petit et mesurable :

Objectif : Sauvegarder et restaurer un NiFi mono-nœud qui déplace des données d'un répertoire local vers Kafka puis vers HDFS, avec validation de bout en bout, le tout sur une machine de développeur ou une petite VM.

Périmètre :

Un groupe de processus avec 5 à 10 processeurs.
Un petit jeu de données (quelques centaines d'enregistrements) aux résultats déterministes.

Étapes :

Construire le flux et enregistrer une somme de contrôle des sorties attendues (ex. sha256sum expected_output/* > baseline.sha256).
Effectuer une sauvegarde à froid comme montré ci-dessus.
Simuler une panne en supprimant l'installation NiFi (rm -rf $NIFI_HOME).
Restaurer depuis la sauvegarde ; démarrer NiFi.
Réexécuter le petit jeu de données et comparer sommes de contrôle et compteurs.

Métriques à capturer :

Temps de sauvegarde et temps de restauration (RTO de base).
Divergence des données (zéro acceptable pour le pilote).
Exactitude du playbook : des étapes manquaient-elles ou étaient-elles floues ?

Une fois le pilote reproductible, passer à un cluster de staging et ajouter des instantanés automatisés et la copie hors site.

Conclusion

Des opérations NiFi fiables reposent sur des sauvegardes prévisibles, des restaurations propres et des retours arrière rapides. Identifier ce qu'il faut protéger, automatiser des instantanés sûrs, valider les restaurations dans un bac à sable, et répéter les scénarios de sinistre avant d'en avoir besoin.

Check-list rapide :

Sauvegarder conf, définition du flux, référentiels, état, keystore/truststore, Registry et ZooKeeper.
Étiqueter les artefacts avec version et hôte.
Restaurer sur la même version de NiFi ; vérifier les propriétés sensibles et les connecteurs.
Exécuter des tests de bout en bout et surveiller bulletins et logs.
Conserver un chemin de retour arrière.

Avec ces habitudes, vos pipelines de données et leurs intégrations avec Kafka, HDFS, Spark et Airflow resteront résilients face aux changements et aux pannes.