Planifier des tâches automatiques sur un VPS Linux avec cron

Cron est le planificateur de tâches standard sur Linux : il exécute des scripts, des sauvegardes ou des mises à jour à des horaires précis, sans intervention humaine. Sur un VPS Linux (serveur virtuel privé avec sa propre adresse IP, isolé par virtualisation KVM ou LXC), maîtriser cron est une compétence fondamentale pour tout administrateur qui veut automatiser la maintenance et réduire les risques d'oubli.

Ce guide s'adresse aux administrateurs qui gèrent un ou plusieurs serveurs Linux et souhaitent automatiser leurs tâches récurrentes : vérifications de ressources (RAM, CPU, espace disque SSD), sauvegardes nocturnes, redémarrages programmés de services. Que vous administriez un serveur dédié, un serveur cloud ou un serveur VPS, ces configurations s'appliquent directement depuis votre terminal.

Comment fonctionne le daemon cron

Le daemon cron (Vixie Cron sur Debian/Ubuntu) se lance au démarrage du système d'exploitation et se réveille chaque minute pour examiner l'ensemble des crontabs chargées en mémoire. Il compare les cinq champs de temps de chaque entrée à l'heure système courante ; si tous correspondent, la commande est lancée dans un sous-shell avec les droits de l'utilisateur propriétaire de la crontab.

Cron fonctionne identiquement sur tous les environnements Linux, que ce soit sur un serveur physique dédié ou sur des serveurs virtuels issus de la virtualisation (KVM, LXC). Sur un serveur virtuel VPS, un même hôte peut héberger des dizaines de crontabs indépendantes pour des utilisateurs différents, sans qu'aucune n'interfère avec les autres. C'est l'un des avantages de la planification par daemon : la configuration reste entièrement dans l'espace utilisateur.

Sur un VPS Ubuntu ou Debian, le daemon cron lit trois sources :

• Les crontabs utilisateur stockées dans /var/spool/cron/crontabs/ (une par compte Unix).
• Le fichier système /etc/crontab, qui inclut un champ utilisateur explicite pour les tâches d'administration.
• Les fichiers de configuration déposés dans /etc/cron.d/ par les paquets système (même format qu'/etc/crontab).

Les répertoires /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ et /etc/cron.monthly/ contiennent des scripts exécutables appelés par run-parts. Ils sont pratiques pour les tâches de maintenance courantes (nettoyage de logs, vérification de l'espace disque SSD, contrôles de configuration système) qui n'ont pas besoin d'un horaire à la minute près.

La syntaxe complète d'une entrée crontab

Chaque ligne active d'une crontab utilisateur suit ce schéma :

minute  heure  jour-du-mois  mois  jour-de-semaine  commande

Plages de valeurs autorisées :

• minute : 0-59
• heure : 0-23
• jour-du-mois : 0-31
• mois : 0-12 (ou jan à dec)
• jour-de-semaine : 0-7 (0 et 7 représentent tous les deux dimanche, ou sun à sat)

Opérateurs disponibles dans chaque champ :

• * : toutes les valeurs du champ
• */n : toutes les n unités (ex. */15 en minutes = toutes les 15 minutes)
• a-b : plage inclusive (ex. 1-5 = lundi à vendredi)
• a,b,c : liste de valeurs (ex. 0,6,12,18 = quatre fois par jour)
• a-b/n : plage avec pas (ex. 8-20/2 = de 8h à 20h, toutes les 2 heures)

Règle importante : si les champs jour-du-mois ET jour-de-semaine sont tous deux restreints (pas d'astérisque), cron exécute la tâche quand l'un ou l'autre correspond. Par exemple, 0 4 1 * 5 s'exécute le 1er de chaque mois et tous les vendredis à 4h.

Exemples pratiques pour administrer un serveur VPS

Voici des exemples directement utilisables par les administrateurs d'un serveur dédié ou d'un serveur VPS Linux. Ces configurations couvrent les cas les plus courants : sauvegardes, mises à jour, gestion des logs et surveillance des ressources RAM et CPU.

# Sauvegarde du dossier /var/data chaque nuit à 2h30
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# Mise à jour des listes de paquets chaque lundi à 6h
0 6 * * 1 apt-get update -qq >> /var/log/apt-update.log 2>&1

# Nettoyage des fichiers temporaires toutes les 4 heures
0 */4 * * * find /tmp -mtime +1 -delete

# Rechargement de la configuration du serveur Web Nginx sans coupure de service
0 3 * * sun nginx -t && systemctl reload nginx

# Rapport RAM/CPU quotidien à 8h
0 8 * * * free -h >> /var/log/ram-report.log && top -bn1 | head -5 >> /var/log/cpu-report.log

# Redémarrage d'un service de jeu chaque dimanche à 3h
0 3 * * sun systemctl restart gameserver.service

# Vérification de la résolution DNS toutes les heures (diagnostic réseau)
0 * * * * dig @8.8.8.8 elypsecloud.com +short >> /var/log/dns-check.log 2>&1

La redirection 2>&1 envoie aussi la sortie d'erreur dans le fichier de log, ce qui est indispensable pour déboguer. Définir MAILTO="" en haut de la crontab supprime les mails de sortie envoyés par cron au compte admin du serveur.

Éditer sa crontab utilisateur

Ne modifiez jamais directement les fichiers sous /var/spool/cron/crontabs/. Utilisez toujours la commande dédiée dans votre terminal, avec sudo pour les tâches root :

# Ouvrir l'éditeur pour l'utilisateur courant
crontab -e

# Lister la crontab active
crontab -l

# Supprimer toute la crontab
crontab -r

# Administrer la crontab d'un autre utilisateur (sudo requis)
sudo crontab -e -u www-data

L'éditeur par défaut est généralement nano. Pour utiliser vim :

VISUAL=vim crontab -e

Cron détecte automatiquement les modifications du spool et recharge les configurations concernées. Il n'est pas nécessaire de redémarrer le daemon après chaque modification de crontab.

Cron système : /etc/crontab et /etc/cron.d

Pour les tâches d'administration système qui doivent tourner sous un utilisateur spécifique sur vos serveurs virtuels, préférez /etc/cron.d/. Le format est identique à /etc/crontab, avec un champ utilisateur entre le cinquième champ temporel et la commande :

# /etc/cron.d/mon-service
# minute heure jour mois dow utilisateur commande
0 1 * * * root /usr/local/bin/nightly-cleanup.sh >> /var/log/cleanup.log 2>&1

Contraintes des fichiers dans /etc/cron.d/ : ils doivent être détenus par root, ne pas être inscriptibles par le groupe ou les autres, et leurs noms ne peuvent contenir que des lettres, chiffres, tirets et underscores (aucun point, sous peine d'être ignorés par cron).

Les scripts dans /etc/cron.daily/ et les répertoires analogues doivent être exécutables (chmod +x) et respecter les mêmes règles de nommage. Ces répertoires sont gérés par le système : les paquets Debian/Ubuntu y déposent leurs propres scripts lors de leur installation.

Déboguer une tâche cron qui ne s'exécute pas

Le premier réflexe est de consulter les logs système. Sur un serveur VPS administré avec systemd, la commande journalctl donne accès à tous les événements du daemon cron. Ces logs sont précieux pour identifier une configuration défaillante avant qu'elle n'affecte votre infrastructure :

# Voir les logs cron des dernières 24 heures
journalctl -u cron --since "24 hours ago"

# Suivre les logs en temps réel
journalctl -u cron -f

# Chercher les erreurs d'une tâche spécifique
journalctl -u cron | grep "CMD (/usr/local/bin/backup"

Cron loggue par défaut le démarrage de chaque tâche (niveau 1). Pour activer aussi le logging de fin d'exécution et des échecs sur Debian/Ubuntu, éditez les configurations de démarrage :

# /etc/default/cron
EXTRA_OPTS="-L 7"

Rechargez ensuite le daemon : sudo systemctl restart cron.

Les causes d'échec les plus fréquentes pour les administrateurs d'un serveur VPS Linux :

• Environnement minimal : cron exécute les commandes avec un PATH limité (/usr/bin:/bin). Si votre script appelle python3, node ou un binaire hors de ce chemin, spécifiez le chemin absolu ou définissez PATH=/usr/local/bin:/usr/bin:/bin en haut de la crontab.
• Sortie non redirigée : sans redirection 2>&1 >> /fichier.log, les erreurs sont envoyées par mail au compte Unix, qui ne les lit jamais sur un VPS.
• Script non exécutable : vérifiez chmod +x /usr/local/bin/monscript.sh.
• Chemins relatifs : cron exécute les commandes depuis le répertoire home de l'utilisateur. Utilisez toujours des chemins absolus dans vos scripts et vos fichiers de configuration.
• Daemon inactif : vérifiez sudo systemctl status cron.
• Résolution DNS absente : si votre script contacte un serveur distant, vérifiez que la résolution DNS fonctionne dans l'environnement cron avec dig ou host depuis le même compte.

Tester une commande dans l'environnement cron

Pour simuler l'environnement minimal de cron avant d'ajouter une entrée à la crontab :

env -i HOME=/root PATH=/usr/bin:/bin /usr/local/bin/backup.sh

Si la commande échoue ici mais réussit dans votre terminal normal, le problème vient de l'environnement. Ajoutez les variables manquantes en tête de votre crontab ou directement dans le script de sauvegarde ou de maintenance.

Alternative : les timers systemd

Depuis Ubuntu 16.04 et Debian 9, systemd propose ses propres timers comme alternative au daemon cron. Ils offrent un meilleur logging (chaque exécution est journalisée sous son propre service) et supportent des intervalles relatifs au dernier démarrage (OnBootSec). Cette flexibilité est appréciable lors d'une migration vers un nouveau serveur ou après un redémarrage imprévu.

Pour un VPS Linux hébergeant des services gérés par systemd (serveur Web Nginx, serveur de jeu ou agent de monitoring), les timers peuvent remplacer avantageusement cron pour les tâches de maintenance liées à ces services :

# Voir tous les timers actifs
systemctl list-timers --all

# Vérifier les logs d'un timer spécifique
journalctl -u mon-service.timer

Pour les cas simples (scripts ponctuels, sauvegardes, nettoyages), cron reste plus léger et plus universel sur les serveurs virtuels et les serveurs Linux administrés en ligne de commande.

Sécurité de cron sur un serveur VPS

Quelques bonnes pratiques d'administration pour ne pas introduire de vulnérabilités via la planification de tâches sur votre serveur privé ou votre serveur cloud :

• N'exécutez jamais une tâche en root si un compte moins privilégié suffit. Utilisez sudo uniquement quand c'est nécessaire.
• Vérifiez les permissions des scripts appelés : un script accessible en écriture par tous peut être remplacé par un attaquant.
• Utilisez /etc/cron.allow pour restreindre les comptes autorisés à créer des crontabs sur vos serveurs virtuels.
• Redirigez la sortie dans un fichier de log plutôt que dans /dev/null : les logs permettent de détecter des anomalies et de tracer les exécutions sur votre infrastructure.
• Couplez cron avec un pare-feu actif configuré avec nftables ou UFW : une tâche qui se connecte à une adresse IP externe pour télécharger des mises à jour doit passer par des règles réseau adaptées.
• Versionnez vos scripts avec Git : un historique vous permet de revenir à une version antérieure si une modification introduit un bug dans vos automatisations.

Pour aller plus loin sur la sécurisation globale de votre VPS, consultez notre guide Sécuriser un serveur dédié - premiers réglages et notre guide sur la limitation des tentatives SSH.

Pour automatiser la surveillance de vos ressources, cron s'intègre naturellement avec les guides sur la surveillance de l'espace disque et sur l'automatisation des mises à jour de sécurité.