| Guide de maintenance et d'administration d'Oracle® Hierarchical Storage Manager et StorageTek QFS Software Version 6.0 E56772-02 |
|
 Précédent |
 Suivant |
| Guide de maintenance et d'administration d'Oracle® Hierarchical Storage Manager et StorageTek QFS Software Version 6.0 E56772-02 |
|
Précédent |
Suivant |
Pour migrer des fichiers archive d'un ancien média vers un nouveau média, vous devez identifier les fichiers qui vont migrer, les transférer sur le cache disque et les écrire sur le nouveau média, sans interférer avec les opérations de système de fichiers Oracle Hierarchical Storage Manager habituelles. Ce chapitre traite les étapes suivantes du processus :
Avant de déplacer les données, vous devez effectuer les tâches suivantes :
Les détails du processus réel de migration des données dépendent en grande partie de deux facteurs : la capacité de stockage de disque disponible et le nombre de lecteurs de média amovibles disponibles. Durant la migration des médias, l'outil de transfert Oracle HSM charge les anciens volumes amovibles dans les disques capables de lire le format de l'ancien média et restaure les fichiers archivés sur le cache disque. Ensuite, l'archiveur Oracle HSM réarchive les fichiers vers les nouveaux volumes amovibles à l'aide des lecteurs capables d'écrire le nouveau format de média. Idéalement, vous transféreriez ainsi tous les fichiers de tout volume de bande donné vers le disque en une seule fois puis vous les archiveriez immédiatement sur le nouveau média.
Pour cela, vous devriez utiliser un grand nombre de ressources pendant toute la durée de la migration :
l'espace de disque équivalent à la capacité d'une bande complète
l'utilisation exclusive d'un lecteur qui peut lire l'ancien format de bande
l'utilisation exclusive d'un lecteur qui peut écrire sur le nouveau format
Les ressources ci-dessus ne posent pas de problème si vous pouvez mettre le système de fichiers en veille jusqu'à ce que la migration soit complète. Mais il est recommandé de bien réfléchir à la migration de données dans un paramétrage de production, sans interférer excessivement avec le système de fichiers et les opérations d'archivage en cours. Si l'espace de disque ou les lecteurs de bande viennent à manquer, vous devez identifier les ressources que vous pouvez ne pas migrer puis ajuster le processus de migration. Procédez comme suit :
Estimez la quantité de cache disque que vous pouvez utiliser pour la migration sans gêner les opérations de système de fichiers habituelles.
Estimez le nombre de lecteurs de bande que vous pouvez dédier à la migration.
Si un nombre limité de lecteurs de bande sont disponibles, envisagez de limiter les processus de transfert et d'archivage pour que le processus de migration ne gêne pas les opérations habituelles.
En fonction de vos estimations, sélectionnez les paramètres de transfert et d'archivage. Déterminez le nombre maximum de fichiers à migrer que l'espace de disque disponible pourra prendre en charge à un moment donné et le taux maximum auquel les fichiers peuvent être déplacés du cache et vers un nouveau média.
Une fois que vous avez estimé les ressources, passez à la Planification de la suppression de l'ancien média après la migration.
A la suite de la migration des données, vous devrez peut-être conserver l'ancien média. Identifiez vos besoins et planifiez dès maintenant la suppression du média, avant de commencer le processus de migration des données.
Si vous disposez de fichiers de point de récupération créés avec samfsdump avant la migration, les métadonnées de système de fichiers du fichier de vidage fait toujours référence aux volumes de l'ancienne bande. Vous ne pouvez pas restaurer le système de fichiers sur ces points de récupération sans accéder aux données sur le média d'origine. Vous devriez au moins conserver l'ancien média jusqu'à ce que vous soyez sûr que vous n'aurez pas besoin de récupérer le système de fichiers dans l'état dans lequel il était au moment où les anciens fichiers de point de récupération ont été créés. Lorsque vous avez suffisamment exécuté samfsdump pour créer des points de récupération qui font références aux nouveaux volumes, vous pouvez vous débarrasser des anciens volumes.
Une fois que tous les fichiers des points de récupération en cours se trouvent sur le nouveau média, vous pouvez exporter les anciens volumes à partir de la bibliothèque robotique ou les mettre à jour et les étiqueter de nouveau pour une nouvelle utilisation, en fonction du type de média. Par exemple, vous pouvez simplement exporter le média DLT pour le supprimer. Vous pouvez aussi étiqueter de nouveau le média d'un ancien lecteur Oracle StorageTek T10000C et l'utiliser avec un nouveau lecteur T10000D.
Lorsque vous avez décidé comment supprimer l'ancien média, vous pouvez démarrer la Configuration du processus d'archivage pour la migration.
Lors du processus de migration, vous pouvez modifier le fichier de configuration de l'archiveur archiver.cmd pour inclure le nouveau type de média de remplacement à côté du type que vous remplacez.
archiver.cmdModifiez le fichier archiver.cmd afin que la deuxième copie d'archive soit envoyée vers le nouveau média. Inutile d'ajouter une copie d'archive supplémentaire.
Ouvrez le fichier /etc/opt/SUNWsamfs/archiver.cmd dans un éditeur de texte.
La stratégie d'archivage indique deux copies qui doivent être écrites sur le type de média que vous souhaitez remplacer. Dans cet exemple, nous ouvrons le fichier dans l'éditeur vi. Nous souhaitons remplacer les cartouches DLT (type lt) :
root@solaris: vi /etc/opt/SUNWsamfs/archiver.cmd # ============================================= # /etc/opt/SUNWsamfs/archiver.cmd # --------------------------------------------- ... # --------------------------------------------- # VSN Directives vsns allfiles.1 lt .* allfiles.2 lt .* endvsns
Dans les directives destinée à la copie 2, modifiez le type de média spécifié et remplacez-le par l'identificateur du nouveau média, enregistrez le fichier et fermez l'éditeur de texte.
Dans l'exemple, nous souhaitons migrer les données des anciennes bandes DLT vers les nouvelles cartouches LTO. Dans la copie 2, nous modifions l'ancien type de média, lt (DLT), en li (LTO) :
root@solaris: vi /etc/opt/SUNWsamfs/archiver.cmd # ============================================= # /etc/opt/SUNWsamfs/archiver.cmd # --------------------------------------------- ... # --------------------------------------------- # VSN Directives vsns allfiles.1 lt .* allfiles.2li.* endvsns:wqroot@solaris:~#
Vérifiez qu'il n'y pas d'erreurs de syntaxe dans le fichier archiver.cmd. Exécutez la commande archiver -lv et corrigez les erreurs jusqu'à ce qu'il n'y en ait plus.
La commande archiver -lv imprimera le fichier ligne par ligne. En cas d'erreur, elle s'arrête au niveau où l'erreur s'est produite.
root@solaris:~#archiver-lvReading '/etc/opt/SUNWsamfs/archiver.cmd'. 1: # ============================================= 2: # /etc/opt/SUNWsamfs/archiver.cmd 3: # --------------------------------------------- 4: # Global Directives 5: logfile = /var/opt/SUNWsamfs/archiver.log 6: # --------------------------------------------- 7: # File System Directives: 8: fs = samqfsms 9: all . 10: 1 5m ... root@solaris:~#
Une fois que le fichier archiver.cmd modifié ne comporte plus aucune erreur, chargez-le dans la configuration actuelle à l'aide de la commande samd config :
root@solaris:~#samdconfigConfiguring SAM-FS root@solaris:~#
Ensuite, procédez à la Migration de données d'une cartouche vers une autre.
La procédure recommandée pour la migration des données utilise sfind, l'extension Oracle HSM de la commande GNU find. La commande sfind est utilisée pour localiser les fichiers sur un volume de bande spécifié et pour lancer les commandes stage et rearchive par rapport à tous les fichiers trouvés.
(Si vous ne connaissez pas les commandes sfind, stage et/ou rearchive, consultez leurs pages de manuel respectives.) Procédez comme suit pour chaque cartouche de bande qui contient des données à migrer :
Connectez-vous à l'hôte du système de fichiers en tant qu'utilisateur root.
root@solaris:~#
Passez au répertoire de points de montage pour le système de fichiers qui contient les fichiers à migrer.
Dans cet exemple, nous migrons des copies de fichiers archivées et stockées dans le système de fichiers samqfs1 monté dans /samqfs1 :
root@solaris:~#cd/samqfs1root@solaris:~#
Sélectionnez un volume de bande.
Lors de la migration de données d'un type de média vers un autre, procédez avec un volume à la fois. Dans les exemples ci-dessous, nous utilisons le numéro de série de volume VOL008.
Cherchez tout d'abord dans le volume sélectionné des fichiers endommagés qui ne peuvent pas être transférés. Exécutez la commande Oracle HSM sfind . -vsn volume-serial-number -damaged, où volume-serial-number est la chaîne alphanumérique qui identifie de façon unique le volume dans la bibliothèque.
Dans cet exemple, nous démarrons la recherche à partir du répertoire de travail actuel (.). Le paramètre -vsn limite la recherche aux fichiers trouvés sur notre bande actuelle, VOL008. L'indicateur -damaged limite la recherche aux fichiers qui ne peuvent pas être transférés :
root@solaris:~#sfind.-vsnVOL008-damaged
Si la recherche sfind pour trouver les fichiers endommagés donne des résultats, essayez de réparer le fichier. Exécutez la commande undamage -m media-type -vsn volume-serial-number file, où :
media-type est l'un des codes de type de média à deux caractères répertoriés dans l'Annexe A, Glossaire des types d'équipement.
volume-serial-number est la chaîne alphanumérique qui identifie de façon unique le volume.
file est le chemin d'accès et le nom du fichier endommagé.
Parfois, une copie est marquée comme endommagée du fait d'une erreur d'E/S temporaire. La commande Oracle HSM undamage supprime cette condition. Dans cet exemple, la copie du fichier archive /samqfs1/data0008/20131025DAT est signalée comme endommagée. Par conséquent, nous la réparons et nous relançons la recherche des fichiers endommagés :
root@solaris:~#sfind.-vsnVOL008-damaged/samqfs1/data0008/20131025DAT root@solaris:~#undamage-mlt-vsnVOL008/samqfs1/data0008/20131025DATroot@solaris:~#sfind.-vsnVOL008-damaged
Si la commande sfind signale à nouveau le fichier comme endommagé, la copie est inutilisable. Vérifiez si l'archive contient une autre copie non endommagée du fichier. Pour afficher la liste des copies disponibles, exécutez la commande sls -D file, où file est le chemin et le nom du fichier. Pour vérifier le statut des copies trouvées, exécutez la commande sfind file -vsn volume-serial-number.
Dans l'exemple, la commande undamage n'a pas pu réparer la copie. Nous utilisons donc sls pour répertorier toutes les copies du fichier /samqfs1/data0008/20131025DAT :
root@solaris:~# undamage -m lt -vsn VOL008 /samqfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /samqfs1/data0008/20131025DAT root@solaris:~#sls-D/samqfs1/data0008/20131025DAT20131025DAT: mode: -rw-r--r-- links: 1 owner: root group: other length: 319279 admin id: 7 inode: 1407.5 project: system(0) offline; archdone; stage -n; copy 1: ---- May 21 07:12 1e4b1.1 lt VOL008copy 2:---- May 21 10:29 109c6.1 ltVOL022...
Le volume de bande VOL022 détient une seconde copie du fichier. Nous recherchons donc la deuxième copie à l'aide de la commande sfind :
root@solaris:~#sfind/samqfs1/data0008/20131025DAT-vsnVOL022-damaged
Si une copie est inutilisable et qu'une copie non endommagée du fichier existe, réarchivez le fichier. Une fois que l'archive contient deux copies correctes, désarchivez la copie endommagée.
Dans l'exemple, la copie 1 du fichier /samqfs1/data0008/20131025DAT située sur le volume VOL008 est inutilisable, mais la commande sfind n'a détecté aucun dommage sur la copie 2. Nous exécutons donc la commande archive avec l'option -c afin de créer une copie 1 valide avant d'annuler l'archivage de la copie endommagée sur le volume VOL008 :
root@solaris:~# sfind /samqfs1/data0008/20131025DAT -vsn VOL022 -damaged root@solaris:~#archive-c1/samqfs1/data0008/20131025DAT... root@solaris:~#unarchive-mlt-vsnVOL008/samqfs1/data0008/20131025DAT
Si vous ne trouvez aucune copie utilisable, regardez si le fichier est stocké en cache. Exécutez la commande sfind . -vsn volume-serial-number -online.
Dans l'exemple, la copie 1 du volume VOL008 et la copie 2 du volume VOL022 sont endommagées et inutilisables. Nous recherchons donc si le fichier est disponible en ligne, dans le cache disque :
root@solaris:~# undamage -m lt -vsn VOL008 /samqfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /samqfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /samqfs1/data0008/20131025DAT root@solaris:~# sfind /samqfs1/data0008/20131025DAT -vsn VOL022 -damaged /samqfs1/data0008/20131025DAT root@solaris:~#sfind/samqfs1/data0008/20131025DAT-online
Si aucune copie utilisable n'existe mais que le fichier se trouve dans le cache, archivez le fichier. Une fois que l'archive contient deux copies correctes, désarchivez la copie endommagée.
Dans cet exemple, la copie 1 du volume VOL008 et la copie 2 du volume VOL022 sont inutilisables. Par conséquent, nous exécutons la commande archive afin de créer deux copies valides avant de désarchiver la copie endommagée sur le volume VOL008 :
root@solaris:~# undamage -m lt -vsn VOL008 /samqfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /samqfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /samqfs1/data0008/20131025DAT root@solaris:~# sfind /samqfs1/data0008/20131025DAT -vsn VOL022 -damaged /samqfs1/data0008/20131025DAT root@solaris:~# sfind /samqfs1/data0008/20131025DAT -online /samqfs1/data0008/20131025DAT root@solaris:~#archive/samqfs1/data0008/20131025DATroot@solaris:~#unarchive-mlt-vsnVOL008/samqfs1/data0008/20131025DAT
Si vous ne trouvez aucune copie utilisable et si le fichier n'est pas stocké dans le cache disque, les données sont probablement perdues. Si les données sont critiques, consultez une entreprise spécialiste de la récupération des données pour obtenir de l'aide. Sinon, désarchivez la copie endommagée.
Dans l'exemple, la copie 1 du volume VOL008 et la copie 2 du volume VOL022 sont inutilisables. La commande sfind n'a pas pu trouver le fichier et le cache disque. Les données ne sont pas critiques. Par conséquent, nous désarchivons la copie endommagée sur le volume VOL008 :
root@solaris:~# undamage -m lt -vsn VOL008 /samqfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /samqfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /samqfs1/data0008/20131025DAT root@solaris:~# sfind /samqfs1/data0008/20131025DAT -vsn VOL022 -damaged /samqfs1/data0008/20131025DAT root@solaris:~# sfind /samqfs1/data0008/20131025DAT -online root@solaris:~#archive/samqfs1/data0008/20131025DATroot@solaris:~#unarchive-mlt-vsnVOL008/samqfs1/data0008/20131025DAT
Lorsque la recherche sfind pour trouver les fichiers endommagés ne donne aucun résultat, transférez les fichiers de la bande actuelle vers le cache disque. Exécutez la commande sfind . -vsn volume-serial-number -offline -exec stage {}\;
Le paramètre -vsn limite la recherche aux fichiers trouvés sur notre bande actuelle. La migration des données est toujours faite sur une bande à la fois.
Le paramètre -offline restreint davantage les résultats de la commande sfind aux fichiers qui ne sont pas déjà stockés en cache, ce qui empêche aux données d'être écrasées.
L'argument -exec stage {}\; prend chacun des chemins et noms de fichier renvoyés par la commande sfind et les utilisent comme argument dans une ligne de commande Oracle HSM stage. La commande stage restaure ensuite le fichier spécifié sur le cache disque. Le processus se répète jusqu'à ce que tous les fichiers archivés soient transférés.
Dans l'exemple, la commande sfind -vsn VOL008 -damaged ne renvoie aucune sortie. Nous utilisons sfind pour transférer tous les fichiers trouvés sur VOL008 qui ne sont pas déjà stockés dans le cache :
root@solaris:~# sfind . -vsn VOL008 -damaged root@solaris:~#sfind.-vsnVOL008-offline-execstage{}\;
Une fois que les fichiers ont été transférés de la bande, archivez-les de nouveau de manière sélective. Exécutez la commande sfind . -vsn volume-serial-number -online -exec rearch -r -m media-type {}\;, où media-type est le type de média à partir duquel la migration se fait.
Le paramètre -vsn limite la recherche aux fichiers trouvés sur la bande actuelle. La migration des données est toujours faite sur une bande à la fois.
Le paramètre -online restreint davantage les résultats de la commande sfind aux fichiers déjà stockés en cache, ce qui empêche aux données d'être écrasées.
L'argument -exec rearch -r -m media-type {}\; prend chacun des chemins et noms de fichier renvoyés par la commande sfind et les utilisent comme argument dans une ligne de commande Oracle HSM rearch -r -m media-type. L'argument -r exécute le processus récursivement dans les sous-répertoires. L'argument -m réarchive uniquement les fichiers qui sont stockés sur le média source.
Dans cet exemple, la valeur du paramètre -vsn est VOL008, et la valeur du paramètre -m spécifie lt pour le média DLT :
root@solaris:~#sfind.-vsnVOL008-online-execrearch-r-mlt{}\;
Répétez l'étape précédente jusqu'à ce que la recherche sfind ne trouve plus de fichiers.
Lorsque tous les fichiers ont été réarchivés, supprimez la bande comme prévu (reportez-vous à la Planification de la suppression de l'ancien média après la migration).
Répétez cette procédure jusqu'à ce que les données aient entièrement migré des anciens médias vers les nouveaux médias.
