#1 Le 20/02/2017, à 15:46
- benji721
Executer une tache cron que la nuit
Bonjour à tous.
J'ai une machine qui tourne sous un serveur linux et qui peut se connecter à internet avec une bande passante pas adaptée pour un serveur.
J'aimerais bien utiliser la commande rsync en cron afin de transférer 50Go de données à un serveur externe via SSH.
Le problème, c'est qu'il faudra plusieurs jours pour le faire et que la commande rsync va utiliser beaucoup de bande passante pendant ces quelques jours.
Du coup, j'ai envie que mon cron ne s'execute que la nuit (entre 0H et 7H du matin par exemple),
qu'à 7H il arrête ou mets en suspens l'execution du rsync
et qu' il continue la nuit suivante à minuit là ou il l'à laissé.
Serait-ce possible selon vous ?
Merci d'avance
Hors ligne
#2 Le 22/02/2017, à 10:28
- DonutMan75
Re : Executer une tache cron que la nuit
Bonjour,
il me semble que rsync est censé pouvoir reprendre une copie interrompue (à confirmer ?).
Une solution sale (très sale) serait peut-être de rajouter dans ton cron un script qui se lance à 7H du matin et dont le but est de killer le processus rsync lancé à 0h ? De plus, je n'ai aucune idée si ça peut marcher... Par ailleurs, il ne me semble pas qu'il existe d'option "timeout" dans rsync qui le forcerait à s'arrêter de lui-même après une certaine durée d'exécution...
Mais, je suggère une autre solution : si les 50 Go en question n'ont pas vocation à *trop* bouger dans le temps, on pourrait penser que seul le premier rsync prendra du temps (le temps de copier l'intégralité des 50 Go). Les autres synchronisations ne se feront en principe que de façon différentielle.
Pourquoi ne pas copier *manuellement* (via disque USB par exemple) l'intégralité du répertoire à sauvegarder une fois au tout début ? Ou alors accepter exceptionnellement un rsync très long juste au début ?
Donut.
Dernière modification par DonutMan75 (Le 22/02/2017, à 10:28)
Hors ligne
#3 Le 22/02/2017, à 10:43
- benji721
Re : Executer une tache cron que la nuit
Merci de ta réponse.
En effet, ce rsync long ne servirait qu'au début et qu'exceptionnellement
J'ai pensé à ta solution et je l'avais testé. Mais je crois que ce n'est pas si évident que ça. Si on fait une simple copie (cp) sur un disque dur, des fichiers (avec des nouveaux inoeuds) sont créés. Je les transfert à mon autre serveur via mon disque dur.
Je fais mon mon rsync et c'est toujours aussi long car comme ils ont des inoeuds différents, il n'a pas percuté que les fichiers n'auront pas besoins d'être modifiés.
Peut être que j'avais mal fait la copie.
Hors ligne
#4 Le 22/02/2017, à 11:23
- DonutMan75
Re : Executer une tache cron que la nuit
Hello,
avec l'option -u de rsync, on ne transfère que les fichiers plus récent (à peaufiner ensuite pour avoir le bon rsync qui va bien)
Mise en place d'un test : on veut sauvegarder le répertoire SOURCE dans DEST1, initialement vide. Le répertoire DEST2 contiendra lui une copie "manuelle" de SOURCE/
Mise en place des répertoires de test :
$ mkdir SOURCE
$ mkdir DEST1
$ mkdir DEST2
$ echo "Premier fichier" > ./SOURCE/a.txt
$ echo "Deuxieme fichier" > ./SOURCE/b.txt
$ echo "Troisieme fichier" > ./SOURCE/c.txt
$ cp ./SOURCE/* ./DEST2/
On lance deux fois d'affilée la commande rsync avec l'option -u. On rajoute également -v pour avoir le mode "verbeux".
On remarque que le premier appel à rsync copie bien les trois fichiers... mais pas le deuxième appel !
$ rsync -vu ./SOURCE/* ./DEST1/
building file list ... done
a.txt
b.txt
c.txt
sent 304 bytes received 86 bytes 780.00 bytes/sec
total size is 51 speedup is 0.13
$ rsync -vu ./SOURCE/* ./DEST1/
building file list ... done
sent 115 bytes received 20 bytes 270.00 bytes/sec
total size is 51 speedup is 0.38
Si maintenant on exécute ce même rsync sur /DEST2/ (qui contient, rappelons le, une copie "manuelle" des fichiers sources), rsync ne fait rien du tout (comme attendu) :
$ rsync -vu ./SOURCE/* ./DEST2/
sent 70 bytes received 20 bytes 180.00 bytes/sec
total size is 51 speedup is 0.57
Bon c'est un exemple très simplifié. Je t'invite à regarder en détail les différentes options de rsync pour avoir *exactement* le comportement que tu souhaites
Les questions à se poser à ce stade :
- si un fichier est supprimé de ma source, est-ce que je veux qu'il soit également supprimé de ma destination ?
- est-ce que je souhaite préserver le propriétaire, le groupe etc... associé à mon fichier source ?
- qu'est-ce que ça signifie que mon fichier a été "modifié" ? (avec -u par exemple, je crois qu'on ne regarde que la date de dernière modification).
- est ce que ces 50 Go dont tu parles se décomposent en plein de petits fichiers ou alors quelques très gros fichiers ? Je ne sais plus si rsync ne copie que la partie du fichier qui a été modifié ou alors le fichier en intégralité... La encore, ce sont des questions d'optimisation...
Bon courage pour la suite
Donut.
Hors ligne