backup via rsync

Le
Une Bévue
j'ai du louper qqc car mon backup rsync oublie des trucs, par exemple le
symlink et son script de backup :

/home/yt/bin/backup2DD

symlink qui pointe vers :

/home/yt/bin/scripts/backup2DD.zsh

j'ai eu le mesage d'erreur suivant :

yt@D620:~$ sudo /home/yt/bin/backup2DD >
Installations/11-12-15--09-48--backup2DD.txt
rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1060) [sender=3.0.7]

les perms de .gvfs :
yt@D620:~$ ls -al /home/yt/.gvfs
total 4
dr-x 2 yt yt 0 2011-12-15 07:04 .
drwxr-xr-x 47 yt yt 4096 2011-12-15 09:19 ..


mon script "backup2DD.zsh" :
=
#!/usr/bin/zsh

[ "$SUDO_USER" -a `id -u` -eq 0 ] || {
echo "Please run via sudo."
exit 1
}

export backup=/media/DD

if [ -d "$backup" ]; then
yt="/home/yt"
yt_="$backup/yt/"
echo "backup de '$yt' dans '$yt_'."
rsync -avz --delete-after $yt $yt_
etc="/etc"
etc_="$backup/etc/"
echo "backup de '$etc' dans '$etc_'."
rsync -avz --delete-after $etc $etc_
else
echo "Le disque '$backup' n'est pas monté."
fi

exit 0

=


aussi, quand je suis en sudo, apparemment, le PATH est différent, par
exemple, je n'ai pas mon "/home/yt/bin" dans le PATH, ça se règle
comment le PATH de sudo ???

c'est automatique sur Ubuntu d'avoir "/home/yt/bin" dans le PATH ?
je ne l'ai pas ajouté par moi-même et pourtant il y est
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
denis.paris
Le #24071981
Le 15/12/2011 10:25, Une Bévue a écrit :
j'ai du louper qqc car mon backup rsync oublie des trucs, par exemple le
symlink et son script de backup :

/home/yt/bin/backup2DD

symlink qui pointe vers :

/home/yt/bin/scripts/backup2DD.zsh

j'ai eu le mesage d'erreur suivant :

:~$ sudo /home/yt/bin/backup2DD >
Installations/11-12-15--09-48--backup2DD.txt
rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1060) [sender=3.0.7]

les perms de .gvfs :
:~$ ls -al /home/yt/.gvfs
total 4
dr-x------ 2 yt yt 0 2011-12-15 07:04 .
drwxr-xr-x 47 yt yt 4096 2011-12-15 09:19 ..


mon script "backup2DD.zsh" :
======================================================================================= >
#!/usr/bin/zsh

[ "$SUDO_USER" -a `id -u` -eq 0 ] || {
echo "Please run via sudo."
exit 1
}

export backup=/media/DD

if [ -d "$backup" ]; then
yt="/home/yt"
yt_="$backup/yt/"
echo "backup de '$yt' dans '$yt_'."
rsync -avz --delete-after $yt $yt_
etc="/etc"
etc_="$backup/etc/"
echo "backup de '$etc' dans '$etc_'."
rsync -avz --delete-after $etc $etc_
else
echo "Le disque '$backup' n'est pas monté."
fi

exit 0

======================================================================================= >


aussi, quand je suis en sudo, apparemment, le PATH est différent, par
exemple, je n'ai pas mon "/home/yt/bin" dans le PATH, ça se règle
comment le PATH de sudo ???

c'est automatique sur Ubuntu d'avoir "/home/yt/bin" dans le PATH ?
je ne l'ai pas ajouté par moi-même et pourtant il y est...



Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour
lancer une commande, il faut toujours lancer le programme avec le chemin
complet. Quand on lance un shell on risque de ne pas retrouver ses
variables.
Nicolas George
Le #24071971
"denis.paris" , dans le message
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour
lancer une commande



Totalement faux.
Nicolas George
Le #24071961
Une Bévue , dans le message écrit :
rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1060) [sender=3.0.7]



Au hasard, .gvfs est un point de montage FUSE, ce qui est toujours
particulier.
Pascal
Le #24072171
-------- Message original --------

"denis.paris" , dans le message
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour
lancer une commande



Totalement faux.


Ceci dit des commandes lancées via la crontab sans le chemin complet de cette
commande échouent souvent
Nicolas George
Le #24072161
Pascal , dans le message écrit :
Ceci dit des commandes lancées via la crontab sans le chemin complet de cette
commande échouent souvent



Il faut définir l'environnement dans la crontab, évidemment. C'est valable
pour PATH, mais aussi pour LD_LIBRARY_PATH si nécessaire, LC_CTYPE et
compagnie et bien d'autres.
denis.paris
Le #24072211
Le 15/12/2011 11:22, Pascal a écrit :


-------- Message original --------

"denis.paris" , dans le message
Une bonne pratique en Linux est de ne pas compter sur le "PATH" pour
lancer une commande



Totalement faux.


Ceci dit des commandes lancées via la crontab sans le chemin complet de cette
commande échouent souvent



Évidemment c'est bien ce que je voulais dire, car en mode interactif
dans un shell ce n'est le plus souvent pas nécessaire.

Mon affirmation ne se veut pas une vérité première, elle s'adresse aux
débutants en linux qui viennent du monde Windows ou cette notion de
chemin complet pour les exécutables est moins connue.

En particulier l'invocation d'un programme du répertoire courant
fonctionne toujours en Windows, en linux le chemin "." n'est en général
pas dans le path, sauf bidouille non recommandable.
Nicolas George
Le #24072281
"denis.paris" , dans le message a écrit :
Mon affirmation ne se veut pas une vérité première, elle s'adresse aux
débutants en linux qui viennent du monde Windows ou cette notion de
chemin complet pour les exécutables est moins connue.



Tu as dit que c'était une bonne pratique. C'est totalement faux, c'est une
_mauvaise_ pratique.

La bonne pratique, c'est de définir l'environnement si c'est nécessaire.

En particulier l'invocation d'un programme du répertoire courant
fonctionne toujours en Windows, en linux le chemin "." n'est en général
pas dans le path, sauf bidouille non recommandable.



L'invocation d'un programme du répertoire courant en situation d'utilisation
normale est en général preuve que quelque chose a été mal fait.
unbewusst.sein
Le #24072531
Nicolas George
Une Bévue , dans le message écrit :
> rsync: readlink_stat("/home/yt/.gvfs") failed: Permission denied (13)
> rsync error: some files/attrs were not transferred (see previous errors)
> (code 23) at main.c(1060) [sender=3.0.7]

Au hasard, .gvfs est un point de montage FUSE, ce qui est toujours
particulier.



Ah, d'accord, je me doutais - un peu - d'un truc de ce genre...
à cause du "fs"...

Et donc, ça peut faire que tout mon rsync a foiré, je veux dire à cause
de ce .gvfs ???

Dans ce cas il me faudrait le mettre en exclude.

--
« L'homme est capable du meilleur comme du pire,
mais c'est vraiment dans le pire qu'il est le meilleur. »
(Grégoire Lacroix)
unbewusst.sein
Le #24072521
Nicolas George
Totalement faux.



c'est sûr !!!
Mais ça ne me dit pas comment avoir, sous sudo, /home/yt/bin dans le
PATH.
Le rép "/home/yt/bin" est bien dans mon PATH comme utilisateur "normal",
ie. SANS sudo...
Sur Mac OS X, sans rien faire de spécial, le PATH normal est le même, il
me semble, que le PATH avec sudo.
--
« L'homme est capable du meilleur comme du pire,
mais c'est vraiment dans le pire qu'il est le meilleur. »
(Grégoire Lacroix)
Nicolas George
Le #24072511
Une Bévue, dans le message
Et donc, ça peut faire que tout mon rsync a foiré, je veux dire à cause
de ce .gvfs ???



Non, juste pour ce répertoire.
Publicité
Poster une réponse
Anonyme