La bande est un média stable et extrêmement fiable pour le stockage et la préservation des données à long terme. En revanche, sa durée de vie est limitée. L'usure résultant des processus mécaniques normaux tels que montage, tension et lecture/écriture s'accumule au fil du temps. Quand de nouveaux lecteurs aux performances supérieures deviennent disponibles, les anciens lecteurs deviennent plus difficiles à prendre en charge et les médias compatibles sont plus chers et difficiles à trouver. Donc, à un certain stade, vous devez transférer vos archives vers un nouveau média.
Dans un système de fichiers hiérarchique Oracle HSM, le remplacement d'anciens médias par des nouveaux est un processus complexe. Les médias de bande font partie intégrante du système de fichiers. Les métadonnées du système de fichiers enregistrent les emplacements d'une multitude de copies de données de chaque fichier, certaines sur disque et d'autres sur bande. Les inodes du système de fichiers doivent donc être mis à jour pour refléter les nouveaux emplacements des copies de fichier migrées à mesure que les bandes sont copiées. Parallèlement, les médias et lecteurs doivent être gérés afin que les copies soient effectuées sans perturber les opérations habituelles du système de fichiers, telles que l'archivage et le transfert.
Oracle Hierarchical Storage Manager propose deux façons de gérer les complexités liées à la migration des médias. Chacune a ses avantages, selon vos besoins.
La fonctionnalité de migration de médias introduite dans Oracle HSM 6.1 copie des volumes entiers de médias montés sur un lecteur de bibliothèque vers des médias montés sur un autre, en mettant à jour les métadonnées du système de fichiers au cours du processus (les lecteurs chargés manuellement ne sont pas pris en charge). Cela réduit le temps système et la charge de travail de l'administrateur. Les volumes sont copiés en arrière-plan, lorsque les lecteurs ne sont pas requis pour l'archivage ou le transfert. Vous pouvez indiquer le nombre de lecteurs utilisés et l'heure du jour à laquelle la migration peut se faire. Vous pouvez aussi laisser Oracle HSM migrer les volumes à chaque fois que les lecteurs sont inactifs. Si un lecteur ou un volume est nécessaire pour un travail d'archivage ou de transfert, le processus de migration de médias procède à l'opération ayant la priorité la plus élevée. Si vous avez correctement configuré les lecteurs de destination StorageTek T1000D (ou version supérieure) disponibles, vous pouvez effectuer la migration à l'aide de la fonctionnalité T10000 Extended Copy et de l'option xcopy d'Oracle HSM. Une fois la demande effectuée, les lecteurs gèrent la copie eux-mêmes, sans utiliser les ressources du serveur. Autrement, vous pouvez aussi minimiser la charge du serveur en utilisant l'option de copie sur serveur d'Oracle HSM. Le serveur du système de fichiers copie alors les volumes de lecteur à lecteur via un tampon d'E/S configurable.
Les processus d'archivage normaux peuvent également migrer les données, un fichier d'archive à la fois. Vous configurez le système pour transférer les fichiers de l'ancien média vers le cache disque puis les réarchiver sur le nouveau média. Cette approche fichier par fichier vous permet d'exercer un plus grand contrôle sur la façon dont les fichiers sont regroupés et distribués. En revanche, elle nécessite une administration supérieure. Comme vous allouez vous-même le cache disque et les ressources de lecteur, vous devez prévoir avec soin s'il faut minimiser les interférences avec les opérations habituelles du système de fichiers.
Le reste de ce document vous guide tout au long du processus :
Migration des données, par Migration de volumes complets ou par Transfert de fichiers et réarchivage sur un média de remplacement.
Avant de poursuivre, effectuez les étapes suivantes :
Avant de lancer une migration de médias, assurez-vous que les mécanismes de récupération qui protègent normalement les données d'archive d'Oracle HSM restent effectifs pendant et après la transition. Des défaillances matérielles et des erreurs utilisateur peuvent survenir pendant une opération de migration. En conséquence, vous devez, comme d'habitude, vous assurer de pouvoir récupérer les fichiers et/ou les systèmes de fichiers complets à partir de vos fichiers de point de récupération samfsdump.
Lors de la migration et parfois après, la récupération dépend des fichiers de point de récupération qui référencent les volumes de bande source, plutôt que les nouveaux volumes de destination. Si une défaillance matérielle majeure désactive le système de fichiers et que ces anciennes bandes ne sont pas disponibles, vous ne pourrez pas procéder à la récupération.
Donc, au minimum, veillez à conserver les anciennes bandes jusqu'à ce que vous ayez créé suffisamment de points de récupération pour restaurer le système de fichiers actuel à partir des nouveaux médias. Si vous devez pouvoir restaurer les fichiers pour des périodes données, il vous faudra conserver les anciens médias plus longtemps, voire indéfiniment. Dans l'idéal, les anciens volumes doivent être conservés dans une bibliothèque et être facilement accessibles.
Assurez-vous que la bibliothèque de destination contient suffisamment de médias pour recevoir les fichiers migrés. Veillez à ce que tous les volumes soient correctement étiquetés, comme décrit dans Etiquetage d'une nouvelle bande ou réétiquetage d'une bande existante. La migration échouera si les volumes ne sont pas étiquetés.
La méthode de migration que vous choisissez dépend de l'état de vos archives et des exigences de l'application et des utilisateurs. Pour prendre une décision, procédez comme suit.
Déterminez si l'archive restera opérationnelle lors de la migration.
Pour vous simplifier la tâche et accélérer la migration, vous pouvez mettre l'archive au ralenti et dédier toutes les ressources à l'opération. Toutefois, cette méthode n'est pas pratique si l'archive est en cours d'utilisation.
Si vous devez migrer, de façon sélective, des groupes de fichiers d'archive plutôt que des volumes complets, ou si vous devez maintenir des relations spéciales entre des groupes de fichiers d'archive, utilisez la méthode de transfert et de réarchivage. Passez à Transfert de fichiers et réarchivage sur un média de remplacement.
Si vous devez simplement copier d'anciens volumes vers un nouveau média et/ou si vous avez besoin de minimiser l'impact de la migration sur les opérations du système de fichiers, utilisez la méthode de migration de volume.
Si vous ne disposez pas de lecteurs Fibre Channel Oracle StorageTek T10000D (ou version supérieure) que vous pouvez utiliser comme lecteurs de destination ou si les bandes source et cible ne partagent pas une taille de bloc commune, utilisez la méthode de copie sur serveur.
Avec ce mode, le logiciel Oracle HSM copie uniquement les fichiers d'archive valides du lecteur source vers un tampon d'E/S configurable sur le serveur du système de fichiers. Si les tailles de bloc source et de destination diffèrent, le logiciel effectue automatiquement les ajustements, tant que la taille du bloc de destination est supérieure. Le logiciel envoie ensuite les blocs de bande du tampon au lecteur de destination.
Si vous disposez de lecteurs de destination Fibre Channel StorageTek T10000D (ou version supérieure), si les deux lecteurs exécutent le microprogramme actuel, si les bandes source et cible partagent la même taille de bloc, et si les lecteurs source et de destination se connectent via le même commutateur de réseau de stockage (SAN), utilisez l'option xcopy d'Oracle HSM.
Quand vous spécifiez xcopy, le serveur du système de fichiers envoie une demande de copie SCSI au lecteur et le lecteur T10000D copie la source vers la bande de destination, bloc par bloc, en commençant par le premier fichier d'archive valide. Si l'opération xcopy échoue pour une raison ou une autre, le logiciel de migration passe automatiquement à la méthode de copie sur serveur. La méthode xcopy maximise la performance et minimise le temps système du serveur.
Pour plus d'informations sur les exigences en matière de lecteur et de microprogramme, voir les notes de version, README.txt, dans le fichier ZIP téléchargé ou sur le serveur de système de fichiers spécifié dans /opt/SUNWsamfs/doc/README.txt
Si les volumes source contiennent relativement peu de fichiers expirés, utilisez l'option xcopy en mode eod (fin de données).
Dans ce mode, le lecteur T10000 copie tous les fichiers d'archive trouvés entre le premier fichier valide et la marque de fin de données (EOD) sur la bande. Si certains de ces fichiers sont périmés, ils sont copiés vers le volume de destination avec les fichiers valides.
Si les volumes source contiennent beaucoup de fichiers expirés, utilisez l'option xcopy en mode repack.
Dans ce mode, le lecteur T10000 copie uniquement les fichiers d'archive non expirés sur le volume de destination.
Passez à Transfert de fichiers et réarchivage sur un média de remplacement.
Sélectionnez la méthode de copie sur serveur ou de copie directe et configurez la migration en créant le fichier migrationd.cmd. Effectuez les tâches suivantes :
migrationd.cmdConnectez-vous au serveur de métadonnées Oracle HSM en tant qu'utilisateur root.
root@solaris:~#
Ouvrez le fichier /etc/opt/SUNWsamfs/migrationd.cmd dans un éditeur de texte.
Dans l'exemple, nous utilisons l'éditeur vi pour ouvrir le fichier et ajouter un commentaire initial :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements
Si vous ne devez migrer que quelques volumes, spécifiez chaque volume source et volume de destination et indiquez la direction de la migration. Pour chaque volume source, entrez une ligne sous la forme migrate = from source to destination, où :
media_type est le code de deux lettres qui identifie le type de média qui contient la source (pour plus de détails, voir Annexe A, Glossaire des types d'équipement).
VSN est le numéro de série unique de volume qui identifie un volume de bande dans une bibliothèque.
Dans l'exemple, nous migrons les données d'une ancienne bande LTO (li), VOL305, vers une nouvelle cartouche de bande Oracle StorageTek T10000 (ti), VOL820 :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements # Migrate a single volume. migrate = from li VOL305 to ti VOL820
Si vous devez migrer un grand nombre de volumes, définissez des pools de médias pour les volumes source et de destination. Définissez chaque pool en entrant une ligne sous la forme vsnpool = poolname library equipment_number media_type VSNlist, où :
name identifie le pool de façon univoque.
equipment_number est le nombre ordinal que le fichier mcf affecte à la bibliothèque qui contient les volumes source.
media_type est le code de deux lettres qui identifie le type de média qui contient la source (pour plus de détails, voir Annexe A, Glossaire des types d'équipement).
VSNlist est une liste séparée par des espaces de numéros de série de volume (VSN) et/ou d'expressions régulières qui identifient des groupes et des plages de VSN.
Dans l'exemple, nous migrons les données des anciens volumes de bande LTO4 (li) vers des nouvelles cartouches de bande LTO6 (ti). Nous ajoutons une ligne pour un pool source, pool1, qui représente les volumes LTO4 dans la bibliothèque 20 à migrer. Cela inclut les volumes dont les VSN figurent dans la plage comprise entre VOL000 et VOL299 ainsi que deux volumes uniques, VOL300 et VOL304. Nous ajoutons ensuite une ligne pour un pool de destination, pool2, qui représente une plage de volumes LTO6 dans la bibliothèque 30.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd # /etc/opt/SUNWsamfs/migrationd.cmd # A configuration file for migrating data from old tape volumes to replacements # pool1 contains the source volumes vsnpool = pool1 library 20 li ˆVOL[0-2][0-9][0-9] VOL300 VOL304 # pool2 contains the destination volumes vsnpool = pool2 library 30 li ˆVOL50[0-9]
Si vous avez défini des pools de médias source et de destination, indiquez la direction de la migration. Entrez une ligne sous la forme migrate = from sourcepool to destinationpool, où :
sourcepool représente le pool de médias contenant les données qui seront migrées.
destinationpool représente le pool de médias qui recevra les données migrées.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... vsnpool = pool1 library 20 li ˆVOL[0-2][0-9][0-9] VOL300 VOL304 # pool2 contains the destination volumes vsnpool = pool2 library 30 ti ˆVOL50[0-9] # Migrate data from tapes in pool1 to tapes in pool2. migrate = from pool1 to pool2
Si vous envisagez d'utiliser exclusivement la méthode de migration de copie sur serveur, désactivez la fonctionnalité xcopy. Entrez une ligne sous la forme xcopy = off.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Disable xcopy and the StorageTek T10000 Extended Copy feature. xcopy = off
Si vous prévoyez d'utiliser exclusivement la fonctionnalité StorageTek T10000 Extended Copy et que vous n'envisagez pas de migrer des données si les lecteurs prenant en charge cette fonctionnalité sont indisponibles, activez uniquement la migration xcopy. Entrez une ligne sous la forme xcopy = only.
Dans l'exemple, nous activons xcopy uniquement. Si le lecteur source ou de destination ne prend pas en charge la fonctionnalité Extended Copy, le logiciel de migration annulera automatiquement la migration :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Enable xcopy, StorageTek T10000D Extended Copy feature. # If the source or destination is not xcopy capable, cancel migration. xcopy = only
Si vous prévoyez de tirer parti de la fonctionnalité StorageTek T10000 Extended Copy, lorsque cela est possible, activez la méthode de migration xcopy. Entrez une ligne sous la forme xcopy = on.
Dans l'exemple, nous activons xcopy même si des lecteurs compatibles peuvent ne pas être toujours disponibles pendant la période de migration. Si le lecteur source ou de destination ne prend pas en charge la fonctionnalité Extended Copy, le logiciel de migration basculera automatiquement en mode de copie sur serveur :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # Enable xcopy, StorageTek T10000D Extended Copy feature. # If the source or destination is not xcopy capable, automatically switch # to the server buffer copy. xcopy = on
Si vous prévoyez d'utiliser la méthode xcopy pour migrer des volumes de bande qui contiennent peu de fichiers expirés, configurez xcopy pour une exécution en mode fin de données (eod). Entrez une ligne sous la forme xcopy_eod = on.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy = on xcopy_eod = on
Si vous prévoyez d'utiliser la méthode xcopy pour migrer des volumes de bande qui contiennent un grand nombre de fichiers expirés, configurez xcopy pour une exécution en mode repack. Entrez une ligne sous la forme xcopy_eod = off.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy = on xcopy_eod = off
Indiquez le volume de données minimum qui doit être copié avant que l'option xcopy puisse être interrompue par une tâche d'archivage ou de transfert ayant une priorité plus élevée. Entrez une ligne sous la forme xcopy_minsize = amountunits, où :
amount représente un entier.
units représente k pour kilooctets, M pour mégaoctets, G pour gigaoctets, T pour téraoctets, P pour pétaoctets ou E pour exaoctets.
Cette valeur définit un compromis entre l'utilisation efficace des lecteurs T10000 et la disponibilité des lecteurs pour d'autres tâches. Des valeurs supérieures permettent une écriture plus rapide des données sur les lecteurs. Des valeurs inférieures augmentent la disponibilité des lecteurs pour l'archivage et le transfert. Dans l'exemple, nous définissons la taille de copie minimum à 30 gigaoctets :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy_eod = on # xcopy can be interrupted after 30GB copied. xcopy_minsize = 30G
Définissez la période journalière pendant laquelle les tâches de migration peuvent être exécutées. Entrez une ligne sous la forme runtime = window, où window représente l'une des valeurs suivantes :
always laisse le démon de migration migrer les données chaque fois que les lecteurs et médias ne sont pas requis pour l'archivage ou le transfert. Si le démon de migration utilise des lecteurs ou médias quand ils sont requis pour l'archivage ou le transfert, il ne les cède pas.
start_time end_time, où start_time et end_time représentent, respectivement, les heures de début et de fin de la période autorisée, exprimées en heures et minutes dans un format 24 heures (HHMM).
Vous pouvez remplacer cette instruction à tout moment en exécutant les commandes samcmd, migstart, migidle ou migstop.
Le service de migration abandonne les volumes et les lecteurs s'ils sont requis par le programme d'archivage ou de transfert. En conséquence, sauf si vous rencontrez des problèmes lors de l'archivage ou du transfert (par exemple, pendant les heures de pointe), vous devez accepter la valeur par défaut, always :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... xcopy_minsize = 30G # Run all of the time. Migration daemon will yield VSNs and drives when # resources are wanted by the SAM-QFS archiver and stager. run_time = always
Activez la journalisation en spécifiant un répertoire de journal. Entrez une ligne sous la forme logdir = path, où path représente le chemin et le nom du répertoire.
Lorsque le répertoire est défini, le démon de migration journalise la destination de chaque fichier d'archive qui migre à partir de chaque volume source. Chaque volume source a son propre fichier journal, nommé media_type.VSN où :
media_type est un code de deux lettres qui identifie le type de média source (pour plus de détails, voir Annexe A, Glossaire des types d'équipement).
VSN est le numéro de série unique de volume qui identifie le volume source.
Ainsi, par exemple, le fichier journal pour le volume source ayant le VSN VOL300 serait nommé li.VOL300.
A l'instar du journal du programme d'archivage, ces journaux de migration s'avèrent très utiles lors de la récupération après sinistre (pour plus de détails, voir Compréhension des points de récupération et des journaux d'archive et Guide de récupération des systèmes de fichiers d'Oracle Hierarchical Storage Manager et du logiciel StorageTek QFS). Si vous le pouvez, spécifiez toujours un répertoire de journal. Sélectionnez un emplacement qui ne sera pas affecté par une défaillance matérielle ou logicielle d'Oracle HSM, tel que /var/adm/. Dans l'exemple, nous spécifions le répertoire /var/adm/hsm_migration_logs :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... run_time = always # Log directory for the migration logs. logdir = /var/adm/hsm_migration_logs
Indiquez un répertoire de base pour les bases de données d'inode de migration. Entrez une ligne sous la forme dbdir = path, où path représente un nom de chemin de répertoire absolu.
Une base de données d'inode est créée pour chaque volume source et gérée pour la durée de la migration. Un enregistrement de base de données de 224 octets est créé pour chaque copie d'archive figurant sur le volume source. Vous devez donc choisir un emplacement offrant suffisamment d'espace disque pour accueillir le nombre de copies le plus important qui pourrait tenir sur le média source. Par exemple, chaque volume Oracle StorageTek T10000D peut contenir jusqu'à 8 200 104 892 copies d'archive. En conséquence, il vous faudra 1,67 téraoctets d'espace de base de données pour chaque volume T10000D à faire migrer à un moment donné (pour plus de détails, reportez-vous à la page de manuel migration.cmd (1m)).
L'emplacement de la base de données par défaut est /var/opt/SUNWsamfs/sammig/db. Dans l'exemple, nous spécifions le répertoire par défaut :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... logdir = /var/adm/hsm_migration_logs # database home directory dbdir = /var/opt/SUNWsamfs/sammig/db
Définissez la taille du tampon de migration pour le périphérique de destination. Entrez une ligne sous la forme buffsize = media_type blocks, où :
media_type est le code de deux lettres qui identifie le type de média qui contient la source (pour plus de détails, voir Annexe A, Glossaire des types d'équipement).
size est un nombre entier dans la plage [2-8192], où la valeur d'entier spécifie le nombre de blocs de bande que peut contenir le tampon. La valeur par défaut est 64.
Dans l'exemple, nous allouons suffisamment d'espace pour accueillir le nombre par défaut de blocs de bandes Oracle StorageTek T10000 :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... # database home directory dbdir = /var/opt/SUNWsamfs/sammig/db # allocate buffer space for 64 T10000D tape blocks bufsize = ti 64
Indiquez le nombre maximal de lecteurs pouvant être utilisés par bibliothèque pour la migration. Entrez une ligne sous la forme max_drives = library-list, où :
library-list est une liste, séparée par des espaces, d'entrées de bibliothèque, chacune sous la forme library equipment-number device-count.
equipment-number est le nombre ordinal d'équipement affecté à la bibliothèque dans le fichier mcf.
device-count est le nombre maximal de lecteurs pouvant être utilisés dans la bibliothèque spécifiée. Par défaut, device-count est défini sur le nombre de lecteurs dans la bibliothèque
Le service de migration abandonne les volumes et les lecteurs s'ils sont requis par le programme d'archivage ou de transfert. En conséquence, sauf si vous rencontrez des problèmes lors de l'archivage ou du transfert, vous devez accepter la valeur par défaut et autoriser la migration à utiliser tout lecteur disponible. Dans l'exemple, nous avons déterminé que nous devons, en fait, limiter l'utilisation des lecteurs. Nous allouons donc huit lecteurs à la migration dans la bibliothèque 20, six dans la bibliothèque 30, et deux dans la bibliothèque 40 :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... dbdir = /var/opt/SUNWsamfs/sammig/db # allocate buffer space for 64 T10000D tape blocks bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2
Spécifiez le nombre maximal d'opérations de copie liées à la migration pouvant s'exécuter en même temps. Entrez une ligne sous la forme max_copy = processes, où processes représente un nombre entier.
La valeur par défaut est la valeur maximale, qui est égale au nombre de lecteurs configurés dans toutes les bibliothèques listées dans le fichier mcf divisée par 2. Dans l'exemple, nous autorisons jusqu'à huit processus de copie simultanés :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2 # Up to 8 sam-migcopy process can be run simultaneously. max_copy = 8
Spécifiez le nombre maximal d'opérations d'analyse liées à la migration pouvant s'exécuter en même temps. Entrez une ligne sous la forme max_scan = processes, où processes représente un nombre entier.
Pour identifier les copies d'archive sur les numéros de série de volume (VSN) des volumes source de la migration, le démon sam-migrationd analyse tous les systèmes de fichiers configurés dans le fichier mcf, lit tous les inodes à partir du cache disque et compare le champ vsn de chaque inode aux numéros de série de volume (VSN) des volumes source de la migration. Le processus augmente l'activité de métadonnées du système de fichiers et peut donc en affecter la performance.
Sélectionnez une valeur qui équilibre au mieux la performance acceptable du système de fichiers et la vitesse de migration ou acceptez la valeur par défaut, 4, pour la plupart des utilisations. Si vous envisagez de mettre au ralenti le système de fichiers pour accélérer la migration, définissez max_scan sur 0, afin que tous les volumes source soient analysés à la fois. Dans l'exemple, nous savons par expérience que nous pouvons autoriser jusqu'à huit processus d'analyse simultanés sans perturber les opérations habituelles du système de fichiers :
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd ... bufsize = ti 64 # For migration, use 8 drives in library 20, 6 in 30, and 2 in 40 max_drives = library 20 8 library 30 6 library 40 2 # Run up to 8 sam-migcopy processes simultaneously. max_copy = 8 # Scan up to 8 VSNs simultaneously. max_scan = 8
Enregistrez le fichier et fermez l'éditeur de texte.
root@solaris:~# vi /etc/opt/SUNWsamfs/migrationd.cmd
...
max_copy = 8
# Scan up to 8 VSNs simultaneously.
max_scan = 8
:wq
root@solaris:~#
Les instructions de cette section décrivent la saisie des commandes à partir de l'invite de commande du shell à l'aide de la commande samcmd. Notez que toutes les commandes peuvent également être saisies à partir de l'interface samu, sous la forme :command, où command représente le nom de la commande.
Si vous n'êtes pas déjà connecté au serveur de métadonnées Oracle HSM en tant qu'utilisateur root, connectez-vous maintenant.
root@solaris:~#
Assurez-vous qu'aucune migration précédente n'est active ou non terminée. Tout d'abord, vérifiez le statut de la migration. Exécutez la commande samcmd x.
Si un autre travail de copie de migration est en cours, la commande répertorie les volumes source et de destination, par type de média et VSN, le mode de copie, le pourcentage d'avancement et le statut actuel de la copie :
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year samcmd on hsm61sol Status: Stop: Waiting for :migstart source dest cmod perc status li VOL004 li VOL042 - 60% Copy idled
Si aucun autre travail de copie de migration n'est en cours d'exécution, la commande ne répertorie aucun travail :
root@solaris:~# samcmd x Migration status samu ver time date Source Vsns - wait: 0 fsscan: 0 copy: 0 update ino: 0 log: 0 done: 0 Status: Idle: Waiting for :migstart source dest cmod perc status
Ensuite, vérifiez le statut de tous les volumes source (S) et/ou de destination (D) actuels. Exécutez la commande samcmd y.
Dans le premier exemple, la valeur end time du travail pour les seuls volumes source et de destination répertoriés est 10/16 12:14. La copie du volume source est terminée. Aucun travail n'est donc en cours d'exécution :
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOLa01 10/16 12:12 10/16 12:14 complete 35023/35023 550.00M 0 D li VOLa80 10/16 12:12 10/16 12:14 avail 550.00M
Dans le second exemple, la valeur end time du travail pour les volumes source et de destination est none. Le volume source est toujours en cours de copie vers le volume de destination. Un travail de migration est donc toujours en cours d'exécution :
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOLa02 10/16 12:12 none copy 0/35023 164.50M 0 D li VOLa81 10/16 12:12 none copy 148.75M
Enfin, vérifiez les listes de volumes dans le catalogue de la bibliothèque. Exécutez la commande samcmd v. Recherchez les indicateurs suivants dans la sortie :
R indique que le volume est en lecture seule. Quand la migration commence, les volumes source sont marqués en lecture seule.
S (source) indique que les données sont toujours en cours de copie à partir de ce volume.
D (destination) indique que les données sont toujours en cours de copie vers ce volume.
m indique que la migration du volume source est terminée.
e indique l'échec de la migration du volume source en raison d'une erreur.
Dans l'exemple, le volume VOLa01 a été migré vers VOLa80 avec succès. Le volume VOLa02 est toujours en cours de migration vers VOLa81. Echec de la migration.
root@solaris:~# samcmd v Robot catalog samcmd version HH:MM:SS month day year Robot VSN catalog by slot : eq 800 slot access time count use flags ty vsn count 64 0 2015/06/29 17:00 1 95% -il---b--Rm- li VOLa01 1 2015/07/02 17:43 2 89% -il-o-b--RS- li VOLa02 2 2015/07/02 18:31 2 89% -il-o-b--Re- li VOLa03 ... 51 2015/10/16 15:18 2 82% -il-o-b----- li VOLa80 52 2015/10/16 15:25 2 84% -il-o-b---D- li VOLa81
Si des travaux sont en cours d'exécution, attendez qu'ils se terminent.
Sinon, une fois que vous êtes sûr qu'aucune migration n'est en cours, procédez à la Migration des volumes.
Les instructions de cette section décrivent la saisie des commandes à partir de l'invite de commande du shell à l'aide de la commande samcmd. Notez que toutes les commandes peuvent également être saisies à partir de l'interface samu, sous la forme :command, où command représente le nom de la commande.
Si vous n'êtes pas déjà connecté au serveur de métadonnées Oracle HSM en tant qu'utilisateur root, connectez-vous maintenant.
root@solaris:~#
Assurez-vous que le système de fichiers source est monté.
Activez le fichier migrationd.cmd. Exécutez la commande samcmd migconfig.
Si la configuration a abouti, la commande affiche le message Configuring migration et vous invite à consulter le fichier journal pour plus de détails :
root@solaris:~# samcmd migconfig samcmd: migconfig: Configuring migration (see /var/opt/SUNWsamfs/sammig/logfile) root@solaris:~#
Autrement, la commande s'interrompt avec une erreur. Soit vous avez oublié d'arrêter le processus de migration avant d'exécuter la commande de configuration, soit vous avez arrêté la migration alors qu'un volume de bande était encore en attente de migration :
root@solaris:~# samcmd migconfig samcmd: migconfig: Can't configure migration, migration status is not stop, or migration job is pending root@solaris:~#
Affichez la configuration de la migration. Exécutez la commande samcmd y.
Si la configuration a abouti, les volumes spécifiés sont répertoriés, le statut du volume source est sched_wait (scheduled, waiting), et le statut du volume de destination est avail (available). Dans l'exemple, la configuration a réussi :
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year samcmd on hsm61sol Status: Stop: Waiting for :migstart Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 none none sched_wait 0/0 0 0 D li VOL501 none none avail 0
Si la configuration a abouti, lancez la migration. Exécutez la commande samcmd migstart.
root@solaris:~# samcmd migstart samcmd: migstart: State changed to start root@solaris:~#
Vérifiez le statut de la migration. Exécutez les commandes samcmd x et samcmd y.
Dans l'exemple, la migration vient juste de démarrer. Dans l'écran Migration status, le statut du travail est maintenant Run, 1 copie est en cours en mode (cmod) s (server), la copie est effectuée à 0%, 0 inode a été mis à jour, et le volume source est encore en cours de chargement (Loading) :
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 1 update ino: 0 log: 0 done: 0 Status: Run source dest cmod perc status li VOL001 li VOL501 s 0% Loading li.VOL001
L'écran Migration vsn list indique que 2 volumes sont actuellement en cours de traitement, 1 source et 1 de destination. Le statut des deux volumes est maintenant copy pour indiquer que le volume source est copié vers celui de destination. A ce stade, 0 octet a été copié du volume source à celui de destination et aucun des 35023 inodes n'a été mis à jour :
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 none copy 0/35023 0 0 D li VOL501 10/16 12:12 none copy 0
Vérifiez le statut de la migration de temps en temps, en exécutant de nouveau les commandes samcmd x et samcmd y.
Dans l'exemple, l'écran Migration status indique que la copie est maintenant effectuée à 23% et que 560 (0x00000230) blocs de bande ont été lus depuis la source :
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 1 update ino: 0 log: 0 done: 0 Status: Run source dest cmod perc status li VOL001 li VOL501 s 24% 0x00000230 blocks read
L'écran Migration vsn list indique que 164.50 mégaoctets ont été lus depuis le volume source et que 148.75 mégaoctets ont été écrits sur le volume de destination :
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 none copy 0/35023 164.50M 0 D li VOL501 10/16 12:12 none copy 148.75M
A la fin de la migration, vérifiez le statut. Exécutez les commandes samcmd x et samcmd y et consultez le fichier journal de la migration :
Dans l'exemple, les volumes source et de destination ne sont plus affichés dans l'écran Migration status, qui indique maintenant qu'1 copie a été effectuée. Notez que le statut de la migration est toujours Run et qu'il le restera jusqu'à ce que vous exécutiez les commandes migidle ou migstop :
root@solaris:~# samcmd x Migration status samcmd version HH:MM:SS month day year Source Vsns - wait: 0 fsscan: 0 copy: 0 update ino: 0 log: 0 done: 1 Status: Run source dest cmod perc status
L'écran Migration vsn list indique que 550.00 mégaoctets ont été lus depuis le volume source et que 550.00 mégaoctets ont été écrits sur le volume de destination. Les 35023 inodes ont été mis à jour pour refléter les nouveaux emplacements des copies d'archive migrées :
root@solaris:~# samcmd y Migration vsn list samcmd version HH:MM:SS month day year Status: Run Vsns:2 src:1 dest:1 maxcopy:2 ord m ty vsn start time end time status Inodes done/tot bytes 0 S li VOL001 10/16 12:12 10/16 12:14 complete 35023/35023 550.00M 0 D li VOL012 10/16 12:12 10/16 12:14 avail 550.00M
Le fichier journal du démon de migration répertorie chaque étape de la migration et se termine par un récapitulatif. Dans l'exemple, nous utilisons la commande Solaris tail pour afficher les entrées les plus récentes :
root@solaris:~# tail /var/opt/SUNWsamfs/sammig/logfile date time Info: Schedule: Create VsnList file. date time Info: Schedule: VsnList file created, source: 1, destination: 1. date time Info: Schedule: Migration status changed to Start. date time Info: 'li.VOL001' Filesystem scan: Started date time Info: 'li.VOL001' Filesystem scan: Completed, total copy bytes: 517.2M, inodes: 35023, multi vsn copy: 0, removable-media file: 0, obsolete copy: 0 date time Info: 'li.VOL001' Copy: Started, pid: 2459 destination 'li.VOL012' date time Info: 'li.VOL001' Copy: Mode - server copy date time Info: 'li.VOL001' Copy: Server copy started from position 0x4. date time Info: 'li.VOL001' Copy: Tar header check started from position 0x4. date time Info: 'li.VOL001' Copy: Tar header check succeeded, 5 inodes checked, 0 tar header error found. date time Info: 'li.VOL001' Copy: Completed, pid: 2459, exit status: 12, signal: 0 date time Info: 'li.VOL001' Update inode: Started, source position: 0 date time Info: 'li.VOL001' Update inode: Completed. date time Info: 'li.VOL001' Log: Started, source position: 0 date time Info: 'li.VOL001' Log: Completed. date time Summ: 'li.VOL001' date time Summ: 'li.VOL001' =============== Summary =============== date time Summ: 'li.VOL001' Status: Complete date time Summ: 'li.VOL001' Copy mode: Server copy date time Summ: 'li.VOL001' Start at: date time date time Summ: 'li.VOL001' End at: date time date time Summ: 'li.VOL001' Bytes: 550.00M date time Summ: 'li.VOL001' Archive copies: 35023 date time Summ: 'li.VOL001' Read error copies: 0 date time Summ: 'li.VOL001' Multi vsn copies: 0 date time Summ: 'li.VOL001' Removable-Media file: 0 date time Summ: 'li.VOL001' ---Dest--- ---Bytes--- ---Copies--- date time Summ: 'li.VOL001' li VOL501 550.00M 35023 root@solaris:~#
Enfin, veillez à copier les journaux de migration/volume vers un emplacement sécurisé.
Ces journaux enregistrent le volume de destination et la position de départ de chaque copie de fichier d'archive migrée à partir de chaque volume source. Ces informations s'avèrent essentielles pour la récupération de fichiers ou de systèmes de fichiers, le cas échéant. Aussi, Oracle vous recommande vivement de conserver des copies de sauvegarde de ces fichiers avec les fichiers journaux du programme d'archivage et de point de récupération, comme décrit dans le Chapitre 7, Sauvegarde de la configuration et des systèmes de fichiers et le chapitre correspondant du manuel Guide d'installation et de configuration d'Oracle Hierarchical Storage Manager et StorageTek QFS.
Le démon de migration crée des fichiers journaux de migration dans le répertoire que vous avez indiqué dans le fichier migrationd.cmd. Pour chaque volume migré, il crée un fichier nommé media_type.VSN où :
media_type est un code de deux lettres qui identifie le type de média source (pour plus de détails, voir Annexe A, Glossaire des types d'équipement).
VSN est le numéro de série unique de volume qui identifie le volume source.
Dans l'exemple, nous copions les journaux de volume du répertoire spécifié, /var/adm/hsm_migration_logs/, vers le répertoire où nous stockons les ressources de récupération du système de fichiers sur un système de fichiers distant monté sur NFS :
root@solaris:~# ls /var/adm/hsm_migration_logs/ li.VOL001 li.VOL002 li.VOL003 li.VOL004 li.VOL005 li.VOL006 ... ti.801 ... root@solaris:~# cp /var/adm/hsm_migration_logs/*.* /zfs/recover/hsmfs1/2015mig/
Quand tous les fichiers ont été réarchivés, éliminez la bande selon vos exigences (voir Elimination des anciens médias après la migration).
Arrêtez la procédure à cette étape. La migration est terminée.
Pour migrer des fichiers d'archive d'un ancien média vers un nouveau à l'aide de la méthode de transfert et de réarchivage, vous devez identifier les fichiers à migrer, les transférer sur le cache disque, puis les écrire sur le nouveau média, sans interférence avec les opérations habituelles du système de fichiers. Ce chapitre traite les étapes suivantes du processus :
Les détails du processus de transfert et de réarchivage dépendent en grande partie de deux facteurs : la capacité de stockage sur 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 nécessaires, planifiez l'élimination après migration des anciens médias.
Ajoutez le nouveau média au fichier archiver.cmd et modifiez les instructions de copie d'archive afin qu'une copie soit toujours effectuée à l'aide du nouveau média.
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.2 li .* endvsns :wq root@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 -lv Reading '/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:~# samd config Configuring SAM-FS root@solaris:~#
La méthode de transfert et de réarchivage 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 archivées de fichiers stockées dans le système de fichiers hsmfs1 monté dans /hsm/hsmfs1 :
root@solaris:~# cd /hsm/hsmfs1 root@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 . -vsn VOL008 -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.
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 d'archive /hsm/hsmfs1/data0008/20131025DAT est signalée comme étant endommagée. Par conséquent, nous la réparons et nous relançons la recherche des fichiers endommagés :
root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -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 /hsm/hsmfs1/data0008/20131025DAT :
root@solaris:~# undamage -m lt -vsn VOL008 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sls -D /hsm/hsmfs1/data0008/20131025DAT 20131025DAT: 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 VOL008 copy 2: ---- May 21 10:29 109c6.1 lt VOL022 ...
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 /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -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 /hsm/hsmfs1/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 /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged root@solaris:~# archive -c 1 /hsm/hsmfs1/data0008/20131025DAT ... root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/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 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/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 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# archive /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/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 dans 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 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind . -vsn VOL008 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# undamage -m lt -vsn VOL022 /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -vsn VOL022 -damaged /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# sfind /hsm/hsmfs1/data0008/20131025DAT -online root@solaris:~# archive /hsm/hsmfs1/data0008/20131025DAT root@solaris:~# unarchive -m lt -vsn VOL008 /hsm/hsmfs1/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 . -vsn VOL008 -offline -exec stage {}\;
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 . -vsn VOL008 -online -exec rearch -r -m lt {}\;
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 Elimination des anciens médias 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.
Une fois la migration terminée, les anciens médias ne perdent pas nécessairement toute leur valeur. Vous devez donc songer à la façon dont vous allez les éliminer.
Au minimum, conservez les anciennes bandes jusqu'à ce que vous ayez cumulé suffisamment de points de récupération pour récupérer n'importe quel fichier du système de fichiers en n'utilisant que les nouveaux médias de remplacement.
Si l'espace de stockage le permet, conservez les anciens médias indéfiniment. Tant que des lecteurs compatibles demeurent disponibles, les anciens médias constituent une ressource de sauvegarde et de récupération précieuse.
Si l'espace de la bibliothèque est limité, exportez les anciens médias et conservez-les dans un lieu de stockage hors site.
Si les anciens médias peuvent être réutilisés et que vous êtes sûr que les données qu'ils contiennent ne sont plus utiles, réétiquetez les anciens volumes. Vous pouvez aussi étiqueter de nouveau le média d'un ancien lecteur Oracle StorageTek T10000C et l'utiliser avec un lecteur T10000D plus récent.
Sinon, si les données des anciens volumes et les médias ne présentent plus aucune valeur, exportez les volumes à partir de la bibliothèque et éliminez-les comme il convient.