Bonjour à tous
(et bonne année, on est encore dans les temps)
 
Notre robotique de sauvegarde arrive bientôt en fin de vie et je cherche à savoir comment bien dimensionner/choisir la remplaçante
Mon interrogation porte principalement sur la technologie, le nombre de lecteurs et le nombre de slots.
 
Connaissez vous des calculateurs pour essayer de déterminer la meilleure solution. je vais essayer de faire un bête excel, mais j'ai peur d'oublier des paramètres ou de ne pas savoir déterminer correctement certains autres (genre le taux de compression)
 
Actuellement, nous tournons avec 2 lecteurs LTO4 et 58 slots, cependant avec près de 20To à sauvegarder à la source chaque semaine, nous explosons les délais et avec une croissance de presque 50% l'année dernière ça risque d'empirer.
 
Merci d'avance

bah difficile de le dire comme ça, ça dépend de trop de choses : de ta façon de sauvegarder (sauvegarde directe sur bandes ? pool disques ?), de tes contraintes (externalisation des bandes ? manipulation des bandes quotidienne ? hebdo ?), de tes données (bases de données ? boîtes emails ?), de l'évolution de tes données (+30% tous les 18 mois ? 24 mois ?), etc.
 
ca se trouve juste changer le robot n'est pas pertinent

Pour répondre à tes questions :  
Sauvegarde sur disque puis clone sur bande
1 full hebdomadaire conservée 15 jours, ou 1 ans si dernière du mois, ou 2 ans si dernière de l'année.
 
actuellement seules les bandes mensuelles et annuelles sont externalisées, à termes toutes les bandes le seront.
 
manipulations quasiment quotidienne en fonction des besoins de restaurations.  
 
types de données : on a de tout: system, file share, bases, mails, AD, mais tout est sauvegardé en mode fichier. les incrémentales quotidiennes montre un taux quotidien de changement de 10%.
 
je me doute que seulement changer le robot ne sera pas forcément pertinent, mais en l'occurrence, le changement de la robotique est un passage obligatoire (fin de support...) et on souhaite en profiter pour revenir dans les clous sur la durée de copie vers les bandes où on est très limite en temps.
 
là en l'occurrence, je suis plus sur un choix théorique. J'ai commencé le fichier suivant, mais je dois avoir oublié quelque chose car actuellement ma copie sur bande prend 4 jours avec compression et environ 22 bandes
 
http://dl.free.fr/hWlNupCh3

ok donc quand tu parles de 20To, c'est uniquement la taille de la FULL, il n'y a donc pas de copie des INC sur bandes
 
si tu as autant de manipulations de bandes à cause des restaurations, peut-être penser à augmenter la durée de rétention de la sauvegarde sur disque. Quelle est ta solution de sauvegarde actuelle ? La taille de tes disques pour la sauvegarde ?
 
Sinon 4 jours pour une copie de 20To, en étant vraiment pessimiste ca fait 20To copié en 90 heures soit 222Go/h sur 2 lecteurs, soit ~30Mo/s par lecteur : tu as vraisemblablement un problème pour alimenter suffisamment vite tes lecteurs en données.
Il vaut mieux que tu identifies et résoud ce problème parce que si ce n'est pas les lecteurs qui sont en tort, si tu passes à une autre techno que du LTO4 tu risques de flinguer tes lecteurs avec le phénomène du "shoe shining" (stop/start des lecteurs qui, à terme l'use et le détériore). En LTO5, c'est minimum 40Mo/s
 
Du coup regarde :
- si c'est pas tes lecteurs ou la connectique qui déconnent : si tu as des HP Ultrium tu peux utiliser HPTapePerf pour tester la vitesse de tes lecteurs (attention à utiliser avec une bande vide de données utiles)
- si ce ne sont pas tes disques qui ne sont pas à l'agonie ou trop sollicité pour réussir à faire plus que 30Mo/s
 
Sur le dernier point, en replanifiant correctement les jobs de sauvegardes et de copie, ca peut aider. Ensuite ca peut devenir plus complexe suivant ton infra et la solution de backup (réhydradation de données dédupliquées, mauvais dimensionnement de serveur, disques trop lents, version de soft de backup boggué...)

Malheureusement pour la rétention sur disque, ce n'est pas évident, on est 2-3mois entre les fulls et les incrémentals, et on a beaucoup de demandes aux alentours d'un an...
 
pour les limites de performance, je suis dessus aussi...
j'ai déjà tenté de faire du monitoring sur les serveurs de sauvegarde, après, les baies MD3200i de Dell ne sont pas super pour le monitoring à ce niveau, mais je n'ai rien vu pour le moment qui semble indiquer une limitation à ce niveau...
 
je vais essayer de voir pour les perf des lecteurs...
pour la version du soft, on est en simpana v9 et on ne nous à pas remonter de bug particulier là dessus. Mais on a en effet une réhydratation des données avant mise du bande.
 
Merci tout de même...
Sinon, d'un point de vu théorique, les calculs de mon fichier sont justes ? où y a-t-il d'autres facteurs que je pourrais inclure ?

J'ai eu de gros ennuis de perf lors de la réhydratation de données avec simpana v8 et le passage en v9 est beaucoup mieux
Par contre il faut créer des machines séparées entre le CommServe et le(s) MediaAgent qui réhydrate, sinon gros problèmes de lenteurs lors de la réhydratation même si la machine n'est pas à genoux
Essaies de faire une storage policy de test sans dédup, et de lancer une AuxCopy sur bandes histoire de voir si ce n'est pas la réhydratation qui a un soucis
 
As-tu de bons taux de transfert entre ta baie et ton MediaAgent ? Parce que si ta baie n'est pas dédiée et qu'il y a un fort traffic, cela peut jouer
Quel type de disques as-tu ? SATA ou SAS ?
 
Ton fichier est juste d'un point de vue théorique, mais en pratique c'est trop optimiste tu n'auras jamais un taux de compression de 2, car cela dépend de tes données. De plus avec Simpana si tu veux bénéficier de la compression hardware du LTO, il faut désactiver la compression software dans ta storage policy. Regarde le taux chez toi, c'est un peu empirique mais ca te donnera une meilleure idée de la compression possible avec tes données
 
Côté robotique, j'ai essentiellement travaillé avec de l'overland, c'est un bon rapport qualité/prix. Si tu pars sur un NEO2000e tu risques d'être un peu court niveau nombre de slots (de mémoire 30 slots) à moins de changer toutes tes cartouches en LTO5. L'intérêt d'un LTO5 c'est que tu pourras écrire sur tes bandes LTO4, surtout si il t'en restes beaucoup de valide (attention quand même à l'usure, regarde les stats d'écriture dans Simpana)
Sinon si t'avais l'intention de racheter des bandes, pars sur du LTO6
 
Un NEO4000e te permettra d'avoir plus de slots et jusqu'à 4 lecteurs, mais ce ne sera pas forcément utile en LTO5  ou LTO6, mais tu auras toujours une période de cohabitation où il faudra charger des bandes en LTO4 pour tes restaurations

le commServ est une VM dédiée et j'ai 2 média agents physiques chargées de la sauvegarde et de la mise sur bande
je dois essayé de faire un le test sur la compression, parce qu'on a aussi un souci de bandes (depuis la v9, aucune bande n'atteint les 800Go d'utiliser, on tourne entre 500 et 600Go en moyenne)
 
pour la baie pour le stockage des sauvegarde, elle est dédiée aux 2 MA. Je ne pense pas avoir de souci de transfert. Je crois que les disques sont en SAS de mémoire.
 
Pour info, on a actuellement un NEO4000e... Là je pensais partir sur un intermediare : 80 slots, 4 lecteurs LTO5 pour être tranquille sur l'évolutions à venir.

Il faut désactiver la compression logicielle dans la storage policy, sinon tu ne pourras pas utiliser la compression hardware de tes LTO. La compression logicielle n'est vraiment pas utile quand tu as activé de la déduplication. Si tu le désactives tu ne verras pas de gain sur tes bandes avant la prochaine FULL
Il faut aussi éviter d'avoir trop de storage policy, car tu ne peux pas mixer les AuxCopy entre Storage Policy. Vérifie bien que tu as au maximum autant de stream que tu as de lecteurs, sinon tu auras un gros gâchis de bandes
 
Marrant de mettre 2 MediaAgent sur 1 baie, après je ne connais pas le besoin mais moi quitte à dédier des disques pour la sauvegarde j'aurais mis un MediaAgent avec un(des) simple tiroir(s) de disques en SAS (une à plusieurs MD1200 pour rester chez Dell) c'est moins cher et le débit max est meilleur
 
Si tu mets 4 lecteurs, gaffe à comment ils sont connectés : si tu pars sur de la fibre, il faut soit mettre un switch fibre, soit mettre 4 HBA sur ton MediaAgent

je dois faire le test sur le compression justement... (reco support simpana) mais j'ai pas eu le temps depuis le début de l'année...
 
pour les stream, j'ai même redescendu à 1 (un lecteur par MA) parce que j'ai plus de bandes non pleine quand j'en mets 2, mais je pense que ça vient aussi du fait qu'on a une storage policy par mediaagent. là je n'ai que la dernière bande de chaque lecteur qui est incomplète.
 
Pour les MediaAgent en fait j'ai deux baies, une MD3200i en primaire, et une extension avec une MD1200. Après je fais avec l'historique construit avec des consultants expert simpana à la base... A terme si j'ai le choix j'essayerais de séparer les deux.

Justement non, pour moi il ne devrais y avoir qu'un seul MediaAgent car au final tout est sur la même baie. A moins que tu en ai vraiment besoin, et je ne vois vraiment pas pourquoi, tu ne devrais mettre qu'1 seul MediaAgent connecté à la baie+extension et connecté au robot avec tes 2 lecteurs.
L'intérêt est :
- d'avoir un seul serveur MediaAgent
- d'avoir toute la volumétrie MD3200+MD1200 disponible
- d'avoir un robot connecté au MediaAgent et lui laisser les 2 lecteurs dispo pour avoir 2 streams. En plus tu n'auras plus qu'1 seul storage policy pour utiliser au maximum tes bandes
Sur ce point par contre, la migration de 2 storage policy en 1 seule n'est pas simple
 
Chez moi j'ai plusieurs MediaAgent également, mais c'est pour des raisons de sauvegardes sur les sites distants : tout est sauvegardé sur le MediaAgent local, et les backup sont répliquées sur le site central en DASH Copy, qui est le seul site possédant un robot et des bandes
On a également mis une DASH Copy sur le site de PRA, vu le faible prix que nous a coûté le serveur et ses disques (tiroir D2600 chez HP, équivalent d'un MD1200 chez Dell), mais ça c'est une autre histoire

pour la config actuelle, c'est une reco du presta expert simpana qui nous a fait la migration en v9. de ce que j'en sais ils sont passés à 2 MediaAgent parce que visiblement un seul ne suffisait pas pour faire passer la sauvegarde dans la fenetre... pas assez puissant (j'ai du mal à le croire vu leur taux d'utilisation actuel )
 
pour le DRP on a les même chose, avec un 3 MediaAgent qui se chargent de récupérer les données et de les restaurer directement.

pour ta sauvegarde disque, tu utilise une baie de-dupliquée ?

Non, les baies MD ne font pas de la déduplication en natif, c'est mon outil de sauvegarde qui s'en charge
enfin si c'est ce que tu voulais dire

Ce sont des serveurs physiques ou des VMs qu'il faut sauvegarder ?

 
les deux, mais majoritairement des VMs

je ne connais pas assez commvault
mais si tu n'as que des vm , la dedup doit etre assez efficace

 
je n'ai pas que ça, mais principalement.
Après la dédup sur disque est efficace, en effet, on passe en moyenne de 20To à 500Go, mais en fait je ne vois pas le rapport avec le topic.
 
 
Par contre, des petits tests ont montré que lors de la mise sur bande, on est en moyenne à 60MB/s en lecture sur la baies (pour les 2 serveurs confondus) alors que lorsque je lance un IOMeter sur la baie, j'arrive à faire une moyenne de plus de 300MB/s en lecture.
Je commence à me dire que c'est peut être Simpana qui me plante mes perfs...

- fais un test de perf sur tes lecteurs avec HPTapePerf si ce sont des HP (je me répète...)
- fais un test de validation de lecteurs depuis Simpana
- fais un test de copie sur bandes avec des données non dédupliquées
 
La configuration possède peut être des choses incorrectes, et j'ai l'impression que ton prestataire qui a mis en place Simpana s'est un peu raté
Tu peux me mp le nom de la société ? j'ai déjà eu affaire à 2 experts différents, ca se trouve il est dans l'un des deux y'a pas beaucoup d'intégrateurs en France, et les vrais experts se comptent sur les doigts de la main

- Le test de perf sur les lecteurs (avec HP Library and Tape Tools) donne 120MB/s sur chacun des deux lecteurs en écriture et 117-118MB/s en lecture
 
- le test de validation donne 57MB/s en symétrique sur un lecteur
 
j'ai pas fait le test de copie sur bande en non dédup, déjà ce weekend je teste la désactivation de la Soft compression sur la dédup...
 
Ca sent en effet de plus en plus la problème de config avec simpana

Sur la robotique pur et dur tu as effectivement Overland & Quantum avec les Scalar qui sont très bien placés,

oui je t'avais bien dit de désactiver la software compression ca pourri les perfs (faut décompresser en plus de réhydrater) et cela t'empêche d'utiliser la hardware compression et tes bandes ne sont utilisés à leur plein capacité

Bon ben le test de désactivation de la Soft Compression est partiellement concluant...
 
j'ai mes Disk Library qui sont pleine (je sauvegarde 20To, j'ai 32To de library dont plus de 15To de libre avant le début de la sauvegarde) et là j'ai plus rien de libre et une sauvegarde qui en est à 60%... je comprends pas, la déduplication ne semble pas suffisamment efficace...
 
à côté de ça, le peu que j'ai pu mettre sur bande a atteint un score tout à fait honorable... dommage

cela s'explique par le fait que les données dédupliquées étaient compressés, là tu as maintenant dans ta base de déduplication des données non compressées
La prochaine sauvegarde non compressées devraient atteindre des taux normaux

déjà j'aimerais réussir à finir la première sauvegarde... j'ai ma baie qui est rempli, et je ne sais pas pourquoi, d'après le report il aurait écrit moins de 5To sur les jobs de sauvegarde...
 
j'ai un case ouvert au niveau support et ils doivent investigué car pour eux il n'y a pas de souci au niveau du data aging (pourtant j'ai des fichiers vieux de plusieurs mois sur la baie et pas de sauvegarde de plus de 15jours sur la baie d'après le CommServe)... allez comprendre

as-tu activé la gestion automatique de l'espace disque (ou un truc du genre) ? cette option met la gestion du stockage en mode auto et c'est pas terrible : les données dédupliquées ne sont jamais expirées et l'espace disque n'est jamais libérée par rapport à la rétention définie

bon je me suis connecté au boulot pour voir où était l'option :3 dans Storage Policy, propriétés de ta primary copy, tu dois avoir la case décochée "Enable Managed Disk Space for disk data"
En théorie c'est pour laisser Simpana gérer l'espace disque et garder les données au maximum suivant l'espace disque, et avoir plus de rétention
En pratique cela ne marche pas bien quand les espaces disques sont mal configurés donc vaut mieux le décocher et lancer un Data Aging : au bout de quelques minutes les données vont commencer à expirer et l'espace va se libérer

c'est fait, ça marchait pas mal, mais là visiblement il a supprimé les données de la base simpana, mais pas des disque, enfin c'est l'impression que cela donne

huh ? supprimer des disques ?

Oui, ce n'est pas trop recommander, mais je vais voir avec le support avant... des fois que les remontées Windows sur les LastWriteTime des fichiers ne soient pas bonnes...