Guide pratique de sauvegarde, restauration et reprise après sinistre pour Nginx

Introduction

Quand Nginx tombe en panne ou qu'un changement de configuration casse votre site, chaque minute d'indisponibilité coûte de l'argent et de la confiance. Les procédures de sauvegarde et de restauration ne sont pas uniquement destinées aux catastrophes ; elles constituent votre filet de sécurité pour la maintenance quotidienne, les mises à niveau et les erreurs accidentelles. Ce guide propose une approche pratique, étape par étape, pour sauvegarder et restaurer les configurations Nginx, valider les changements et récupérer après une défaillance.

Vous apprendrez à inventorier votre environnement, à gérer les changements de configuration en toute sécurité, à vérifier la santé du serveur et à mettre en œuvre une reprise après sinistre robuste. À la fin, vous disposerez d'une liste de contrôle opérationnelle claire et de la confiance nécessaire pour gérer les pannes de Nginx sans paniquer.

Inventaire de la version et de l'environnement

Avant de toucher à quoi que ce soit, sachez exactement avec quoi vous travaillez. Cette section explique comment recueillir les détails essentiels sur votre installation Nginx, la topologie de déploiement et les prérequis pour la sauvegarde et la restauration.

Identifier la version installée

Exécutez la commande suivante en lecture seule pour vérifier la version de Nginx et les options de compilation :

nginx -V

La sortie attendue inclut la version et une longue liste d'arguments de configuration. Par exemple :

nginx version: nginx/1.24.0
built by gcc 12.2.0 (Debian 12.2.0-14)
built with OpenSSL 3.0.9 30 May 2023
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf ...

Notez la version, le chemin vers le fichier de configuration principal (--conf-path) et le répertoire préfixe. Ces chemins varient selon la méthode d'installation ; ne supposez jamais les valeurs par défaut.

Si votre Nginx est dans un conteneur Docker, utilisez :

docker exec <nom_du_conteneur> nginx -V

Remplacez <nom_du_conteneur> par le nom réel du conteneur (par exemple, mon-nginx).

Localiser les fichiers et répertoires de configuration

Nginx inclut souvent la configuration à partir de plusieurs fichiers. Trouvez tous les fichiers inclus avec :

nginx -T

Cette commande affiche la configuration complète telle qu'elle est chargée, y compris toutes les inclusions. La sortie est longue, vous pouvez donc la sauvegarder :

nginx -T > /tmp/nginx_config_complete_$(date +%Y%m%d_%H%M%S).txt

Cela crée un instantané horodaté de la configuration actuelle. C'est une sauvegarde critique en soi.

Vérifiez le répertoire de configuration par défaut :

ls -la /etc/nginx/

Le contenu typique inclut nginx.conf, sites-available/, sites-enabled/, conf.d/ et éventuellement snippets/. Votre configuration peut différer, surtout si vous utilisez un préfixe personnalisé.

Si Nginx s'exécute dans un conteneur Docker, inspectez les montages du conteneur pour comprendre où la configuration et les journaux sont stockés :

docker inspect <nom_du_conteneur> --format='{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"\n"}}{{end}}'

Par exemple :

/etc/nginx/nginx.conf -> /etc/nginx/nginx.conf
/var/log/nginx -> /var/log/nginx

Cela confirme si votre configuration est montée en volume ou intégrée à l'image.

Topologie de déploiement : machine physique, VM ou Kubernetes

Votre stratégie de sauvegarde diffère selon l'environnement :

• Machine physique/VM : Les fichiers de configuration sont sur le système de fichiers local. Utilisez des outils de sauvegarde de fichiers standard (rsync, tar).
• Docker : La configuration peut être dans un volume ou un montage lié. Sauvegardez le répertoire source sur l'hôte, pas le système de fichiers du conteneur (qui est éphémère).
• Kubernetes : Nginx peut s'exécuter comme contrôleur Ingress (par exemple, ingress-nginx). La configuration est gérée via des ConfigMaps, des Secrets et des ressources Ingress. Sauvegardez ces objets Kubernetes, pas les fichiers du pod.

Pour voir si Nginx s'exécute dans Kubernetes :

kubectl get pods -A | grep nginx

Exemple de sortie :

NAMESPACE     NAME                              READY   STATUS    RESTARTS   AGE
ingress-nginx ingress-nginx-controller-abc123   1/1     Running   0          5d

Si vous êtes sur une VM, confirmez l'état du service avec :

systemctl status nginx

Si Nginx n'est pas géré par systemd (par exemple, s'exécute dans un conteneur), utilisez ps :

ps aux | grep nginx

Prérequis pour la sauvegarde et la restauration

Pour effectuer des sauvegardes efficacement, assurez-vous de disposer :

• D'un espace disque suffisant pour les fichiers de sauvegarde (vérifiez avec df -h).
• Des permissions pour lire les fichiers de configuration (généralement root ou sudo).
• D'un accès réseau au stockage distant si vous sauvegardez hors site.
• D'un système de contrôle de version (comme Git) pour le suivi des configurations.
• D'un environnement de test pour valider les configurations restaurées avant de les appliquer en production.

Chemin de configuration sûr

Modifier la configuration Nginx peut être risqué. Une erreur de syntaxe peut empêcher le serveur de démarrer, provoquant une indisponibilité. Cette section décrit un flux de travail sûr pour effectuer et sauvegarder les changements de configuration.

Avant tout changement : sauvegarder la configuration actuelle

Créez une sauvegarde horodatée de tout le répertoire de configuration Nginx :

sudo tar -czf /backups/nginx_$(date +%Y%m%d_%H%M%S).tar.gz -C /etc/nginx .

Exemple de sortie :

$ ls -lh /backups/
-rw-r--r-- 1 root root 12K Aug 22 14:35 nginx_20240822_143530.tar.gz

Cela archive tous les fichiers sous /etc/nginx par rapport à ce répertoire. Ajustez le chemin source si votre configuration se trouve ailleurs (par exemple, /usr/local/nginx/conf).

Pour les montages liés Docker, archivez le répertoire hôte. Pour Kubernetes, exportez les ressources pertinentes :

kubectl get configmap,secret,ingress -n <namespace> -o yaml > nginx_k8s_backup_$(date +%Y%m%d_%H%M%S).yaml

Remplacez <namespace> par votre namespace Nginx (par exemple, ingress-nginx).

Utiliser le contrôle de version pour la configuration

Même avec des sauvegardes de fichiers, le contrôle de version fournit un historique des modifications et un retour arrière facile. Si votre /etc/nginx n'est pas encore un dépôt Git, initialisez-le :

cd /etc/nginx
sudo git init
sudo git add .
sudo git commit -m "Sauvegarde initiale de la configuration Nginx"

Ensuite, après chaque changement, validez avec un message descriptif :

sudo git commit -am "Mise à jour de la limitation de débit pour les points de terminaison API"

Si vous ne pouvez pas utiliser Git directement dans /etc/nginx, copiez la configuration dans un dépôt Git ailleurs :

rsync -av /etc/nginx/ /chemin/vers/depot/nginx-config/
cd /chemin/vers/depot/nginx-config
git add . && git commit -m "Synchronisation de la config Nginx $(date)"

Tester la configuration avant de l'appliquer

Ne rechargez ni ne redémarrez jamais Nginx sans tester la configuration pour détecter les erreurs de syntaxe :

sudo nginx -t

Sortie en cas de succès :

nginx: configuration file /etc/nginx/nginx.conf test is successful

Exemple d'échec :

nginx: [emerg] unexpected "}" in /etc/nginx/conf.d/myapp.conf:10
nginx: configuration file /etc/nginx/nginx.conf test failed

Ne poursuivez que si le test réussit.

Pour Docker :

docker exec <nom_du_conteneur> nginx -t

Rechargement vs redémarrage

Après un test réussi, appliquez le changement sans interrompre les connexions en rechargeant :

sudo systemctl reload nginx

Ou, si vous n'utilisez pas systemd :

sudo nginx -s reload

Cela envoie un signal HUP au processus maître, lui faisant relire la configuration et démarrer de nouveaux processus worker pendant que les anciens terminent les requêtes en cours. C'est transparent pour la plupart des changements de configuration.

N'utilisez un redémarrage complet que lorsque c'est nécessaire (par exemple, après une mise à niveau du binaire ou des changements majeurs de configuration) car il interrompt brièvement les connexions :

sudo systemctl restart nginx

Vérifier après le rechargement

Vérifiez que la nouvelle configuration est chargée et que le serveur est sain :

sudo nginx -T | grep 'votre_directive_modifiée'

Vérifiez également le journal des erreurs pour les avertissements ou les erreurs :

sudo tail -f /var/log/nginx/error.log

Vérification et diagnostics

Après tout changement, vous devez vérifier que Nginx fonctionne correctement. Cette section couvre les commandes de diagnostic essentielles et leur interprétation.

Vérifier l'état du service

Sur les systèmes systemd :

systemctl status nginx

Recherchez Active: active (running) et les entrées de journal récentes. Exemple :

● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2024-08-22 14:30:00 UTC; 1h 2min ago

S'il ne fonctionne pas, enquêtez avec journalctl -u nginx :

sudo journalctl -u nginx --since "10 minutes ago"

Surveiller les journaux d'accès et d'erreurs

Les journaux d'accès montrent les requêtes entrantes :

tail -n 20 /var/log/nginx/access.log

Les journaux d'erreurs montrent les problèmes :

tail -n 20 /var/log/nginx/error.log

Entrées courantes du journal des erreurs :

• [emerg] : Erreur de configuration fatale, le serveur ne peut pas démarrer.
• [alert] : Condition sérieuse, peut nécessiter une attention immédiate.
• [crit] : Condition critique.
• [error] : Erreur récupérable (par exemple, échec de connexion en amont).
• [warn] : Avertissement, non critique.

Surveillez ces journaux en temps réel pendant la vérification :

sudo tail -f /var/log/nginx/error.log

Tester du point de vue du client

Utilisez curl pour effectuer des requêtes et inspecter les réponses :

curl -I http://localhost/

Sortie attendue montrant le statut HTTP et les en-têtes :

HTTP/1.1 200 OK
Server: nginx/1.24.0
Date: Tue, 22 Aug 2024 14:40:00 GMT
Content-Type: text/html
...

Si vous attendez un backend spécifique, testez-le directement :

curl -I http://localhost/api/health

Vérifiez la connectivité amont du proxy :

curl -v http://localhost/ 2>&1 | grep -i 'upstream'

Si Nginx est un proxy inverse, vous devriez voir les détails de la réponse amont.

Vérifications des processus et des ports

Assurez-vous que les processus maître et worker de Nginx fonctionnent :

ps aux | grep nginx

La sortie normale inclut un processus maître appartenant à root et plusieurs processus worker appartenant à l'utilisateur www-data (ou nginx).

Vérifiez que Nginx écoute sur les ports attendus :

sudo ss -tlnp | grep nginx

Exemple :

LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=1234,fd=6))
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*    users:(("nginx",pid=1234,fd=7))

Si aucune sortie, Nginx n'écoute pas ; vérifiez la configuration pour les directives listen et les erreurs.

Modes de défaillance et récupération

Même avec une planification minutieuse, des pannes surviennent. Cette section couvre les modes de défaillance courants et les procédures de récupération étape par étape.

Erreur de configuration empêchant le démarrage

Scénario : Vous avez modifié un fichier de configuration et redémarré Nginx, mais il ne démarre pas en raison d'une erreur de syntaxe.

Diagnostic : Exécutez nginx -t pour voir les détails de l'erreur. Le journal des erreurs contiendra également la ligne et le fichier exacts.

Récupération :

1. Restaurez la dernière configuration connue bonne à partir de la sauvegarde :

   sudo tar -xzf /backups/nginx_<horodatage>.tar.gz -C /etc/nginx

Ou, si vous utilisez Git :

   cd /etc/nginx && sudo git checkout -- .

1. Testez la configuration restaurée :

   sudo nginx -t

1. Démarrez Nginx :

   sudo systemctl start nginx

1. Vérifiez avec curl -I http://localhost/.

Disque plein provoquant des échecs de journalisation ou de cache

Scénario : Nginx démarre mais la journalisation s'arrête ou la mise en cache échoue parce que le disque est plein.

Diagnostic : Vérifiez l'utilisation du disque :

df -h

Si une partition pertinente (par exemple, /var) est à 100 %, c'est le coupable.

Récupération :

1. Identifiez les gros fichiers :

   sudo du -sh /var/log/nginx/*

1. Faites pivoter ou archivez les anciens journaux. Si vous utilisez logrotate, exécutez-le manuellement :

   sudo logrotate -f /etc/logrotate.d/nginx

Ou, si les journaux ne sont pas critiques, tronquez-les :

   sudo truncate -s 0 /var/log/nginx/access.log
   sudo truncate -s 0 /var/log/nginx/error.log

1. Videz les répertoires de cache Nginx le cas échéant.
2. Vérifiez avec df -h et nginx -t.

Backend amont indisponible

Scénario : Nginx fonctionne, mais renvoie 502 Bad Gateway pour les requêtes proxifiées parce que le backend amont est en panne.

Diagnostic : Vérifiez le journal des erreurs :

grep 'connect() failed' /var/log/nginx/error.log

Vous pouvez voir des lignes comme :

2024/08/22 15:10:00 [error] 1234#1234: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.100, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/", host: "example.com"

Récupération :

1. Vérifiez le service backend avec curl http://ip_backend:port/health.
2. Si le backend est en panne, démarrez-le. Si le backend est intentionnellement en panne pour maintenance, configurez Nginx avec une solution de repli statique ou une page d'erreur personnalisée.
3. Si le backend est opérationnel mais que Nginx échoue toujours, vérifiez les règles de pare-feu, SELinux ou la connectivité réseau :

   sudo netstat -tulpn | grep :8080

1. Rechargez Nginx après la correction.

Problèmes de certificat SSL

Scénario : Nginx ne parvient pas à charger les certificats SSL ou sert des certificats expirés.

Diagnostic :

sudo nginx -t

Peut montrer des erreurs comme :

nginx: [emerg] cannot load certificate "/etc/nginx/ssl/example.com.crt": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory)

Ou utilisez openssl pour vérifier l'expiration du certificat :

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Récupération :

1. Assurez-vous que les fichiers de certificat existent et ont les bonnes permissions.
2. Renouvelez les certificats expirés (par exemple, en utilisant Certbot pour Let's Encrypt).
3. Rechargez Nginx :

   sudo systemctl reload nginx

1. Vérifiez avec curl -I https://example.com/ et vérifiez les dates du certificat.

Suppression ou corruption accidentelle de fichiers

Scénario : Un fichier de configuration critique ou un fichier journal est accidentellement supprimé ou corrompu.

Récupération :

1. Restaurez à partir de la sauvegarde comme décrit précédemment.
2. Si vous n'avez pas de sauvegarde de fichier, vous pouvez reconstruire à partir de la mémoire du processus en cours si disponible :

• Utilisez nginx -T si Nginx est toujours en cours d'exécution (il affiche la configuration actuelle à partir de la mémoire).
• Sauvegardez la sortie et recréez le fichier.

1. Recréez le fichier manuellement à partir de la configuration affichée, si nécessaire.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après tout changement Nginx pour garantir la sécurité et la récupérabilité.

Avant d'apporter des modifications

• [ ] Confirmez la version de Nginx et les chemins d'installation avec nginx -V.
• [ ] Créez une sauvegarde horodatée de tout le répertoire de configuration (par exemple, sudo tar -czf /backups/nginx_$(date +%Y%m%d_%H%M%S).tar.gz -C /etc/nginx .).
• [ ] Validez la configuration actuelle dans le contrôle de version si vous utilisez Git.
• [ ] Notez l'état actuel du service (systemctl status nginx) et la fin du journal pertinent.
• [ ] Identifiez un point de récupération (fichier de sauvegarde, commit Git ou YAML Kubernetes exporté).
• [ ] Assurez-vous d'avoir accès à un environnement de test ou à un plan de retour arrière.
• [ ] Attribuez un responsable du changement (par exemple, « Priya Shah, responsable ingénierie ») et une cadence de revue (par exemple, revue hebdomadaire des changements de configuration).

Après avoir apporté des modifications

• [ ] Exécutez sudo nginx -t et confirmez le succès.
• [ ] Rechargez Nginx (sudo systemctl reload nginx) et vérifiez l'état du service.
• [ ] Vérifiez les journaux d'erreurs pour les nouvelles entrées (tail -n 20 /var/log/nginx/error.log).
• [ ] Testez les points de terminaison clés avec curl -I et vérifiez les codes de statut HTTP attendus.
• [ ] Vérifiez que la nouvelle configuration apparaît dans la sortie nginx -T.
• [ ] Mettez à jour la documentation et validez dans Git avec un message descriptif.
• [ ] Planifiez une revue post-changement (par exemple, vérifiez à nouveau dans 24 heures et pendant le jour ouvrable suivant).

Pièges courants et comment les éviter

• Sauter nginx -t : De nombreux incidents d'indisponibilité sont causés par une configuration non testée. Exécutez toujours le test de syntaxe.
• Sauvegarder uniquement nginx.conf : Nginx inclut souvent d'autres fichiers (conf.d/.conf, sites-enabled/). Sauvegardez tout le répertoire de configuration.
• Ne pas versionner la configuration : Sans Git, vous perdez l'historique des modifications et le retour arrière facile. Initialisez un dépôt Git comme décrit.
• Tester en production : Même avec la validation, une erreur de configuration peut provoquer un comportement inattendu. Utilisez un environnement de staging ou un déploiement canari lorsque c'est possible.
• Ignorer les journaux : Les journaux révèlent des échecs silencieux (par exemple, les délais d'attente amont) qui peuvent ne pas être évidents de l'extérieur. Surveillez-les régulièrement.
• Ne pas avoir de plan de restauration testé : Une sauvegarde est inutile si vous ne pouvez pas la restaurer rapidement. Pratiquez périodiquement la restauration dans un environnement non productif.
• Coder en dur les adresses IP dans la configuration : Utilisez des noms DNS ou des variables de gestion de configuration pour réduire les pannes lorsque les backends changent.
• Oublier de renouveler les certificats SSL : Automatisez le renouvellement (par exemple, Certbot) et surveillez les dates d'expiration.

Conclusion

La sauvegarde et la restauration de Nginx sont des compétences essentielles pour tout ingénieur d'exploitation ou développeur gérant une infrastructure web. En inventoriant votre environnement, en sauvegardant les configurations, en testant les changements en toute sécurité et en ayant un plan de récupération clair, vous pouvez minimiser les temps d'arrêt et maintenir la fiabilité du service.

Ce guide a fourni des commandes pratiques et des flux de travail pour l'inventaire des versions, la gestion sûre de la configuration, la vérification, la récupération après défaillance et les listes de contrôle opérationnelles. Le point clé à retenir est de toujours observer avant de changer, limiter le rayon d'impact, vérifier chaque étape et documenter les procédures de récupération.

Comme prochaine étape, choisissez une vérification à faible risque de cet article, effectuez une sauvegarde et pratiquez une restauration dans un environnement de test. Ensuite, intégrez ces procédures dans les opérations régulières de votre équipe, avec une attribution claire des responsabilités et une cadence de revue. Rappelez-vous : une sauvegarde n'est aussi bonne que votre capacité à la restaurer.