Sauvegardes nocturnes, rotation de journaux, redémarrage automatique d'un serveur de jeu, envoi d'un rapport sur la RAM et le SSD : toutes ces opérations répétitives peuvent être entièrement automatisées sur un VPS Linux sans intervention manuelle. Deux mécanismes complémentaires coexistent sur toutes les distributions modernes : cron, le planificateur historique accessible depuis le terminal, et les systemd timers, l'alternative intégrée à systemd. Ce tutoriel guide l'admin pas à pas pour configurer, déboguer et choisir entre les deux outils selon la nature des tâches planifiées sur un serveur VPS ou dédié sous Ubuntu, Debian ou Rocky Linux.
Comprendre cron et la syntaxe crontab
Le daemon crond (ou cron selon la distribution) surveille les fichiers
crontab et déclenche les commandes aux moments programmés. Ce daemon est présent par défaut sur tout
serveur VPS Linux bien configuré (Ubuntu, Debian, Rocky Linux) et s'intègre à l'infrastructure de
journalisation du serveur cloud. Chaque ligne d'un crontab suit la structure suivante :
minute heure jour-du-mois mois jour-de-semaine commande
* * * * * /chemin/vers/script.shLes cinq premiers champs définissent la planification :
- minute : valeur entre 0 et 59
- heure : valeur entre 0 et 23
- jour-du-mois : valeur entre 1 et 31
- mois : valeur entre 1 et 12
- jour-de-semaine : valeur entre 0 et 7 (0 et 7 = dimanche)
Un astérisque * signifie « toutes les valeurs ». Des raccourcis existent :
@daily correspond à 0 0 * * *, @weekly à 0 0 * * 0
et @reboot exécute la commande au prochain démarrage du serveur dédié ou VPS Linux.
Exemples de planifications courantes sur un serveur dédié ou VPS Linux :
# Sauvegarde des données chaque nuit a 3 h 30
30 3 * * * /opt/backups/backup-fivem.sh
# Rotation des journaux tous les dimanches a minuit
0 0 * * 0 /usr/sbin/logrotate /etc/logrotate.conf
# Rapport RAM et disque toutes les 6 heures
0 */6 * * * df -h / >> /var/log/disk-report.log
# Nettoyage des fichiers temporaires le 1er de chaque mois
0 2 1 * * find /tmp -mtime +7 -delete
# Rechargement de la configuration Nginx après mise à jour des certificats TLS
0 4 * * * nginx -t && systemctl reload nginxConfigurer un crontab utilisateur
Chaque utilisateur du serveur VPS Linux dispose de son propre crontab, stocké dans
/var/spool/cron/crontabs/. Les commandes s'exécutent avec les droits de cet utilisateur,
ce qui est une bonne pratique de sécurité pour l'admin du serveur cloud : évitez d'exécuter des
tâches système sensibles depuis le crontab root si un utilisateur dédié suffit.
# Ouvrir l'éditeur du crontab de l'utilisateur courant
crontab -e
# Lister le crontab actuel
crontab -l
# Supprimer le crontab (attention : irréversible)
crontab -r
# Éditer le crontab d'un autre utilisateur (en tant que root)
crontab -e -u fivem-userPar défaut, crontab utilise l'éditeur défini dans la variable $EDITOR (souvent
nano ou vi). Pour forcer nano sur votre serveur VPS :
EDITOR=nano crontab -eLes sorties standard et d'erreur sont envoyées par email à l'utilisateur si le champ
MAILTO n'est pas défini. Pour éviter les mails parasites sur un serveur cloud sans MTA
configuré, redirigez la sortie dans un fichier de log :
# Supprimer toute sortie de la commande
* * * * * /opt/scripts/check.sh > /dev/null 2>&1
# Conserver seulement les erreurs dans un fichier de log
0 3 * * * /opt/backups/backup.sh >> /var/log/backup.log 2>&1Cron système : /etc/cron.d et /etc/crontab
Pour les tâches d'administration système à l'échelle du serveur dédié ou VPS Linux, l'admin dispose de plusieurs répertoires de configuration :
/etc/crontab: crontab global avec un champ utilisateur supplémentaire/etc/cron.d/: un fichier de configuration par service ou application installée sur le serveur VPS/etc/cron.daily/,/etc/cron.weekly/, etc. : scripts déclenchés à la fréquence indiquée par le nom du répertoire
Exemple de fichier de configuration dans /etc/cron.d/minecraft-backup :
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=""
# Sauvegarde automatique Minecraft chaque nuit a 4 h sur le serveur VPS
0 4 * * * minecraft /opt/minecraft/backup.sh >> /var/log/minecraft-backup.log 2>&1Le champ utilisateur (ici minecraft) est obligatoire dans /etc/crontab
et dans tous les fichiers de /etc/cron.d/. Les scripts déposés dans
/etc/cron.daily/ n'en ont pas besoin : ils sont lancés par run-parts
avec les droits root. Pour redémarrer Nginx ou un autre daemon réseau après une opération planifiée,
ajoutez systemctl restart nginx à la fin du script cron, ou mettez à jour la configuration
Nginx et rechargez le service sans coupure avec systemctl reload nginx.
Systemd timers : principe et avantages
Les timers systemd constituent une alternative à cron intégrée à l'écosystème systemd, disponible sur tout serveur VPS Linux ou serveur cloud sous Ubuntu, Debian et Rocky Linux. Chaque timer est associé à un service systemd contenant la commande à exécuter. L'admin du serveur VPS bénéficie d'une gestion centralisée des tâches planifiées, avec journalisation intégrée et gestion des dépendances entre services.
Avantages par rapport à cron pour l'administration d'un serveur VPS Linux :
- Journaux centralisés dans journald : la sortie du service est capturée et
consultable avec
journalctl -u nom-du-service, sans fichier de log séparé à gérer sur le serveur. - Gestion des dépendances : un timer peut attendre qu'un service réseau, un daemon (Nginx, pare-feu nftables, MariaDB) ou un répertoire monté soit disponible avant de démarrer.
- Calendriers précis ou relatifs :
OnCalendar=pour les horaires fixes,OnBootSec=etOnUnitActiveSec=pour les délais relatifs au démarrage du serveur VPS. - Rattrapage des tâches manquées : avec
Persistent=true, le timer relance immédiatement la tâche si le serveur VPS ou dédié était éteint au moment prévu. - Statut en temps réel : la commande
systemctl list-timersaffiche la prochaine exécution de chaque timer actif sur le serveur Linux.
Créer un timer systemd pas à pas
Tutoriel complet : sauvegarde automatique quotidienne d'un serveur FiveM à 3 h, avec envoi vers un stockage distant, en deux fichiers de configuration systemd sur votre serveur VPS Linux.
Étape 1 : créer le fichier de service
sudo nano /etc/systemd/system/fivem-backup.service[Unit]
Description=Sauvegarde automatique du serveur FiveM sur VPS Linux
After=network.target
[Service]
Type=oneshot
User=fivem
ExecStart=/opt/fivem/backup.sh
StandardOutput=journal
StandardError=journalType=oneshot indique que le service s'exécute une fois puis se termine : comportement
attendu pour toute tâche planifiée sur un serveur VPS. La sortie est envoyée à journald
(StandardOutput=journal), consultable avec journalctl -u fivem-backup.
Étape 2 : créer le fichier timer
sudo nano /etc/systemd/system/fivem-backup.timer[Unit]
Description=Timer de sauvegarde FiveM (tous les jours a 3 h) sur serveur VPS Linux
Requires=fivem-backup.service
[Timer]
OnCalendar=*-*-* 03:00:00
AccuracySec=1min
Persistent=true
[Install]
WantedBy=timers.targetOnCalendar=*-*-* 03:00:00 déclenche le service chaque jour à 3 h.
Persistent=true garantit que si le serveur VPS redémarre après cette heure, la tâche sera
rattrapée dès le prochain démarrage. AccuracySec=1min réduit la fenêtre d'imprécision.
Étape 3 : activer et démarrer le timer
# Recharger les configurations systemd après modification d'un fichier
sudo systemctl daemon-reload
# Activer le timer au démarrage du serveur VPS ou dédié
sudo systemctl enable fivem-backup.timer
# Démarrer le timer immédiatement sans redémarrer
sudo systemctl start fivem-backup.timer
# Vérifier le statut depuis le terminal
systemctl status fivem-backup.timerSyntaxe OnCalendar pour l'admin
# Tous les jours à 3 h
OnCalendar=*-*-* 03:00:00
# Toutes les heures
OnCalendar=hourly
# Chaque lundi à 7 h
OnCalendar=Mon *-*-* 07:00:00
# Le 1er de chaque mois à 2 h
OnCalendar=*-*-01 02:00:00
# Toutes les 15 minutes
OnCalendar=*:0/15Pour valider une expression de calendrier avant de l'utiliser sur votre serveur VPS :
systemd-analyze calendar "*-*-* 03:00:00"Déboguer les tâches planifiées
Une tâche qui ne s'exécute pas ou produit des erreurs est l'un des problèmes les plus courants pour un admin VPS Linux. Voici la démarche de diagnostic depuis le terminal du serveur cloud.
Vérifier que le daemon cron est actif
# Sur Ubuntu/Debian (serveur VPS Linux)
systemctl status cron
# Sur Rocky Linux / CentOS (serveur dédié)
systemctl status crondConsulter les journaux cron
# Via journald (distributions modernes sur serveur VPS Linux)
journalctl -u cron --since "1 hour ago"
# Via syslog si disponible sur le serveur
grep CRON /var/log/syslog | tail -30Tester un script manuellement avant planification
Avant de planifier un script sur votre serveur VPS, exécutez-le dans un environnement proche de celui de cron : les variables d'environnement disponibles dans cron sont limitées (PATH réduit, sans HOME automatique). Simulez ce contexte depuis le terminal :
# Lancer avec un environnement minimaliste similaire à cron
env -i HOME=/root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
bash /opt/scripts/mon-script.shSi le script échoue dans ce contexte mais pas dans votre shell interactif, c'est un problème de chemin ou de variable d'environnement. La solution pour l'admin du serveur VPS est de définir explicitement les variables nécessaires en tête du crontab :
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOME=/rootConsulter les journaux d'un timer systemd
# Journaux du service associé sur le serveur VPS
journalctl -u fivem-backup.service -n 50
# Historique complet des activations du timer
journalctl -u fivem-backup.timer
# Lister tous les timers actifs avec leur prochaine activation
systemctl list-timers --allDéclencher un timer manuellement pour tester
# Redémarrer le service associé immédiatement
sudo systemctl restart fivem-backup.service
# Suivre la sortie en temps réel
journalctl -u fivem-backup.service -fCron ou systemd timer : quand choisir quoi
Les deux outils coexistent sans conflit sur un serveur VPS Linux ou dédié moderne. Le choix de l'admin dépend du contexte d'hébergement et de la criticité des tâches planifiées :
| Critère | Cron | Systemd timer |
|---|---|---|
| Fichier de configuration | Une seule ligne dans crontab | Deux fichiers .service et .timer |
| Journaux sur le serveur VPS | Syslog ou email | Journald centralisé |
| Dépendances système | Aucune gestion native | After= et Requires= disponibles |
| Rattrapage des tâches manquées | Non disponible | Oui avec Persistent=true |
| Redémarrage après reboot | @reboot dans crontab | OnBootSec= ou enable |
| Portabilité entre distributions Linux | Toutes distributions Linux | Systemd uniquement |
Recommandation pour l'admin VPS Linux : utilisez cron pour les tâches simples sans
dépendances (sauvegardes légères, rotations de fichiers). Préférez un timer systemd quand la tâche est
critique, quand elle doit attendre un daemon réseau ou un service au démarrage du serveur dédié, ou
quand vous souhaitez des journaux structurés consultables via journalctl.
Bonnes pratiques sur un serveur VPS de jeu
Sur un VPS ou serveur dédié hébergeant un serveur de jeu (FiveM, Minecraft, Rust...) ou une application web derrière Nginx, les tâches planifiées s'accumulent rapidement. Voici les règles appliquées par les admins expérimentés pour éviter les conflits sur le serveur Linux :
- Évitez les horaires ronds pour les sauvegardes lourdes. Préférez 3 h 17 à 3 h 00 : de nombreux daemons système (logrotate, apt, Nginx...) s'exécutent aux heures rondes et un cumul de tâches I/O peut saturer la RAM ou le SSD du serveur VPS.
- Testez chaque script avant de le planifier. Exécutez la commande depuis le terminal du serveur VPS, vérifiez la sortie. Un script planifié qui échoue silencieusement peut priver l'admin de semaines de sauvegardes.
- Redirigez toujours les sorties dans un fichier de log. Sans redirection, cron peut tenter d'envoyer un email pour chaque exécution, ce qui peut saturer la file de messagerie sur un serveur VPS sans MTA configuré.
- N'exécutez pas de tâches lourdes pendant les heures de pointe. Sur un serveur de jeu ou une infrastructure cloud, la fenêtre nocturne (entre 2 h et 5 h) est le meilleur créneau pour les opérations intensives en RAM, en I/O disque ou en CPU.
- Documentez chaque entrée de configuration cron. Ajoutez un commentaire au-dessus de chaque ligne pour expliquer la tâche. Un crontab sans commentaire est illisible après quelques mois d'administration du serveur VPS.
- Contrôlez les droits des scripts. Assurez-vous que le script est exécutable
(
chmod +x /opt/scripts/mon-script.sh) et qu'il appartient à l'utilisateur qui le lance. Un fichier lisible par d'autres utilisateurs peut exposer des identifiants ou la configuration du pare-feu du serveur VPS. - Versionnez vos scripts avec Git. En stockant vos scripts cron dans un dépôt Git sur le serveur VPS, vous gardez un historique complet des modifications et pouvez restaurer une version précédente rapidement en cas de régression.
Pour aller plus loin dans la surveillance de votre infrastructure, consultez notre guide sur la configuration des alertes de monitoring sur un VPS Linux et celui sur la surveillance de l'espace disque avant saturation.
Vous souhaitez un VPS Linux prêt à l'emploi pour automatiser vos tâches planifiées et héberger vos serveurs de jeu dans un environnement cloud fiable ? Découvrez les offres ElypseCloud.
Voir les VPS LinuxLes tâches planifiées sont au coeur de l'administration d'un serveur VPS Linux ou dédié : elles automatisent les sauvegardes, la maintenance des configurations et la surveillance de la RAM et du SSD sans intervention manuelle. Maîtriser cron pour la simplicité et les timers systemd pour la robustesse donne à l'admin la flexibilité nécessaire pour gérer un serveur de jeu ou une infrastructure cloud depuis le terminal. Pour approfondir, lisez aussi notre guide sur la création d'un service systemd pour son serveur de jeu, la rotation des journaux avec logrotate, la gestion de la taille des journaux systemd et la détection des échecs de connexion SSH. Sur un serveur VPS ElypseCloud, toutes ces configurations s'appliquent sans restrictions depuis le premier accès en tant qu'admin.