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.
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.
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.
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: |
| +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 |
======================== ==Þbian=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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
multimedia.com
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:frederic@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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/541964A1.9030106@juliana-
multimedia.com
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: |
| +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 |
======================== ==Þbian=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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
multimedia.com
rdiff-backup est quand-même packagé Wheezy. Peut-être ne l'est-il plus
sur Jessie ?
rdiff-backup est quand-même packagé Wheezy. Peut-être ne l'est-il plus
sur Jessie ?
rdiff-backup est quand-même packagé Wheezy. Peut-être ne l'est-il plus
sur Jessie ?
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.
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.
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.
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.
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.
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.
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.
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) ?
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.
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) ?
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.
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) ?
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,
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
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.dinot@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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20140917122128.GC4791@hector.home.dinot.net
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,
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
[…]
J'utilise beaucoup de VM mais la volumétrie des images disque
[…]
Exemple extrême mais réel avec une VM utilisée pour du test
unitaire et de la génération de paquet :[…]
[…]
Je ne sais pas ce que tu entends par « fichier spare » dans ce
cas.
[…]
J'utilise beaucoup de VM mais la volumétrie des images disque
[…]
Exemple extrême mais réel avec une VM utilisée pour du test
unitaire et de la génération de paquet :[…]
[…]
Je ne sais pas ce que tu entends par « fichier spare » dans ce
cas.
[…]
J'utilise beaucoup de VM mais la volumétrie des images disque
[…]
Exemple extrême mais réel avec une VM utilisée pour du test
unitaire et de la génération de paquet :[…]
[…]
Je ne sais pas ce que tu entends par « fichier spare » dans ce
cas.
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)
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.
Sans doute « sparse file » : fichier à trous.
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)
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.
Sans doute « sparse file » : fichier à trous.
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)
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.
Sans doute « sparse file » : fichier à trous.
