Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
On Wed, Sep 17, 2014 at 01:45:55AM +0200, Gaël wrote: Hello, [ rdiff-backup, tout ça...] Je ne vais pas être péremptoire et dire que c'est le meilleur outil de sauvegarde de tous les temps mais simplement que c'est le meilleur outil de sauvegarde parmi tous ceux que j'ai pu essayer. ;) J'ai voulu le tester, et en effet, j'ai été arrêté par sa rusticité. Pour ma part j'utilise un script rsync, qui utilise les hardlinks. ici : http://sebsauvage.net/paste/?cb1d48f07245879e#2TkAHKxuq2s5oAc7V9Pd+bbq/QY7kHDJ/gcs7HzjWLk= Sinon l'outil rsnapshot fait ça aussi : http://www.rsnapshot.org/ dispo en paquet debian; :) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/CAGKqBrkhCqjMxExg0acPQE5j+E=nqw1trynp8yfvqeabsew...@mail.gmail.com -- Bertrand Orvoine -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140917061217.gb24...@bop.univ-ubs.fr
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Bertrand Orvoine a écrit : Sinon l'outil rsnapshot fait ça aussi : http://www.rsnapshot.org/ En effet mais le reproche que je fais à rsnapshot est que, à l'instar de la plupart des outils, il fonctionne en mode incrémental et non différentiel. Pour bien comprendre la différence, prenons un cas assez fréquent chez moi : l'ajout de tags dans les photographies, opération qui ajoute ou altère quelques centaines d'octets du fichier. Si un soir, je me lance dans une séance de taguage de photographies et que j'en modifie ainsi une centaine qui font en moyenne 5 Mo, avec rsnapshot, la sauvegarde (incrémentale) suivante consommera 500 Mo. Avec rdiff-backup, elle n'en consommera tout au plus que quelques Mo, voire moins. Et j'ai le même problème au niveau professionnel avec une base de 110 Go, dumpée toutes les nuits dans un gros fichier texte et dont les modifications quotidiennes représentent une trentaine de Mo. Avec rsnapshot, chaque sauvegarde incrémentale occuperait 110 Go ou tout au moins une bonne dizaine de Go en activant la compression. Avec rdiff-backup, chaque sauvegarde consomme trente à quarante Mo (et j'ai donc une année glissante de sauvegarde sur un simple disque). Le volume des sauvegardes incrémentales pose un problème d'espace consommé sur disque (et donc mécaniquement de durée de conservation des données) mais aussi de transfert des données lorsqu'on effectue des sauvegardes distantes (c'est mon cas, j'ai une sauvegarde locale et une sauvegarde distante). Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140917084756.ga3...@hector.home.dinot.net
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Salut Seb, Le 17/09/2014 10:47, Sébastien Dinot a écrit : Bertrand Orvoine a écrit : Sinon l'outil rsnapshot fait ça aussi : http://www.rsnapshot.org/ En effet mais le reproche que je fais à rsnapshot est que, à l'instar de la plupart des outils, il fonctionne en mode incrémental et non différentiel. Oui, mais c'est aussi l'intérêt ! On n'a pas à craindre qu'une corruption d'un diff fiche par terre l'ensemble des versions d'un fichier. L'argument sur la taille est bien sûr tout à fait justifié (et l'exemple d'une parfaite pertinence) mais pour ma part j'ai préféré joué la sécurité et donc choisi rsnapshot pour sauvegarder les VM LXC du boulot. J'avais un peu regardé le format des diffs de rdiff-backup et ça me semblait trop complexe en cas de corruption de données sur le volume de sauvegarde. On peut cependant pondérer (voire ignorer) ce risque en dédoublant les sauvegardes comme tu l'indiques ! Juste une question : est-ce que le calcul du diff (de rdiff-backup) est moins consommateur de temps pour une sauvegarde sur disque externe (pas de réseau) qu'une duplication à la rsnapshot ? Et puisqu'on y est, une deuxième question : comment se comporte rdiff-backup sur les fichiers spare (genre machines virtuelles par exemple) ? À plus Patrice Pillot -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54195861.4060...@teletopie.net
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Sébastien Dinot wrote on Tue, Sep 16, 2014 at 11:37:47PM +0200 Bonsoir, C. Mourad Jaber a écrit : Aucun FS ne te protégera contre un crash matériel ce qui est la plaie des disques externes... Ou plutôt « ce qui est la plaie de tout système de stockage ». Et contre cela, un seul remède : il faut multiplier les systèmes de stockage, si possible sur des sites géographiques différents. Et au passage, voici un petit conseil : ne laissez jamais le disque dur externe connecté en dehors des opérations de sauvegarde. Voici deux ans, le disque dur externe de sauvegarde d'un collègue a grillé en même temps que le PC sauvegardé lorsque ce dernier a été victime d'un court-circuit (et accessoirement d'un début d'incendie). Si tu veux de l'historisation, il faut penser à utiliser rsync avec des scripts utilisant les liens durs (hard link)... Mieux que le hard link, je préconise l'utilisation de rdiff-backup [1], outil qui peut paraître rustique (et qui l'est sous certains aspects) mais qui a moult avantages, le principal étant la compacité des sauvegardes différentielles (on peut stocker un long historique sans consommer trop d'espace), le second l'approche « r(everse )diff » : la sauvegarde complète correspond toujours à la dernière sauvegarde et les « r(everse )diff » permettent de remonter dans le passé (d'habitude, c'est le contraire). Du coup, il n'est plus nécessaire de faire une sauvegarde complète une fois la première réalisée (c'est important dans le cadre de sauvegardes distantes avec une faible bande passante montante) et pour conserver un historique glissant, il suffit à rdiff-backup de supprimer les « r(everse )diff » les plus anciens. Seule ombre (de taille) au tableau : il n'est plus maintenu. rdiff-backup est quand-même packagé Wheezy. Peut-être ne l'est-il plus sur Jessie ? A+ Dominique -- -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140917095307.ga18...@telecom-paristech.fr
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Yope! En effet mais le reproche que je fais à rsnapshot est que, à l'instar de la plupart des outils, il fonctionne en mode incrémental et non différentiel. Intéressant, je n'avais pas saisi cette différence. Sais-tu comment fonctionne rsync ? en cherchant un peu je vois que ça fait de l'incrémental, même avec les hardlinks. Un fichier modifié est re-écrit en entier, j'ai l'impression. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/CAGKqBrkgt9ZdV6=uyb4vt_b5xhwktzzrxz3tydo53f_bel7...@mail.gmail.com
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
outil qui peut paraître rustique (et qui l'est sous certains aspects) rdiff-backup est quand-même packagé Wheezy. Peut-être ne l'est-il plus sur Jessie ? il est bien packager sous jessie également A+ j Dominique jerem -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54195c6b.6070...@prego-network.net
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Le 16/09/2014 17:06, mahashakti a écrit : Bonjour Je sollicite votre avis avant de me lancer: quel système de fichiers choisir pour une sauvegarde régulière vers un disque dur externe ? Le tout avec rsync. Et pas mal de fichiers. Je cherche avant tout la solidité et les possibilités de récupération en cas de crash. Pour la sauvegarde des serveurs j'utilise BackupPC http://backuppc.sourceforge.net Sur le serveur de backup, le volume logique qui stock les sauvegardes utilise XFS. J'avais utilisé Ext3 mais j'ai eu des problèmes avec le nombre maximum d'inodes. -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:frede...@juliana-multimedia.com | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ===Debian=GNU/Linux=== -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/541964a1.9030...@juliana-multimedia.com
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Le 17 sept. 14 à 12:38, Frédéric MASSOT a écrit : Le 16/09/2014 17:06, mahashakti a écrit : Bonjour Je sollicite votre avis avant de me lancer: quel système de fichiers choisir pour une sauvegarde régulière vers un disque dur externe ? Le tout avec rsync. Et pas mal de fichiers. Je cherche avant tout la solidité et les possibilités de récupération en cas de crash. Pour la sauvegarde des serveurs j'utilise BackupPC http:// backuppc.sourceforge.net Sur le serveur de backup, le volume logique qui stock les sauvegardes utilise XFS. J'avais utilisé Ext3 mais j'ai eu des problèmes avec le nombre maximum d'inodes. J'utilise backup-manager. On a le choix entre tous les types de sauvegarde. -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:frede...@juliana-multimedia.com | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ===Debian=GNU/Linux=== -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/541964A1.9030106@juliana- multimedia.com -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/35e2ea36-91ac-4681-8b6d-7e88c79a5...@worldonline.fr
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Dominique Asselineau a écrit : rdiff-backup est quand-même packagé Wheezy. Peut-être ne l'est-il plus sur Jessie ? Il est maintenu en tant que paquet par Debian : https://tracker.debian.org/pkg/rdiff-backup Mais le développement est arrêté depuis 2009 : http://www.nongnu.org/rdiff-backup/ Le problème à plus ou moins long terme est l'abandon du support de Python 2.7 au profit des souches 3.x : il faudra alors que quelqu'un se dévoue pour migrer le code. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140917113731.ga4...@hector.home.dinot.net
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Gaël a écrit : Intéressant, je n'avais pas saisi cette différence. Sais-tu comment fonctionne rsync ? en cherchant un peu je vois que ça fait de l'incrémental, même avec les hardlinks. Un fichier modifié est re-écrit en entier, j'ai l'impression. Primo, il faut se méfier des termes employés. Par exemple, l'auteur de l'article : http://earlruby.org/2013/05/creating-differential-backups-with-hard-links-and-rsync/ parle de sauvegarde différentielle mais c'est une sauvegarde incrémentale qu'il décrit. http://en.wikipedia.org/wiki/Incremental_backup http://en.wikipedia.org/wiki/Differential_backup À ma connaissance, rsync effectue des sauvegardes incrémentales mais il transfère les données d'une machine à l'autre de manière peu ou prou différentielle (i.e. il ne transfère que les blocs qui ont changé). Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140917114758.gb4...@hector.home.dinot.net
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Le 17/09/2014 12:38, Frédéric MASSOT a écrit : Le 16/09/2014 17:06, mahashakti a écrit : Bonjour Je sollicite votre avis avant de me lancer: quel système de fichiers choisir pour une sauvegarde régulière vers un disque dur externe ? Le tout avec rsync. Et pas mal de fichiers. Je cherche avant tout la solidité et les possibilités de récupération en cas de crash. Pour la sauvegarde des serveurs j'utilise BackupPC http://backuppc.sourceforge.net Sur le serveur de backup, le volume logique qui stock les sauvegardes utilise XFS. J'avais utilisé Ext3 mais j'ai eu des problèmes avec le nombre maximum d'inodes. J'ai oublié de précisé, BackupPC utilise au choix rsync, rsync+ssh, FTP, SMB ou TAR. -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:frede...@juliana-multimedia.com | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ===Debian=GNU/Linux=== -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54197963.9000...@juliana-multimedia.com
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Salut Patrice, phep a écrit : Oui, mais c'est aussi l'intérêt ! On n'a pas à craindre qu'une corruption d'un diff fiche par terre l'ensemble des versions d'un fichier. Ah... l'idéal inatteignable de la sauvegarde : historisé, rapide, compact, robuste et chiffré. Je crains qu'on ne puisse pas tout avoir. Il faut faire des choix qui dépendent des priorités et des contraintes. :) Pour ma part, mes exigences principales sont : - Historiser les sauvegardes sur une période confortable (au boulot, un an glissant, à la maison... je n'ai encore rien supprimé depuis que j'utilise rdiff-backup). - Minimiser les données transférées (pour cause de sauvegarde distante et de débit montant qui plafonne à 110 ko/s). À ce titre, devoir faire de temps à autres des sauvegardes complètes est rédhibitoire. - Accéder aisément à la dernière sauvegarde qui, par expérience, est celle que j'utilise le plus souvent. L'argument sur la taille est bien sûr tout à fait justifié (et l'exemple d'une parfaite pertinence) mais pour ma part j'ai préféré joué la sécurité et donc choisi rsnapshot pour sauvegarder les VM LXC du boulot. J'utilise beaucoup de VM mais la volumétrie des images disque fait que j'ai abandonné tout espoir de les sauvegarder de manière régulière, d'autant plus qu'avec une VM, la sauvegarde différentielle perd drastiquement en efficacité : pour l'outil de sauvegarde, l'image disque n'est qu'un blob binaire et il ne peut savoir de l'extérieur si un secteur est occupé ou non. Du coup, il suffit que ce secteur ait changé pour qu'il le sauvegarde, même si ce secteur ne contient rien au moement de la sauvegarde. Exemple extrême mais réel avec une VM utilisée pour du test unitaire et de la génération de paquet : 1. Je récupère les sources de l'application et les données de test (500 Mo de sources pour l'appli + 3,6 Go de données). 1. Je compile dans la VM notre application, ce qui produit 14 Go de fichiers intermédiaires ou finaux en mode debug. 2. Je déroule la batterie de 2900 tests unitaires qui produisent à leur tour moult fichiers de données et de logs. 3. Comme tout passe, je lance la génération des paquets (re-compilation en mode release) et je pousse des paquets sur notre référentiel de paquets. 4. Je supprime toute l'arborescence. Si je mets de côté ce qui s'est passé entre temps au niveau système (par exemple, les écritures dans /var/log), je peux dire que j'en suis revenu au point de la veille. L'état intrinsèque de la VM n'a pas bougé. Pour autant, l'outil de sauvegarde va détecter l'équivalent de plusieurs dizaines de Go de changement dans le fichier image de la VM et va donc me produire un « diff » gigantesque. Pour cette raison, je fais tourner rdiff-backup dans les VM et sur le serveur hébergeant les VM mais pour de dernier, je lui demande d'ignorer les images de disques des VM. On peut cependant pondérer (voire ignorer) ce risque en dédoublant les sauvegardes comme tu l'indiques ! J'ai fait court mais en réalité, j'ai trois supports de sauvegarde. Mes données (photos, textes, code) valent bien plus à mes yeux que les 3 x 100 euros que peuvent coûter des disques. Juste une question : est-ce que le calcul du diff (de rdiff-backup) est moins consommateur de temps pour une sauvegarde sur disque externe (pas de réseau) qu'une duplication à la rsnapshot ? À moins que les volumes à transférer ne soient importants en regard de la bande passante disponible, rdiff-backup est bien moins efficace lorsqu'on effectue une sauvegarde sur un disque externe local que sur une machine « distante ». En effet, pour calculer le différentiel, il doit lire l'intégralité du fichier précédemment sauvegardé. Si tu utilises un disque externe, c'est l'instance locale de rdiff-backup qui se charge de cette lecture (et qui commence donc par lire le disque externe). Si tu utilises une machine tierce, rdiff-backup lance une instance sur cette seconde machine qui travaille en parallèle de la première et calcule les sommes de contrôle sur le serveur de sauvegarde pendant que ton instance locale travaille sur les fichiers de ta machine. D'ailleurs, je conseille vivement des disques externes disposant d'une interface USB3, ça vous change la vie. :) Et puisqu'on y est, une deuxième question : comment se comporte rdiff-backup sur les fichiers spare (genre machines virtuelles par exemple) ? Je ne sais pas ce que tu entends par « fichier spare » dans ce cas. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140917122128.gc4...@hector.home.dinot.net
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
On Wed, Sep 17, 2014 at 02:21:28PM +0200, Sébastien Dinot wrote: Salut Patrice, phep a écrit : Oui, mais c'est aussi l'intérêt ! On n'a pas à craindre qu'une corruption d'un diff fiche par terre l'ensemble des versions d'un fichier. Ah... l'idéal inatteignable de la sauvegarde : historisé, rapide, compact, robuste et chiffré. Je crains qu'on ne puisse pas tout avoir. Il faut faire des choix qui dépendent des priorités et des contraintes. :) Pour ma part, mes exigences principales sont : - Historiser les sauvegardes sur une période confortable (au boulot, un an glissant, à la maison... je n'ai encore rien supprimé depuis que j'utilise rdiff-backup). - Minimiser les données transférées (pour cause de sauvegarde distante et de débit montant qui plafonne à 110 ko/s). À ce titre, devoir faire de temps à autres des sauvegardes complètes est rédhibitoire. - Accéder aisément à la dernière sauvegarde qui, par expérience, est celle que j'utilise le plus souvent. L'argument sur la taille est bien sûr tout à fait justifié (et l'exemple d'une parfaite pertinence) mais pour ma part j'ai préféré joué la sécurité et donc choisi rsnapshot pour sauvegarder les VM LXC du boulot. J'utilise beaucoup de VM mais la volumétrie des images disque fait que j'ai abandonné tout espoir de les sauvegarder de manière régulière, d'autant plus qu'avec une VM, la sauvegarde différentielle perd drastiquement en efficacité : pour l'outil de sauvegarde, l'image disque n'est qu'un blob binaire et il ne peut savoir de l'extérieur si un secteur est occupé ou non. Du coup, il suffit que ce secteur ait changé pour qu'il le sauvegarde, même si ce secteur ne contient rien au moement de la sauvegarde. Exemple extrême mais réel avec une VM utilisée pour du test unitaire et de la génération de paquet : 1. Je récupère les sources de l'application et les données de test (500 Mo de sources pour l'appli + 3,6 Go de données). 1. Je compile dans la VM notre application, ce qui produit 14 Go de fichiers intermédiaires ou finaux en mode debug. 2. Je déroule la batterie de 2900 tests unitaires qui produisent à leur tour moult fichiers de données et de logs. 3. Comme tout passe, je lance la génération des paquets (re-compilation en mode release) et je pousse des paquets sur notre référentiel de paquets. 4. Je supprime toute l'arborescence. Si je mets de côté ce qui s'est passé entre temps au niveau système (par exemple, les écritures dans /var/log), je peux dire que j'en suis revenu au point de la veille. L'état intrinsèque de la VM n'a pas bougé. Pour autant, l'outil de sauvegarde va détecter l'équivalent de plusieurs dizaines de Go de changement dans le fichier image de la VM et va donc me produire un « diff » gigantesque. Pour cette raison, je fais tourner rdiff-backup dans les VM et sur le serveur hébergeant les VM mais pour de dernier, je lui demande d'ignorer les images de disques des VM. On peut cependant pondérer (voire ignorer) ce risque en dédoublant les sauvegardes comme tu l'indiques ! J'ai fait court mais en réalité, j'ai trois supports de sauvegarde. Mes données (photos, textes, code) valent bien plus à mes yeux que les 3 x 100 euros que peuvent coûter des disques. Juste une question : est-ce que le calcul du diff (de rdiff-backup) est moins consommateur de temps pour une sauvegarde sur disque externe (pas de réseau) qu'une duplication à la rsnapshot ? À moins que les volumes à transférer ne soient importants en regard de la bande passante disponible, rdiff-backup est bien moins efficace lorsqu'on effectue une sauvegarde sur un disque externe local que sur une machine « distante ». En effet, pour calculer le différentiel, il doit lire l'intégralité du fichier précédemment sauvegardé. Si tu utilises un disque externe, c'est l'instance locale de rdiff-backup qui se charge de cette lecture (et qui commence donc par lire le disque externe). Si tu utilises une machine tierce, rdiff-backup lance une instance sur cette seconde machine qui travaille en parallèle de la première et calcule les sommes de contrôle sur le serveur de sauvegarde pendant que ton instance locale travaille sur les fichiers de ta machine. D'ailleurs, je conseille vivement des disques externes disposant d'une interface USB3, ça vous change la vie. :) Et puisqu'on y est, une deuxième question : comment se comporte rdiff-backup sur les fichiers spare (genre machines virtuelles par exemple) ? Je ne sais pas ce que tu entends par « fichier spare » dans ce cas. je suppose qu'il voulait dire sparse file ? Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Le mercredi 17 septembre 2014, 14:21:28 Sébastien Dinot a écrit : […] J'utilise beaucoup de VM mais la volumétrie des images disque Bataille personnelle : s/volumétrie/taille/ (car, contrairement à ce que certains voudraient, « volumétrie » ne signifie pas « volume » avec plus de lettres pour faire plus intelligent mais _mesure_ ou _méthode de mesure_ du volume ou de la taille) […] Exemple extrême mais réel avec une VM utilisée pour du test unitaire et de la génération de paquet :[…] Dans ce genre de cas, tu peux utiliser les fonctions instantané/snapshot des VM : tu sais que veux retourner à une version « vierge » de ta VM, donc tu travailles sur une copie jetable de celle-ci. D’où aussi l’avantage des chroots ou des conteneurs (LXC…) qui permettent d’utiliser facilement les snapshots et copie sur écriture (COW) des FS pour les images (mutualisation d’une base commune, versionnage, tests…). […] Je ne sais pas ce que tu entends par « fichier spare » dans ce cas. Sans doute « sparse file » : fichier à trous. Tout secteur/bloc qui est à zéro n’est pas réellement alloué sur le disque. L’allocation se fait quand l’espace est utilisé. Et quand on copie un fichier à trous avec le mauvais outil ou sans la bonne option, on crée des blocs vides dans la copie et on bouffe de la place pour rien (GNU cp sait correctement copier les fichiers à trous). -- Sylvain Sauvage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/4850676.nJNGenXxDW@earendil
Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Sylvain L. Sauvage a écrit : Bataille personnelle : s/volumétrie/taille/ (car, contrairement à ce que certains voudraient, « volumétrie » ne signifie pas « volume » avec plus de lettres pour faire plus intelligent mais _mesure_ ou _méthode de mesure_ du volume ou de la taille) J'en prends note d'autant plus volontiers qu'à la réflexion, ça me paraît évident. Je me coucherai moins bête ce soir. :) Dans ce genre de cas, tu peux utiliser les fonctions instantané/snapshot des VM : tu sais que veux retourner à une version « vierge » de ta VM, donc tu travailles sur une copie jetable de celle-ci. J'utilise en effet des instantanés sur les VM que je suis en train de préparer en vue de l'intégration continue. Mais celle dont j'ai parlé dans mon précédent message est une VM de test plus générique. J'ai pris cet exemple parce qu'il est extrême mais on peut l'appliquer avec des changements de taille moindre à toutes les VM. L'expérience montre que du différentiel sur des VM qui vivent est contre-productif, j'invite tout le monde à en faire l'expérience par lui-même. Sans doute « sparse file » : fichier à trous. Dans ce cas, je ne sais pas répondre à la question. Primo, je n'ai jamais fait attention à la chose. Secundo, j'utilise des VM qui « vivent beaucoup » et ont tendance à provoquer une extension rapide de l'image disque à sa taille maximale. Même si, vu de l'intérieur, le disque n'est plein qu'à 35 %, de l'extérieur, c'est un blob binaire bien bruité qui se compresse très mal. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140917134345.ga6...@hector.home.dinot.net
Re: Quel EDI pour une application node.js ?
Adrien Poupin http://www.adrien-poupin.fr - cont...@adrien-poupin.fr Tel : 06 76 18 32 36 Le 16/09/2014 10:40, Adrien a écrit : Le 16/09/2014 23:23, Sylvain L. Sauvage a écrit : Le mardi 16 septembre 2014, 23:08:46 Adrien a écrit : […] Non, non... Je n'ai pas dû être clair : je parlais d'avoir un nuancier de couleurs, afin de pouvoir choisir directement celle-ci pendant l'édition du fichier CSS ! Ah. (Tu parlais de JS, pas de CSS…) Sinon, ça existe aussi (forcément : Emacs !) : [...] Tu as raison Sylvain, désolé ! Bon, du coup je pars sur emacs + js2-mode. Pour l'instant je n'utilise pas les nuanciers de couleur. Ce n'est pas parfait, mais déjà ça permet bien d'avancer. J'ai effectivement écrit : [...] Dans ce cas, si je choisissais emacs j'aurais besoin également de pouvoir choisir la couleur dans emacs (et tout ce genre de choses) ! Je comprends ce qui n'allait pas dans ma question, car ce qui m'intéresse n'est pas le comment faire, mais plutôt le quoi ! Avoir un nuancier, je peux effectivement me renseigner :-) Non, ce qui m'intéressait, c'étaient toutes les fonctions plus-values qu'on peut trouver dans les EDI pour le web. De mon côté, je regarde aussi les autres EDI, comme http://brackets.io/ et les fonctions qu'il comporte. Ainsi et pour en revenir plus spécifiquement à Debian, dans le cadre du développement d'une application web en node.js, quelqu'un aurait-il un retour d'expérience sur un IDE qui se trouverait dans les dépôts, comme geany par exemple, ou encore sur un EDI propriétaire installé en local ? Cela me permettra soit 1) de passer à quelque chose de plus intégré et qui me fera gagner du temps, 2) soit de me donner des idées de choses qui manqueraient à ma configuration d'emacs actuelle. Merci d'avance ! Adrien. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/5419521e.7050...@adrien-poupin.fr
