Checklist de maintenance pour un serveur Linux

Ce que recouvre réellement la maintenance d’un serveur Linux

La maintenance d’un serveur Linux consiste en une courte liste de contrôles effectués selon un calendrier fixe, et non en un projet qui se termine un jour. Chaque semaine, vérifiez que les mises à jour sont installées, que le disque dispose de suffisamment d’espace, qu’aucun service ne s’est arrêté et que la tâche de sauvegarde est terminée. Chaque mois, testez une restauration, vérifiez l’expiration des certificats, auditez les comptes et les clés, puis supprimez les anciens kernels et journaux. À chaque nouvelle version de la distribution, planifiez la mise à niveau et effectuez enfin le redémarrage que vous repoussez constamment.

La construction du serveur est une autre tâche. Les dix premières minutes sur un nouveau VPS couvrent cette étape. Cette page concerne l’année qui suit. Chaque élément ci-dessous indique la panne qu’il permet d’éviter, car une checklist sans conséquences est rapidement abandonnée.

Les commandes présentées ici sont données à titre d’exemple et doivent être lues avant leur exécution. Comparez leur sortie avec celle de votre propre serveur, car une valeur normale pour l’espace libre ou le nombre de processus dépend de l’usage de la machine. Lorsque la vérification diffère selon la distribution, le texte le précise. Les exemples utilisent Debian et Ubuntu avec apt. Dans la famille RHEL, l’outil est dnf et plusieurs chemins sont différents.

Comment choisir une fréquence de maintenance Linux que vous respecterez

Les vérifications hebdomadaires couvrent les éléments qui changent sans intervention de votre part : paquets, utilisation du disque, état des services et tâches planifiées. Ces éléments évoluent seuls. Une semaine est donc environ la durée maximale pendant laquelle vous pouvez les laisser sans contrôle.

Les vérifications mensuelles couvrent l’usure progressive : certificats proches de leur expiration, comptes que personne n’a supprimés, noyaux qui s’accumulent dans /boot et fichiers journaux qui dépassent une règle de rotation devenue inadaptée. Aucun de ces problèmes ne provoquera une panne demain. Tous finiront par en provoquer une.

Les vérifications des releases suivent le calendrier. Une release de distribution est le seul élément de maintenance soumis à une échéance externe, car la prise en charge de votre version actuelle prend fin, que vous soyez prêt ou non.

Planifiez ces opérations sur un créneau fixe : le lundi matin pour la vérification hebdomadaire et le premier jour du mois pour la vérification mensuelle. Une checklist exécutée « quand vous aurez le temps » n’est pas une checklist. Au-delà de quelques machines, exécutez ces opérations depuis un point central plutôt que manuellement. C’est le sujet de la gestion de plusieurs serveurs Linux depuis un point central.

Chaque semaine : les mises à jour ont-elles réellement été installées ?

Activer unattended-upgrades ne signifie pas savoir s’il s’est exécuté. Le service peut être masqué, la configuration peut être limitée à une source que vous n’utilisez pas, et un seul paquet conservé peut faire échouer toutes les exécutions suivantes. Son installation est décrite dans les mises à jour de sécurité automatiques sur Ubuntu. La vérification hebdomadaire consiste à prouver que ce que vous avez installé a bien effectué son travail.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable est la mesure la plus fiable, car il indique l’état actuel plutôt que l’intention. La présence de mises à jour de sécurité dans cette liste signifie que l’automatisation ne fonctionne pas correctement. Consultez donc le journal avant de considérer la machine comme à jour. Un paquet bloqué avec apt-mark hold est ignoré indéfiniment et ne signale rien. C’est pourquoi apt-mark showhold doit être vérifié au même moment.

Le problème évité : exécuter pendant des mois un paquet dont une vulnérabilité est connue tout en pensant que les mises à jour étaient automatiques.

Espace disponible sur le disque et les inodes : contrôle hebdomadaire

Un système de fichiers root plein provoque des problèmes qui semblent sans rapport avec l’espace disque. La base de données refuse les écritures, la journalisation s’arrête, une mise à niveau de paquet échoue après une configuration partielle et, dans certaines configurations, vous ne pouvez pas ouvrir de nouvelle session, car le système ne peut pas écrire ses propres fichiers.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i est la moitié du contrôle que la plupart des administrateurs négligent. Les inodes sont des structures en nombre fixe qui contiennent les métadonnées des fichiers. Un système de fichiers peut en manquer alors que df -h indique encore plusieurs gigaoctets disponibles. Les écritures échouent alors avec No space left on device, malgré un affichage indiquant qu’il reste de l’espace libre. La première fois, cela peut faire perdre une heure de diagnostic. Des millions de petits fichiers, générés par une file d’attente de messagerie bloquée ou un répertoire de sessions jamais nettoyé, en sont généralement la cause.

du -xh reste sur un seul système de fichiers, ce qui convient à un serveur utilisant des bind mounts ou du stockage attaché. Sur un hôte Docker, la cause se trouve généralement dans les couches d’images et les volumes inutilisés. Vous pouvez les supprimer comme indiqué dans nettoyer l’espace disque Docker sur un VPS.

L’espace libre renseigne sur la capacité. Le stockage sous-jacent peut tomber en panne selon son propre calendrier. Il s’agit d’un contrôle distinct, décrit dans surveiller l’état des disques sur un VPS.

Chaque semaine : qu’est-ce qui s’est arrêté sans vous prévenir ?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Une unité qui a planté et atteint sa limite de redémarrages passe à l’état failed et y reste, sans émettre le moindre message. Aucun e-mail ne vous en informe. list-timers est la commande la plus utile ici : elle indique quand chaque timer s’est exécuté pour la dernière fois et quand il s’exécutera ensuite. Ainsi, une valeur LAST plus ancienne que l’intervalle du timer indique que la tâche ne s’est pas exécutée.

Consultez le journal de l’unité avant de la redémarrer, avec journalctl -u <unit> -n 100 --no-pager. Un redémarrage efface le symptôme. Vous n’aurez alors aucune raison de vérifier à nouveau le service jusqu’à ce que le problème se reproduise à une heure encore moins favorable.

Cette vérification évite qu’un agent de supervision, un worker de file d’attente ou un service de sauvegarde reste arrêté depuis un pic de consommation mémoire survenu trois semaines plus tôt.

Hebdomadaire : la tâche de sauvegarde s’est-elle réellement terminée ?

Une sauvegarde planifiée et une sauvegarde terminée sont deux faits différents. Une seule des deux permet une restauration. Vérifiez la fin de l’exécution.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

Vérifiez deux éléments. La dernière exécution doit se terminer avec le code 0, et l’archive la plus récente doit être récente et avoir une taille conforme à vos attentes. Un fichier de sauvegarde qui ne fait soudainement plus qu’un dixième de sa taille habituelle correspond à un dump en échec qui a tout de même créé un fichier. C’est la forme la plus dangereuse d’échec d’une sauvegarde, car tout ce qui suit semble fonctionner normalement.

Si votre script envoie un dump vers un compresseur dans un pipe, ajoutez set -o pipefail au début. Sans cette option, le code retour du pipe est celui du compresseur, qui s’est exécuté correctement : il a compressé le message d’erreur. La tâche signale alors une réussite chaque nuit, tout en écrivant une petite archive vide.

Mensuel : restaurer une sauvegarde ailleurs

C’est l’étape que la plupart des gens sautent, alors que c’est elle qui détermine si le reste de la liste a servi à quelque chose.

Restaurez la sauvegarde sur une autre machine ou dans un conteneur vierge, jamais par-dessus les données en production. Ouvrez ensuite les éléments restaurés et vérifiez qu’ils sont exploitables. Comptez les lignes d’une table. Ouvrez un document. Connectez-vous à l’application restaurée. Une extraction terminée prouve que l’archive est lisible, mais rien de plus.

Les outils de dépôt disposent de leurs propres commandes de vérification : restic check --read-data-subset=5% et borg check --verify-data lisent les données stockées, et pas seulement l’index. Exécutez-les et considérez-les comme un smoke test, pas comme un remplacement de la restauration. La vérification confirme que les octets ont été conservés. Une restauration confirme qu’il s’agit bien des octets dont votre application a besoin.

Deux détails que l’on apprend généralement à ses dépens. Testez la passphrase de déchiffrement sur une machine qui ne contient pas déjà la clé dans un agent, car une sauvegarde que vous ne pouvez pas déchiffrer n’est pas une sauvegarde. Mesurez aussi la durée de la restauration, car cette durée correspond à votre véritable temps de reprise. Vous la découvrirez généralement au moment d’une panne.

Chaque mois : quels certificats vont bientôt expirer ?

L’automatisation du renouvellement peut échouer silencieusement. Le timer certbot peut renouveler le fichier sur le disque alors que le serveur web continue de servir l’ancien certificat chargé en mémoire, parce que le deploy hook qui recharge le service ne s’est pas exécuté. Interrogez donc le serveur en cours d’exécution pour savoir quel certificat il sert, depuis l’extérieur de la machine.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

L’option -servername définit le SNI (indication du nom du serveur). Elle est requise pour toute adresse qui héberge plusieurs sites. Sinon, vous recevez le certificat par défaut au lieu du vôtre. Si certbot a été installé depuis un snap, le timer porte un autre nom. Recherchez donc le mot concerné plutôt qu’une unité dont vous avez supposé le nom.

N’oubliez pas les certificats qui ne disposent d’aucune automatisation : ceux d’un serveur de messagerie, d’un VPN ou d’une autorité de certification interne. Ce sont eux qui expirent pendant le week-end. Les navigateurs et les clients les refusent directement au lieu d’afficher un avertissement.

Mensuel : utilisateurs, accès sudo et clés SSH

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T affiche la configuration effective après la fusion de tous les fichiers Include. C’est cette configuration que le daemon utilise réellement. Les images Ubuntu récentes fournissent des fichiers drop-in dans /etc/ssh/sshd_config.d/. Ceux-ci peuvent remplacer les paramètres du fichier principal. Lire uniquement sshd_config peut donc donner une conclusion opposée à la réalité. Sur la famille RHEL, le groupe administratif est wheel et non sudo. Adaptez donc la ligne getent.

Lisez ensuite directement les fichiers authorized_keys. L’accès est accordé par clé, et non par compte. Une clé laissée par un prestataire dont le contrat s’est terminé il y a six mois permet encore de se connecter. Aucun inventaire des utilisateurs ne la signalera. Les clés contiennent un champ de commentaire. Utilisez-le et supprimez toute clé que vous ne pouvez pas attribuer à une personne.

Pour l’historique des connexions, journalctl -t sshd --since "30 days ago" | grep -i accepted recherche l’identifiant syslog et non le nom d’une unité. C’est important, car Ubuntu 24.04 active SSH via un socket. Chaque connexion est donc journalisée dans une unité générée pour cette connexion. Une commande journalctl -u ssh simple peut ne pas les afficher.

Mensuel : anciens noyaux et partition /boot pleine

/boot est souvent une partition distincte de quelques centaines de mégaoctets sur une image VPS standard. Chaque mise à jour du noyau y ajoute une image et un initramfs. Lorsqu’elle est pleine, la mise à niveau suivante échoue en cours d’exécution et laisse des paquets non configurés. Il est préférable de ne pas découvrir cette situation par surprise un vendredi.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r d’abord, toujours : il indique le noyau que vous utilisez actuellement, et celui-ci doit rester en place, quels que soient les éléments supprimés. apt autoremove prend en charge le cas courant sur Debian et Ubuntu, car les noyaux sont marqués comme installés automatiquement et le noyau actuel est protégé. Les cas particuliers, notamment un noyau installé manuellement ou un /boot déjà suffisamment plein pour bloquer apt lui-même, sont traités dans supprimer les anciens noyaux sur Ubuntu.

Croissance des journaux et journal systemd : contrôle mensuel

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug effectue une simulation et n’écrit rien. Cette commande peut donc être exécutée sans risque sur un serveur en production. Il est utile de l’exécuter, car les règles de rotation correspondent aux chemins : lorsqu’une application change l’emplacement de ses journaux pendant une mise à niveau, son propre fichier de configuration ne la couvre plus. Le fichier grossit alors sans limite jusqu’à remplir le disque.

systemd limite la taille du journal, mais en fonction d’une fraction du système de fichiers plutôt que d’une valeur que vous avez choisie. Définissez SystemMaxUse= dans /etc/systemd/journald.conf, puis redémarrez systemd-journald si vous voulez fixer une limite précise. sudo journalctl --vacuum-time=14d libère immédiatement de l’espace. Il s’agit d’une action ponctuelle et non d’une policy : associez-la donc à la modification de configuration.

Par version : le redémarrage que vous repoussez sans cesse

Un paquet de kernel mis à jour sur le disque n’est pas un kernel en cours d’exécution. Tant que vous n’avez pas redémarré, la machine utilise toujours l’ancien kernel. Le live patching, lorsqu’il est disponible, ne couvre qu’une partie des correctifs.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Ce fichier indicateur est une convention Debian et Ubuntu, créée par les scripts des paquets. Les systèmes de la famille RHEL ne le créent pas. Dans ce cas, la question équivalente est résolue par needs-restarting -r, fourni par dnf-utils. needrestart, installé par défaut sur les images récentes de serveur Ubuntu, répond au niveau inférieur au kernel : il liste les processus qui utilisent encore une bibliothèque remplacée sur le disque. C’est pourquoi une version corrigée d’OpenSSL ne prend effet qu’après le redémarrage des services qui l’utilisent.

Planifiez le redémarrage au lieu de l’éviter. Dans /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; et Unattended-Upgrade::Automatic-Reboot-Time "03:00";, vous déléguez la décision à l’heure que vous avez choisie. Un redémarrage planifié est également le seul moyen de vérifier que la machine redémarre correctement, car une entrée fstab incorrecte ou un service que vous n’avez jamais activé se manifeste au démarrage, et nulle part ailleurs.

Pour chaque version : planifier la mise à niveau de la distribution

Les versions Ubuntu LTS bénéficient de cinq ans de support standard, tandis que les versions intermédiaires en bénéficient pendant neuf mois. Ce choix détermine donc votre charge de travail de mise à niveau pour les années à venir. Consultez LTS ou version intermédiaire sur un serveur pour comprendre ce compromis.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade lit ce fichier et Prompt=lts limite la procédure aux mises à niveau d’une version LTS vers une autre version LTS. Le parcours LTS vers LTS devient normalement disponible à la sortie de la première mise à jour intermédiaire de la nouvelle version, et non le jour de sa sortie. Vérifiez donc la version proposée à votre machine au lieu de planifier la mise à niveau à partir d’une date supposée. La procédure détaillée se trouve dans mettre Ubuntu 24.04 à niveau vers 26.04.

Prévoyez une marge de trois mois. Prenez un snapshot dont vous avez testé la restauration, répertoriez vos dépôts apt tiers — la mise à niveau les désactive et chacun doit être adapté à la nouvelle version — puis définissez la procédure de rollback avant de commencer. En août 2026, Ubuntu 24.04 LTS bénéficie encore du support standard jusqu’en avril 2029. Il s’agit donc d’une question de planification, pas d’une urgence.

À automatiser et à garder manuel

Automatisez les décisions que vous avez déjà prises : mises à jour de sécurité, rotation des journaux, renouvellement des certificats et tâches de sauvegarde. Automatisez également les alertes, car un contrôle qui dépend de votre mémoire ne sera pas effectué à 2 h du matin. Un outil de supervision externe, comme la supervision d’état auto-hébergée avec Uptime Kuma, détecte le seul problème qu’aucun script exécuté sur le serveur ne peut signaler : l’inaccessibilité du serveur.

Gardez deux opérations manuelles : le test de restauration et l’audit des comptes. Dans les deux cas, une personne doit déterminer si le résultat est correct. Si vous préférez consulter l’état du système dans un navigateur plutôt que dans un terminal, Cockpit ou Webmin pour administrer un serveur compare les deux consoles web courantes.

L’automatisation doit ensuite être contrôlée elle-même. C’est pourquoi le premier élément hebdomadaire de cette liste consiste à vérifier l’outil de mise à jour. Une automatisation qui échoue silencieusement est pire que l’absence d’automatisation, car elle supprime à la fois le signal d’échec et l’habitude de vérifier.

Toute la checklist au même endroit

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

À quelle fréquence dois-je effectuer la maintenance d’un serveur Linux ?

Chaque semaine pour les éléments qui changent seuls : état des mises à jour, espace disponible sur les disques et les inodes, unités en échec et vérification de la fin du job de sauvegarde. Chaque mois pour les problèmes qui apparaissent progressivement : test de restauration, expiration des certificats, audit des comptes et des clés SSH, anciens noyaux et croissance des journaux. Une fois par version de distribution pour la mise à niveau et le redémarrage sur le noyau courant. Sur un serveur en bon état, le contrôle hebdomadaire prend quelques minutes. C’est précisément l’intérêt de l’effectuer chaque semaine plutôt que d’attendre qu’un problème apparaisse.

Pourquoi tester une restauration si le job de sauvegarde indique qu’il a réussi ?

Parce que le job indique son propre code de sortie, et que ce code peut être correct alors que l’archive est inutilisable. Un dump envoyé vers un compresseur sans set -o pipefail renvoie le code du compresseur. Un dump en échec qui n’a produit qu’un message d’erreur peut donc se terminer avec le code 0 et écrire un petit fichier. Effectuez la restauration sur une autre machine, ouvrez les données et comptez un élément. Mesurez également la durée de la restauration. Cette durée correspond à votre temps réel de reprise.

Dois-je redémarrer après chaque mise à jour du noyau ?

Vous devez redémarrer avant que le nouveau noyau soit celui qui s’exécute. Sur Debian et Ubuntu, la présence de /var/run/reboot-required indique qu’un paquet l’a demandé, et /var/run/reboot-required.pkgs indique lequel. Sur la famille RHEL, ce fichier n’existe pas. La commande needs-restarting -r de dnf-utils répond à la même question. Définissez une fenêtre de redémarrage automatique dans /etc/apt/apt.conf.d/50unattended-upgrades plutôt que de repousser ce redémarrage indéfiniment. Une machine qui n’a pas redémarré depuis un an possède à la fois un ancien noyau et un chemin de démarrage qui n’a pas été testé.

Lesquels de ces contrôles puis-je automatiser sans risque ?

Automatisez les actions dont la décision est déjà prise : mises à jour de sécurité, rotation des journaux, renouvellement des certificats et sauvegardes planifiées. Automatisez aussi les notifications, afin qu’une unité en échec ou qu’un disque qui se remplit vous soit signalé sans qu’une personne doive exécuter une commande. Gardez le test de restauration et l’audit des clés manuels, car chacun nécessite qu’une personne vérifie si le résultat est correct. Ajoutez ensuite un contrôle de l’automatisation elle-même, car l’échec silencieux d’un updater ressemble exactement à un fonctionnement normal.