Cette section décrit les processus de récupération utilisés en cas de perte ou d'altération de l'ensemble d'un système de fichiers Oracle HSM. Les procédures varient selon le type de système de fichiers impliqués, le type de sauvegarde et les préparatifs de récupération que vous avez effectués. Vous devez néanmoins effectuer deux tâches de base :
Avant de commencer, prenez en compte les éléments suivants : si vous effectuez une récupération à la suite de la perte d'un serveur de métadonnées Oracle HSM, assurez-vous d'avoir terminé la procédure de restauration de la configuration de Oracle HSM, comme décrit au Chapitre 3 avant de continuer. Les procédures décrites dans ce chapitre supposent que le logiciel Oracle HSM présente une installation et une configuration identiques à celles initiales avant la perte du système de fichiers.
Avant de récupérer des fichiers et des répertoires, vous devez avoir un emplacement où les placer. La première étape du processus de récupération consiste à créer un système de fichiers de remplacement vide. Procédez comme suit :
sammkfsConnectez-vous au serveur de métadonnées du système de fichiers en tant qu'utilisateur root.
root@solaris:~#
Si le système de fichiers est monté, démontez-le. Exécutez la commande umount mount-point, où mount-point est le répertoire sur lequel le système de fichiers est monté.
Dans cet exemple, nous démontons le système de fichiers /hsmfs1 :
root@solaris:~# umount /hsmfs1 root@solaris:~#
Ouvrez le fichier /etc/opt/SUNWsamfs/mcf dans un éditeur de texte. Vérifiez la configuration matérielle. Dans le cas d'une modification de matériel, modifiez le fichier et enregistrez les modifications.
Dans cet exemple, les identificateurs d'équipement des deux périphériques de disque défaillants sont remplacés par ceux des périphériques de remplacement. Notez que les ordinaux d'équipement restent inchangés :
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #----------------------- --------- --------- --------- ------ ------------- hsmfs1 100 ms hsmfs1 on /dev/dsk/c1t3d0s3 101 md hsmfs1 on /dev/dsk/c1t4d0s5 102 md hsmfs1 on # Tape library /dev/scsi/changer/c1t2d0 800 rb lib800 on .../lib800_cat /dev/rmt/0cbn 801 li lib800 on /dev/rmt/1cbn 802 li lib800 on :wq root@solaris:~#
Recherchez les erreurs éventuelles dans le fichier mcf. Utilisez la commande sam-fsd.
La commande sam-fsd lit les fichiers de configuration Oracle HSM et initialise le logiciel. Elle s'arrête en cas d'erreur :
root@solaris:~# sam-fsd
Si la commande sam-fsd détecte une erreur dans le fichier mcf, modifiez le fichier pour corriger l'erreur et vérifiez à nouveau, comme décrit à l'étape précédente.
Dans l'exemple ci-dessous, sam-fsd signale un problème non spécifié avec un périphérique. Il s'agit probablement d'une erreur dans un champ de l'identificateur d'équipement :
root@solaris:~# sam-fsd Problem in mcf file /etc/opt/SUNWsamfs/mcf for filesystem qfsms sam-fsd: Problem with file system devices.
Généralement, les erreurs de ce type découlent de fautes de frappe involontaires. Lorsque nous ouvrons le fichier mcf dans un éditeur, nous constatons que nous avons saisi la lettre o au lieu du chiffre 0 dans la partie du numéro de tranche du nom de l'équipement pour le périphérique 102, le deuxième périphérique md :
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf ... qfsms 100 ms qfsms on /dev/dsk/c0t0d0s0 101 md qfsms on /dev/dsk/c0t3d0so 102 md qfsms on
Nous corrigeons donc l'erreur, enregistrons le fichier et revérifions :
root@solaris:~# vi /etc/opt/SUNWsamfs/mcf ... qfsms 100 ms qfsms on /dev/dsk/c0t0d0s0 101 md qfsms on /dev/dsk/c0t3d0s0 102 md qfsms on :wq root@solaris:~# sam-fsd
Si la commande sam-fsd s'exécute sans erreur, le fichier mcf est correct. Passez à l'étape suivante.
Dans cet exemple, sam-fsd s'exécute sans erreur :
root@solaris:~# sam-fsd Trace file controls: sam-amld /var/opt/SUNWsamfs/trace/sam-amld ... Would start sam-archiverd() Would start sam-stagealld() Would start sam-stagerd() Would start sam-amld() root@solaris:~#
Indiquez au logiciel Oracle HSM de lire le fichier mcf et de se reconfigurer en conséquence :
root@solaris:~# samd config Configuring SAM-FS root@solaris:~#
Créez le système de fichiers de remplacement. Exécutez la commande sammkfs family-set-name, où family-set-name est le nom du système de fichiers.
Dans cet exemple, le système de fichiers hsmfs1 est recréé :
root@solaris:~# sammkfs hsmfs1 Building 'hsmfs1' will destroy the contents of devices: /dev/dsk/c0t0d0s0 /dev/dsk/c0t3d0s0 Do you wish to continue? [y/N]yes total data kilobytes = ... root@solaris:~#
Si nécessaire, recréez le répertoire de point de montage pour le système de fichiers.
Dans cet exemple, le répertoire /hsmfs1 est recréé :
root@solaris:~# mkdir /hsmfs1 root@solaris:~#
Sauvegardez le fichier /etc/vfstab du système d'exploitation.
root@solaris:~# cp /etc/vfstab /etc/vfstab.backup root@solaris:~#
Ouvrez le fichier /etc/vfstab dans un éditeur de texte. Si le fichier /etc/vfstab ne contient pas de paramètres de montage pour le système de fichiers à restaurer, vous devrez restaurer les paramètres de montage.
Dans cet exemple, le serveur Oracle HSM est installé sur un hôte de remplacement. Par conséquent, le fichier ne contient aucun paramètre de montage pour le système de fichiers à restaurer, hsmfs1 :
root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ...
Dans la mesure du possible, ouvrez une copie de sauvegarde du fichier /etc/vfstab d'origine et copiez la ligne requise dans le fichier /etc/vfstab actif lorsque vous restaurez les paramètres de montage. Lorsque les modifications sont terminées, enregistrez le fichier et fermez l'éditeur.
Cet exemple montre une copie de sauvegarde, /zfs1/sam_config/20140127/etc/vfstab. La ligne du système de fichiers hsmfs1 est donc copiée depuis la copie de sauvegarde et collée dans le fichier /etc/vfstab actif :
root@solaris:~# vi /zfs1/sam_config/20140127/etc/vfstab.20140127 #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... hsmfs1 - /hsmfs1 samfs - yes stripe=1,bg :q
root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------- ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... hsmfs1 - /hsmfs1 samfs - yes stripe=1,bg :wq root@solaris:~#
Montez le système de fichiers.
Dans cet exemple, le système de fichiers hsmfs1 est monté :
root@solaris:~# mount /hsmfs1 root@solaris:~#
Maintenant, commencez la restauration des répertoires et des fichiers.
Après avoir recréé le système de fichiers de base, vous pouvez commencer à restaurer les répertoires et les fichiers. Il existe deux approches possibles :
La restauration des fichiers et des répertoires depuis un fichier de points de récupération samfsdump (qfsdump) est de loin la meilleure option si vous avez créé et stocké des points de récupération régulièrement.
Cette approche rétablit immédiatement l'ensemble des fonctionnalités du système de fichiers grâce à la restauration des métadonnées du système de fichiers. Un système de fichiers d'archivage peut immédiatement accéder aux données du média d'archivage et retransférer les fichiers vers le cache disque, de manière immédiate ou selon les besoins, lorsque les utilisateurs accèdent aux fichiers. Les fichiers sont restaurés avec leurs attributs d'origine.
Si le point de récupération contient à la fois des données et des métadonnées, cette approche est également la seule manière de restaurer des systèmes de fichiers autonomes qui n'ont pas été sauvegardés par des applications tierces.
Restauration de fichiers et de répertoires à partir d'un média d'archivage sans fichier de points de récupération à l'aide d'un script de récupération et de l'utilitaire Oracle HSM star.
samfsdump (qfsdump)Dans la mesure du possible, basez vos tentatives de récupération de système de fichiers sur le dernier fichier de points de récupération disponible. Cette approche est de loin la manière la plus rapide, la plus fiable, la plus précise et la moins laborieuse d'effectuer une récupération suite à l'échec d'un système de fichiers Oracle HSM. Par conséquent, si un fichier de points de récupération existe, procédez comme suit :
Connectez-vous au serveur de métadonnées du système de fichiers en tant qu'utilisateur root.
root@solaris:~#
Si ce n'est pas déjà fait, arrêtez l'archivage et le recyclage en suivant les procédures décrites à la Arrêt des processus d'archivage et de recyclage.
Identifiez le dernier fichier de points de récupération disponible.
Dans cet exemple, des fichiers de points de récupération datés ont été créés pour le système de fichiers hsmfs1 dans un emplacement connu : le sous-répertoire hsmfs1_recovery du système de fichiers indépendant /zfs1. Le fichier le plus récent, 20140324, est donc facile à trouver :
root@solaris:~# ls /zfs1/hsmfs1_recovery/ 20140321 20140322 20140323 20140324 root@solaris:~#
Accédez au répertoire de points de montage du système de fichiers recréé.
Dans cet exemple, le système de fichiers recréé est monté sur /hsmfs1:
root@solaris:~# cd /hsmfs1 root@solaris:~#
Restaurez l'ensemble du système de fichiers correspondant au répertoire actif. Exécutez la commande samfsrestore -T -f recovery-point-file -g logfile ou la commande QFS uniquement qfsrestore -T -f recovery-point-file -g logfile, où :
-T affiche les statistiques de récupération lorsque l'exécution de la commande se termine, y compris le nombre de fichiers et de répertoires traités et le nombre d'erreurs et d'avertissements.
-f recovery-point-file spécifie le chemin d'accès et le nom du fichier de points de récupération sélectionné.
-g logfile crée une liste de répertoires et de fichiers qui étaient en ligne lorsque le point de récupération a été créé et enregistre la liste dans le fichier spécifié par logfile.
Si vous restaurez un système de fichiers d'archivage, vous pouvez utiliser ce fichier pour transférer automatiquement les fichiers des médias d'archivage afin que l'état du cache disque soit le même qu'au moment de la création du point de récupération.
Dans cet exemple, nous restaurons le système de fichiers hsmfs1 depuis le fichier de points de récupération /zfs1/hsmfs1_recovery/20140324. Nous enregistrons les fichiers en ligne dans le fichier /root/20140324.log (remarque : la commande ci-dessous est saisie sur une seule ligne ; le saut de ligne est échappé à l'aide de la barre oblique inverse) :
root@solaris:~# samfsrestore -T -f /zfs1/hsmfs1_recovery/20140324 \ -g /root/20140324.log samfsdump statistics: Files: 52020 Directories: 36031 Symbolic links: 0 Resource files: 8 File segments: 0 File archives: 0 Damaged files: 0 Files with data: 24102 File warnings: 0 Errors: 0 Unprocessed dirs: 0 File data bytes: 0 root@solaris:~#
Si vous avez restauré un système de fichiers autonome ne se prêtant pas à l'archivage, les métadonnées du système de fichiers et les données de fichiers qui étaient enregistrées dans le fichier de points de récupération ont été restaurées. Arrêtez la procédure à cette étape.
Dans la plupart des cas, il n'est pas nécessaire de retransférer les fichiers d'un média d'archivage vers le disque suite à la récupération d'un système de fichiers. Les utilisateurs peuvent transférer les fichiers en fonction de leurs besoins en y accédant.
Cette approche donne automatique la priorité au transfert en fonction des besoins de l'utilisateur. Elle optimise la disponibilité du système de fichiers à un moment où il peut avoir été hors ligne pendant un certain temps. Seuls les fichiers requis immédiatement sont transférés. L'effort de transfert total est donc réparti sur l'ensemble d'une période. Les ressources du système de fichiers, telles que les lecteurs, sont ainsi toujours disponibles pour les tâches de haute priorité, telles que l'archivage de nouveaux fichiers et le transfert urgent des données utilisateurs requises.
Cette approche réduit également les efforts administratifs associés à la récupération.
Si vous devez retransférer les fichiers qui résidaient sur le cache disque avant une panne, utilisez la commande /opt/SUNWsamfs/examples/restore.sh logfile, où logfile est le chemin et le nom du fichier journal créé à l'aide de l'option -g de la commande samfsrestore (qfsrestore).
Le script restore.sh transfère les fichiers répertoriés dans le fichier journal. Il s'agit des fichiers qui étaient en ligne lors de la création du fichier de points de récupération samfsrestore (qfsrestore).
Si des milliers de fichiers doivent être transférés, essayez de partager le fichier journal en deux fichiers de taille inférieure. Exécutez ensuite alternativement le script restore.sh avec chaque fichier. Le transfert est ainsi réparti sur une période de temps ce qui réduit les interférences dues à l'archivage et aux demandes de transfert des utilisateurs.
Maintenant, identifiez les fichiers endommagés et localisez les copies de remplacement.
Le processus samfsrestore restaure une copie des métadonnées du système de fichiers d'un fichier de point de récupération, de sorte que vous pouvez trouver les données du système de fichiers correspondant sur la bande et les restaurer à leur bon emplacement dans le système de fichiers. Des fichiers du point de récupération sont cependant créés avant la perte du système de fichiers. Certaines métadonnées pointent donc inévitablement vers les emplacements de données ayant été modifiés depuis la création du point de récupération. Le système de fichiers contient un enregistrement de ces fichiers mais ne peut pas localiser leur contenu. Il définit donc l'indicateur endommagé sur chaque fichier de ce type.
Dans certains cas, les données d'un fichier endommagé peuvent être perdues. Cependant, dans d'autres cas, les métadonnées restaurées sont simplement obsolètes. Le système de fichiers restauré peut ne pas parvenir à trouver les données des fichiers archivés ou migrés après la création du point de récupération simplement du fait que les métadonnées restaurées ne sont pas enregistrées dans un emplacement actuel. Dans ces cas, il se peut que vous puissiez réparer les fichiers en localisant les données vous-même et en mettant ensuite à jour les métadonnées restaurées.
Utilisez le fichier journal de l'archiveur ou les fichiers journaux de migration des médias (le cas échéant) pour localiser les données manquantes, mettre à jour les métadonnées et réparer les fichiers. Procédez comme suit :
Si ce n'est pas déjà fait, connectez-vous au serveur de métadonnées du système de fichiers en tant qu'utilisateur root.
root@solaris:~#
Identifiez le dernier fichier journal de l'archiveur disponible.
Si le journal de l'archiveur situé sur le serveur est toujours disponible, il est susceptible de contenir les informations les plus récentes. Si ce n'est pas le cas, utilisez une copie de sauvegarde.
Dans cet exemple, le fichier journal de l'archiveur hsmfs1.archiver.log se trouve sur le serveur, dans le sous-répertoire /var/adm/. Nous avons également daté les copies de fichiers journaux d'archiveur dans un emplacement connu, le sous-répertoire hsmfs1_recovery/archlogs sur le système de fichiers indépendant /zfs1. Deux versions du dernier fichier sont donc disponibles hsmfs1.archiver.log, ainsi qu'une sauvegarde récente, 20150324 :
root@solaris:~# dir /var/adm/*.archiver.log hsmfs1.archiver.log root@solaris:~# dir /zfs1/hsmfs1_recovery/archivelogs 20150322 20150323 20150324 root@solaris:~#
Si les fichiers ont été migrés récemment vers le média de remplacement, localisez également les journaux de migration.
Les journaux de migration des médias sont créés pour chaque volume source dans le répertoire de consignation spécifié par le fichier migrationd.cmd. Les noms des journaux sont : media-type.vsn, où media-type est l'un des codes à deux chiffres décrit dans Annexe B, Glossaire des types d'équipement et vsn est le numéro de série du volume alphanumérique à six caractères du volume source.
Le format des journaux de migration des médias contient les mêmes informations de récupération que les journaux de l'archiveur, elles peuvent être utilisées de la même façon. Pour une description des quelques différences de format, reportez-vous à Annexe A, Compréhension des journaux de migration et de l'archiveur.
Dans le système de fichiers récemment restauré, identifiez tout fichier endommagé. Exécutez la commande sfind mountpoint -damaged, où mountpoint est le répertoire où le système de fichiers récupéré est monté.
Dans cet exemple, la recherche commence dans le répertoire /hsmfs1 où six fichiers endommagés sont trouvés :
root@solaris:~# sfind /hsmfs1 -damaged ./genfiles/ay0 ./genfiles/ay1 ./genfiles/ay2 ./genfiles/ay5 ./genfiles/ay6 ./genfiles/ay9 root@solaris:~#
Recherchez les entrées associées à chaque fichier endommagé dans la dernière copie du journal de l'archiveur. Exécutez la commande grep "file-name-expression" archiver-log, où file-name-expression est une expression régulière correspondant au fichier endommagé et où archiver-log est le chemin d'accès et le nom de la copie du journal de l'archiveur que vous examinez.
Dans cet exemple, nous utilisons l'expression régulière genfiles\/ay0 pour rechercher les entrées associées au fichier genfiles/ay0 dans le fichier journal le plus récent :
root@solaris:~# grep "genfiles\/ay0 " /var/adm/hsmfs1.archiver.log
Lorsque vous trouvez une entrée pour un fichier, notez le type de média, le numéro de série du volume et la position du fichier archive (tar) où le fichier de données est archivé. Notez également le type de fichier qui aura une incidence sur la méthode de restauration du fichier.
Dans cet exemple, nous localisons une entrée pour le fichiergenfiles/ay0. L'entrée de journal indique qu'elle a été archivée (A) le 4 mars 2015 à 21h49 à l'aide de LTO (li) volume VOL012. Le fichier est enregistré dans le fichier d'archive de bande situé à la position hexadécimale 0x78 (78). Il s'agit d'un fichier standard ; saisissez f :
root@solaris:~# grep "genfiles\/ay0 " /var/adm/hsmfs1.archiver.log A 2015/03/04 21:49:15 li VOL012 SLOT12 allsets.1 78.1 hsmfs1 7131.14 8087 genfiles/ay0 f 0 51 root@solaris:~#
Pour une explication complète concernant les champs des entrées du journal de l'archiveur, reportez-vous à l'Annexe A, Compréhension des journaux de migration et de l'archiveur.
Si vous ne trouvez pas d'entrée pour un fichier endommagé dans la copie active du journal de l'archiveur, recommencez la recherche dans les journaux de l'archive de sauvegarde créés après la génération du fichier de points de récupération.
Les journaux de l'archiveur sont fréquemment purgés. Par conséquent, si vous conservez plusieurs copies du journal de l'archiveur, vous devrez peut-être récupérer les fichiers endommagés à l'aide des copies d'archive créées avant la période couverte par le journal de l'archiveur actif.
Ensuite, recherchez les fichiers qui ont été archivés après la création du point de récupération.
Le processus samfsrestore restaure une copie des métadonnées du système de fichiers d'un fichier de point de récupération, de sorte que vous pouvez trouver les données du système de fichiers correspondant sur la bande et les restaurer à leur bon emplacement dans le système de fichiers. Des fichiers du point de récupération sont cependant créés avant la perte du système de fichiers. Ils ne peuvent pas contenir de métadonnées pour les fichiers créés et archivés après leur création.
En règle générale, des fichiers sont archivés après la création du dernier point de récupération et avant la perte d'un système de fichiers. Les métadonnées de ces fichiers ne se trouvant pas dans le fichier de point de récupération, samfsrestore ne peut pas les récupérer, même sous forme de fichiers endommagés. Toutefois, les fichiers de données se situent sur un média d'archivage. Vous pouvez donc recréer les métadonnées et récupérer les fichiers à leur bon emplacement dans le système de fichiers à l'aide des journaux d'archive. Si les fichiers ont été migrés vers le média de remplacement avant la perte du système de fichiers, vous pouvez également utiliser les journaux de migration des médias.
Si ce n'est pas déjà fait, connectez-vous au serveur de métadonnées du système de fichiers en tant qu'utilisateur root.
root@solaris:~#
Identifiez le dernier fichier journal de l'archiveur disponible.
Si le journal de l'archiveur situé sur le serveur est toujours disponible, il est susceptible de contenir les informations les plus récentes. Si ce n'est pas le cas, utilisez une copie de sauvegarde.
Dans cet exemple, le fichier journal de l'archiveur hsmfs1.archiver.log se trouve sur le serveur, dans le sous-répertoire /var/adm/. Nous avons également daté les copies de fichiers journaux d'archiveur dans un emplacement connu, le sous-répertoire hsmfs1_recovery/archlogs sur le système de fichiers indépendant /zfs1. Deux versions du dernier fichier sont donc disponibles hsmfs1.archiver.log, ainsi qu'une sauvegarde récente, 20150324 :
root@solaris:~# dir /var/adm/*.archiver.log hsmfs1.archiver.log root@solaris:~# dir /zfs1/hsmfs1_recovery/archivelogs 20150322 20150323 20150324 root@solaris:~#
Si les fichiers ont été migrés récemment vers le média de remplacement, localisez également les journaux de migration.
Les journaux de migration des médias sont créés pour chaque volume source dans le répertoire de consignation spécifié par le fichier migrationd.cmd. Les noms des journaux sont : media-type.vsn, où media-type est l'un des codes à deux chiffres décrit dans Annexe B, Glossaire des types d'équipement et vsn est le numéro de série du volume alphanumérique à six caractères du volume source.
Le format des journaux de migration des médias contient les mêmes informations de récupération que les journaux de l'archiveur, elles peuvent être utilisées de la même façon. Pour une description des quelques différences de format, reportez-vous à Annexe A, Compréhension des journaux de migration et de l'archiveur.
Recherchez les entrées créées après le point de récupération dans la dernière copie en date du journal de l'archiveur. Exécutez la commande grep "time-date-expression" archiver-log, où time-date-expression est une expression régulière correspondant à la date et l'heure à laquelle vous souhaitez démarrer la recherche et où archiver-log est le chemin d'accès et le nom de la copie du journal de l'archiveur que vous examinez.
Dans cet exemple, nous avons perdu le système de fichiers à 2h02 le 24 mars 2015. Le dernier fichier de point de récupération a été créé à 2h10 le 23 mars 2015. Nous utilisons donc l'expression régulière ˆA 2015\/03\/2[45] pour rechercher des fichiers archivés enregistrés le 23 ou le 24 mars dans le fichier journal le plus récent :
root@solaris:~# grep "ˆA 2015\/03\/2[34]" /var/adm/hsmfs1.archiver.log
Lorsque vous trouvez une entrée correspondante à la copie d'archive d'un fichier non restauré, notez le chemin d'accès, le nom et le type du fichier, le type de média ainsi que les informations d'emplacement.
Les types de fichiers sont répertoriés en tant que f pour les fichiers standard, R pour les fichiers de média amovible ou S pour un segment de données dans un fichier segmenté. Le type de média est un code à deux caractères (voir l'Annexe B, Glossaire des types d'équipement).
Pour localiser la copie de sauvegarde, vous devez disposer du numéro de série du volume de média où la copie est stockée. Si la copie est stockée sur un média à accès séquentiel, une bande magnétique par exemple, notez également la valeur hexadécimale qui représente la position de départ du fichier archive (tar). Si la copie est stockée sur un média à accès aléatoire, un disque d'archive par exemple, notez le chemin et le nom du fichier tar par rapport au numéro de série de volume. Enfin, si le fichier est segmenté, notez la longueur du segment.
Dans l'exemple ci-dessous, les entrées du journal de l'archiveur indiquent que les fichiers suivants ont été archivés après la création du dernier point de récupération :
root@solaris:~# grep "ˆA 2015\/03\/2[34]" /var/adm/hsmfs1.archiver.log A 2015/03/23 10:43:18 li VOL002 all.1 111.1 hsmfs1 1053.3 69 genfiles/hops f 0 0 A 2015/03/23 10:43:18 li VOL002 all.1 111.3 hsmfs1 1051.1 104 genfiles/anic f 0 0 A 2015/03/23 13:09:05 li VOL004 all.1 212.1 hsmfs1 1535.2 1971 genfiles/genA0 f 0 0 A 2015/03/23 13:09:06 li VOL004 all.1 212.20 hsmfs1 1534.2 1497 genfiles/genA9 f 0 0 A 2015/03/23 13:10:15 li VOL004 all.1 212.3f hsmfs1 1533.2 6491 genfiles/genA2 f 0 0 A 2015/03/23 13:12:25 li VOL003 all.1 2.5e hsmfs1 1532.2 17717 genfiles/genA13 f 0 0 A 2015/03/23 13:12:28 li VOL003 all.1 2.7d hsmfs1 1531.2 14472 genfiles/genA4 f 0 0 A 2015/03/23 13:12:40 li VOL003 all.1 2.9c hsmfs1 1530.2 19971 genfiles/genA45 f 0 0 A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.2e9 hsmfs1 1511.2 8971 socfiles/spcC4 f 0 0 A 2015/03/23 21:49:15 dk DISKVOL1/f2 all.1 2.308 hsmfs1 1510.2 7797 spcfiles/spcC5 f 0 0 A 2015/03/23 14:01:47 li VOL013 all.1 76a.1 hsmfs1 14.5 10485760 bf/dat011/1 S 0 51 A 2015/03/23 14:04:11 li VOL013 all.1 76a.5002 hsmfs1 15.5 10485760 bf/dat011/2 S 0 51 A 2015/03/23 14:06:24 li VOL013 all.1 1409aa4.1 hsmfs1 16.5 184 bf/dat011/3 S 0 51 A 2015/03/23 18:28:51 li VOL036 all.1 12d.1 hsmfs1 11731.1 89128448 rf/rf81 f 0 210 A 2015/03/23 18:28:51 li VOL034 all.1 15f.0 hsmfs1 11731.1 525271552 rf/rf81 f 1 220 root@solaris:~#
Nous remarquons les informations suivantes :
Huit fichiers (de type f) standard sont archivés (A) sur le média LTO (li) : genfiles/hops et genfiles/anic à l'emplacement 0x111 du volume VOL002, genfiles/genA0, genfiles/genA9 et genfiles/genA2 à l'emplacement 0x212 du volume VOL004, ainsi que genfiles/genA13, genfiles/genA4 etgenfiles/genA45 à l'emplacement 0x212 du volume VOL003.
Deux fichiers (de type f) standard sont archivés (A) sur le média d'archive (dk) : spcfiles/spcC4 et spcfiles/spcC5, dans le fichier archive DISKVOL1 \f2 du volume DISKVOL1.
Un fichier (de type S) segmenté en trois parties est archivé sur le média (li) LTO : bf/dat011, la segmentation en deux parties démarre à la position 0x76a et la segmentation en une partie commence à la position 1409aa4 sur le volume VOL013. La longueur du segment /1 est 10485760 octets, celle du segment /2 est 10485622 octets et celle du segment /3 est 184 octets.
Un fichier de dépassement de volume (de type f) est archivé (A) sur le média LTO (li) : rf/rf81, il commence à la position 0x12d sur le volume VOL036 et poursuit à la position 0x15f sur le volume VOL034.
Pour une explication complète concernant les champs des entrées du journal de l'archiveur, reportez-vous à l'Annexe A, Compréhension des journaux de migration et de l'archiveur.
Recommencez la recherche à l'aide de l'un des journaux d'archive de sauvegarde créé après la création du fichier de points de récupération.
Les journaux de l'archiveur sont fréquemment purgés. Par conséquent, si vous conservez plusieurs copies du journal de l'archiveur, vous devrez peut-être récupérer les fichiers endommagés à l'aide des copies d'archive créées avant la période couverte par le journal de l'archiveur actif.
Maintenant, restaurez les fichiers endommagés et/ou manquants.
En raison du volume de média et de la position d'un fichier d'archive (tar) sur le média, la restauration d'un fichier manquant ou endommagé revient à accéder au fichier tar et à l'extraire du fichier de données requis. Lorsque les fichiers archive se trouvent sur des périphériques de disque d'archive, la restauration est simple car les fichiers tar se trouvent dans des répertoires à accès aléatoire sous un point de montage du système de fichiers. Toutefois, lorsque le fichier tar se trouve sur un média à accès séquentiel haute capacité tel qu'un lecteur, une complication supplémentaire existe : il n'est pas possible d'extraire le fichier de données requis normalement à partir du fichier archive tant que celui-ci n'a pas été transféré vers un périphérique de disque à accès aléatoire. En raison du volume significatif de certains fichiers archive, cette opération peut prendre du temps et s'avérer gênante en cas de récupération. Les procédures ci-dessous utilisent la commande request de Oracle HSM, qui permet de lire les fichiers archive dans la mémoire et de les rendre disponibles comme s'ils étaient lus à partir du disque.
Restaurez autant de fichiers standard endommagés et manquants que possible. Pour chaque fichier, procédez comme suit :
Commencez par récupérer les fichiers standard qui ne sont pas répartis sur plusieurs volumes. Suivez la procédure décrite à la Restauration des fichiers standard perdus et endommagés
Récupérez ensuite les fichiers segmentés. Suivez la procédure décrite à la Restauration des fichiers segmentés perdus et endommagés
Puis, restaurez les fichiers standard qui ne sont pas répartis sur plusieurs volumes. Suivez la procédure décrite à la Restauration des fichiers de dépassement de volume perdus ou endommagés
Une fois que vous avez restauré tous les fichiers manquants et endommagés ayant des copies, réactivez l'archivage en supprimant les directives wait du fichier archiver.cmd. Réactivez le recyclage en supprimant les paramètres -ignore du fichier recycler.cmd.
Le système de fichiers doit être aussi proche de son état initial que possible. Les fichiers qui sont toujours endommagés ou manquants ne peuvent pas être récupérés.
Une fois que vous avez restauré tous les fichiers manquants et endommagés disposant de copies, passez à la Restauration des systèmes de fichiers d'archivage pour un fonctionnement normal
Vous avez la possibilité de récupérer un système de fichiers directement à partir du média d'archivage, sans l'assistance d'un fichier de points de récupération. Procédez comme suit :
Si vous tentez de restaurer des fichiers à partir d'un média optique, arrêtez-vous à ce stade et contactez les services de support d'Oracle pour obtenir de l'aide.
Désactivez le partage du système de fichiers réseau (NFS) pour le système de fichiers.
Désactivez l'archivage et le recyclage. Suivez ensuite la méthode présentée à la section Arrêt des processus d'archivage et de recyclage.
Réservez un lecteur de bande à l'usage exclusif du processus de récupération. Exécutez la commande samcmd unavail drive-equipment-number, où drive-equipment-number est le nombre ordinal d'équipement affecté au lecteur dans le fichier /etc/opt/SUNWsamfs/mcf.
La commande samcmd unavail rend le disque indisponible pour les processus d'archivage, de transfert et de libération. Dans cet exemple, le lecteur 804 est réservé
root@solaris:~# samcmd unavail 804 root@solaris:~#
Copiez le fichier /opt/SUNWsamfs/examples/tarback.sh à un autre emplacement, par exemple /tmp.
Le fichier tarback.sh est un script exécutable qui restaure les fichiers à partir d'un ensemble de volumes de média spécifié. Le script exécute la commande star -n dans chaque fichier d'archive (tar) sur chaque volume. Lorsqu'une copie de sauvegarde sur bande ne contient pas de fichier correspondant dans le système de fichiers ou lorsque la copie sur bande est plus récente que le fichier correspondant dans le système de fichiers, star -n restaure la copie.
Dans cet exemple, le script a été copié dans /tmp :
root@solaris:~# cp /opt/SUNWsamfs/examples/tarback.sh /tmp/tarback.sh root@solaris:~#
Ouvrez la copie du fichier tarback.sh dans un éditeur de texte.
Dans cet exemple, nous utilisons l'éditeur de texte vi :
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh #!/bin/sh # script to reload files from SAMFS archive tapes STAR="/opt/SUNWsamfs/sbin/star" LOAD="/opt/SUNWsamfs/sbin/load" UNLOAD="/opt/SUNWsamfs/sbin/unload" EQ=28 TAPEDRIVE="/dev/rmt/3cbn" # BLOCKSIZE is in units of 512 bytes (e.g. 256 for 128K) BLOCKSIZE=256 MEDIATYPE="lt" VSN_LIST="VSNA VSNB VSNC VSNZ" ...
Si les utilitaires Oracle HSM star, load et unload sont installés dans des emplacements non standard, modifiez les chemins d'accès de commande par défaut dans la copie du fichier tarback.sh.
Dans l'exemple, tous les utilitaires sont installés dans les emplacements par défaut, par conséquent, aucune modification n'est nécessaire :
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh #!/bin/sh # script to reload files from SAMFS archive tapes STAR="/opt/SUNWsamfs/sbin/star" LOAD="/opt/SUNWsamfs/sbin/load" UNLOAD="/opt/SUNWsamfs/sbin/unload" ...
Dans la copie du fichier tarback.sh, localisez la variable EQ. Définissez sa valeur sur le nombre ordinal d'équipement du lecteur que vous avez réservé pour la récupération.
Dans l'exemple, nous définissons EQ=804 :
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
# script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
...
Dans la copie du fichier tarback.sh, localisez la variable TAPEDRIVE. Définissez sa valeur sur le chemin d'accès brut au périphérique, entre guillemets.
Dans cet exemple, le chemin d'accès brut au périphérique 804 est /dev/rmt/3cbn :
root@solaris:~# vi /opt/SUNWsamfs/examples/tarback.sh
#!/bin/sh
# script to reload files from SAMFS archive tapes
STAR="/opt/SUNWsamfs/sbin/star"
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
...
Dans la copie du fichier tarback.sh, localisez la variable BLOCKSIZE. Définissez sa valeur sur le nombre d'unités 512 octets dans la taille de bloc souhaitée.
Dans cet exemple, nous souhaitons avoir une taille de segment de 256 kilo-octets pour le lecteur LTO-4. La valeur 512 est donc indiquée :
LOAD="/opt/SUNWsamfs/sbin/load"
UNLOAD="/opt/SUNWsamfs/sbin/unload"
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
...
Dans la copie du fichier tarback.sh, localisez la variable MEDIATYPE. Définissez sa valeur sur le code de type de média à deux caractères que Annexe B répertorie pour le type de média pris en charge par le lecteur. Placez le type de média entre guillemets doubles.
Dans cet exemple, un lecteur LTO-4 est utilisé. La valeur li est donc indiquée :
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="li"
...
Dans la copie du fichier tarback.sh, localisez la variable VSN_LIST. Pour sa valeur, indiquez une liste de valeurs séparées par des espaces pour les numéros de série de volume (VSN) identifiant les bandes pouvant contenir des copies de sauvegarde de vos fichiers. Mettez la liste entre guillemets.
Dans cet exemple, les volumes VOL002, VOL003, VOL004, VOL013, VOL034 et VOL036 sont spécifiés :
EQ=804 TAPEDRIVE="/dev/rmt/3cbn" BLOCKSIZE=512 MEDIATYPE="lt" VSN_LIST="VOL002 VOL003 VOL004 VOL013 VOL034 VOL036" ...
Enregistrez la copie du fichier tarback.sh. Fermez l'éditeur.
EQ=804
TAPEDRIVE="/dev/rmt/3cbn"
BLOCKSIZE=512
MEDIATYPE="lt"
VSN_LIST="VOL002 VOL003 VOL004 VOL013 VOL034 VOL036"
...
:wq
root@solaris:~#
Exécutez le script /tmp/tarback.sh.
root@solaris:~# /tmp/tarback.sh
Pour chaque fichier restauré, recréez si nécessaire la propriété, les modes, les attributs étendus et les listes de contrôle d'accès (ACL) des utilisateurs et des groupes.
Le script /tmp/tarback.sh ne peut pas restaurer ces types de métadonnées.
Une fois que vous avez exécuté le script /tmp/tarback.sh et achevé la récupération des fichiers, passez à la Restauration des systèmes de fichiers d'archivage pour un fonctionnement normal.