Citation
christophe46
(exécuté en tant que root). L'archive ne dépasse
jamais plus de 1300 ko.
Si je lance le shell manuellement tout se passe
normalement (l'archive fait quelque 12 Go).

Vraiment exécuté en tant que root par cron ? As tu vérifié par ps durant le lancement automatique ?
N'aurais tu pas pas hasard une gestion de quotas qui pourrait poser problème ?



Linux user # 386486 (serveur debian sarge sur un athlon64 , laptop PIV-HT sur etch noyau 2.6.20).

Poste le Thursday 9 June 2005 10:42:36

Bonjour glorfindel,

le cron tourne bien en tant que root et je n'ai pas de quotas.
J'ai refait un test du cron, j'ai cette fois une archive de 41 Mo corrompue.

Poste le Thursday 9 June 2005 11:30:28

Ton volume hébergeant ce qui doit être archivé est actif vu l'heure à laquelle tu postes...
Donc par exemple le fichier machin_truc_muche qui est en cours de tar disparait au milieu du mauvais moment...

Que fait tar ? Il se plante...

Expérience tentable : un cron au milieu de la nuit si possible avec avant un arrêt du serveur samba, puis un redémarrage.

C'est pas plausible ?

Rien de sur, juste une application du principe de causalité...





Linux user # 386486 (serveur debian sarge sur un athlon64 , laptop PIV-HT sur etch noyau 2.6.20).

Poste le Thursday 9 June 2005 15:08:51

C'est une piste. Mon cron tourne à minuit 10 mais certaines personnes sont susceptibles de travailler encore à cette heure et certains traitements peuvent être en cours. Je décale le cron, j'arreterai samba si cela ne suffit pas mais qu'en dernier ressort (il doit impérativement etre actif à la reprise des personnels et l'archivage est très long de par son volume, même en mise à jour).

Merci de faire partager tes réflexions.
Bonne fin de semaine.

Poste le Friday 10 June 2005 15:19:43

quel script utilise tu? quelle est ta ligne dans crontab? recupere tu des messages d'erreurs?

Poste le Friday 10 June 2005 15:57:08

salut

quels sont les sorties (log) de ton script

il faut faire, dans le crontab /xxx/nom_script.sh >logfile 2>&1

si tu ne l'as pas fait avant, une lecture des mails de root devrait aider (cron maile son stdout/stderr sur le mail de root)

Poste le Sunday 12 June 2005 16:41:26

Bonjour a tous,

j'ai verifié les logs et pas d'erreurs.

J'ai par contre modifié l'heure du cron, le premier jour pas de changement, mêmes symptomes, par contre cela fait 3 jours consécutifs que la sauvegarde se passe normalement (sans modification d'aucune sorte, tant au niveau serveur que script).

A temps perdu j'essaierai de comprendre, car le changement d'heure du cron ne me semble pas une explication suffisante

Merci à vous.

Poste le Wednesday 15 June 2005 08:17:08

ça depand

par exemple vdump et tar si certaines applications sont ouvertes durant les backups ça mets un message d'erreur sur le fichier mais ne plante pas la sauvegarde (fichier different entre l'indexation et le moment ou il est vraiment sauvé)

ça c'est le fonctionnement normal.


par contre parfois si le fichier subit une ecriture physique (ou lecture) au moment ou il est soit indexé soit sauvé là ça te plante la sauvegarde et c'est tout.

le troisieme cas : si la machine est trop chargée (bus scsi/ide/ ou sata) le lecteur de bande par exemple (peripherique pourtant lent) ne recoit plus assez de volume de donnée à la fois pour que la mecanique soit synchrone avec les ordres recu du logiciel d'archivage et la encore ça plante.

si tu n'as pas assez de swap (pour les entrées/sorties) là encore ça peut planter des backups pour les même raisons de synchro (que ce soit sauvegarde sur disques ou sur bandes...

dans ces 3 derniers cas la solution est la replanification des sauvegardes à un moment ou l'activité machine est très reduites pour diminiué significativement le %age de sauvegarde échouées...

SI ça a une importance extrème le choix de la planification.

Poste le Wednesday 15 June 2005 11:42:20