On Thu, 26 Jul 2007 14:06:29 +0200, Le Gaulois wrote:
heu...normalement les bandes on les fait tourner de nuit, et la durée n'a pas trops d'importance, le plus important c'est que cela tienne sur une seule bande sinon en dehors d'un robot on est boligé de manipuler donc par exemple faire une complete en debut de semaine de jour et des différentielles de nuit les reste
Oui, mais quand c'est chez soi, on n'a pas forcément une pièce dédiée comme salle machine. Si on dors près de l'ordinateur il faut les boules Quies. Et je n'ai pas non plus les moyens de me payer un robot pour manipuler les bandes.
oupps désolé je pensais que tu parlais d'une entreprise, evidément pour la maison le DVD c'est adapté !
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
On Thu, 26 Jul 2007 14:06:29 +0200, Le Gaulois <nonlu@ifrance.com>
wrote:
heu...normalement les bandes on les fait tourner de nuit, et la durée
n'a pas trops d'importance, le plus important c'est que cela tienne
sur une seule bande sinon en dehors d'un robot on est boligé de
manipuler donc par exemple faire une complete en debut de semaine de
jour et des différentielles de nuit les reste
Oui, mais quand c'est chez soi, on n'a pas forcément une pièce
dédiée comme salle machine. Si on dors près de l'ordinateur il
faut les boules Quies. Et je n'ai pas non plus les moyens de
me payer un robot pour manipuler les bandes.
oupps désolé je pensais que tu parlais d'une entreprise, evidément
pour la maison le DVD c'est adapté !
--
http://olivier.2a.free.fr/
pas de turlututu. apres l'@robase
On Thu, 26 Jul 2007 14:06:29 +0200, Le Gaulois wrote:
heu...normalement les bandes on les fait tourner de nuit, et la durée n'a pas trops d'importance, le plus important c'est que cela tienne sur une seule bande sinon en dehors d'un robot on est boligé de manipuler donc par exemple faire une complete en debut de semaine de jour et des différentielles de nuit les reste
Oui, mais quand c'est chez soi, on n'a pas forcément une pièce dédiée comme salle machine. Si on dors près de l'ordinateur il faut les boules Quies. Et je n'ai pas non plus les moyens de me payer un robot pour manipuler les bandes.
oupps désolé je pensais que tu parlais d'une entreprise, evidément pour la maison le DVD c'est adapté !
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
Eric Masson
Olivier B. writes:
'Lut,
heu...normalement les bandes on les fait tourner de nuit,
Bof, la majorité des systèmes décents ont le support des snapshots. Il suffit donc d'arrêter les applis le temps de poser un snapshot et de sauvergarder celui-ci une fois les applis relancées, et cela peut se faire à n'importe quel moment.
et la durée n'a pas trops d'importance,
Ben si quand même, il faut éviter que la durée de sauvegarde excède l'intervalle prévu entre celles-ci.
-- Si, en plus, vous cryptez les messages de la bague en PGP, et utilisez un réseau de pigeons remailers, vous pouvez garantir votre anonymat le plus total. -+- CdO in GNU : Le colombocryptophile anonyme -+-
Olivier B. <olivier.2a@turlututu.free.fr> writes:
'Lut,
heu...normalement les bandes on les fait tourner de nuit,
Bof, la majorité des systèmes décents ont le support des snapshots. Il
suffit donc d'arrêter les applis le temps de poser un snapshot et de
sauvergarder celui-ci une fois les applis relancées, et cela peut se
faire à n'importe quel moment.
et la durée n'a pas trops d'importance,
Ben si quand même, il faut éviter que la durée de sauvegarde excède
l'intervalle prévu entre celles-ci.
--
Si, en plus, vous cryptez les messages de la bague en PGP, et
utilisez un réseau de pigeons remailers, vous pouvez garantir votre
anonymat le plus total.
-+- CdO in GNU : Le colombocryptophile anonyme -+-
heu...normalement les bandes on les fait tourner de nuit,
Bof, la majorité des systèmes décents ont le support des snapshots. Il suffit donc d'arrêter les applis le temps de poser un snapshot et de sauvergarder celui-ci une fois les applis relancées, et cela peut se faire à n'importe quel moment.
et la durée n'a pas trops d'importance,
Ben si quand même, il faut éviter que la durée de sauvegarde excède l'intervalle prévu entre celles-ci.
-- Si, en plus, vous cryptez les messages de la bague en PGP, et utilisez un réseau de pigeons remailers, vous pouvez garantir votre anonymat le plus total. -+- CdO in GNU : Le colombocryptophile anonyme -+-
Olivier B.
On Thu, 26 Jul 2007 14:41:16 +0200, Eric Masson wrote:
Olivier B. writes:
'Lut,
heu...normalement les bandes on les fait tourner de nuit,
Bof, la majorité des systèmes décents ont le support des snapshots. Il suffit donc d'arrêter les applis le temps de poser un snapshot et de sauvergarder celui-ci une fois les applis relancées, et cela peut se faire à n'importe quel moment.
arrête une appli de jour pour faire un backup c'est une truc de porc, tout au plus je faisais ça *de nuit* il y a plus de 5 ans, un systeme sérieux se sauvegarde à chaud c'est du moins ce que l'on fait pour la pluspart de nos bdd, et de nuit pour plusieurs raisons: - Pour les donnés utilisateurs c'est le soir que l'on a la derniere synchro sur le serveur - c'est la nuit que l'on a le moins de chance de tomber sur une modification des fichiers partagés coté serveur - la charge serveur est assez forte lorque l'on a des techno qui debitent un peu comme du sdlt ou lto donc c'est la nuit qu'on impacte le moins les utilisateurs.
et la durée n'a pas trops d'importance,
Ben si quand même, il faut éviter que la durée de sauvegarde excède l'intervalle prévu entre celles-ci.
oui, enfin mais si c'est trops long c'est plus de nuit, forcement... -- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
On Thu, 26 Jul 2007 14:41:16 +0200, Eric Masson <emss@free.fr> wrote:
Olivier B. <olivier.2a@turlututu.free.fr> writes:
'Lut,
heu...normalement les bandes on les fait tourner de nuit,
Bof, la majorité des systèmes décents ont le support des snapshots. Il
suffit donc d'arrêter les applis le temps de poser un snapshot et de
sauvergarder celui-ci une fois les applis relancées, et cela peut se
faire à n'importe quel moment.
arrête une appli de jour pour faire un backup c'est une truc de porc,
tout au plus je faisais ça *de nuit* il y a plus de 5 ans, un systeme
sérieux se sauvegarde à chaud c'est du moins ce que l'on fait pour la
pluspart de nos bdd, et de nuit pour plusieurs raisons:
- Pour les donnés utilisateurs c'est le soir que l'on a la derniere
synchro sur le serveur
- c'est la nuit que l'on a le moins de chance de tomber sur une
modification des fichiers partagés coté serveur
- la charge serveur est assez forte lorque l'on a des techno qui
debitent un peu comme du sdlt ou lto donc c'est la nuit qu'on impacte
le moins les utilisateurs.
et la durée n'a pas trops d'importance,
Ben si quand même, il faut éviter que la durée de sauvegarde excède
l'intervalle prévu entre celles-ci.
oui, enfin mais si c'est trops long c'est plus de nuit, forcement...
--
http://olivier.2a.free.fr/
pas de turlututu. apres l'@robase
On Thu, 26 Jul 2007 14:41:16 +0200, Eric Masson wrote:
Olivier B. writes:
'Lut,
heu...normalement les bandes on les fait tourner de nuit,
Bof, la majorité des systèmes décents ont le support des snapshots. Il suffit donc d'arrêter les applis le temps de poser un snapshot et de sauvergarder celui-ci une fois les applis relancées, et cela peut se faire à n'importe quel moment.
arrête une appli de jour pour faire un backup c'est une truc de porc, tout au plus je faisais ça *de nuit* il y a plus de 5 ans, un systeme sérieux se sauvegarde à chaud c'est du moins ce que l'on fait pour la pluspart de nos bdd, et de nuit pour plusieurs raisons: - Pour les donnés utilisateurs c'est le soir que l'on a la derniere synchro sur le serveur - c'est la nuit que l'on a le moins de chance de tomber sur une modification des fichiers partagés coté serveur - la charge serveur est assez forte lorque l'on a des techno qui debitent un peu comme du sdlt ou lto donc c'est la nuit qu'on impacte le moins les utilisateurs.
et la durée n'a pas trops d'importance,
Ben si quand même, il faut éviter que la durée de sauvegarde excède l'intervalle prévu entre celles-ci.
oui, enfin mais si c'est trops long c'est plus de nuit, forcement... -- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
Eric Masson
Olivier B. writes:
'Re,
arrête une appli de jour pour faire un backup c'est une truc de porc,
Bof, une appli tu l'arrêtes lorsque ça ne gêne pas la production, et ce n'est pas forcément de nuit.
tout au plus je faisais ça *de nuit* il y a plus de 5 ans, un systeme sérieux se sauvegarde à chaud c'est du moins ce que l'on fait pour la pluspart de nos bdd,
Je n'ai jamais été vraiment convaincu par les modules de sauvegarde à chaud de sgbd, tu restes dépendant de l'éditeur de la solution de sauvegarde alors qu'une sauvegarde brutale des structures de données du sgbd te permet à coup sur de redémarrer sans avoir à se préoccuper de toute la logistique nécessaire pour que l'outil de sauvegarde retrouve ses petits.
- Pour les donnés utilisateurs c'est le soir que l'on a la derniere synchro sur le serveur - c'est la nuit que l'on a le moins de chance de tomber sur une modification des fichiers partagés coté serveur - la charge serveur est assez forte lorque l'on a des techno qui debitent un peu comme du sdlt ou lto donc c'est la nuit qu'on impacte le moins les utilisateurs.
Logiquement tu sépares les données de type bureautique et celles des instances de sgbd.
Et si vraiment la performance importe, tu passes à des outils comme les filers netapp ou équivalent, ce qui évite de charger les serveurs d'appli avec des tâches qui ne les concerne pas vraiment.
-- RM : (Lance ResEdit ou Resorcerer ...) PC : C'est fini tout ça, ils écrivent leurs trucs en binaire chinois recompilé en martien. -+- PC in Guide du Macounet Pervers : ResEdit a marche pu -+-
Olivier B. <olivier.2a@turlututu.free.fr> writes:
'Re,
arrête une appli de jour pour faire un backup c'est une truc de porc,
Bof, une appli tu l'arrêtes lorsque ça ne gêne pas la production, et ce
n'est pas forcément de nuit.
tout au plus je faisais ça *de nuit* il y a plus de 5 ans, un systeme
sérieux se sauvegarde à chaud c'est du moins ce que l'on fait pour la
pluspart de nos bdd,
Je n'ai jamais été vraiment convaincu par les modules de sauvegarde à
chaud de sgbd, tu restes dépendant de l'éditeur de la solution de
sauvegarde alors qu'une sauvegarde brutale des structures de données du
sgbd te permet à coup sur de redémarrer sans avoir à se préoccuper de
toute la logistique nécessaire pour que l'outil de sauvegarde retrouve
ses petits.
- Pour les donnés utilisateurs c'est le soir que l'on a la derniere
synchro sur le serveur
- c'est la nuit que l'on a le moins de chance de tomber sur une
modification des fichiers partagés coté serveur
- la charge serveur est assez forte lorque l'on a des techno qui
debitent un peu comme du sdlt ou lto donc c'est la nuit qu'on impacte
le moins les utilisateurs.
Logiquement tu sépares les données de type bureautique et celles des
instances de sgbd.
Et si vraiment la performance importe, tu passes à des outils comme les
filers netapp ou équivalent, ce qui évite de charger les serveurs
d'appli avec des tâches qui ne les concerne pas vraiment.
--
RM : (Lance ResEdit ou Resorcerer ...)
PC : C'est fini tout ça, ils écrivent leurs trucs en binaire chinois
recompilé en martien.
-+- PC in Guide du Macounet Pervers : ResEdit a marche pu -+-
arrête une appli de jour pour faire un backup c'est une truc de porc,
Bof, une appli tu l'arrêtes lorsque ça ne gêne pas la production, et ce n'est pas forcément de nuit.
tout au plus je faisais ça *de nuit* il y a plus de 5 ans, un systeme sérieux se sauvegarde à chaud c'est du moins ce que l'on fait pour la pluspart de nos bdd,
Je n'ai jamais été vraiment convaincu par les modules de sauvegarde à chaud de sgbd, tu restes dépendant de l'éditeur de la solution de sauvegarde alors qu'une sauvegarde brutale des structures de données du sgbd te permet à coup sur de redémarrer sans avoir à se préoccuper de toute la logistique nécessaire pour que l'outil de sauvegarde retrouve ses petits.
- Pour les donnés utilisateurs c'est le soir que l'on a la derniere synchro sur le serveur - c'est la nuit que l'on a le moins de chance de tomber sur une modification des fichiers partagés coté serveur - la charge serveur est assez forte lorque l'on a des techno qui debitent un peu comme du sdlt ou lto donc c'est la nuit qu'on impacte le moins les utilisateurs.
Logiquement tu sépares les données de type bureautique et celles des instances de sgbd.
Et si vraiment la performance importe, tu passes à des outils comme les filers netapp ou équivalent, ce qui évite de charger les serveurs d'appli avec des tâches qui ne les concerne pas vraiment.
-- RM : (Lance ResEdit ou Resorcerer ...) PC : C'est fini tout ça, ils écrivent leurs trucs en binaire chinois recompilé en martien. -+- PC in Guide du Macounet Pervers : ResEdit a marche pu -+-
Olivier B.
On Thu, 26 Jul 2007 18:22:53 +0200, Eric Masson wrote:
Je n'ai jamais été vraiment convaincu par les modules de sauvegarde à chaud de sgbd, tu restes dépendant de l'éditeur de la solution de sauvegarde alors qu'une sauvegarde brutale des structures de données du sgbd te permet à coup sur de redémarrer sans avoir à se préoccuper de toute la logistique nécessaire pour que l'outil de sauvegarde retrouve ses petits.
c'est vrai, en fait nous faison des sauvegardes à chaud en semaine et une fois par mois une a froid, ainsi en cas de crash on peut rapidement remonter le serveur avec celle à froid et mettre à jour avec celle à chaud ce qui évite pas mal de tracas
Logiquement tu sépares les données de type bureautique et celles des instances de sgbd.
oui concernant le stockage, pas forcement concernant l'archiveage, un robot de sauvegarde peut ete partagé avec plusieurs serveurs
Et si vraiment la performance importe, tu passes à des outils comme les filers netapp ou équivalent, ce qui évite de charger les serveurs d'appli avec des tâches qui ne les concerne pas vraiment.
certe
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
On Thu, 26 Jul 2007 18:22:53 +0200, Eric Masson <emss@free.fr> wrote:
Je n'ai jamais été vraiment convaincu par les modules de sauvegarde à
chaud de sgbd, tu restes dépendant de l'éditeur de la solution de
sauvegarde alors qu'une sauvegarde brutale des structures de données du
sgbd te permet à coup sur de redémarrer sans avoir à se préoccuper de
toute la logistique nécessaire pour que l'outil de sauvegarde retrouve
ses petits.
c'est vrai, en fait nous faison des sauvegardes à chaud en semaine et
une fois par mois une a froid, ainsi en cas de crash on peut
rapidement remonter le serveur avec celle à froid et mettre à jour
avec celle à chaud ce qui évite pas mal de tracas
Logiquement tu sépares les données de type bureautique et celles des
instances de sgbd.
oui concernant le stockage, pas forcement concernant l'archiveage, un
robot de sauvegarde peut ete partagé avec plusieurs serveurs
Et si vraiment la performance importe, tu passes à des outils comme les
filers netapp ou équivalent, ce qui évite de charger les serveurs
d'appli avec des tâches qui ne les concerne pas vraiment.
certe
--
http://olivier.2a.free.fr/
pas de turlututu. apres l'@robase
On Thu, 26 Jul 2007 18:22:53 +0200, Eric Masson wrote:
Je n'ai jamais été vraiment convaincu par les modules de sauvegarde à chaud de sgbd, tu restes dépendant de l'éditeur de la solution de sauvegarde alors qu'une sauvegarde brutale des structures de données du sgbd te permet à coup sur de redémarrer sans avoir à se préoccuper de toute la logistique nécessaire pour que l'outil de sauvegarde retrouve ses petits.
c'est vrai, en fait nous faison des sauvegardes à chaud en semaine et une fois par mois une a froid, ainsi en cas de crash on peut rapidement remonter le serveur avec celle à froid et mettre à jour avec celle à chaud ce qui évite pas mal de tracas
Logiquement tu sépares les données de type bureautique et celles des instances de sgbd.
oui concernant le stockage, pas forcement concernant l'archiveage, un robot de sauvegarde peut ete partagé avec plusieurs serveurs
Et si vraiment la performance importe, tu passes à des outils comme les filers netapp ou équivalent, ce qui évite de charger les serveurs d'appli avec des tâches qui ne les concerne pas vraiment.
certe
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
Nicolas S.
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers d'euros. C'est à la portée d'une petite entreprise.
Le problème est toujours de comparer la valeurs des données au coût de la solution de sauvegarde.
Qui est souvent un calcul vite fait, étant donné le coût d'une personne/jour.
-- Nicolas S.
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers
d'euros. C'est à la portée d'une petite entreprise.
Le problème est toujours de comparer la valeurs des données au coût de
la solution de sauvegarde.
Qui est souvent un calcul vite fait, étant donné le coût d'une
personne/jour.
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers d'euros. C'est à la portée d'une petite entreprise.
Le problème est toujours de comparer la valeurs des données au coût de la solution de sauvegarde.
Qui est souvent un calcul vite fait, étant donné le coût d'une personne/jour.
-- Nicolas S.
Le Gaulois
Le LTO et le SDLT c'est sûrement très bien, mais je n'ose même pas pas regarder le tarif.
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers d'euros. C'est à la portée d'une petite entreprise.
Oui, mais il n'y a pas que les petites entreprises, il y a aussi les particuliers et les micro entreprises. Certaines personnes qui travaillent à leur comtpe ont des revenus dérisoires.
Je viens de faire une recherche : de 1500 à 3500 TTC je m'attendais à pire. Un SLR140 c'est dans les 1400 c'est le même ordre de grandeur.
Le problème est toujours de comparer la valeurs des données au coût de la solution de sauvegarde.
Oui, mais pour ceux qui ont un petit budget, le prix de l'appareil peut être de toute façon rédhibitoire. Il faut trouver une solution de sauvegarde suffisamment fiable, suffisamment commode et d'un prix pas trop délirant.
Le LTO et le SDLT c'est sûrement très bien, mais je n'ose même pas
pas regarder le tarif.
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers
d'euros. C'est à la portée d'une petite entreprise.
Oui, mais il n'y a pas que les petites entreprises, il y a aussi les
particuliers et les micro entreprises. Certaines personnes qui
travaillent à leur comtpe ont des revenus dérisoires.
Je viens de faire une recherche : de 1500 à 3500 TTC
je m'attendais à pire. Un SLR140 c'est dans les 1400 c'est le même
ordre de grandeur.
Le problème est toujours de comparer la valeurs des données au coût de
la solution de sauvegarde.
Oui, mais pour ceux qui ont un petit budget, le prix de l'appareil
peut être de toute façon rédhibitoire. Il faut trouver une solution
de sauvegarde suffisamment fiable, suffisamment commode et d'un prix
pas trop délirant.
Le LTO et le SDLT c'est sûrement très bien, mais je n'ose même pas pas regarder le tarif.
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers d'euros. C'est à la portée d'une petite entreprise.
Oui, mais il n'y a pas que les petites entreprises, il y a aussi les particuliers et les micro entreprises. Certaines personnes qui travaillent à leur comtpe ont des revenus dérisoires.
Je viens de faire une recherche : de 1500 à 3500 TTC je m'attendais à pire. Un SLR140 c'est dans les 1400 c'est le même ordre de grandeur.
Le problème est toujours de comparer la valeurs des données au coût de la solution de sauvegarde.
Oui, mais pour ceux qui ont un petit budget, le prix de l'appareil peut être de toute façon rédhibitoire. Il faut trouver une solution de sauvegarde suffisamment fiable, suffisamment commode et d'un prix pas trop délirant.
Nicolas S.
AMHA, tu fais bien trop l'impasse sur la durée de vie espérée des données et des support. Pour l'archivage en entreprises, beaucoup passent par la microfiche et le microfilm.
s/donnes/donnees/g
-- Nicolas S.
AMHA, tu fais bien trop l'impasse sur la durée de vie espérée des
données et des support.
Pour l'archivage en entreprises, beaucoup passent par la microfiche et
le microfilm.
AMHA, tu fais bien trop l'impasse sur la durée de vie espérée des données et des support. Pour l'archivage en entreprises, beaucoup passent par la microfiche et le microfilm.
s/donnes/donnees/g
-- Nicolas S.
JKB
Le 27-07-2007, à propos de Re: perenisation des donnes, Le Gaulois écrivait dans fr.comp.stockage :
Le LTO et le SDLT c'est sûrement très bien, mais je n'ose même pas pas regarder le tarif.
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers d'euros. C'est à la portée d'une petite entreprise.
Oui, mais il n'y a pas que les petites entreprises, il y a aussi les particuliers et les micro entreprises. Certaines personnes qui travaillent à leur comtpe ont des revenus dérisoires.
Je viens de faire une recherche : de 1500 à 3500 TTC je m'attendais à pire. Un SLR140 c'est dans les 1400 c'est le même ordre de grandeur.
Reste simplement à chiffrer le prix de ses données. Personnellement, j'ai investi dans un autoloader parce que mes données le valent.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 27-07-2007, à propos de
Re: perenisation des donnes,
Le Gaulois écrivait dans fr.comp.stockage :
Le LTO et le SDLT c'est sûrement très bien, mais je n'ose même pas
pas regarder le tarif.
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers
d'euros. C'est à la portée d'une petite entreprise.
Oui, mais il n'y a pas que les petites entreprises, il y a aussi les
particuliers et les micro entreprises. Certaines personnes qui
travaillent à leur comtpe ont des revenus dérisoires.
Je viens de faire une recherche : de 1500 à 3500 TTC
je m'attendais à pire. Un SLR140 c'est dans les 1400 c'est le même
ordre de grandeur.
Reste simplement à chiffrer le prix de ses données. Personnellement,
j'ai investi dans un autoloader parce que mes données le valent.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 27-07-2007, à propos de Re: perenisation des donnes, Le Gaulois écrivait dans fr.comp.stockage :
Le LTO et le SDLT c'est sûrement très bien, mais je n'ose même pas pas regarder le tarif.
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers d'euros. C'est à la portée d'une petite entreprise.
Oui, mais il n'y a pas que les petites entreprises, il y a aussi les particuliers et les micro entreprises. Certaines personnes qui travaillent à leur comtpe ont des revenus dérisoires.
Je viens de faire une recherche : de 1500 à 3500 TTC je m'attendais à pire. Un SLR140 c'est dans les 1400 c'est le même ordre de grandeur.
Reste simplement à chiffrer le prix de ses données. Personnellement, j'ai investi dans un autoloader parce que mes données le valent.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Olivier B.
On Sat, 28 Jul 2007 01:12:42 +0200, "Nicolas S." wrote:
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers d'euros. C'est à la portée d'une petite entreprise.
Le problème est toujours de comparer la valeurs des données au coût de la solution de sauvegarde.
Qui est souvent un calcul vite fait, étant donné le coût d'une personne/jour.
si tu paye une personne par jour pour la sauvegarde c'est que ton managment est sérieusement à revoir, en régime établi c'est une tache qui prend entre 1/4 d'heure et 1/2 heure/jour pour: - chercher/ranger les bandes dans une armoire - manipuler les bandes dans les lecteurs - verifier les logs
Elle peut prendre plus de temps lors: - de l'étude&integration d'une nouvelle solution - d'un probleme à gérer (sav/mode degradé)
C'est donc clairement une tache parmis d'autres que l'on affecte à un service/groupe de personne/personne en fonction de la taille de la boite, et encore avec certaines solution c'est une manipulation par semaine quand le service n'est pas externalisé...
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers
d'euros. C'est à la portée d'une petite entreprise.
Le problème est toujours de comparer la valeurs des données au coût de
la solution de sauvegarde.
Qui est souvent un calcul vite fait, étant donné le coût d'une
personne/jour.
si tu paye une personne par jour pour la sauvegarde c'est que ton
managment est sérieusement à revoir, en régime établi c'est une tache
qui prend entre 1/4 d'heure et 1/2 heure/jour pour:
- chercher/ranger les bandes dans une armoire
- manipuler les bandes dans les lecteurs
- verifier les logs
Elle peut prendre plus de temps lors:
- de l'étude&integration d'une nouvelle solution
- d'un probleme à gérer (sav/mode degradé)
C'est donc clairement une tache parmis d'autres que l'on affecte à un
service/groupe de personne/personne en fonction de la taille de la
boite, et encore avec certaines solution c'est une manipulation par
semaine quand le service n'est pas externalisé...
--
http://olivier.2a.free.fr/
pas de turlututu. apres l'@robase
On Sat, 28 Jul 2007 01:12:42 +0200, "Nicolas S." wrote:
Ce n'est pas si effrayant que ça. Ca se compte en peu de milliers d'euros. C'est à la portée d'une petite entreprise.
Le problème est toujours de comparer la valeurs des données au coût de la solution de sauvegarde.
Qui est souvent un calcul vite fait, étant donné le coût d'une personne/jour.
si tu paye une personne par jour pour la sauvegarde c'est que ton managment est sérieusement à revoir, en régime établi c'est une tache qui prend entre 1/4 d'heure et 1/2 heure/jour pour: - chercher/ranger les bandes dans une armoire - manipuler les bandes dans les lecteurs - verifier les logs
Elle peut prendre plus de temps lors: - de l'étude&integration d'une nouvelle solution - d'un probleme à gérer (sav/mode degradé)
C'est donc clairement une tache parmis d'autres que l'on affecte à un service/groupe de personne/personne en fonction de la taille de la boite, et encore avec certaines solution c'est une manipulation par semaine quand le service n'est pas externalisé...
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
