NiFi : sauvegarde et restauration avec exemples pratiques

Intro

Cette version française explique NiFi backup and restore with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Promettre une sauvegarde est facile, la réussir sans perte d'état ni de sécurité l'est moins. Ce guide propose une approche pratique pour mener un NiFi backup et un NiFi restore fiables, avec commandes concrètes, NiFi validation systématique, plan de NiFi rollback et scénarios de NiFi disaster recovery. Nous couvrons les déploiements mono‑nœud et cluster, et les points de contact fréquents avec Kafka, HDFS, Apache Spark et Apache Airflow au sein de vos data pipelines.

Vue d'ensemble du workflow

Un processus de niveau production se décline en étapes reproductibles :

Identifier ce qu'il faut protéger.
Mettre au calme (quiesce) et prendre un instantané en sécurité.
Automatiser les backups.
Stocker hors site et définir une rétention.
Restaurer dans un bac à sable.
Réaliser des contrôles de NiFi validation (fonction et intégrité).
Prévoir et tester un NiFi rollback rapide.
Driller les scénarios de sinistre et mesurer RPO/RTO.

Que 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 de flux (flow.json.gz ou flow.xml.gz selon la version).
Dépôts et état : flowfile_repository, content_repository, provenance_repository, ainsi que le répertoire de state défini dans nifi.properties.
Matériel de sécurité : keystore, truststore, et la clé des propriétés sensibles dans nifi.properties (nifi.sensitive.props.key).
NiFi Registry (si utilisé) : sa configuration et son stockage (ex. stockage Git des flows et sa base), car les flows versionnés font partie de votre reprise.
Coordination de cluster : pour ZooKeeper externe, inclure ses sauvegardes ; pour embarqué, sauvegarder ses répertoires de données.
Journaux opérationnels : non indispensables à la restauration, mais utiles pour la forensique après incident.

Capturer également les configurations d'intégrations externes dont dépend NiFi : topics Kafka et ACLs, chemins HDFS et permissions, et identifiants pour déclencheurs Spark ou Airflow.

Stratégies et automatisation de sauvegarde

Choisissez une stratégie alignée sur vos objectifs RPO/RTO :

Backups à froid : arrêter NiFi puis archiver conf, dépôts et état. Plus simple et plus sûr.
Snapshots de filesystem : laisser NiFi en marche, quiescer les flows, capturer des instantanés LVM/ZFS des volumes de dépôts et d'état. Rapide et cohérent avec l'infrastructure adaptée.
Approche mixte : backup à froid de conf et du flow, snapshots séparés des dépôts.

Conseils d'automatisation :

Planifiez via cron ou votre ordonnanceur et poussez les artefacts hors site.
Conservez au moins un point de restauration quotidien, avec des snapshots plus fréquents pour les clusters chargés.
Étiquetez les archives avec la version de NiFi, l'hôte et un horodatage.
Chiffrez les sauvegardes au repos et en transit.

Exemples pratiques de backup

Exemple 1 : backup à froid mono‑nœud sur Linux

Quiescer et arrêter

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

Créer une archive

cd "$NIFI_HOME"
BACKUP_DIR=/backups
STAMP=$(date +%F-%H%M)
NAME="nifi-$(hostname)-$STAMP.tgz"
mkdir -p "$BACKUP_DIR"
# Adaptez si vous avez personnalisé les chemins des dépôts
 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"

Redémarrer et vérifier

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

Exemple 2 : backup d'un cluster avec orchestration

Exécutez l'archivage sur chaque nœud. Conservez des archives spécifiques à chaque nœud ; ne fusionnez pas.
Sauvegardez les données ZooKeeper selon votre guide d'exploitation ZK.
Sauvegardez le stockage et la base de NiFi Registry si utilisés.
Stockez tous les artefacts ensemble avec un horodatage cohérent.

Exemple 3 : backup par snapshot (NiFi reste actif)

Arrêtez ou désactivez les processeurs qui modifient des données critiques ; laissez les files se drainer jusqu'à un seuil sûr.
Figez les volumes des dépôts via des snapshots LVM ou ZFS.
Snapshottez conf et la définition du flow ou copiez‑les de façon atomique.
Réactivez les processeurs une fois les snapshots terminés.

Procédures de restauration

Restauration mono‑nœud

Préparer l'hôte

Installez la même version de NiFi et le même runtime Java que la sauvegarde.
Créez les chemins filesystem pour les dépôts avec l'espace requis.

Arrêter NiFi

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

Restaurer les fichiers

cd "$NIFI_HOME"
tar xzf /backups/nifi-HOST-YYYY-MM-DD-HHMM.tgz -C "$NIFI_HOME"
# Vérifiez les propriétaires/permissions
chown -R nifi: nifi conf content_repository flowfile_repository provenance_repository state

Contrôles de cohérence

Vérifiez que conf/nifi.properties contient votre nifi.sensitive.props.key d'origine.
Vérifiez les chemins et mots de passe de keystore/truststore.
Optionnel : démarrer avec des dépôts vides pour un boot plus rapide (perte des FlowFiles en file et de la provenance) :

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

Démarrer et observer

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

Surveillez logs/app.log, ouvrez l'UI et confirmez que le flow apparaît correctement.

Restauration de cluster

Appliquez la procédure mono‑nœud à chaque nœud avec son archive propre.
Restaurez ZooKeeper si l'état de coordination est perdu.
Démarrez les nœuds un par un, confirmez la jonction au cluster et la cohérence des UUIDs et de la configuration.

Avec NiFi Registry

Si vous gérez les flows avec Registry, vous pouvez restaurer un NiFi minimal puis ré‑importer les versions désirées. Sauvegardez et restaurez d'abord le stockage et la base de Registry, connectez NiFi, puis déployez les flows versionnés.

Contrôles de validation

Vérifications fonctionnelles après restore

Santé du service : nifi.sh status indique running ; pas d'erreur fatale dans les logs.
Définition de flow : la toile se charge ; aucun composant ou service manquant.
Propriétés sensibles : les processeurs avec secrets démarrent sans erreur de déchiffrement.
Connecteurs : testez les endpoints Kafka, HDFS, Spark et Airflow ; validez les identifiants et la connectivité réseau.
Files et back‑pressure : volumes attendus ; pas de croissance anormale.
Provenance : événements présents ; un replay fonctionne sur un échantillon.
Site‑to‑site et HTTPS : certificats valides, pairs connectés.

Contrôles de données

Exécutez un petit test de bout en bout, de l'entrée connue à la sortie, et comparez charge utile et compte.
Validez schéma et placement de partitions pour HDFS ou systèmes aval.

Contrôles opérationnels

Les bulletins sont calmes ; les états schedule/run sont conformes.
Les tableaux de bord et alertes de métriques sont revenus en ligne.

Plan de rollback

Prévoyez une sortie rapide si la restauration se comporte mal :

Conservez l'instance précédente ou son archive. Si vous avez restauré par‑dessus, gardez l'archive pré‑restore pour revenir vite.
Blue/green : restaurez dans un environnement parallèle, échauffez‑le, puis basculez l'ingress (reverse proxy ou load balancer) une fois validé.
Gel des versions : documentez la version exacte de NiFi et Java pour chaque set de backup.
Tampons de données : utilisez des files amont (Kafka) pour mettre en pause et rejouer en cas de revert.
Exercice de rollback : entraînez un retour chronométré pour prouver votre RTO.

Scénarios de disaster recovery

Préparez‑vous aux grandes pannes :

Perte de nœud : remplacez le nœud, installez la même version de NiFi, restaurez son backup, rejoignez le cluster.
Corruption de dépôt : ne restaurez que le dépôt affecté ou repartez de dépôts vides en conservant conf et flow ; acceptez la perte de files si nécessaire.
Perte de Registry : restaurez le stockage et la base de Registry, puis redéployez les flows.
Perte de site : conservez hors site les backups de tous les nœuds, les données Registry et ZooKeeper. Pré‑provisionnez un environnement de secours dans une autre région. Documentez un plan de remise en route séquencé et un RTO cible.
Alignement RPO : cadencer backups et snapshots pour tenir la fenêtre de perte acceptable.

Erreurs courantes

À éviter absolument :

Sauvegarder pendant que NiFi modifie l'état, sans snapshot de stockage.
Oublier la clé nifi.sensitive.props.key ; les processeurs ne déchiffreront pas.
Omettre keystore/truststore et la configuration TLS.
Ne pas sauvegarder NiFi Registry avec des flows versionnés.
Mélanger les versions à la restauration ; alignez d'abord NiFi et Java.
Restaurer des nœuds de cluster depuis le backup d'un seul nœud ; chaque nœud a le sien.
Ignorer Kafka ACLs ou permissions HDFS.
Ne pas quiescer les processeurs ni drainer les files avant snapshots, d'où des états partiels.

Plan pilote local

Démarrez 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 NiFi validation de bout en bout, sur une machine de dev ou une petite VM.

Périmètre :

Un groupe de processus avec 5 à 10 processeurs.
Un jeu de données minime (quelques centaines d'enregistrements) au résultat déterministe.

Étapes :

Construire le flow et enregistrer une empreinte (checksum) de la sortie attendue.
Réaliser un backup à froid comme ci‑dessus.
Simuler une panne en supprimant l'installation NiFi.
Restaurer depuis le backup ; démarrer NiFi.
Rejouer le petit dataset et comparer checksums et comptes.

Mesures à capturer :

Temps de backup et de restauration (RTO de base).
Divergence de données (cible : zéro pour le pilote).
Qualité du playbook : des étapes manquent‑elles ou sont‑elles ambiguës ?

Une fois le pilote stabilisé, passez à un cluster de staging et ajoutez des snapshots automatisés et une copie hors site.

Conclusion

Des opérations NiFi fiables exigent des backups prévisibles, des restores propres et des rollbacks rapides. Sachez ce qu'il faut protéger, automatisez des snapshots sûrs, validez les restores en sandbox et entraînez les scénarios de sinistre avant d'en avoir besoin.

Checklist rapide :

Sauvegarder conf, flow, dépôts, état, keystore/truststore, Registry et ZooKeeper.
Taguer les artefacts avec version et hôte.
Restaurer sur la même version de NiFi ; vérifier propriétés sensibles et connecteurs.
Exécuter des tests de bout en bout et surveiller bulletins et logs.
Garder un chemin de rollback.

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