étude stockage réseau

Bonjour tous,

Voilà en ce moment je fais un stage et je fais une étude pour mettre en
place une solution de sauvegarde. J'ai fait un certain nombre de
recherches et testé quelques solutions. Mais maintenant je suis en panne
d'idées. Loin de moi l'envie que vous fassiez mon stage à ma place ;
mais j'aimerai vous soumettre les quelques résultats que j'ai déjà, afin
que vous puissiez les commenter et peut-être me conseiller sur d'autres
solutions/architectures de sauvegarde.

L'objectif de la solution à mettre en oeuvre est de pouvoir sauvegarder
les postes de travail de chercheurs (principalement des Windows), chacun
étant responsable de sa machine. Tous ont des souhaits divers et variés,
mais les principaux qui ressortent sont :
- gérer soi même les sauvegardes ;
- automatiser les sauvegardes ;
- sécurité.

J'ai un peu le même problème du fait que j'ai des stations dédiées à
diverses applications et dont les besoins ne se ressemblent pas.

Je pense qu'il faut diviser pour régner :
- sur chaque station, installer une solution de "filtrage & rassemblement"
des données à sauvegarder, dont la politique sera adaptée à son utilisateur,
- préparer ainsi localement des lots à sauvegarder qui soient modulaires et
dotés d'un étiquetage de type "ID station + ID contenu + Date", ceci selon
les critères et le timing de l'utilisateur,
- faire la sauvegarde distante de ces lots selon un principe classique
"annule et remplace" pour chaque paire d'ID, avec conservation d'un certain
nombre de générations (genre T à T-2 + conservation d'un tout mensuel), ceci
durant les heures creuses de l'utilisateur.

Localement, il existe des solutions (y compris gratuites, comme UltraBackup
pour Windows) qui savent faire de l'extraction différentielle au niveau du
répertoire et avec des critères de noms de fichiers. Ca peut vous permettre
de coller au besoin de chaque utilisateur (en plus d'une politique commune
pour les paramètres communs), et de préparer donc les lots dans un
répertoire local.

Et donc ensuite vous gérez séparément la collecte sur un serveur. Pour ce
qui est du stockage, tout dépend du volume que représente un tel lot
différentiel, mais il me semble que **si vous prévoyez dès le départ de
petits lots modulaires plutôt que la sauvegarde d'un disque entier**, vu son
prix, sa stabilité et sa compacité, le CD-R constitue aujourd'hui une
solution intéressante : plus de recyclage, vous détruisez seulement les plus
vieux.

Pour ma part je vais probablement procéder ainsi lorsque je vais automatiser
la chose.

NB: tout dépend de l'esprit dans lequel vous faites ça :
- cherchez-vous une solution simple et économique pour un groupe de travail
de taille petite à moyenne,
- ou est-ce une étude notée ...
... portant sur une solution standard et normalisée, applicable à une grande
entreprise,
... et à l'épreuve d'utilisateurs irresponsables qui vous font archiver
leurs brouillons et vidéos de Q personnelles (sisi, j'en ai vu et là bien
sûr il faut des moyens dimensionnés en conséquence pour que ça passe dans le
week-end) ?

Hope it Helps,
Cordialement

--

/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

[...]
Et donc ensuite vous gérez séparément la collecte sur un serveur. Pour
ce

qui est du stockage, tout dépend du volume que représente un tel lot
différentiel, mais il me semble que **si vous prévoyez dès le départ de
petits lots modulaires plutôt que la sauvegarde d'un disque entier**, vu
son

prix, sa stabilité et sa compacité, le CD-R constitue aujourd'hui une
solution intéressante : plus de recyclage, vous détruisez seulement les
plus

vieux.

Certains utilisateurs font déjà des sauvegardes sur CD/DVD, mais ça
reste un peu contraignant (il faut penser à lancer régulièrement une
gravure, c'est long, capacité limitée, etc). L'objectif de la solution
de sauvegarde à définir n'est pas de remplacer l'existant, mais plus
d'apporter un complément, une souplesse d'utilisation. (l'automatisation
par exemple)
Je n'ai pas encore sérieusement évaluer le volume à sauvegarder. Mais
sachant que j'ai à faire à des chercheurs, ils ont essentiellement à
sauvegarder des études/thêses, des résultats d'expériences (pour
certains, en images assez lourdes) et surtout leurs mails. Ca me laisse
penser qu'il y a plusieurs Go par poste.

Bonjour.

"Hervé" <guillaumeherv@iut-dijon.u-bourgogne.fr> a écrit dans le message de
news: d59v3d$h9l$1@demo2.univ-lyon1.fr...

[...]
Et donc ensuite vous gérez séparément la collecte sur un serveur. Pour

ce

qui est du stockage, tout dépend du volume que représente un tel lot
différentiel, mais il me semble que **si vous prévoyez dès le départ de
petits lots modulaires plutôt que la sauvegarde d'un disque entier**, vu

son

prix, sa stabilité et sa compacité, le CD-R constitue aujourd'hui une
solution intéressante : plus de recyclage, vous détruisez seulement les

plus

vieux.

Certains utilisateurs font déjà des sauvegardes sur CD/DVD, mais ça
reste un peu contraignant (il faut penser à lancer régulièrement une
gravure, c'est long, capacité limitée, etc). L'objectif de la solution
de sauvegarde à définir n'est pas de remplacer l'existant, mais plus
d'apporter un complément, une souplesse d'utilisation. (l'automatisation
par exemple)
Je n'ai pas encore sérieusement évaluer le volume à sauvegarder. Mais
sachant que j'ai à faire à des chercheurs, ils ont essentiellement à
sauvegarder des études/thêses, des résultats d'expériences (pour
certains, en images assez lourdes) et surtout leurs mails. Ca me laisse
penser qu'il y a plusieurs Go par poste.

Le piège à éviter selon moi, c'est justement de raisonner en volume global
par poste (sauvez tout mon disque). Il faut envisager ça par projet (ou
autre division), donc par répertoire. Si les chercheurs produisaient des Go
de données nouvelles toutes les semaines, notre économie se porterait bien
mieux :-)

UltraBackup (par exemple) permet d'isoler des sections de données sur un
même poste, et aussi de faire de la sauvegarde incrémentale. On ne sauve
donc que ce qui a changé, et de plus par lots identifiés. Et ça ça peut
facilement tenir sur des CD de 800Mo (et même si exceptionnellement ce n'est
pas le cas, il y a aussi des options de découpage pour répartir un lot sur
plusieurs CD).

La définition d'un lot implique une certaine collaboration de l'intéressé
(ensuite le calcul des évolutions à l'intérieur est automatique), et c'est
en ça qu'une politique local à chaque plate-forme est intéressante.

Ensuite vous allez donc aboutir à une série de lots, préparés comme des
fichiers archives dans un répertoire du serveur, et à pousser sur des CD :
une gravure de nos jours prend quelques minutes, il y a juste une corvée
consistant à fourrer des CD dans le graveur durant la session d'archivage si
le nombre ne justifie pas un robot (à écrire en ces termes dans la thèse =>
solution efficace et évolutive).
La tâche la plus complexe là-dedans est la définition de la norme de
numérotation des lots et des CD.

D'ailleurs on a souvent tort de raisonner uniquement en termes d'archivage.
Il faut que la restauration d'un état viable en cas de crash d'une station
soit tout aussi efficace, et donc la solution consistant à archiver des
disques entiers ne tient pas vraiment debout : il faudrait ensuite restaurer
les index, raccourcis, et autres. Donc il faut sauvegarder intelligent.

Cordialement,

--

/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Bonjour,

si j'ai bien compris, vous cherchez à centraliser une sauvegarde de
postes clients Windows sur des serveurs, tout en laissant la liberté aux
utilisateurs de pouvoir sauvegarder ou non certains fichiers ou
répertoires.

Dans ce cas, vous avez interet à regarder de près des solutions
professionnelles comme Arcserve, Backup exe ou Retrospect.

Ce dernier a un immense interet, c'est justement de sauvegarder les
postes clients.

Il est téléchargeable sur le site de Dantz.

Cordialement.

Klod

Bonjour.

"Hervé" <guillaumeherv@iut-dijon.u-bourgogne.fr> a écrit dans le
message de
news: d59v3d$h9l$1@demo2.univ-lyon1.fr...

[...]
Et donc ensuite vous gérez séparément la collecte sur un serveur. Pour

ce

qui est du stockage, tout dépend du volume que représente un tel lot
différentiel, mais il me semble que **si vous prévoyez dès le départ de
petits lots modulaires plutôt que la sauvegarde d'un disque
entier**, vu

son

prix, sa stabilité et sa compacité, le CD-R constitue aujourd'hui une
solution intéressante : plus de recyclage, vous détruisez seulement les

plus

vieux.

Certains utilisateurs font déjà des sauvegardes sur CD/DVD, mais ça
reste un peu contraignant (il faut penser à lancer régulièrement une
gravure, c'est long, capacité limitée, etc). L'objectif de la solution
de sauvegarde à définir n'est pas de remplacer l'existant, mais plus
d'apporter un complément, une souplesse d'utilisation. (l'automatisation
par exemple)
Je n'ai pas encore sérieusement évaluer le volume à sauvegarder. Mais
sachant que j'ai à faire à des chercheurs, ils ont essentiellement à
sauvegarder des études/thêses, des résultats d'expériences (pour
certains, en images assez lourdes) et surtout leurs mails. Ca me laisse
penser qu'il y a plusieurs Go par poste.

Le piège à éviter selon moi, c'est justement de raisonner en volume
global
par poste (sauvez tout mon disque). Il faut envisager ça par projet (ou
autre division), donc par répertoire. Si les chercheurs produisaient
des Go
de données nouvelles toutes les semaines, notre économie se porterait
bien
mieux :-)

UltraBackup (par exemple) permet d'isoler des sections de données sur un
même poste, et aussi de faire de la sauvegarde incrémentale. On ne sauve
donc que ce qui a changé, et de plus par lots identifiés. Et ça ça peut
facilement tenir sur des CD de 800Mo (et même si exceptionnellement ce
n'est
pas le cas, il y a aussi des options de découpage pour répartir un lot
sur
plusieurs CD).

La définition d'un lot implique une certaine collaboration de l'intéressé
(ensuite le calcul des évolutions à l'intérieur est automatique), et
c'est
en ça qu'une politique local à chaque plate-forme est intéressante.

Ensuite vous allez donc aboutir à une série de lots, préparés comme des
fichiers archives dans un répertoire du serveur, et à pousser sur des
CD :
une gravure de nos jours prend quelques minutes, il y a juste une corvée
consistant à fourrer des CD dans le graveur durant la session
d'archivage si
le nombre ne justifie pas un robot (à écrire en ces termes dans la
thèse =>
solution efficace et évolutive).
La tâche la plus complexe là-dedans est la définition de la norme de
numérotation des lots et des CD.

D'ailleurs on a souvent tort de raisonner uniquement en termes
d'archivage.
Il faut que la restauration d'un état viable en cas de crash d'une
station
soit tout aussi efficace, et donc la solution consistant à archiver des
disques entiers ne tient pas vraiment debout : il faudrait ensuite
restaurer
les index, raccourcis, et autres. Donc il faut sauvegarder intelligent.

Cordialement,

--

/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

J'aimerai savoir si il existe
une solution pour pouvoir exploiter cet espace libre à disposition ? Y
a-t-il une façon d'aggréger l'ensemble en un gros DD réseau (faire un
RAID5 réseau) ? J'avais déjà trouvé ces solutions approchantes mais qui
non satisfaisantes :

Hervé wrote:

J'aimerai savoir si il existe une solution pour pouvoir exploiter cet
espace libre à disposition ? Y a-t-il une façon d'aggréger l'ensemble
en un gros DD réseau (faire un RAID5 réseau) ? J'avais déjà trouvé ces
solutions approchantes mais qui non satisfaisantes :

Ne prends tu pas le probleme a l'envers? Au lieu d'affecter de l'espace
à tes serveurs et essayer de le récuperer ensuite, pourquoi ne pas
allouer *a la demande* à partir d'un pool de stockage banalisé? Il
existe des solutions de virtualisation comme SANmelody de DataCore
Software qui font ça assez bien, y compris sur des reseaux IP (iSCSI).

Je n'ai pas compris ce que tu voulais dire : "pourquoi ne pas allouer *a
la demande* à partir d'un pool de stockage banalisé".

Mais par contre iSCSI me semble intéressant, appramment on peut faire du
partage sur le réseau de partition type RAW, je vais creuser de ce côté là.
Merci

Hervé wrote:

Je n'ai pas compris ce que tu voulais dire : "pourquoi ne pas allouer *a
la demande* à partir d'un pool de stockage banalisé".

L'idée de base de la virtualisation est de disposer d'une zone de
stockage (pool) à partir duquel des LUNs sont créées et allouées à la
demande aux serveurs qui en ont besoin. L'allocation peut même être
faite dynamiquement (j'alloue un disque de 2Go mais seule une petite
partie est effectivement allouée). Quand une LUN n'est plus nécessaire,
l'espace qui était alloué est retourné au pool de stockage. Voir
DataCoresoftware.com ou falconstore.com pour certaines de ces solutions.

Mais par contre iSCSI me semble intéressant, appramment on peut faire du
partage sur le réseau de partition type RAW, je vais creuser de ce côté
là.

Merci

Les solutions de virtualisation utilisaient principalement FC mais
depuis peu supportent aussi iSCSI, pour des perfs un peu moindre mais un
cout assez significativement plus faible.

Hervé wrote:

Je n'ai pas compris ce que tu voulais dire : "pourquoi ne pas allouer
*a la demande* à partir d'un pool de stockage banalisé".

L'idée de base de la virtualisation est de disposer d'une zone de
stockage (pool) à partir duquel des LUNs sont créées et allouées à la
demande aux serveurs qui en ont besoin. L'allocation peut même être
faite dynamiquement (j'alloue un disque de 2Go mais seule une petite
partie est effectivement allouée). Quand une LUN n'est plus nécessaire,
l'espace qui était alloué est retourné au pool de stockage. Voir
DataCoresoftware.com ou falconstore.com pour certaines de ces solutions.

Mais par contre iSCSI me semble intéressant, appramment on peut faire
du partage sur le réseau de partition type RAW, je vais creuser de ce
côté là.
Merci

Les solutions de virtualisation utilisaient principalement FC mais
depuis peu supportent aussi iSCSI, pour des perfs un peu moindre mais un
cout assez significativement plus faible.