J'ai un serveur web (hébergé très loin de chez moi), avec un disque
dur de 70 Go.
J'ai un serveur local (samba, mail, etc.) avec un très gros disque
dur.
J'aimerais faire un backup complet du serveur web sur la machine
locale, mis à jour quotidiennement (incrémentalement bien sûr), de
telle sorte qu'en cas de crash du disque dur, je puisse fournir un
tarball complet à l'hébergeur, pour une restauration rapide.
Les permissions doivent être sauvegardées, de même que tous les
fichiers -- y compris /etc/shadow.
Je peux éventuellement me connecter sur la machine distante en tant
que root (seul compte ayant accès à tous les fichiers), mais s'il y
avait un moyen d'éviter, ça serait sympa.
Sur la machine locale, en revanche, je ne veux pas que le script de
backup tourne en root.
Or, si je récupère le fichier /etc/shadow (par exemple) avec les
droits qui vont bien, il sera modifiable uniquement par root.
Il doit y avoir une solution toute simple à côté de laquelle le
béotien que je suis est passé, mais en attendant, je patauge...
J'imagine que ce qu'il me faudrait, c'est un système de fichiers
indépendant (i.e. qui n'est pas monté "normalement", avec "mount"),
qui serait l'image parfaite du serveur web.
"Francois Goudal" a écrit dans le message de news:
Rsync est censé permettre le transfert des seuls morceaux différents. En gros, si tu changes un octet dans un fichier de 7 Go, seuls quelques octets seront transférés.
Ouais enfin... Pour savoir que c'est tel octet qui a ete modifie, il faut d'abord que rsync ait pu comparer les deux fichiers, or il n'en a qu'un sous la main. Alors je ne sais pas comment il fait, il paraitrait absurde qu'il s'amuse a completement telecharger le fichier distant pour faire une comparaison bit a bit. Peut-etre qu'il le decoupe en morceaux qu'il hache afin de determiner les parties differentes, dans tous les cas, je ne pense pas que juste "quelques octets" devront etre transferes, dans le cas d'un fichier de 7Go avec juste 1 octet qui a change. A mon avis ca sera quand meme plutot consequent au niveau trafic reseau.
Vous avez tous les 2 raison et tort à la fois. En fait, rsync découpe le fichier local en plusieurs blocs et il calcule les md4 correspondants. Il fait pareil avec le fichier distant. Puis il compare les md4 respectifs de chaque bloc. Si ils sont différents, il envoie le bloc en question.
Le problème avec un fichier tar compressé, c'est que si on ajoute un fichier d'un octet, qu'on génère le tar, qu'on le compresse, et bien les blocs du nouveau tar compressé n'ont plus aucun rapport avec l'ancien tar compressé. Ce qui revient à envoyer tout le fichier, rsync n'a donc plus aucun intérêt et un scp suffit. Donc, pour profiter au maximum de rsync, faut pas utiliser du tar compressé, mais du tar tout court. La compression se fera en tant que option de rsync.
D'ailleurs en théorie : On tar un répertoire qui contient pleins de fichiers puis on le compresse. On aura 2 fichiers : rep_1.tar et rep_1.tar.gz On ajoute un fichier dans le répertoire, on tar le répertoire, puis on le compresse. On aura 2 fichiers : rep_2.tar et rep_2.tar.gz On utilise la commande diff avec rep_1.tar et rep_2.tar on devrait avoir une petite différence. Ensuite on fait un diff avec rep_1.tar.gz et rep_2.tar.gz on devrait avoir une très grosse différence.
rsync sera efficace avec rep_1.tar mais inefficace avec rep_1.tar.gz
Je vous laisse vérifier la théorie.
"Francois Goudal" a écrit dans le message de news:
Rsync est censé permettre le transfert des seuls morceaux différents.
En gros, si tu changes un octet dans un fichier de 7 Go, seuls
quelques octets seront transférés.
Ouais enfin... Pour savoir que c'est tel octet qui a ete modifie, il
faut d'abord que rsync ait pu comparer les deux fichiers, or il n'en a
qu'un sous la main.
Alors je ne sais pas comment il fait, il paraitrait absurde qu'il
s'amuse a completement telecharger le fichier distant pour faire une
comparaison bit a bit.
Peut-etre qu'il le decoupe en morceaux qu'il hache afin de determiner
les parties differentes, dans tous les cas, je ne pense pas que juste
"quelques octets" devront etre transferes, dans le cas d'un fichier de
7Go avec juste 1 octet qui a change. A mon avis ca sera quand meme
plutot consequent au niveau trafic reseau.
Vous avez tous les 2 raison et tort à la fois.
En fait, rsync découpe le fichier local en plusieurs blocs et il calcule les
md4 correspondants. Il fait pareil avec le fichier distant.
Puis il compare les md4 respectifs de chaque bloc.
Si ils sont différents, il envoie le bloc en question.
Le problème avec un fichier tar compressé, c'est que si on ajoute un
fichier d'un octet, qu'on génère le tar, qu'on le compresse, et bien les
blocs du nouveau tar compressé n'ont plus aucun rapport avec l'ancien tar
compressé.
Ce qui revient à envoyer tout le fichier, rsync n'a donc plus aucun intérêt
et un scp suffit.
Donc, pour profiter au maximum de rsync, faut pas utiliser du tar compressé,
mais du tar tout court. La compression se fera en tant que option de rsync.
D'ailleurs en théorie :
On tar un répertoire qui contient pleins de fichiers puis on le compresse.
On aura 2 fichiers : rep_1.tar et rep_1.tar.gz
On ajoute un fichier dans le répertoire, on tar le répertoire, puis on le
compresse.
On aura 2 fichiers : rep_2.tar et rep_2.tar.gz
On utilise la commande diff avec rep_1.tar et rep_2.tar on devrait avoir une
petite différence.
Ensuite on fait un diff avec rep_1.tar.gz et rep_2.tar.gz on devrait avoir
une très grosse différence.
rsync sera efficace avec rep_1.tar mais inefficace avec rep_1.tar.gz
"Francois Goudal" a écrit dans le message de news:
Rsync est censé permettre le transfert des seuls morceaux différents. En gros, si tu changes un octet dans un fichier de 7 Go, seuls quelques octets seront transférés.
Ouais enfin... Pour savoir que c'est tel octet qui a ete modifie, il faut d'abord que rsync ait pu comparer les deux fichiers, or il n'en a qu'un sous la main. Alors je ne sais pas comment il fait, il paraitrait absurde qu'il s'amuse a completement telecharger le fichier distant pour faire une comparaison bit a bit. Peut-etre qu'il le decoupe en morceaux qu'il hache afin de determiner les parties differentes, dans tous les cas, je ne pense pas que juste "quelques octets" devront etre transferes, dans le cas d'un fichier de 7Go avec juste 1 octet qui a change. A mon avis ca sera quand meme plutot consequent au niveau trafic reseau.
Vous avez tous les 2 raison et tort à la fois. En fait, rsync découpe le fichier local en plusieurs blocs et il calcule les md4 correspondants. Il fait pareil avec le fichier distant. Puis il compare les md4 respectifs de chaque bloc. Si ils sont différents, il envoie le bloc en question.
Le problème avec un fichier tar compressé, c'est que si on ajoute un fichier d'un octet, qu'on génère le tar, qu'on le compresse, et bien les blocs du nouveau tar compressé n'ont plus aucun rapport avec l'ancien tar compressé. Ce qui revient à envoyer tout le fichier, rsync n'a donc plus aucun intérêt et un scp suffit. Donc, pour profiter au maximum de rsync, faut pas utiliser du tar compressé, mais du tar tout court. La compression se fera en tant que option de rsync.
D'ailleurs en théorie : On tar un répertoire qui contient pleins de fichiers puis on le compresse. On aura 2 fichiers : rep_1.tar et rep_1.tar.gz On ajoute un fichier dans le répertoire, on tar le répertoire, puis on le compresse. On aura 2 fichiers : rep_2.tar et rep_2.tar.gz On utilise la commande diff avec rep_1.tar et rep_2.tar on devrait avoir une petite différence. Ensuite on fait un diff avec rep_1.tar.gz et rep_2.tar.gz on devrait avoir une très grosse différence.
rsync sera efficace avec rep_1.tar mais inefficace avec rep_1.tar.gz
Je vous laisse vérifier la théorie.
Arol
"Arol" a écrit dans le message de news:
- Je crée, sur le serveur web, un fichier .tar, accessible en lecture à l'utilisateur "backup", avec mise à jour automatique par star ; - Ce fichier est copié sur ma machine locale, avec synchronisation par rsync (via SSH bien sûr) ; - La couche SSH s'occupe de la compression pour éviter le gaspillage de bande passante.
C'est bien ça ?
Pour la mise à jour (sauvegarde incrémentielle) par star, puis-je m'attendre à des performances comparables à celles de rsync ?
Heu, dans rsync, il y a sync, ça veut dire synchroniser des fichiers entre 2
machines. Et rsync optimise justement cette synchronisation pour éviter des transferts
inutiles. Par conséquent, si tu as un unique fichier tar que tu veux t'envoyer du serveur distant au local, un simple scp suffit.
Donc, ou bien tu fais que du rsync, ou bien que du star + scp.
Petite précision, ça devrait marcher avec tar + rsync, mais pas tar.gz + rsync qui lui sera préféré un scp. Donc tant que tu compresses pas ton tar, ta procédure est ok.
"Arol" a écrit dans le message de news:
- Je crée, sur le serveur web, un fichier .tar, accessible en lecture
à l'utilisateur "backup", avec mise à jour automatique par star ;
- Ce fichier est copié sur ma machine locale, avec synchronisation par
rsync (via SSH bien sûr) ;
- La couche SSH s'occupe de la compression pour éviter le gaspillage
de bande passante.
C'est bien ça ?
Pour la mise à jour (sauvegarde incrémentielle) par star, puis-je
m'attendre à des performances comparables à celles de rsync ?
Heu, dans rsync, il y a sync, ça veut dire synchroniser des fichiers entre
2
machines.
Et rsync optimise justement cette synchronisation pour éviter des
transferts
inutiles.
Par conséquent, si tu as un unique fichier tar que tu veux t'envoyer du
serveur distant au local, un simple scp suffit.
Donc, ou bien tu fais que du rsync, ou bien que du star + scp.
Petite précision, ça devrait marcher avec tar + rsync, mais pas tar.gz +
rsync qui lui sera préféré un scp.
Donc tant que tu compresses pas ton tar, ta procédure est ok.
- Je crée, sur le serveur web, un fichier .tar, accessible en lecture à l'utilisateur "backup", avec mise à jour automatique par star ; - Ce fichier est copié sur ma machine locale, avec synchronisation par rsync (via SSH bien sûr) ; - La couche SSH s'occupe de la compression pour éviter le gaspillage de bande passante.
C'est bien ça ?
Pour la mise à jour (sauvegarde incrémentielle) par star, puis-je m'attendre à des performances comparables à celles de rsync ?
Heu, dans rsync, il y a sync, ça veut dire synchroniser des fichiers entre 2
machines. Et rsync optimise justement cette synchronisation pour éviter des transferts
inutiles. Par conséquent, si tu as un unique fichier tar que tu veux t'envoyer du serveur distant au local, un simple scp suffit.
Donc, ou bien tu fais que du rsync, ou bien que du star + scp.
Petite précision, ça devrait marcher avec tar + rsync, mais pas tar.gz + rsync qui lui sera préféré un scp. Donc tant que tu compresses pas ton tar, ta procédure est ok.
Arol
"Arol" a écrit dans le message de news:
- Je crée, sur le serveur web, un fichier .tar, accessible en lecture à l'utilisateur "backup", avec mise à jour automatique par star ; - Ce fichier est copié sur ma machine locale, avec synchronisation par rsync (via SSH bien sûr) ; - La couche SSH s'occupe de la compression pour éviter le gaspillage de bande passante.
C'est bien ça ?
Pour la mise à jour (sauvegarde incrémentielle) par star, puis-je m'attendre à des performances comparables à celles de rsync ?
Heu, dans rsync, il y a sync, ça veut dire synchroniser des fichiers entre 2
machines. Et rsync optimise justement cette synchronisation pour éviter des transferts
inutiles. Par conséquent, si tu as un unique fichier tar que tu veux t'envoyer du serveur distant au local, un simple scp suffit.
Donc, ou bien tu fais que du rsync, ou bien que du star + scp.
Petite précision, ça devrait marcher avec tar + rsync, mais pas tar.gz + rsync qui lui sera préféré un scp. Donc tant que tu compresses pas ton tar, ta procédure est ok.
"Arol" a écrit dans le message de news:
- Je crée, sur le serveur web, un fichier .tar, accessible en lecture
à l'utilisateur "backup", avec mise à jour automatique par star ;
- Ce fichier est copié sur ma machine locale, avec synchronisation par
rsync (via SSH bien sûr) ;
- La couche SSH s'occupe de la compression pour éviter le gaspillage
de bande passante.
C'est bien ça ?
Pour la mise à jour (sauvegarde incrémentielle) par star, puis-je
m'attendre à des performances comparables à celles de rsync ?
Heu, dans rsync, il y a sync, ça veut dire synchroniser des fichiers entre
2
machines.
Et rsync optimise justement cette synchronisation pour éviter des
transferts
inutiles.
Par conséquent, si tu as un unique fichier tar que tu veux t'envoyer du
serveur distant au local, un simple scp suffit.
Donc, ou bien tu fais que du rsync, ou bien que du star + scp.
Petite précision, ça devrait marcher avec tar + rsync, mais pas tar.gz +
rsync qui lui sera préféré un scp.
Donc tant que tu compresses pas ton tar, ta procédure est ok.
- Je crée, sur le serveur web, un fichier .tar, accessible en lecture à l'utilisateur "backup", avec mise à jour automatique par star ; - Ce fichier est copié sur ma machine locale, avec synchronisation par rsync (via SSH bien sûr) ; - La couche SSH s'occupe de la compression pour éviter le gaspillage de bande passante.
C'est bien ça ?
Pour la mise à jour (sauvegarde incrémentielle) par star, puis-je m'attendre à des performances comparables à celles de rsync ?
Heu, dans rsync, il y a sync, ça veut dire synchroniser des fichiers entre 2
machines. Et rsync optimise justement cette synchronisation pour éviter des transferts
inutiles. Par conséquent, si tu as un unique fichier tar que tu veux t'envoyer du serveur distant au local, un simple scp suffit.
Donc, ou bien tu fais que du rsync, ou bien que du star + scp.
Petite précision, ça devrait marcher avec tar + rsync, mais pas tar.gz + rsync qui lui sera préféré un scp. Donc tant que tu compresses pas ton tar, ta procédure est ok.
Fabien LE LEZ
On Wed, 9 Aug 2006 03:08:15 +0200, "Arol" :
Petite précision, ça devrait marcher avec tar + rsync, mais pas tar.gz + rsync qui lui sera préféré un scp.
C'est bien ce que j'avais compris ; c'est pour ça que j'avais écrit "La couche SSH s'occupe de la compression".
On Wed, 9 Aug 2006 03:08:15 +0200, "Arol" <annie.nomat@free.fr>:
Petite précision, ça devrait marcher avec tar + rsync, mais pas tar.gz +
rsync qui lui sera préféré un scp.
C'est bien ce que j'avais compris ; c'est pour ça que j'avais écrit
"La couche SSH s'occupe de la compression".
Petite précision, ça devrait marcher avec tar + rsync, mais pas tar.gz + rsync qui lui sera préféré un scp.
C'est bien ce que j'avais compris ; c'est pour ça que j'avais écrit "La couche SSH s'occupe de la compression".
Fabien LE LEZ
On Wed, 9 Aug 2006 03:08:15 +0200, "Arol" :
Petite précision, ça devrait marcher avec tar + rsync,
mais pas tar.gz + rsync qui lui sera préféré un scp.
Y a-t-il un inconvénient à utiliser rsync quand même ? Après tout, il y a toujours un gain possible -- le fichier peut n'avoir pas été modifié, ou bien le début du .tar peut n'avoir pas été modifié, ce qui fait que le début du .tar.gz sera le même...
Question subsidiaire (et hors-sujet) : y a-t-il un avantage à utiliser gzip plutôt que bzip2 ? Vitesse ? Compatibilité ?
On Wed, 9 Aug 2006 03:08:15 +0200, "Arol" <annie.nomat@free.fr>:
Petite précision, ça devrait marcher avec tar + rsync,
mais pas tar.gz + rsync qui lui sera préféré un scp.
Y a-t-il un inconvénient à utiliser rsync quand même ?
Après tout, il y a toujours un gain possible -- le fichier peut
n'avoir pas été modifié, ou bien le début du .tar peut n'avoir pas été
modifié, ce qui fait que le début du .tar.gz sera le même...
Question subsidiaire (et hors-sujet) : y a-t-il un avantage à utiliser
gzip plutôt que bzip2 ? Vitesse ? Compatibilité ?
Petite précision, ça devrait marcher avec tar + rsync,
mais pas tar.gz + rsync qui lui sera préféré un scp.
Y a-t-il un inconvénient à utiliser rsync quand même ? Après tout, il y a toujours un gain possible -- le fichier peut n'avoir pas été modifié, ou bien le début du .tar peut n'avoir pas été modifié, ce qui fait que le début du .tar.gz sera le même...
Question subsidiaire (et hors-sujet) : y a-t-il un avantage à utiliser gzip plutôt que bzip2 ? Vitesse ? Compatibilité ?
Arol
"Fabien LE LEZ" a écrit dans le message de news:
mais pas tar.gz + rsync qui lui sera préféré un scp.
Y a-t-il un inconvénient à utiliser rsync quand même ? Après tout, il y a toujours un gain possible -- le fichier peut n'avoir pas été modifié, ou bien le début du .tar peut n'avoir pas été modifié, ce qui fait que le début du .tar.gz sera le même...
Si tu utilises systématiquement rsync, il faudra systématiquement calculer les md4 de milliers de blocs des 2 tar.gz et les comparer, ce qui prend du cpu + réseau. Tout ça pour se rendre compte que c'est pas pareil et qu'il faut tout envoyer.
En terme de probabilité, c'est quasi certain que les tar.gz seront différents et par conséquent, inutile de vérifier et balancer direct avec scp.
Vu la puissance des cpus et les débits actuels, la différence se vera surement pas entre targ.gz + rsync et scp. On est à la limite du chippotage, mais faut vraiment tester les 2 techniques et choisir la meilleure, surtout quand il s'agit de 7 Go qu'il faudra syncroniser régulièrement.
Question subsidiaire (et hors-sujet) : y a-t-il un avantage à utiliser gzip plutôt que bzip2 ? Vitesse ? Compatibilité ?
J'utilise bzip2 (avec option -9 pour maximum) parce qu'il compresse beaucoup mieux que gzip. Pour la vitesse, 1sec de plus passer à compresser pour gagner des Mo, permet de gagner plusieurs secondes de transfert. Donc compresser un max avant d'envoyer.
"Fabien LE LEZ" a écrit dans le message de news:
mais pas tar.gz + rsync qui lui sera préféré un scp.
Y a-t-il un inconvénient à utiliser rsync quand même ?
Après tout, il y a toujours un gain possible -- le fichier peut
n'avoir pas été modifié, ou bien le début du .tar peut n'avoir pas été
modifié, ce qui fait que le début du .tar.gz sera le même...
Si tu utilises systématiquement rsync, il faudra systématiquement calculer
les md4 de milliers de blocs des 2 tar.gz et les comparer, ce qui prend du
cpu + réseau. Tout ça pour se rendre compte que c'est pas pareil et qu'il
faut tout envoyer.
En terme de probabilité, c'est quasi certain que les tar.gz seront
différents et par conséquent, inutile de vérifier et balancer direct avec
scp.
Vu la puissance des cpus et les débits actuels, la différence se vera
surement pas entre targ.gz + rsync et scp.
On est à la limite du chippotage, mais faut vraiment tester les 2 techniques
et choisir la meilleure, surtout quand il s'agit de 7 Go qu'il faudra
syncroniser régulièrement.
Question subsidiaire (et hors-sujet) : y a-t-il un avantage à utiliser
gzip plutôt que bzip2 ? Vitesse ? Compatibilité ?
J'utilise bzip2 (avec option -9 pour maximum) parce qu'il compresse beaucoup
mieux que gzip.
Pour la vitesse, 1sec de plus passer à compresser pour gagner des Mo, permet
de gagner plusieurs secondes de transfert. Donc compresser un max avant
d'envoyer.
mais pas tar.gz + rsync qui lui sera préféré un scp.
Y a-t-il un inconvénient à utiliser rsync quand même ? Après tout, il y a toujours un gain possible -- le fichier peut n'avoir pas été modifié, ou bien le début du .tar peut n'avoir pas été modifié, ce qui fait que le début du .tar.gz sera le même...
Si tu utilises systématiquement rsync, il faudra systématiquement calculer les md4 de milliers de blocs des 2 tar.gz et les comparer, ce qui prend du cpu + réseau. Tout ça pour se rendre compte que c'est pas pareil et qu'il faut tout envoyer.
En terme de probabilité, c'est quasi certain que les tar.gz seront différents et par conséquent, inutile de vérifier et balancer direct avec scp.
Vu la puissance des cpus et les débits actuels, la différence se vera surement pas entre targ.gz + rsync et scp. On est à la limite du chippotage, mais faut vraiment tester les 2 techniques et choisir la meilleure, surtout quand il s'agit de 7 Go qu'il faudra syncroniser régulièrement.
Question subsidiaire (et hors-sujet) : y a-t-il un avantage à utiliser gzip plutôt que bzip2 ? Vitesse ? Compatibilité ?
J'utilise bzip2 (avec option -9 pour maximum) parce qu'il compresse beaucoup mieux que gzip. Pour la vitesse, 1sec de plus passer à compresser pour gagner des Mo, permet de gagner plusieurs secondes de transfert. Donc compresser un max avant d'envoyer.
gvdmoort
Humm, hummm...
Pas besoin de script pour cela. GNU tar sait faire de la sauvegarde incrémentielle. Mieux, star sait faire de la vraie sauvegarde incréme ntielle en vérifiant, entre autre, correctement les changements effectués sur le système de fichier.
Vu les messages qui suivent, je me demande s'il n'y a pas maldonne sur le terme "sauvegarde incrémentielle". Je n'ai pas ma linuxette sous la main pour vérifier, mais ce qui me semblerait intéressant, c'est que la sauvegarde crée un fichier complémentaire (!) qui reprendrait uniquement les fichiers ajoutés à l'archive initiale.
Pour créer ce fichier complémentaire, voir l'option --after-dateÚte
L'intérêt étant de ne devoir transférer que celui-là, sans se casser la tête.
De temps à autre (par quinzaine), on recrée une archive complète.
Or, dans les messages de ce fil, quand on évoque la façon de procéder de rsync ou scp, on semble partir du fait qu'il y a un seul gros fichier modifié à chaque fois, ce qui ne me semble pas la bonne piste en terme d'efficacité (temps de création de l'archive, comparaison, volume transféré, etc.)
Quant au fait de compresser ou non cette archive, j'ai "fréquenté" un serveur de backup qui créait un tar.gz sur le même disque que les données: il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée, et que l'originale n'est effacée que lorsque la compression est achevée. Donc à vue de nez, ça fait 3 fois (!!!) le volume de données à caser sur le disque à un moment.
Je crois aussi me souvenir que certaines options de tar ne sont fonctionnelles que si l'archive n'est pas compressée ; l'ajout de données, la comparaison avec l'original.
Donc avant de cogiter sur la manière de transférer, je pense qu'il faut bien étudier la stratégie d'archivage sur le serveur distant. La page info de tar est copieuse, et elle donne de bonnes idées.
Humm, hummm...
Pas besoin de script pour cela. GNU tar sait faire de la sauvegarde
incrémentielle. Mieux, star sait faire de la vraie sauvegarde incréme ntielle
en vérifiant, entre autre, correctement les changements effectués sur le
système de fichier.
Vu les messages qui suivent, je me demande s'il n'y a pas maldonne sur
le terme "sauvegarde incrémentielle". Je n'ai pas ma linuxette sous la
main pour vérifier, mais ce qui me semblerait intéressant, c'est que
la sauvegarde crée un fichier complémentaire (!) qui reprendrait
uniquement les fichiers ajoutés à l'archive initiale.
Pour créer ce fichier complémentaire, voir l'option --after-date=date
L'intérêt étant de ne devoir transférer que celui-là, sans se
casser la tête.
De temps à autre (par quinzaine), on recrée une archive complète.
Or, dans les messages de ce fil, quand on évoque la façon de
procéder de rsync ou scp, on semble partir du fait qu'il y a un seul
gros fichier modifié à chaque fois, ce qui ne me semble pas la bonne
piste en terme d'efficacité (temps de création de l'archive,
comparaison, volume transféré, etc.)
Quant au fait de compresser ou non cette archive, j'ai "fréquenté" un
serveur de backup qui créait un tar.gz sur le même disque que les
données: il faut savoir que l'archive tar est créée, puis qu'une
copie en est faite, que celle-ci est compressée, et que l'originale
n'est effacée que lorsque la compression est achevée. Donc à vue de
nez, ça fait 3 fois (!!!) le volume de données à caser sur le disque
à un moment.
Je crois aussi me souvenir que certaines options de tar ne sont
fonctionnelles que si l'archive n'est pas compressée ; l'ajout de
données, la comparaison avec l'original.
Donc avant de cogiter sur la manière de transférer, je pense qu'il
faut bien étudier la stratégie d'archivage sur le serveur distant. La
page info de tar est copieuse, et elle donne de bonnes idées.
Pas besoin de script pour cela. GNU tar sait faire de la sauvegarde incrémentielle. Mieux, star sait faire de la vraie sauvegarde incréme ntielle en vérifiant, entre autre, correctement les changements effectués sur le système de fichier.
Vu les messages qui suivent, je me demande s'il n'y a pas maldonne sur le terme "sauvegarde incrémentielle". Je n'ai pas ma linuxette sous la main pour vérifier, mais ce qui me semblerait intéressant, c'est que la sauvegarde crée un fichier complémentaire (!) qui reprendrait uniquement les fichiers ajoutés à l'archive initiale.
Pour créer ce fichier complémentaire, voir l'option --after-dateÚte
L'intérêt étant de ne devoir transférer que celui-là, sans se casser la tête.
De temps à autre (par quinzaine), on recrée une archive complète.
Or, dans les messages de ce fil, quand on évoque la façon de procéder de rsync ou scp, on semble partir du fait qu'il y a un seul gros fichier modifié à chaque fois, ce qui ne me semble pas la bonne piste en terme d'efficacité (temps de création de l'archive, comparaison, volume transféré, etc.)
Quant au fait de compresser ou non cette archive, j'ai "fréquenté" un serveur de backup qui créait un tar.gz sur le même disque que les données: il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée, et que l'originale n'est effacée que lorsque la compression est achevée. Donc à vue de nez, ça fait 3 fois (!!!) le volume de données à caser sur le disque à un moment.
Je crois aussi me souvenir que certaines options de tar ne sont fonctionnelles que si l'archive n'est pas compressée ; l'ajout de données, la comparaison avec l'original.
Donc avant de cogiter sur la manière de transférer, je pense qu'il faut bien étudier la stratégie d'archivage sur le serveur distant. La page info de tar est copieuse, et elle donne de bonnes idées.
gvdmoort
Pour créer ce fichier complémentaire, voir l'option --after-dateÚ te
J'ai parlé un peu vite ; à la lecture de la page de man de GNU-tar, les réponses à ce genre de situation se trouvent dans la section
Quant au fait de compresser ou non cette archive, j'ai "fréquenté" un serveur de backup qui créait un tar.gz sur le même disque que les données: il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée, et que l'originale n'est effacée que lorsque la compression est achevée.
Hon ?
Si tu fais un tar c * | bzip2 > archive.bz2 tu es assuré qu'il n'y aura aucune copie superflue.
On 9 Aug 2006 00:25:49 -0700, gvdmoort@skynet.be:
Quant au fait de compresser ou non cette archive, j'ai "fréquenté" un
serveur de backup qui créait un tar.gz sur le même disque que les
données: il faut savoir que l'archive tar est créée, puis qu'une
copie en est faite, que celle-ci est compressée, et que l'originale
n'est effacée que lorsque la compression est achevée.
Hon ?
Si tu fais un
tar c * | bzip2 > archive.bz2
tu es assuré qu'il n'y aura aucune copie superflue.
Quant au fait de compresser ou non cette archive, j'ai "fréquenté" un serveur de backup qui créait un tar.gz sur le même disque que les données: il faut savoir que l'archive tar est créée, puis qu'une copie en est faite, que celle-ci est compressée, et que l'originale n'est effacée que lorsque la compression est achevée.
Hon ?
Si tu fais un tar c * | bzip2 > archive.bz2 tu es assuré qu'il n'y aura aucune copie superflue.
Fabien LE LEZ
Or, si je récupère le fichier /etc/shadow (par exemple) avec les droits qui vont bien, il sera modifiable uniquement par root.
Je viens de penser à une solution toute simple : récupérer séparément les permissions et les fichiers.
Sur la machine-source : find / -print0 |xargs -0 stat -c "%a %u %g %N" > .../stat.txt Puis un petit rsync sans sauvegarde des permissions.
Et si le serveur web tombe en panne, je remets tous les fichiers sur le nouveau serveur (avec des permissions bidon), puis je lance un petit script qui lit "stat.txt" et rétablit les permissions.
Or, si je récupère le fichier /etc/shadow (par exemple) avec les
droits qui vont bien, il sera modifiable uniquement par root.
Je viens de penser à une solution toute simple : récupérer séparément
les permissions et les fichiers.
Sur la machine-source :
find / -print0 |xargs -0 stat -c "%a %u %g %N" > .../stat.txt
Puis un petit rsync sans sauvegarde des permissions.
Et si le serveur web tombe en panne, je remets tous les fichiers sur
le nouveau serveur (avec des permissions bidon), puis je lance un
petit script qui lit "stat.txt" et rétablit les permissions.
Or, si je récupère le fichier /etc/shadow (par exemple) avec les droits qui vont bien, il sera modifiable uniquement par root.
Je viens de penser à une solution toute simple : récupérer séparément les permissions et les fichiers.
Sur la machine-source : find / -print0 |xargs -0 stat -c "%a %u %g %N" > .../stat.txt Puis un petit rsync sans sauvegarde des permissions.
Et si le serveur web tombe en panne, je remets tous les fichiers sur le nouveau serveur (avec des permissions bidon), puis je lance un petit script qui lit "stat.txt" et rétablit les permissions.
