N'y a-t-il pas un pb de variables d'environnement? Regarde le contenu des deux archives constituées (avec cron et en lancement manuel) et repère les éventuels répertoires / fichiers non sauvegardés...

hum...
Il faudrait aussi ajuster la variable PATH dans le script...

++

Salut !
"Il faudrait aussi ajuster la variable PATH dans le script..."
NON !
Pour d'évidentes raisons de sécurité, il ne faut PAS se reposer sur le contenu de PATH dans un script qui va tourner avec cron (c'est peut être là le pb, d'ailleurs si SE linux est réglé serré).
Il te faut faire la liste des commandes dont tu as besoin dans le script et récupérer leur path pour le mettre dans le fichier qui sera exécuté exemple :
j'ai besoin de tar
%whereis tar
/usr/bin/tar
Dans le script je remplace "tar" par "/usr/bin/tar" et le tour est joué.
Cela semble fastidieux, mais en fait c'est assez rapide car la majorité des commandes sont dans /usr/bin, celles d'admin dans /sbin et /usr/sbin donc avec un peu d'habitude, on y arrive très bien.
Enfin, si ton répertoire distant est sur un montage NFS ne fais pas tourner ton script avec l'identité de root, car c'est l'utilisateur qui a le moins de droits pour NFS (pour des raisons de sécurité) Crée plutot un utilisateur backup connu de ta machine et du distant et qui possédera tous les fichiers issus du script sous cron.
Allez au boulot...
P.S. 4Ko de résultat, c'est surement des messages d'érreurs... a regarder de près !

et y'a quoi dans ton fichier de 4ko ?

La plupart des erreurs viennent du fait que l'on ne met pas les respertoires complets dans les scripts

Donc soit tu declares ton PATH, soit dans la crontab tu declares SHELL=/bin/bash.

Et non, sh ca n'est pas bash. Donc ne lancez pas vos scripts bash avec sh.

Pour d'évidentes raisons de sécurité, il ne faut PAS se reposer sur le contenu de PATH dans un script qui va tourner avec cron (c'est peut être là le pb, d'ailleurs si SE linux est réglé serré).

Heing ? En quoi est-ce si evident ? Surtout si c'est toi qui definis le path au sein meme du script quel est le probleme ?
Mais tu sais, tu te bases tous les jours sur le PATH - que tu n'as surement pas definis toi - en ligne de commande, est-ce que ca n'est pas plus insecure, ca, heing ?

"Heing ? En quoi est-ce si evident ? Surtout si c'est toi qui definis le path au sein meme du script quel est le probleme ?"
Il y a quelques années il y a eu un tas d'attaques basées sur la modification du PATH en créant dans un répertoire accessible à tous (/tmp ou /var/tmp par exemple) des fichiers nuisibles aux noms évocateurs : ls, tar, .... ces attaques exploitaient une faille de cron.
Comme les crons de sauvegardes sont souvent faits sous root, je te laisse deviner ce que l'on peut faire avec ce type d'attaques... Et de plus, elles sont bien masquées.
Ceci explique pourquoi il est recommandé de spécifier le chemin complet des commandes à employer et de forcer le choix du shell en commençant son script par une ligne du type "#!/bin/sh"
Mais, bon, si la machine est bien configurée, avec firewall, et SELinux, il ne devrait pas y avoir de PB.
"Ne pas être parano ne veut pas dire qu'il n'y a pas de complôt".....