Script backup comportement étrange

Support Debian
#1

Bonjour

J’ai créé un petit script tout simple pour faire un backup « immuable » hebdomadaire d’un NAS vers un vieux serveur.

Le serveur est sous Debian 12.

Le problème est que quand je lance le script à la main pas de problème il fonctionne, par contre dés que je le place dans crontab (contab -e et écriture de la tâche), il ne fait rien du tout)

Voici le script

root@Backup-06:~# cat xfs_backup_fulloption.sh
#!/bin/bash
# /root/xfs_backup_fulloptions.sh

logfile=$(mktemp /tmp/rsync.XXXXXXXX.log)

# On monte le Nas en lecture seule dans la VM Repo-Backup-Esxi06

mount.cifs //192.168.222.10/data /root/NAS -o username=xxx,domain=xxx.lan,password=xxx,vers=3,file_mode=0400,dir_mode=0400,noserverino,noexec

# On déverrouille le repertoire XFS /BackupData

chattr -R -i /BackupData

# On synchronise le Nas avec le repertoire BackupData - Le fichier exclude-file.txt contient les repertoires à ne pas synchroniser

rsync -avzru --delete-during --force /root/NAS/ --exclude-from='/root/exclude-file.txt' /BackupData >$logfile 2>&1

# On envoi le mail recapitulatif

if [ $? -eq 0 ]; then
        mail -s "rsync backup terminé @ $(date) for $(hostname)" XXX@XXX.com < $logfile
else
        mail -s "rsync backup erreur @ $(date) for $(hostname)" XXX@XXX.com < $logfile
fi

# On revérrouille le repertoire XFS /BackupData

chattr -R +i /BackupData

# On démonte le Nas

umount -a -t cifs -l >$logfile 2>&1

# rm -f $logfile

exit 0

et la tâche cron est écrite comme cela

30 0 * * sat /bin/bash /root/xfs_backup_fulloption.sh

dans cron.log je n’ai aucun message d’erreur 'voila ce que j’ai dans les logs a l’heure du lancement ce samedi):

2024-11-16T00:17:01.820882+01:00 Backup-06 CRON[7352]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
2024-11-16T00:30:01.863762+01:00 Backup-06 CRON[7359]: (root) CMD (/bin/bash /root/xfs_backup_fulloption.sh)
2024-11-16T01:17:01.729148+01:00 Backup-06 CRON[7396]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
2024-11-16T02:17:01.785354+01:00 Backup-06 CRON[7419]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
2024-11-16T03:10:01.841417+01:00 Backup-06 CRON[7447]: (root) CMD (test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r)

Donc je ne vois pas du tout où est le blocage.

C’est aussi possible que je m’y prenne mal.

Merci pour votre aide.

#2

Bonjour @Minus,
Merci pour la description détaillée. Dans un premier temps, je vous invite à faire la part des choses entre le script proprement dit et la programmation de la tâche cron en remplaçant votre script bash par un simple « hello world ». De cette façon, vous pourrez avancer sur la partie impactée.

#3

sat est le compte qui lance le script?
A-t-il suffisamment de droits?
Quand tu lances ton script à la main, tu es en root j’imagine?
Car si le script est dans le répertoire root, je doute que le user sat y ait accès.
Il faut mieux mettre ton script à un endroit où sat y a accès.

#4

Bonjour

Après test, je confirme que les taches cron fonctionnent sans problème

#5

Bonjour

Non sat dans la programmation de la tache cron, c’est saturday, donc la tache se lance tout les samedis, donc ici tous les samedi à minuit 30.

Et oui je lance le script en étant root.

J’ai d’autres serveurs ou le script est dans root/ et qui se lance sans problème via crontab, d’où ma surprise sur le fait que celui ci spécifiquement ne fonctionne pas.

#6

Ok mon erreur était le crontab -e, dans ce cas là on ne spécifie pas le user.
Si on édite le crontab avec vim /etc/crontab par exemple, juste avant la commande on indique le user.
Mais avec crontab -e, si on veut spécifier le user on utilise crontab -u www-data -e par exemple.

#7

Hello @Minus

cron par défaut fonctionne avec sh et un path minimal

Si tu n’as pas le log de la cde rsync c’est qu’elle n’a pas été trouvée.

Ajuste le PATH dans ton crontab ou met le chemin complet du rsync (idem pour mail et tout autre cde)

#8

Salut,

c’est possiblement que le PATH de l’environnement cron ne contient pas les chemins vers toutes les commandes appelées dans ton script.

Dans ta crontab, ajoute une ligne (avant la ligne qui appelle ton script) pour reprendre le PATH de root:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
30 0 * * sat /bin/bash /root/xfs_backup_fulloption.sh
#9

C’est sale :slight_smile:
Dans crontab il est conseillé de mettre dans ses scripts les chemins d’accès complet.
D’ailleurs quand on regarde les scripts du système, c’est exactement ce qui est fait, les chemins sont traité au niveau du script.

#10

Bonjour

merci pour vos conseils

j’ai donc modifié mon script et remplacé

mktemp par /usr/bin/mktemp
mount.cifs par /usr/sbin/mount.cifs
chattr par /usr/bin/chattr
rsync par /usr/bin/rsync
mail par /usr/bin/mail
umount par /usr/bin/umount

On va voir ce que cela donne

Je vous tiens au courant

1 J'aime
#11

Bonjour

petit retour:

Avec le chemin complet, le script s’est bien lancé et exécuté, donc c’était bien un problème de chemin. Il fallait effectivement mettre le chemin complet.

Par contre il ne m’a pas envoyé le mail, si vous avez une idée sur cette partie je suis preneur :wink:

#12

Il faut que tu regarde les logs.
Quel est ton serveur courriel configuré?

#13

Bonjour

Bon j’ai regardé dans les log de exim4

Il me dit que le fichier est trop gros

2024-11-24 20:45:06 1tFIXZ-0003sV-02 rejected from <xxx@xxx.com> U=root: message too big: read=52428801 max=52428800

Je voudrais juste recevoir « rsync backup terminé » si ok et « rsync backup erreur » avec la liste des erreurs si il y a un problème.

#14

52Mo les messagerie n’en veulent pas. Ce n’est pas du FTP.
Il faut d’une part que tu filtres un peu tes logs et que d’autre part que tu compresses le fichier. D’autant que les logs ça se compresse bien.

#15

Modifie ton script dans ce cas, par contre je serais toi je ne supprimerai pas le log (je l’écraserai au prochain lancement plutôt) et je n’enverrai que un mail pour dire OK ou KO effectivement.

#16

Merci pour vos conseils

Je vais voir comment modifier cela