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.
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.
Merci d'avance pour vos pistes et explications...
Voila ce que j'ai chez moi comme systeme de replication entre 2 machines :
Sur la machine qui recoit la sauvegarde, je lance ca via une crontab :
Ca me fait une sauvegarde sans /backups/main tout en gardant les versions precedentes des fichiers dans /backups/<date>.
Je supprime automatiquement les backups de + d'1 mois via une autre tache cron :
for i in `/usr/bin/find /backups -ctime +30 -maxdepth 1 -name "[0-9]*"` do /bin/rm -Rf "$i" done
Par contre, seul bemol par rapport a ce que tu demandes, ceci tourne en root. Pour ne pas avoir a m'authentifier a chaque sauvegarde, y'a un systeme de cles DSA sans passphrase entre les comptes root des deux machines.
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.
Merci d'avance pour vos pistes et explications...
Voila ce que j'ai chez moi comme systeme de replication entre 2 machines :
Sur la machine qui recoit la sauvegarde, je lance ca via une crontab :
Ca me fait une sauvegarde sans /backups/main tout en gardant les
versions precedentes des fichiers dans /backups/<date>.
Je supprime automatiquement les backups de + d'1 mois via une autre
tache cron :
for i in `/usr/bin/find /backups -ctime +30 -maxdepth 1 -name "[0-9]*"`
do
/bin/rm -Rf "$i"
done
Par contre, seul bemol par rapport a ce que tu demandes, ceci tourne en
root. Pour ne pas avoir a m'authentifier a chaque sauvegarde, y'a un
systeme de cles DSA sans passphrase entre les comptes root des deux
machines.
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.
Merci d'avance pour vos pistes et explications...
Voila ce que j'ai chez moi comme systeme de replication entre 2 machines :
Sur la machine qui recoit la sauvegarde, je lance ca via une crontab :
Ca me fait une sauvegarde sans /backups/main tout en gardant les versions precedentes des fichiers dans /backups/<date>.
Je supprime automatiquement les backups de + d'1 mois via une autre tache cron :
for i in `/usr/bin/find /backups -ctime +30 -maxdepth 1 -name "[0-9]*"` do /bin/rm -Rf "$i" done
Par contre, seul bemol par rapport a ce que tu demandes, ceci tourne en root. Pour ne pas avoir a m'authentifier a chaque sauvegarde, y'a un systeme de cles DSA sans passphrase entre les comptes root des deux machines.
Bonjour, 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. Merci d'avance pour vos pistes et explications...
C'est juste une idée qui me vient, comme ça :
Si un script tournait en root via cron sur le serveur distant, il pourrait créer une archive avec tar, changer les permissions sur cette archive, et ta machine de backup pourrait récupérer cette archive par ftp par ex, sous une autre identité.
Mais sauvegarder la totalité, ça signifierait que l'espace disque de la machine distante devrait être au moins le double de celui des données, et ce serait fou de rapatrier la totalité chaque jour (quoique rsync ne transfère que la différence).
Donc, il vaudrait mieux imaginer un script (avec find) qui décèle les fichiers modifiés/créés depuis la veille, et en fait une archive, qui serait elle de taille réduite. Elle pourrait être compressée (réduction du volume de transfert, mais charge système sur la machine distante) et une fois rapatriée, décompressée dans la copie locale du système distant.
Mais ça ne résoud pas le cas des fichiers effacés. À moins d'imaginer un script plus élaboré qui décèlerait les fichiers effacés, transmettrait la liste à la machine miroir, et y effacerait les fichiers en question.
Je me demande si tout ça, ce n'est pas tenter de réinventer la roue, rsync faisant bien les choses... Mais cela dit, quand rsync doit comparer des arborescences entières, il me semble que ça prend beaucoups (!) de ressources et de temps, surtout via internet.
Je ne sais pas, à méditer...
Gvdmoort
Bonjour,
Bonjour,
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.
Merci d'avance pour vos pistes et explications...
C'est juste une idée qui me vient, comme ça :
Si un script tournait en root via cron sur le serveur distant, il
pourrait créer une archive avec tar, changer les permissions sur cette
archive, et ta machine de backup pourrait récupérer cette archive par
ftp par ex, sous une autre identité.
Mais sauvegarder la totalité, ça signifierait que l'espace disque de
la machine distante devrait être au moins le double de celui des
données, et ce serait fou de rapatrier la totalité chaque jour
(quoique rsync ne transfère que la différence).
Donc, il vaudrait mieux imaginer un script (avec find) qui décèle les
fichiers modifiés/créés depuis la veille, et en fait une archive,
qui serait elle de taille réduite.
Elle pourrait être compressée (réduction du volume de transfert,
mais charge système sur la machine distante) et une fois rapatriée,
décompressée dans la copie locale du système distant.
Mais ça ne résoud pas le cas des fichiers effacés. À moins
d'imaginer un script plus élaboré qui décèlerait les fichiers
effacés, transmettrait la liste à la machine miroir, et y effacerait
les fichiers en question.
Je me demande si tout ça, ce n'est pas tenter de réinventer la roue,
rsync faisant bien les choses... Mais cela dit, quand rsync doit
comparer des arborescences entières, il me semble que ça prend
beaucoups (!) de ressources et de temps, surtout via internet.
Bonjour, 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. Merci d'avance pour vos pistes et explications...
C'est juste une idée qui me vient, comme ça :
Si un script tournait en root via cron sur le serveur distant, il pourrait créer une archive avec tar, changer les permissions sur cette archive, et ta machine de backup pourrait récupérer cette archive par ftp par ex, sous une autre identité.
Mais sauvegarder la totalité, ça signifierait que l'espace disque de la machine distante devrait être au moins le double de celui des données, et ce serait fou de rapatrier la totalité chaque jour (quoique rsync ne transfère que la différence).
Donc, il vaudrait mieux imaginer un script (avec find) qui décèle les fichiers modifiés/créés depuis la veille, et en fait une archive, qui serait elle de taille réduite. Elle pourrait être compressée (réduction du volume de transfert, mais charge système sur la machine distante) et une fois rapatriée, décompressée dans la copie locale du système distant.
Mais ça ne résoud pas le cas des fichiers effacés. À moins d'imaginer un script plus élaboré qui décèlerait les fichiers effacés, transmettrait la liste à la machine miroir, et y effacerait les fichiers en question.
Je me demande si tout ça, ce n'est pas tenter de réinventer la roue, rsync faisant bien les choses... Mais cela dit, quand rsync doit comparer des arborescences entières, il me semble que ça prend beaucoups (!) de ressources et de temps, surtout via internet.
Je ne sais pas, à méditer...
Gvdmoort
Francois Goudal
wrote:
Bonjour,
Bonjour, 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. Merci d'avance pour vos pistes et explications...
C'est juste une idée qui me vient, comme ça :
Si un script tournait en root via cron sur le serveur distant, il pourrait créer une archive avec tar, changer les permissions sur cette archive, et ta machine de backup pourrait récupérer cette archive par ftp par ex, sous une autre identité.
Mais sauvegarder la totalité, ça signifierait que l'espace disque de la machine distante devrait être au moins le double de celui des données, et ce serait fou de rapatrier la totalité chaque jour (quoique rsync ne transfère que la différence).
Donc, il vaudrait mieux imaginer un script (avec find) qui décèle les fichiers modifiés/créés depuis la veille, et en fait une archive, qui serait elle de taille réduite. Elle pourrait être compressée (réduction du volume de transfert, mais charge système sur la machine distante) et une fois rapatriée, décompressée dans la copie locale du système distant.
Mais ça ne résoud pas le cas des fichiers effacés. À moins d'imaginer un script plus élaboré qui décèlerait les fichiers effacés, transmettrait la liste à la machine miroir, et y effacerait les fichiers en question.
Je me demande si tout ça, ce n'est pas tenter de réinventer la roue, rsync faisant bien les choses... Mais cela dit, quand rsync doit comparer des arborescences entières, il me semble que ça prend beaucoups (!) de ressources et de temps, surtout via internet.
Je ne sais pas, à méditer...
Gvdmoort
Je fais des synchros d'arborescences plutot consequentes sur 2 machines disposant chacune d'une ADSL, c'est pas si long que cela. Ceci dit, je reviens sur la solution que j'ai proposee : On doit pouvoir faire tourner le script rsync que j'ai donne du cote serveur, et inverser les source/destination dans la ligne de commande. Ainsi c'est l'hote distant qui fait tourner un script en root et qui vient faire sa sauvegarde rsync sur la machine locale.
Bonjour,
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.
Merci d'avance pour vos pistes et explications...
C'est juste une idée qui me vient, comme ça :
Si un script tournait en root via cron sur le serveur distant, il
pourrait créer une archive avec tar, changer les permissions sur cette
archive, et ta machine de backup pourrait récupérer cette archive par
ftp par ex, sous une autre identité.
Mais sauvegarder la totalité, ça signifierait que l'espace disque de
la machine distante devrait être au moins le double de celui des
données, et ce serait fou de rapatrier la totalité chaque jour
(quoique rsync ne transfère que la différence).
Donc, il vaudrait mieux imaginer un script (avec find) qui décèle les
fichiers modifiés/créés depuis la veille, et en fait une archive,
qui serait elle de taille réduite.
Elle pourrait être compressée (réduction du volume de transfert,
mais charge système sur la machine distante) et une fois rapatriée,
décompressée dans la copie locale du système distant.
Mais ça ne résoud pas le cas des fichiers effacés. À moins
d'imaginer un script plus élaboré qui décèlerait les fichiers
effacés, transmettrait la liste à la machine miroir, et y effacerait
les fichiers en question.
Je me demande si tout ça, ce n'est pas tenter de réinventer la roue,
rsync faisant bien les choses... Mais cela dit, quand rsync doit
comparer des arborescences entières, il me semble que ça prend
beaucoups (!) de ressources et de temps, surtout via internet.
Je ne sais pas, à méditer...
Gvdmoort
Je fais des synchros d'arborescences plutot consequentes sur 2 machines
disposant chacune d'une ADSL, c'est pas si long que cela.
Ceci dit, je reviens sur la solution que j'ai proposee : On doit pouvoir
faire tourner le script rsync que j'ai donne du cote serveur, et
inverser les source/destination dans la ligne de commande. Ainsi c'est
l'hote distant qui fait tourner un script en root et qui vient faire sa
sauvegarde rsync sur la machine locale.
Bonjour, 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. Merci d'avance pour vos pistes et explications...
C'est juste une idée qui me vient, comme ça :
Si un script tournait en root via cron sur le serveur distant, il pourrait créer une archive avec tar, changer les permissions sur cette archive, et ta machine de backup pourrait récupérer cette archive par ftp par ex, sous une autre identité.
Mais sauvegarder la totalité, ça signifierait que l'espace disque de la machine distante devrait être au moins le double de celui des données, et ce serait fou de rapatrier la totalité chaque jour (quoique rsync ne transfère que la différence).
Donc, il vaudrait mieux imaginer un script (avec find) qui décèle les fichiers modifiés/créés depuis la veille, et en fait une archive, qui serait elle de taille réduite. Elle pourrait être compressée (réduction du volume de transfert, mais charge système sur la machine distante) et une fois rapatriée, décompressée dans la copie locale du système distant.
Mais ça ne résoud pas le cas des fichiers effacés. À moins d'imaginer un script plus élaboré qui décèlerait les fichiers effacés, transmettrait la liste à la machine miroir, et y effacerait les fichiers en question.
Je me demande si tout ça, ce n'est pas tenter de réinventer la roue, rsync faisant bien les choses... Mais cela dit, quand rsync doit comparer des arborescences entières, il me semble que ça prend beaucoups (!) de ressources et de temps, surtout via internet.
Je ne sais pas, à méditer...
Gvdmoort
Je fais des synchros d'arborescences plutot consequentes sur 2 machines disposant chacune d'une ADSL, c'est pas si long que cela. Ceci dit, je reviens sur la solution que j'ai proposee : On doit pouvoir faire tourner le script rsync que j'ai donne du cote serveur, et inverser les source/destination dans la ligne de commande. Ainsi c'est l'hote distant qui fait tourner un script en root et qui vient faire sa sauvegarde rsync sur la machine locale.
Dans le message <news:, ** tapota sur f.c.o.l.configuration :
Donc, il vaudrait mieux imaginer un script (avec find) qui décèle les fichiers modifiés/créés depuis la veille, et en fait une archive, qui serait elle de taille réduite.
Pas besoin de script pour cela. GNU tar sait faire de la sauvegarde incrémentielle. Mieux, star sait faire de la vraie sauvegarde incrémentielle en vérifiant, entre autre, correctement les changements effectués sur le système de fichier. De plus, star permet de sauvegarder et de restaurer toutes les permissions, les attributs étendus, les ACLs et les fichiers à trou.
-- Sébastien Monbrun aka TiChou
Dans le message
<news:1155047697.588246.138860@n13g2000cwa.googlegroups.com>,
*gvdmoort@skynet.be* tapota sur f.c.o.l.configuration :
Donc, il vaudrait mieux imaginer un script (avec find) qui décèle les
fichiers modifiés/créés depuis la veille, et en fait une archive,
qui serait elle de taille réduite.
Pas besoin de script pour cela. GNU tar sait faire de la sauvegarde
incrémentielle. Mieux, star sait faire de la vraie sauvegarde incrémentielle
en vérifiant, entre autre, correctement les changements effectués sur le
système de fichier. De plus, star permet de sauvegarder et de restaurer
toutes les permissions, les attributs étendus, les ACLs et les fichiers à
trou.
Dans le message <news:, ** tapota sur f.c.o.l.configuration :
Donc, il vaudrait mieux imaginer un script (avec find) qui décèle les fichiers modifiés/créés depuis la veille, et en fait une archive, qui serait elle de taille réduite.
Pas besoin de script pour cela. GNU tar sait faire de la sauvegarde incrémentielle. Mieux, star sait faire de la vraie sauvegarde incrémentielle en vérifiant, entre autre, correctement les changements effectués sur le système de fichier. De plus, star permet de sauvegarder et de restaurer toutes les permissions, les attributs étendus, les ACLs et les fichiers à trou.
-- Sébastien Monbrun aka TiChou
Fabien LE LEZ
On Tue, 8 Aug 2006 18:45:09 +0200, Sébastien Monbrun aka TiChou :
Mieux, star sait faire de la vraie sauvegarde incrémentielle en vérifiant, entre autre, correctement les changements effectués sur le système de fichier.
Donc, si je comprends bien :
- 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 ?
On Tue, 8 Aug 2006 18:45:09 +0200, Sébastien Monbrun aka TiChou :
Mieux, star sait faire de la vraie sauvegarde incrémentielle
en vérifiant, entre autre, correctement les changements effectués sur le
système de fichier.
Donc, si je comprends bien :
- 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 ?
On Tue, 8 Aug 2006 18:45:09 +0200, Sébastien Monbrun aka TiChou :
Mieux, star sait faire de la vraie sauvegarde incrémentielle en vérifiant, entre autre, correctement les changements effectués sur le système de fichier.
Donc, si je comprends bien :
- 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 ?
- 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.
"Fabien LE LEZ" 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.
- 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.
Arol
"Fabien LE LEZ" 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.
Puis faut faire attention avec les versions de rsync en local et distant. En local 2.4.4 en distant 2.4.4, ça ne marche pas. En local 2.4.4 en distant 2.4.6 ou 2.4.8, ça marche.
"Fabien LE LEZ" 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.
Puis faut faire attention avec les versions de rsync en local et distant.
En local 2.4.4 en distant 2.4.4, ça ne marche pas.
En local 2.4.4 en distant 2.4.6 ou 2.4.8, ça marche.
- 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.
Puis faut faire attention avec les versions de rsync en local et distant. En local 2.4.4 en distant 2.4.4, ça ne marche pas. En local 2.4.4 en distant 2.4.6 ou 2.4.8, ça marche.
Fabien LE LEZ
On Tue, 8 Aug 2006 21:42:30 +0200, "Arol" :
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.
Un scp de 7 Go à travers une connexion ADSL ? Et ce, tous les jours ? C'est pas gagné.
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.
On Tue, 8 Aug 2006 21:42:30 +0200, "Arol" <annie.nomat@free.fr>:
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.
Un scp de 7 Go à travers une connexion ADSL ? Et ce, tous les jours ?
C'est pas gagné.
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.
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.
Un scp de 7 Go à travers une connexion ADSL ? Et ce, tous les jours ? C'est pas gagné.
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.
Francois Goudal
Fabien LE LEZ wrote:
On Tue, 8 Aug 2006 21:42:30 +0200, "Arol" :
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.
Un scp de 7 Go à travers une connexion ADSL ? Et ce, tous les jours ? C'est pas gagné.
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.
On Tue, 8 Aug 2006 21:42:30 +0200, "Arol" <annie.nomat@free.fr>:
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.
Un scp de 7 Go à travers une connexion ADSL ? Et ce, tous les jours ?
C'est pas gagné.
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.
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.
Un scp de 7 Go à travers une connexion ADSL ? Et ce, tous les jours ? C'est pas gagné.
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.
"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 son md4. Il fait pareil avec le fichier distant. Puis il compare les md4 de chaque bloc. Si ils sont différents, il envoie le bloc en question.
Le problème avec un unique fichier tar qui de plus est 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 n'ont plus aucun rapport avec l'ancien tar. 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, d'ailleurs personne ne le fait.
"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 son
md4. Il fait pareil avec le fichier distant.
Puis il compare les md4 de chaque bloc.
Si ils sont différents, il envoie le bloc en question.
Le problème avec un unique fichier tar qui de plus est 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 n'ont plus aucun rapport avec l'ancien tar.
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,
d'ailleurs personne ne le fait.
"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 son md4. Il fait pareil avec le fichier distant. Puis il compare les md4 de chaque bloc. Si ils sont différents, il envoie le bloc en question.
Le problème avec un unique fichier tar qui de plus est 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 n'ont plus aucun rapport avec l'ancien tar. 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, d'ailleurs personne ne le fait.
