cClaude.rocks ☕ Le blog

La commande rsync est incontournable dans la mise en place des sauvegardes. Une autre fonctionnalité incontournable est l’utilisation du cron pour automatiser le lancement du « backup ».

Le cas d’usage étant souvent quelque chose qui tourne ne tourne pas directement sur votre machine, mais sur un serveur et qui va effectuer une sauvegarde sur une troisième machine. Généralement tous cela se passe donc à distance hors d’une surveillance directe.

Si vous avez testé la commande rsync avec succès en utilisant le même utilisateur et les mêmes paramètres que dans le cron, votre problème est plus certainement lié au cron (et à son environnement) qu’à la commande rsync.

Voici quelques écueils que vous pourrez rencontrer et comment les éviter.

La commande « rsync »

L’avantage de rsync est sa vitesse d’exécution d’une part et le fait qu’il soit basé sur ssh d’autre part. rsync permet de faire des copies de dossiers (d’arborescences) entre 2 machines (noté que ce dernier point est une possibilité, pas une obligation, rsync pouvant être utilisé en local).

Par exemple :

rsync --archive --compress --delete --links --progress --recursive --times --update --verbose -vv /var/www/nextcloud/ admin@192.168.10.221:/share/homes/backups/nextcloud-backup/

La commande « crontab »

La commande crontab permet de manipuler le planificateur de tâches qui a le doux nom de cron.

Les principaux usages de crontab :

Pour afficher le contenu du fichier crontab d’un autre utilisateur (par exemple : www-data), utiliser sudo :

sudo -u www-data crontab -l

Une action de cron typique ressemble à cela :

*/5 * * * * COMMAND

Le format est le suivant :

minute hour jour du mois mois jour de la semaine commande à exécuter

Par exemple :

*/5 * * * * /usr/local/bin/mybackup.sh >>/var/log/apps/mybackup-from-cron.log 2>&1

Pour vous aider à générer la partie date vous pouvez utiliser crontab guru.

« ssh » ou ces dérivés et le « cron »

Lors de la mise au point d’un script utilisant directement ou indirectement ssh (indirectement comme rsync, rcp — qui est obsolète depuis 2019, sftp)

Les particularités du « cron »

L’utilisation de taches avec le cron différent d’un appel depuis un terminal ou d’une session ssh :

Les variables $HOME et $USER :

Suivant le cas ces variables ne sont pas initialisées depuis le cron, si vous en avez besoin, le plus simple est de les tester en début de script et éventuellement de les initialiser vous-même comme suit :

if [ -z "${USER:-}" ] ; then
  USER="$( id -un )"
fi
declare -gx USER # Rend la variable globale et l’exporte

Pour la variable $HOME, on doit s’appuyer sur la variable $USER :

HOME="/home/${USER}"

if [ -z "${HOME:-}" ] ; then
  HOME="$( grep "^${USER}:" /etc/passwd | cut -d':' -f6 )"
fi
declare -gx HOME # Rend la variable globale et l’exporte

• Remarque

  La remarque ci-dessous ne s’applique pas nécessairement à tous les Linux, ni à toutes leur version, cela étant cette précaution n’a pas d’effet négatif.

  Vous noterez que j’ai mis la déclaration globale et l’export en dehors du if … fi, la raison est que là encore l’environnement du cron se distingue, certaines variables n’ont pas le drapeau « exporté » actif. Certaines commandes ne prennent en compte que les variables exportées, c’est le cas en particulier de : envsubst.

Un shell limité

Le shell utilisé par le cron est sh, pour contourner cela vous devez préciser le shell dans la ligne de commande ou mieux appeler un script, qui vous permettra d’initialiser vos variables.

Pour ma part, je conseille la création d’un script dans presque tous les cas d’usage.

La redirection

*/5 * * * * /usr/local/bin/mybackup.sh >>/var/log/apps/mybackup-from-cron.log 2>&1

Un petit piège avec la redirection est qu’il faut s’assurer que l’utilisateur défini par le cron ait bien le droit d’écrire le log. Une remarque qui peut sembler évidente, mais si le fichier de redirection ne peut pas être créé ou modifier, la tache échouera en silence.

Les croches pieds avec « rsync » et « ssh » en général

• Le transfert d’agent SSH ou « SSH agent forwarding »

Cette fonctionnalité n’est généralement pas active par défaut, mais elle offre quelques avantages et vous l’avez peut-être activée volontairement ou au détour d’un tutoriel…

Sur un petit réseau, on utilisera le transfert d’agent SSH pour que la clé présente sur votre machine (machine administrateur) puisse être réutilisée lors du transfert du serveur applicatif vers le serveur de sauvegarde.

Cela implique que la commande de sauvegarde soit lancée depuis une session ssh, et donc cela ne fonctionnera pas depuis le cron.

Dans un milieu professionnel on pourra utiliser le transfert d’agent SSH dans le cadre d’un bastion.

Ici la machine de l’administrateur n’est pas sur le même réseau que les serveurs. Seul la machine bastion a accès aux deux réseaux.

Là le transfert d’agent SSH prend tout son sens, puisque cela permet de ne pas stocker de clés sur le bastion.

opening connection using: ssh -l admin 192.168.10.221 rsync --server -vvvulogDtprze --delete . /share/homes/backups/nextcloud-backup/config
Permission denied, please try again.
Permission denied, please try again.
admin@192.168.10.221: Permission denied (publickey,password,keyboard-interactive).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(228) [sender=3.2.3]
[sender] _exit_cleanup(code=12, file=io.c, line=228): about to call exit(255)

Diagnostic du « cron »

Pour voir ce qu’il se passe autour du cron, vous pouvez utiliser l’une des commandes suivantes :

journalctl --unit cron.service

grep CRON /var/log/syslog

Un type d’erreur dans le cron indique que le diagnostic n’est pas réellement possible :

Mar 30 07:40:01 TheHostName CRON[17671]: (CRON) info (No MTA installed, discarding output)

En français : « Aucun agent de transfert de courrier installé, suppression de la sortie »

Cela arrive dans le cas où la sortie est redirigée vers les mails. Un sujet à part entière trop complexe pour l’aborder dans ce billet. Concrètement, il s’agit d’installer un service smtp comme postfix, exim4, ssmtp (facile mais qui n’est plus maintenu), msmtp (simple) ou OpenSMTPD.

Liens

• Over SSH, can you use the same private key on the host side for other purposes?
• How to disable ssh-agent forwarding
• Page wikipedia Mail_Transfer_Agent
• msmtp
• OpenSMTPD
• Cron et crontab : le planificateur de tâches !
• Utilisation d'un bastion

ᦿ