D'ACCORD. quelques données à prendre en compte
J'utilise Backup Exec 12.x / 13.x, ai l'environnement du serveur 2003/2008, y compris Exchange.
J'ai une sauvegarde sur disque (Full / Diff) qui est indépendante de la sauvegarde sur LTO (Full / Diff). Pour plus d'une raison, je préfère ne pas simplement effectuer une sauvegarde du disque sur la bande, je voudrais que la sauvegarde se poursuive directement sur LTO.
J'ai actuellement un seul lecteur LTO-3 sans aucune sorte de chargeur / robot / bibliothèque. Le boîtier qui dessert le lecteur LTO contient une carte Adaptec 39160 Ultra160 SCSI . J'utilise actuellement une cassette pour Full (une par semaine) et une cassette pour Diff (quatre jours par semaine avant la sortie de la cassette). La sauvegarde complète se heurte à la barrière de 372,5 Go et lorsqu'elle ne se termine pas samedi, elle attend toujours une bande lundi matin.
Ward a mentionné la mise en place de la deuxième bande LTO3 complète lundi après-midi / soir après les heures normales de bureau. Le problème avec ceci est comparé ci-dessous:
Débit normal
- Vendredi, insérez la bande LTO3 1 pour une sauvegarde complète pour la semaine 1
- Lundi insérer du ruban LTO3 pour différentiel
- Les différentiels de mardi, mercredi et jeudi utilisent une bande insérée lundi
- répéter pour la semaine 2
2 bandes LTO3 pour un flux de sauvegarde complet
- Vendredi, insérez la bande LTO3 1 pour une sauvegarde complète pour la semaine 1
- Lundi, insérez la bande LTO3 2 pour une sauvegarde complète pour la semaine 1
- Lundi, insérez la bande 1 LTO3 pour la sauvegarde complète de la semaine 1 (pour le processus de vérification)
- Lundi, insérez la bande LTO3 2 pour la sauvegarde complète de la semaine 1 (pour le processus de vérification)
- Mardi insérer du ruban LTO 3 pour différentiel
- Mercredi, jeudi, les différentiels utilisent une bande insérée mardi
- répéter pour la semaine 2
Les échanges de bandes supplémentaires prennent plus de 6 heures lundi (à partir du moment où j'ai mis la deuxième bande). Si je le faisais à 17 heures, je serais ici jusqu'à minuit pour échanger des cassettes. Cela ne compte pas le temps d'inactivité samedi / dimanche / lundi en attente d'une bande.
Maintenant, je peux désactiver le processus de vérification et enregistrer deux échanges de bande et raccourcir le processus de «sauvegarde» de plusieurs heures, mais je ne peux pas simplement insérer la bande 2 et repartir à la fin de la journée si je ne désactive pas la vérification . Le fait que la sauvegarde déborde sur une deuxième bande allonge le processus de sauvegarde, mais
- Augmente le nombre de bandes dans la rotation (coût)
- Augmente le nombre de bandes dans le transport (taille / poids de la mallette allant au stockage hors site)
- Augmente la complexité du processus de sauvegarde en me faisant rester sur le site après les heures pour le processus de vérification
- Augmente la complexité de la gestion des sauvegardes / restaurations depuis mon bureau qui n'est pas juste à côté de la salle des serveurs. Cela va quadrupler pour faire face à ces problèmes à domicile.
Et oui, je ne vais pas samedi pour y rester pendant plus de 6 heures et garder le lecteur de bande. J'aimerais avoir une vie en dehors du travail. 12 heures par jour MF sont déjà assez mauvais quand ils se produisent. Je ne vais pas m'attacher de façon permanente à une semaine de travail de 6 jours.
Le lecteur de bande est un Dell PowerVault 110T LTO3. Le serveur de sauvegarde est sur Gigabit Ethernet en utilisant une seule carte réseau et peut remplir une bande complète en environ 12 heures.
Je peux changer le processus de sauvegarde pour séparer l'un des serveurs les plus intensifs en une sauvegarde complète sur son propre LTO pour suspendre temporairement cette décision, mais je pense que je devrai bientôt choisir l'une de ces options:
Achetez un lecteur LTO-3 et profitez de la disponibilité d'une deuxième bande physique.C'est une option moins souhaitable et n'a de sens que si les lecteurs LTO-3 sont considérablement moins chers que les lecteurs LTO-4, ce qui n'est pas le cas.Achetez un lecteur LTO-4 et utilisez les bandes LTO-4 pour des sauvegardes complètes et utilisez des bandes LTO-3 pour les différentielles jusqu'à ce que les bandes LTO-3 soient pivotées et que les nouvelles bandes LTO4 correspondent au prix des bandes LTO3. Cela me permettra probablement de passer la sauvegarde du week-end pour les années à venir sans avoir à changer de bande. Cela concerne également partiellement le cirage des chaussures, car le LTO4 a une vitesse minimale inférieure à celle du LTO3.
Achetez quelque chose qui peut alimenter automatiquement les bandes. Je suppose qu'il n'y a rien que je puisse ajouter au PowerVault 110T et cela signifierait l'achat d'un nouvel appareil qui a la bande et le chargeur dans une seule unité. Ce n'est probablement pas rentable par rapport à l'obtention d'un lecteur et au chargement manuel de bandes, mais le chargement automatique LTO4 serait le summum de la commodité. Je laisse le patron au-dessus de moi choisir entre un lecteur de bande unique et un lecteur de chargement automatique.
Evan Anderson a mentionné dans une autre solution que vous pourriez acheter des disques dans cette gamme de prix
LTO-4 (internal drive, 1 tape / day) - $2,766.00
LTO-4 (autoloader, 1 tape / day) - $4,566.00
mais je ne sais pas de détails sur ce qu'il recommanderait pour le lecteur réel et, si nécessaire, le contrôleur. Montrez-moi une nouvelle URL (ou Dell, ou HP, ou quel que soit votre fournisseur préféré) pour votre solution si cela ne vous dérange pas de la rechercher ou donnez-moi simplement une marque et un numéro de modèle et je serai heureux de le faire la jambe me travaille.
Je cherche à faire un achat nécessaire un peu de temps avant que cette rotation de sauvegarde ne devienne trop lourde. J'ai probablement quelques mois.
Xenny mentionne l'âge des serveurs et la vitesse de sauvegarde. Le serveur Exchange a 6 ans (bien que les disques durs soient beaucoup plus récents). Il y a quelques serveurs âgés de 4 ans dans le mélange avec des disques sata de qualité grand public (WD6400AAKS). Les serveurs que je considère comme "nouveaux" ont 2 ans à ce stade.
La sauvegarde sur disque à partir de l'ancien serveur Exchange a été aussi rapide que 2184 Mo / min, mais en général, la sauvegarde sur disque est tout aussi lente que la sauvegarde sur bande dans cette configuration. En fait, la sauvegarde sur disque est parfois plus lente que la sauvegarde sur le lecteur de bande LTO-3. J'ai également eu des problèmes avec les disques en panne et le manque de baies pour ajouter plus de disques. En général, la sauvegarde sur disque est encore plus problématique que la transition LTO3 / 4 mais cela appartient à une question différente sur le défaut de serveur si je voulais une entrée sur ce sujet.
Je vais juste choisir quelques chiffres dans une sauvegarde récente pour vous donner une idée des vitesses. Ce n'est pas une liste complète mais vous donne une idée de la variété des vitesses impliquées. Je prévois de le mettre à jour bientôt au format oldspeed MB / min newspeed MB / min où oldspeed est l'ancien SCSI 320 LTO3 et newspeed est le SAS LTO4.
DC C: ~ 850 Mo / min
État du système DC ~ 700 Mo / min
Exchange Server C: et état du système ~ 500 Mo / min ~ 600 Mo / min
Exchange Server D: ~ 1400 Mo / min ~ 1200 Mo / min
Exchange Server First Groupe de stockage ~ 1100 Mo / min ~ 700 Mo / min
Serveur Web C: ~ 600 Mo / min ~ 950 Mo / min
Serveur Web E: ~ 1700 Mo / min ~ 1950 Mo / min
Serveur de fichiers C: ~ 500 Mo / min
Serveur de fichiers E: ~ 1500 Mo / min ~ 2200 Mo / min
Serveur de fichiers G: ~ 1800 Mo / min ~ 2400 Mo / min
État du système de fichiers ~ 650 Mo / min
serveur de fax C: ~ 400 Mo / min ~ 550 Mo / min
Serveur de comptabilité C: ~ 1300 Mo / min ~ 1775 Mo / min
Serveur de comptabilité D: ~ 1500 Mo / min ~ 2250 Mo / min
Instance SQL de comptabilité ~ 1600 Mo / min
Serveur d'application C: et état du système ~ 700 Mo / min ~ 900
Serveur de sauvegarde Mo / min C: 700 Mo / min ~ 1800 Mo /
serveur de sauvegarde E: 1350 Mo / min ~ 2900 Mo / min
Surveillance du Fileserver J'ai vu des chiffres qui me font penser que le contrôleur de raid freine les taux de transfert. Le contrôleur est SATA 1.5 mais les disques sont compatibles 3.0. J'ai remarqué après avoir changé les volumes de RAID 1 à RAID 10 et n'avoir obtenu aucune augmentation de vitesse pour les sauvegardes. Malheureusement, doubler la vitesse de lecture soutenue n'a eu aucun effet sur la sauvegarde sur le lecteur de bande LTO3.
En général, la sauvegarde directement sur LTO me donne une référence décente de la limite des E / S de mes serveurs. Les serveurs qui sauvegardent en dessous de 1500 Mo / min sont généralement lents sur le disque et ceux entre là et 2400 Mo / min sont toujours des fruits bas. Par exemple, le serveur Exchange 2003 manque d'espace disque et continue d'étendre la base de données du premier groupe de stockage vers des parties plus lentes des disques. Ce serveur sera remplacé par un serveur Exchange 2010 avec des processeurs plus rapides et plus de disques. Les autres serveurs recevront des mises à niveau de disque et / ou des SSD ajoutés.
http://en.wikipedia.org/wiki/Tape_drive mentionne "Lorsque le cirage des chaussures se produit, il affecte considérablement le débit de données réalisable, ainsi que la durée de vie du lecteur et de la bande." mais il ne mentionne pas le cirage des chaussures réduisant la capacité effective d'une bande. Après avoir regardé les bandes d'archives de la banque, je peux confirmer environ 2% à 15% d'espace perdu sur les bandes LTO3. Nulle part assez près pour m'empêcher de passer au LTO4 ou à un chargeur automatique, mais cela pourrait être important. Pour ceux d'entre vous avec Backup Exec, vous pouvez calculer vos déchets de cirage de chaussures en:
- Faire un travail de sauvegarde qui sauvegardera environ 100% de la capacité native des bandes sans compression. Désactivez la compression sur le lecteur et le logiciel lors de l'exécution du test.
- regardez dans l'onglet média de l'exec de sauvegarde et comparez la colonne "capacité utilisée" à la colonne "Données". Si la compression est désactivée et que les chiffres correspondent, vous ne cirez pas du tout.
Dans mon cas, j'avais une bande LTO3 d'archivage avec 272,4 Go "utilisés" mais seulement 233,67 Go de "données" et une autre avec 400,6 Go contre 395,19 Go. J'ai également essayé une sauvegarde sur LTO4 sans compression et j'ai obtenu 833 Go "utilisés" avec seulement 786,77 Go de "données". Évidemment, le cirage de chaussures variera de mon environnement au vôtre, mais avant cela, je n'ai pas pensé à le tester. J'espère que cela vous indiquera clairement comment calculer la quantité de bande gaspillée que vous avez dans votre environnement de sauvegarde.
modifier: nouvelles informations sur http://www.fujifilmusa.com/shared/bin/LTO_Overview.pdf montrant les vitesses de bande minimales pour LTO3 et LTO4. Il semble que l'IBM LTO4 ait en fait une vitesse minimale inférieure à l'IBM LTO3. Quoi qu'il en soit, mon serveur moyen est trop lent pour alimenter LTO3 / 4 sans cirage de chaussures. Je crains même que ma sauvegarde sur disque des volumes locaux ne soit trop lente pour alimenter rapidement le lecteur, mais je devrai le tester.
En tirant les informations sur le lecteur IBM pleine hauteur du PDF ci-dessus, je reçois
LTO4 : 30-120MB/s 800GB native (45-240MB/s compressed)
LTO3 : 40- 80MB/s 400GB native (60-160MB/s compressed)
LTO2 : 18- 35MB/s 200GB native (27- 70MB/s compressed)
LTO1 : 15- 15MB/s 100GB native (30- 30MB/s compressed)
Mise à jour : le serveur que j'utilisais pour la sauvegarde a commencé à me donner des erreurs d'arrêt, j'ai donc déplacé le lecteur de bande vers un autre serveur. L'ancien contrôleur SCSI était un Adaptec 160, le "nouveau" contrôleur est un LSI basé sur 320 (au moins je suppose que le connecteur externe est un 320 car les 4 disques durs à l'intérieur du serveur mentionnent 320 SCSI dans la gestion du serveur).
La nouvelle situation de serveur me laisse temporairement sans sauvegarde sur disque jusqu'à ce que j'obtienne un boîtier externe pour le stockage directement connecté. En général, cette discussion LTO m'a orienté vers l'achat de plus de disques durs pour mes serveurs. J'aurai du travail à faire pour reconfigurer les matrices RAID pour augmenter la vitesse de la sauvegarde et, espérons-le, augmenter la fiabilité de la configuration globale.
Mise à jour 2 : La comparaison ci-dessous utilise un ancien serveur de fichiers dont les goulots d'étranglement du contrôleur de raid tous les transferts à ~ 40 Mo / s, donc l'idéal serait d'environ 2400 Mo / min. Il s'agit de la vitesse nécessaire pour tester le bord du cirage des chaussures. Vraisemblablement, le flux de données ne sera pas parfaitement régulier et forcera la correspondance de vitesse presque tout au long du test.
Je ne connais plus la taille du tampon et le nombre de tampons que j'ai utilisés sur le test de vitesse de l'ancien lecteur LTO3, mais cela ne change pas grand-chose du tout. Les données de test représentent environ 20 Go de tifs et jpgs numérisés. J'ai fait ces tests un vendredi après-midi et je n'ai pas répété les tests suffisamment de fois pour faire la moyenne des données ou sinon éliminer les données invalides. Les tests après les heures, le choix de données différentes et d'autres variables pourraient sensiblement affecter ces tests.
Les mêmes serveurs sont utilisés dans tous les tests. L'ancien lecteur se trouve sur un contrôleur LVD 320 SCSI PCIx. Le nouveau lecteur se trouve sur un contrôleur SAS PCIe LSI 3801E. Il est possible que le contrôleur de lecteur et / ou le lecteur de bande LTO3 soient des goulots d'étranglement. Je ne testerai pas les composants individuels, uniquement l'ancien couplage par rapport au nouveau couplage. Le serveur exécutant Backup Exec a 4 Go de RAM, 32 bits Server 2008 standard, un processeur double cœur Pentium D 3,2 GHz.
La connectivité réseau se fait via un commutateur 1 Go, les deux serveurs sont sur le même commutateur. J'ai une connexion Bureau à distance ouverte, mais avec la sauvegarde allant + cette connexion, la connexion Gb est utilisée à moins de 50% au pire et en moyenne plus à 25% d'utilisation.
Donc, aussi rudes que soient les méthodes de test, je suis raisonnablement convaincu que les goulots d'étranglement ne sont pas dans une variable que j'ignore.
Résultats de test courts :
~ 1500 Mo / min en utilisant le lecteur Dell LTO3 et la compression de bande LTO3 ON, taille de bloc de 64 Ko (de nombreux nombres de tampons testés, le meilleur résultat est répertorié ici)
~ 1800 Mo / min en utilisant le lecteur Quantum Superloader3 LTO 4 avec une bande LTO3 (même bande que ci-dessus), compression ON, taille de bloc de 64 Ko, taille de tampon de 64 Ko, nombre de tampons 10, nombre de hautes eaux 0, mode d'écriture de bloc unique activé, passe SCSI d'écriture - via le mode ON
~ 2150 Mo / min en utilisant le lecteur Quantum Superloader3 LTO 4 avec une bande LTO3 (même bande que ci-dessus), compression ON, taille de bloc de 256 Ko, taille de tampon de 256 Ko, nombre de tampons 10, nombre de hautes eaux 0, mode écriture de bloc unique activé, passe SCSI d'écriture - en mode ON
~ 2200 Mo / min en utilisant le lecteur Quantum Superloader3 LTO 4 avec une bande LTO3 (même bande que ci-dessus) compression OFF, taille de bloc de 256 Ko, taille de tampon de 256 Ko, nombre de tampons 10, nombre de hautes eaux 0, écriture Mode bloc unique ON, écriture Mode d'intercommunication SCSI activé
~ 2050 Mo / min avec lecteur Quantum Superloader3 LTO 4 avec compression de bande LTO4 activée, taille de bloc de 256 Ko, taille de tampon de 256 Ko, nombre de tampons 10, nombre élevé 0, mode d'écriture bloc unique activé, mode de transfert SCSI activé ON
~ 2250 Mo / min en utilisant le lecteur Quantum Superloader3 LTO 4 avec une compression de bande LTO4 désactivée, une taille de bloc de 256 Ko, une taille de tampon de 256 Ko, un nombre de tampons 10, un décompte des hautes eaux 0, mode d'écriture de bloc unique activé, mode de transmission SCSI d'écriture activé
~ 2050 Mo / min en utilisant le lecteur Quantum Superloader3 LTO 4 avec une compression de bande LTO4 activée, taille de bloc de 256 Ko, taille de tampon de 1 Mo, nombre de tampons 10, nombre élevé 0, mode d'écriture bloc unique activé, mode de transmission SCSI activé ON
~ 2300 Mo / min en utilisant le lecteur Quantum Superloader3 LTO 4 avec une compression de bande LTO4 désactivée, une taille de bloc de 256 Ko, une taille de tampon de 1 Mo, un nombre de tampons de 10, un décompte des hautes eaux 0, mode d'écriture de bloc unique activé, mode de transmission SCSI d'écriture activé
~ 2200 Mo / min en utilisant le lecteur Quantum Superloader3 LTO 4 avec une compression de bande LTO4 activée, taille de bloc de 256 Ko, taille de tampon de 1 Mo, nombre de tampons 20, nombre élevé 0, mode d'écriture bloc unique activé, mode de transfert SCSI activé ON
~ 2300 Mo / min en utilisant le lecteur Quantum Superloader3 LTO 4 avec une compression de bande LTO4 désactivée, une taille de bloc de 256 Ko, une taille de tampon de 1 Mo, un nombre de tampons de 20, un décompte des hautes eaux 0, un mode d'écriture de bloc unique activé, un mode de transmission SCSI d'écriture activé
Il est clair que le réglage de la taille du bloc est plus important que la taille du tampon. Peu importe la taille de bloc ou de tampon que vous utilisez, vous obtiendrez de meilleures performances en désactivant la compression si vos données source ne peuvent pas suivre le taux de correspondance de données minimum des lecteurs de bande. Malheureusement, il s'agit d'un paramètre par lecteur et non par travail ou par format de bande, vous ne pouvez donc pas limiter la compression aux sauvegardes complètes ou à LTO3 uniquement. Vous devrez également tester l'ampleur du problème avec votre combinaison de matériel / logiciel. Bien sûr, cette baisse de performances est mineure et les tests les plus importants seront d'optimiser la sauvegarde complète de 600 Go à 800 Go au lieu de 20 Go. J'essaierai de mettre à jour à nouveau une fois que j'ai quelques semaines ou quelques mois de sauvegardes effectuées.