web-dev-qa-db-fra.com

Configuration de la sauvegarde hebdomadaire CRON

Je souhaite effectuer une sauvegarde de mes dossiers /var/lib/mysql et /var/www et les enregistrer en tant que fichiers tar.gz sur mon serveur de fichiers réseau monté (uslons001).

Voici mon fichier bash situé dans: /bin/backups/mysqlbackup.sh

#!/bin/bash
mkdir /home/lv_admin/uslons001/`date +%d%m%y`
cd /home/lv_admin/uslons001/`date +%d%m%y`
tar -czf mysql.tar.gz /var/lib/mysql
tar -czf www.tar.gz /var/www

Ce qui fonctionne parfaitement bien lorsque je l'exécute dans un shell de commande, mais lorsque je configure le travail cron, celui-ci ne s'exécute jamais. Par conséquent, je ne le configure pas correctement. Mon travail cron ressemble à ceci.

   36 10 * * 5 /bin/backups/mysqlbackup.sh

..il n'y a rien non plus dans le fichier /var/log/cron.log, aucune erreur n'est donc consignée. (même après avoir activé la journalisation cron dans le fichier /etc/syslog.conf

bashbackupcron
7
sadmicrowave

J'ai changé l'emplacement du fichier bash en /usr/local/mysqlbackup.sh. Après cela, j’ai exécuté les commandes suivantes sur le fichier:

cd /usr/local/
Sudo chown [username] mysqlbackup.sh
Sudo chmod -rwx mysqlbackup.sh
Sudo chmod go= mysqlbackup.sh

puis j'ai arrêté d'utiliser ~$ crontab -e comme commande pour modifier le travail cron et j'ai commencé à utiliser Sudo nano /etc/crontab, où j'ai créé une nouvelle ligne de travail avec les éléments suivants:

00 20    * * 5  root  /usr/local/mysqlbackup.sh

J'ai commencé à utiliser ce fichier à la place, car il m'a permis de lui indiquer quel utilisateur devait l'exécuter. Après ces changements, le travail cron fonctionne.

1
sadmicrowave

Quelques points à souligner:

  • Pourquoi utilisez-vous des timestrings dans les scripts /etc/cron.weekly/? Vous n'êtes censé y placer que des scripts exécutables. Vous n'avez pas besoin de les contacter ou quoi que ce soit d'autre. Cela ne fera que dupliquer leur travail. Regardez /etc/cron.daily/apt pour un exemple de ce dont je parle. C'est juste un script simple.

  • Par commentaire de geirha, le fichier ne peut pas avoir une extension. Bizarre, je sais, alors renommez-le:

    Sudo mv /etc/cron.weekly/mysqlbackup{.sh,}

  • Vous devez exécuter Sudo chmod +x /etc/cron.weekly/mysqlbackup pour le rendre exécutable. Vous pouvez ensuite le tester en l'exécutant, en utilisant ce chemin.

  • Si vous le laissez dans /etc/cron.weekly/, le script sera exécuté en tant que root. Aucun de vos liens ~/ ne va fonctionner. Utilisez des chemins complets. Je suggérerais qu'après avoir fait la mkdir vous cd dedans et que cela réduise les énormes chemins dans les commandes suivantes. Si vous avez besoin que les fichiers générés soient la propriété de votre utilisateur, définissez votre script chown sur votre utilisateur une fois la sauvegarde terminée.

    Je ne vois aucune raison pour que cela soit basé sur la racine. Vous pouvez copier le script dans votre répertoire personnel et utiliser simplement le crontab -e standard pour ajouter votre règle et l'exécuter. Il doit encore être exécutable et je vous recommanderais quand même d'utiliser des chemins d'accès complets, mais cela simplifiera légèrement les autorisations.

7
Oli

Le jour de la semaine est un champ numérique, il échoue lorsque l'on essaie d'analyser 'fri'. Changez cela en 5 (dimanche est 0). modifier: Je vois que l'OP a été mis à jour pour résoudre ce problème et qu'il reste des problèmes, mais ils sont traités dans d'autres réponses.

Le format cron étant bien documenté en ligne, je vérifie généralement la documentation avant d'écrire un nouveau travail cron: http://en.wikipedia.org/wiki/Cron

De plus, assurez-vous que vous utilisez crontab -e (ou similaire) pour éditer votre fichier cron, ce qui garantira qu'il sera analysé à nouveau.

2
ImaginaryRobots

Vous pouvez essayer de rediriger les erreurs de votre ligne cron vers un fichier, par exemple:

/usr/local/mysqlbackup.sh &>/var/log/mysqlcron.log

Cela devrait intercepter stdout et stderr et indiquer s'il y a une erreur de syntaxe, etc.

Remarque: si vous effectuez une sauvegarde d’un vivre base de données, vous devez utiliser les utilitaires spécifiques pour la sauvegarde, tels que mysqldump, plutôt que d'utiliser une commande tar générique. La raison en est que si les fichiers de/var/lib/mysql/change alors que le fichier tar est en cours d’exécution, vous risquez de vous retrouver avec une image incohérente de la base de données.

0
bitwelder