Une instance que personne ne maintient est une bombe à retardement : le jour où elle casse est le jour où tu découvres que la sauvegarde n'a jamais été testée. Cette page met en place une sauvegarde nocturne et la restaure une fois, met NetBox à jour vers une version choisie exprès, branche la tâche d'entretien, et laisse derrière elle une sonde qui te prévient quand quelque chose cloche.
Avant de commencer
$systemctl is-active netbox netbox-rq postgresqlactive active active
Sauvegardes nocturnes
$sudo mkdir -p && sudo chmod 700 #!/usr/bin/env bashset -euo pipefailstamp=$(date +%Y%m%d-%H%M)dest=sudo -u postgres pg_dump -Fc netbox > "$dest/netbox-$stamp.dump"files=(netbox/media netbox/netbox/configuration.py)for f in netbox/netbox/ldap_config.py local_requirements.txt gunicorn.py; do if [ -e "/$f" ]; then files+=("$f"); fidonetar -czf "$dest/netbox-files-$stamp.tar.gz" -C "${files[@]}"find "$dest" -name 'netbox-*' -mtime + -delete$sudo chmod 750 /usr/local/sbin/netbox-backup.sh$sudo systemctl daemon-reload$sudo systemctl enable --now netbox-backup.timer$sudo systemctl start netbox-backup.service$systemctl is-active netbox-backup.timeractive
$ls | sed 's/-[0-9]*-[0-9]*\././' | LC_ALL=C sort -unetbox-files.tar.gz netbox.dump
Si le service échoue
journalctl -u netbox-backup -n 20 donne la raison. Les habituelles : pg_dump ne peut pas se connecter (PostgreSQL est arrêté, ou pg_hba.conf a perdu sa ligne local all postgres peer) ; tar se plaint d'un netbox/media manquant (le dossier a été déplacé, corrige le chemin) ; plus de place dans .
Exercice de restauration
$latest=$(ls -t /netbox-*.dump | head -1)$sudo -u postgres createdb -O netbox netbox_drill$sudo -u postgres pg_restore --no-owner --role=netbox -d netbox_drill < "$latest"$sudo -u postgres psql -d netbox_drill -tAc 'SELECT count(*) > 0 FROM dcim_site't
$sudo -u postgres dropdb netbox_drillMettre NetBox à jour
$sudo systemctl start netbox-backup.service$cd $sudo git fetch --tags$sudo git checkout $sudo ./upgrade.sh$sudo systemctl restart netbox netbox-rq$sudo git -C describe --tags --exact-match$curl -skf -H 'Authorization: Token ' https:///api/status/ | python3 -c 'import sys,json; print("v" + json.load(sys.stdin)["netbox-version"])'$curl -sk -o /dev/null -w '%{http_code}' https:///login/200
Ensuite, ouvre https:/// et clique sur une page d'équipement et une recherche : que l'API réponde ne veut pas dire que l'interface s'affiche, puisque les fichiers statiques et les plugins peuvent casser l'un sans l'autre.
Si un plugin bloque la mise à jour
- Regarde le tableau de compatibilité du plugin sur son dépôt. S'il existe une release compatible, fige-la dans
local_requirements.txt(netbox-bgp==0.15.0) et relancesudo ./upgrade.sh. - S'il n'en existe pas, retire le plugin de
PLUGINSdansconfiguration.pyet delocal_requirements.txt, mets à jour, et remets-le quand le plugin aura rattrapé. Ses tables restent dans la base ; rien n'est perdu, les pages disparaissent juste en attendant. - Si les notes de version disent que le plugin est devenu une fonction native (ça arrive), migre les données avec les instructions du plugin avant la mise à jour.
Retour arrière
$sudo systemctl stop netbox netbox-rq$cd $sudo git checkout $(sudo git describe --tags --abbrev=0 ^)$latest=$(ls -t /netbox-*.dump | head -1)$sudo -u postgres dropdb netbox && sudo -u postgres createdb -O netbox netbox$sudo -u postgres pg_restore --no-owner --role=netbox -d netbox < "$latest"$sudo ./upgrade.sh$sudo systemctl start netbox netbox-rqEntretien
$sudo ln -sf /contrib/netbox-housekeeping.sh /etc/cron.daily/netbox-housekeeping$sudo /venv/bin/python /netbox/manage.py housekeeping$run-parts --test /etc/cron.daily | grep netbox/etc/cron.daily/netbox-housekeeping
Logs et disque : gunicorn écrit sur la sortie standard, que systemd capture dans le journal ; plafonne-le. nginx et Apache font tourner leurs propres fichiers via logrotate, livré avec le paquet.
[Journal]SystemMaxUse=500MPuis sudo systemctl restart systemd-journald.
Chaque semaine, cinq minutes :
| Vérification | Commande | Attendu |
|---|---|---|
| Les deux services tournent | systemctl is-active netbox netbox-rq | active deux fois |
| La dernière sauvegarde a tourné | systemctl list-timers netbox-backup.timer | un LAST de moins de 24 h |
| Taille de sauvegarde cohérente | ls -lh ${BACKUP_DIR} | des tailles du même ordre que la semaine dernière |
| Disque | df -h / | sous 80 % |
| File calme | redis-cli info memory | used_memory_human stable |
| Nouvelle release ? | page des releases | lire les notes, planifier la mise à jour |
Supervision de base
$systemctl status netbox netbox-rq --no-pager | grep Active$curl -skf -H "Authorization: Token " https:///api/status/ | python3 -m json.tool$curl -skf -H 'Authorization: Token ' https:///api/status/ | python3 -c 'import sys,json; print(json.load(sys.stdin)["rq-workers-running"] >= 1)'True
Terminé
Chaque nuit un dump et une archive atterrissent dans , tu en as restauré un à la main, NetBox tourne en , le journal des changements est purgé chaque jour, et une sonde sait quand les workers s'arrêtent. La page suivante arrête de cliquer : un utilisateur d'automatisation, pynetbox, des imports en masse, des webhooks et des scripts personnalisés.