Léa-Linux & amis :   LinuxFR   GCU-Squad   Zarb.Org   GNU
Archive de la liste aide - [Aide] Lancer un cron le dernier jour du mois
Le Tue, 2 Sep 2014 01:16:13 +0200,
Peko <papa.papa.echo at gmail.com> a écrit :

> Tous les chemins mènent à Rome, mais certains sont plus pénibles et
> dangeureux, alors on pourrait dire bien des choses en somme.
> 
> 
> 1) Proposition 1
> Principe KISS: faire une solution qui marche, et simple, même style bourrin.
> 
> Lancer un script tous les jours à 23h30, en vérifiant si c'est bien le
> dernier jour du mois.
> 
> Tu peux utiliser ton test,
> ou te servir de l'astuce suivante pour déterminer le dernier jour du mois
> en cours:
> <code>
> date --date "next month - $(date +%d) day"
> </code>
> 
> Que tu peux comparer au jour en cours, aussi.

Dans ce cas point n'est besoin de le lancer tous les jours du 28 au 31 suffit, si jamais on a un mois qui se termine le 27 ou le 12 c'est qu'on aura des problèmes autrement graves qu'un backup de serveur ;-)

> <!> Piège de conception: Attention quand même, si le système est chargé, et
> que le script que tu comptais lancer à 23h30 ne tourne que 31 minutes plus
> tard, il ne s'exécutera pas comme tu l'entends, puisque le jour sera le
> premier du mois, et non le dernier...

Oui mais non. Il s'agit d'un serveur de backup rsnapshot, donc la rotation mensuelle est quelque chose qui ressemble à un logrotate. Ça ne fait que copier avec des liens en dur le dernier backup horaire (hourly.0) dans le monthly.0 après avoir renommé le 3 en 4, le 2 en 3 etc. et idem pour les mois. Ça prend trente cinq secondes pour 300 Go en gros. Cependant je peux avancer la sauvegarde par sûreté en effet. Et cette machine ne fait que ça, aucun autre service, juste du backup rsync. Elle a des gros disques mais un petit cerveau...

> 2) Proposition 2
> Philosophie Unix: Faire un pgm qui marche, puis optimiser
> 
> Pour éviter de faire tourner ce script tous les jours, et éviter le bug de
> conception cité, tu pourrais écrire un script qui s'exécute tranquillement
> le premier du mois, par [cron], et qui va créer une tâche qui ne
> s'exécutera une seule fois, au dernier jour du mois, grâce à la commande
> [at]
> 
> Le dernier jour du mois en cours étant toujours déterminable par :
> <code>
> date --date "next month - $(date +%d) day"
> </code>

Ouais j'y avais pensé, mais ça ne permet pas de prendre le truc en route. Il faut passer obligatoirement par un premier du mois. Il faut que je regarde ce que ça implique, c'est un problème d'intervalles, j'ai jamais aimé ça... Mais bon, pourquoi pas. 

> 
> 3) Proposition 3
> Prendre du recul par rapport à la demande du client et remettre en cause
> son "comment".
> 
> En prenant un peu de recul par rapport à ta demande initiale, pour faire
> encore plus simple, tu pourrais simplement lancer le backup le premier jour
> du mois à la première minute du jour par [cron], s'il n'y a pas de problème
> pour décaler ton backup de 30mn. Simple et robuste. :-)

Non là pas possible. De par la conception même de rsnapshot. Le backup "hourly" se fait toutes les heures (en fait chez moi toutes les quatre heures, donc six par jour) à la minute 0 pile. Il faut donc que les rotations se fassent avant le backup de minuit, sous peine d'incohérence. 

Ou alors si, en fait, une solution serait de repousser le backup horaire dans l'heure. du coup je pourrais en effet travailler le 1er du mois genre :

20 */4 *  *  *  rsnapshot hourly
15 0   *  *  *  rsnapshot daily
10 0   *  *  0  rsnapshot weekly
5  0   1  *  *  rsnaphot  monthly
1  0   1  1  *  rsnapshot yearly

au lieu de mon actuel :

0    */4          *        *    * rsnapshot hourly
50    23          *        *    * rsnapshot daily
40    23          *        *    6 rsnapshot weekly
30    23     28,29,30,31   *    * rsnapshot monthly
20    23         31       12    * rsnapshot yearly

C'est tout à fait faisable parce qu'il y a quatre heures entre chaque backup et que les backups sont très courts (par contre le backup initial a duré presque 8 heures). Avec 240 Go backupés, en rythme de croisière, avec la sauvegarde des mails qui est ce qui bouge le plus, mes sauvegardes sont entre 10 secondes et 3 minutes pour la base de données piwik (avec compris dedans le lancement du script de dump MySQL). Si jamais un utilisateur se met en tête de renommer ses répertoires de photos et de vidéo, là ça pourrait craindre... Mais ils ont des consignes pour ne pas faire ce genre de choses, ou alors m'en avertir avant. 

Si je passe à un backup toutes les heures ça sera plus serré en cas de gros mouvements, mais en usage normal plus l'intervalle est petit, moins le nombre de fichiers modifiés est élevé.

C'est sans doute la solution la plus simple à adopter. 

Merci pour les idées.


Serveur hébergé par ST-Hebergement et Lost-Oasis / IRC hébergé par FreeNode / NS secondaire hébergé par XName
Sauf mention contraire, les documentations publiées sont sous licence Creative-Commons