2 Concepts d'Oracle DIVArchive

Ce chapitre décrit les différents concepts utilisés dans le système DIVArchive.

Objets

Chaque ressource archivée dans DIVArchive est un objet.

Un objet est un conteneur logique DIVArchive pour tous les fichiers qui composent une ressource à partir d'une source originale. Les ressources de certaines sources peuvent avoir des fichiers vidéo, audio et de métadonnées distincts. Lorsqu'ils sont archivés dans DIVArchive, tous ces fichiers sont référencés comme un seul objet. Quand l'objet est restauré vers une destination, tous les fichiers qui étaient initialement associés à cette ressource sont automatiquement restaurés par DIVArchive.

Un objet est identifié dans DIVArchive par son nom et sa catégorie. Le nom de l'objet ne doit pas forcément correspondre à celui du fichier source qui est archivé. DIVArchive restaure toujours les fichiers tels qu'ils ont été archivés, quel que soit le nom de l'objet DIVArchive. Le même fichier source peut donc être archivé plusieurs fois dans la même catégorie, si chaque instance a un nom d'objet unique.

Une fois qu'un objet existe dans DIVArchive, il ne peut pas être remplacé sans être d'abord supprimé. Si une demande d'archivage utilise les mêmes nom et catégorie qu'un objet existant, DIVArchive arrête automatiquement la demande. En revanche, plusieurs copies (ou instances) d'un objet peuvent être créées une fois que la ressource est archivée.

Si une ressource source doit être stockée dans divers formats d'encodage (par exemple, MPEG2 Long GOP, DV50, ou proxies à basse résolution), vous pouvez utiliser des catégories spécifiques pour archiver le même objet en fonction de son format d'encodage.

Objets complexes

Quand la fonction Base des métadonnées est activée, la fonction Objet complexe est disponible. DIVArchive peut effectuer le suivi de plus de 10 000 fichiers par limite d'objets définie pour des objets non complexes à l'aide d'objets complexes. Le volume réel varie en fonction de la puissance de traitement et de la capacité de stockage du système. Un objet complexe stocke un plus grand nombre d'informations sur les fichiers et dossiers dans une archive, notamment les sous-totaux pour chaque répertoire.

Quand un objet est archivé, DIVArchive détermine si le nouvel objet doit être complexe ou non complexe en fonction du nombre de ses composants (fichiers). Si le nombre de composants est supérieur à 1 000 (seuil configurable d'objet complexe par défaut), l'objet devient un objet complexe : sinon, l'objet est non complexe. Une fois qu'un objet est considéré comme complexe, il le restera toujours, même s'il est copié à l'aide de la commande Copy As ou importé à l'aide de l'utilitaire d'exportation/d'importation d'Oracle DIVArchive.

Objets complexes et non complexes

Un objet complexe se distingue d'un objet non complexe de plusieurs façons. Par exemple, les informations de métadonnées de fichier et de dossier d'un objet complexe sont stockées dans un fichier et non dans la base de données Oracle. Le fichier contient les noms de fichier, les noms de dossier, les checksums et les tailles des fichiers. Le répertoire qui contient ces fichiers est le répertoire racine de la base des métadonnées. La section suivante explique comment configurer ce paramètre. Un objet complexe doit être stocké au format AXF sur bande ou sur disque.

Un objet complexe peut contenir des centaines de milliers de fichiers. Dans l'interface graphique (GUI) de contrôle de DIVArchive, le jeu complet des fichiers d'une bande ne s'affiche pas dans les boîtes de dialogue des propriétés d'objet et de bandes. Un seul fichier d'espace réservé s'affiche pour représenter l'objet complexe.

Toutes les opérations DIVArchive ne sont pas prises en charge pour les objets complexes. Par exemple, la fonction Delete on Source est désactivée pour les objets complexes. Les fonctions checksum Verify on Archive et Verify on Restore sont également désactivées pour les objets complexes. Oracle DIVAnet ne prend pas actuellement en charge la réplication des objets complexes.

Certaines opérations d'API DIVArchive utilisées dans Oracle DIVArchive Avid Connectivity (telles que GetByFilename et DeleteByFilename) ne sont actuellement pas prises en charge pour les objets complexes.

Un objet complexe tient à jour des informations sur les fichiers et dossiers dans l'archive. Les objets complexes stockent les sous-totaux pour chaque dossier, notamment le nombre total de fichiers et de sous-répertoires du dossier ainsi que la taille totale de tous les fichiers du dossier et des éventuels sous-dossiers.

Le paramètre de seuil d'objet complexe est configurable et est utilisé par DIVArchive pour déterminer si un nouvel objet doit être considéré comme complexe. Si un nouvel objet a de nombreux composants (fichiers) qui dépassent le seuil, l'objet devient automatiquement un objet complexe. Cette valeur est définie dans le fichier de configuration manager.conf. Oracle recommande de conserver la valeur par défaut (1 000 composants) pour le seuil, sauf s'il existe une raison spécifique de modifier cette valeur.

Base des métadonnées

Pour traiter avec efficacité de larges volumes de fichiers et dossiers et d'autres métadonnées, DIVArchive stocke les métadonnées séparément de la base de données Oracle dans la base des métadonnées DIVArchive. La base des métadonnées DIVArchive contient les fichiers stockés dans un système de fichiers local sur DIVArchive Manager. Le répertoire qui contient ces fichiers est le répertoire racine de la base des métadonnées.

La base des métadonnées offre des performances très élevées et une évolutivité quasi illimitée. La base des métadonnées doit être traitée avec la même circonspection que la base de données Oracle : elle doit être sauvegardée à intervalles réguliers à l'aide de DIVArchive Backup Service.

Objets complexes et FTP

Lors de l'archivage d'objets complexes avec le protocole FTP et FileZilla configuré avec les paramètres par défaut, le transfert échoue généralement lors de l'archivage d'un objet contenant environ 3 900 fichiers. Deux raisons peuvent expliquer cet échec potentiel :

La connexion du composant Actor expire avant que la taille de l'objet puisse être calculée.
Une demande s'arrête au milieu du transfert car le serveur FTP (FileZilla par exemple) consomme tous les sockets disponibles.

Remarque :
Oracle ne prend en charge que les serveurs FTP basés sur Linux pour les systèmes DIVArchive s'exécutant dans l'environnement Linux et non les serveurs FileZilla et IIS FTP.

Vous pouvez résoudre le problème d'expiration de la connexion du composant Actor en définissant les deux paramètres suivants dans les options de commande de source/destination ou dans les options de la commande elle-même comme suit :

-transfer_timeout 1200
-list_timeout 600

Oracle recommande également de définir les paramètres correspondants dans le serveur FileZilla sous les paramètres généraux :

Connections Timeout = 600
No Transfer Timeout = 1200 (this is the default)

Si une interruption se produit, ce qui peut arriver pendant un transfert, vous pouvez créer (en général) ou modifier deux paramètres de registre :

TcpTimedWaitDelay = 10
MaxUserPort = 90000

Oracle recommande de contacter le support technique Oracle pour plus d'informations sur ces paramètres ainsi que pour les modifications à apporter au registre concernant l'ordinateur et le serveur FTP si vous ne disposez pas de personnel qualifié sur site.

Transferts WAN d'objets complexes Oracle DIVAnet

DIVArchive 7.5 comporte une fonctionnalité d'accélération WAN (facultative) intégrée qui lui permet de tirer pleinement parti des chemins réseau longue distance à latence élevée (tels que les liens de site à site privés ou l'Internet public), et peut effectuer des transferts d'objets complexes efficacement à l'aide du protocole Data Expedition MTP/IP.

Exemple :

La procédure se présente comme suit :

DIVA1 restaure l'objet complexe sur le système DIVA2 en créant d'abord un nouveau fichier AXF sur le serveur Data Expedition du système DIVA2.
DIVA1 restaure tous les fichiers du stockage local vers le nouveau fichier AXF créé sur le serveur Data Expedition du système DIVA2.
Le système DIVA2 crée un nouveau fichier AXF sur la destination (bande, disque, etc.).
Le système DIVA2 archive tous les fichiers à partir du fichier AXF (créé par le serveur Data Expedition du système DIVA1) vers le nouveau fichier AXF créé sur la destination.

Reportez-vous au Guide d'installation, de configuration et d'opérations d'Oracle DIVAnet fourni dans la bibliothèque Documentation DIVAnet ou contactez le support technique Oracle pour plus d'informations ou obtenir de l'aide (le cas échéant).

Formats de stockage de média

Cette section décrit les formats de média disponibles dans DIVArchive.

Formats de stockage de disque et de bande AXF

Archive Exchange Format (AXF) est un format ouvert qui prend en charge l'interopérabilité entre différents systèmes de stockage de contenus et assure la disponibilité à long terme des contenus, quelle que soit l'évolution de la technologie de stockage ou de système de fichiers.

Un objet AXF est un conteneur de fichier informatique qui encapsule n'importe quel nombre et type de fichiers dans un package autonome et auto-documenté. Le package encapsulé contient son propre système de fichiers interne, qui protège vos données sensibles du système d'exploitation et de la technologie de stockage sous-jacents. Il opère comme un système de fichiers dans un fichier pouvant stocker tout type de données sur tout type de média de stockage.

Identification de version AXF

DIVArchive Actor peut lire des instances au format AXF 0.9 et AXF 1.0, mais peut uniquement écrire au format AXF 1.0. DIVArchive affiche le niveau de version AXF utilisé par une instance. Dans l'interface graphique (GUI) de contrôle, le format de média pour une instance sera Legacy (Hérité), AXF 0.9 ou AXF 1.0. Les bandes, les groupes et les baies configurés au format AXF resteront au format AXF car ces médias peuvent contenir des instances AXF de version 0.9 ou 1.0.

Format de média de stockage

Dans DIVArchive, un groupe de bandes ou une baie de disques comporte un paramètre Media Format qui indique le format du média de stockage à utiliser lors de la création de nouveaux objets archivés. Ce paramètre peut être défini en fonction du format Legacy de DIVArchive ou du format AXF. Vous pouvez modifier ce paramètre à tout moment car il n'a aucune incidence sur le contenu déjà stocké. Il est donc possible d'avoir plusieurs formats de média de stockage dans des groupes de bandes et baies de disques.

Un système DIVArchive écrit une instance d'objet dans un seul et unique format de média. Ainsi, si un objet est fragmenté sur plusieurs bandes, chaque bande utilisée dans le cadre d'une instance d'objet sera écrite dans le même format de média. Dans DIVArchive 7.5, un objet peut contenir plusieurs instances, chacune pouvant être stocké au format Legacy ou AXF.

Les objets complexes introduits dans DIVArchive 7.0 doivent être stockés au format AXF. Comme tous les objets complexes sont écrits au format AXF, chaque instance d'un objet complexe sera au format AXF.

Format de média de stockage de bande

Bien qu'un groupe de bandes puisse contenir plusieurs formats de stockage, une bande a (au plus) un format de média de stockage. DIVArchive affecte le format de média bande à une bande vide quand il écrit le premier objet sur cette bande. Le format du groupe de bandes est affecté à la bande qui figure dans la demande. Une fois que le format de média est affecté à une bande, il ne peut pas être modifié à moins que tous les objets de la bande soient supprimés. Après la suppression de tous les objets d'une bande, le format de la bande devient non affecté jusqu'à ce que DIVArchive écrive à nouveau du contenu sur la bande. Si la bande était en cours d'utilisation, le format ne peut pas être modifié tant que la bande n'est pas vide et effacée.

Des bandes aux formats Legacy et AXF peuvent exister dans le même groupe. Les objets au format AXF seront écrits uniquement sur des bandes formatées en AXF et les objets au format Legacy seront écrits uniquement sur des bandes formatées en Legacy même s'ils sont dans le même groupe de bandes.

Dans la version actuelle de DIVArchive, une demande de recompression écrira toujours la bande de destination dans le même format de média que celui de la bande source. De la même façon, les opérations de fragmentation de bande utiliseront toujours le même format pour tous les objets fragmentés de stockage sur bande.

Format de média de stockage de disque

Contrairement aux bandes, les disques n'ont pas un format dédié. DIVArchive permet le stockage des objets dans différents formats de média sur le même disque. Si un disque contient des objets au format Legacy et que ce disque est ensuite affecté à une baie au format AXF, il contiendra toujours des objets au format Legacy. En revanche, les nouveaux objets écrits sur le disque seront au format AXF.

Format de média d'instances d'objet

Un format Legacy ou AXF est affecté à chaque instance d'objet de bande et de disque. Le format d'une instance de bande ou de disque est affecté quand l'instance est créée et est le format de la bande sur laquelle réside l'instance. Toutes les instances d'une bande doivent avoir le même format.

Si une instance de disque est non complexe et permanente (n'est pas une instance de cache), elle est stockée dans le format de la baie de destination. Si une instance de cache est non complexe, elle est stockée dans le format du groupe indiqué dans la demande.

Les groupes ou les baies utilisés par des demandes d'objet complexe doivent être au format AXF car les objets complexes ne peuvent pas être stockés au format Legacy. Toute instance d'un objet complexe sera donc au format AXF.

Vous devez utiliser un travail de migration pour faire passer un format de bande de Legacy à AXF. La recompression d'une bande ne modifiera pas son format. La recompression des objets au format Legacy existant conserve le format de la bande, même si le format du groupe de bandes a été modifié de Legacy en AXF dans la configuration.

Demandes

Une demande est une commande envoyée à DIVArchive pour effectuer une opération. Vous pouvez émettre des demandes au moyen de l'interface graphique (GUI) de contrôle ou d'une application initiatrice d'archivage.

Les types de demande les plus courants concernent le transfert de contenu vers l'archive (demande d'archivage) ou depuis l'archive (demande de restauration ou demande de restauration de fichiers partielle Oracle DIVArchive).

Les autres types de demande permettent de gérer les objets dans l'archive après leur création. Il peut s'agir, par exemple, de demandes de copie, de suppression et de recompression de bande.

Un identifiant unique (appelé ID demande) est automatiquement attribué à chaque demande par DIVArchive. Il peut ensuite être utilisé pour extraire les journaux d'événement ou d'autres propriétés de chaque demande. DIVArchive stocke les enregistrements, jusqu'à 50 000 demandes, dans sa base de données.

Comme de multiples demandes peuvent être reçues simultanément par DIVArchive, elles sont placées dans une file d'attente et sont exécutées sur la base premier arrivé, premier servi. Il est possible de prioriser l'ordre d'exécution des demandes à l'aide du paramètre de priorité de demande. L'écran des demandes actuelles (Current Requests) de la vue Manager (Manager View) dans l'interface graphique (GUI) de contrôle affiche la file d'attente des demandes qui sont en cours de traitement par DIVArchive.

Lors de la restauration d'un même fichier sur la même destination à deux reprises en parallèle, le comportement de Windows et de Linux est différent. Sous Windows, la première restauration (elles ne peuvent pas arriver exactement en même temps) verrouille le fichier afin que la seconde puisse se terminer. Sous Linux, il n'y a aucun verrouillage de ce type au niveau du système de fichiers. Les deux restaurations sont exécutées en même temps et sont écrites dans le même fichier. Le contenu du fichier qui en résulte n'est pas prévisible.

DIVArchive 7.5 offre les options de demande suivantes :

Demandes d'archivage

-delete_on_source

Demandes de restauration

-do_not_overwrite

-do_not_check_existence

-delete_and_write

Les options de demande ont la priorité sur la spécification de service supplémentaire normale. En outre, la spécification de service supplémentaire normale a la priorité sur les options de connexion source/destination.

Vous pouvez également spécifier les services supplémentaires disponibles pour une demande de restauration dans les options de connexion source/destination. S'il est spécifié, la source/destination utilisera le paramètre de service supplémentaire comme valeur par défaut. Vous pouvez remplacer cette valeur en indiquant le service supplémentaire normalement au niveau de la demande ou en tant que nouvelle option de demande. Comme ces options de connexion sont spécifiques d'une demande de restauration, les options sont ignorées pour tout autre type de demande utilisant la source/destination.

Sources et destinations

Une source est définie comme un système connecté ayant du contenu destiné à être transféré vers DIVArchive. Une destination est définie comme un système connecté demandant que du contenu lui soit transféré depuis DIVArchive. Les serveurs Broadcast Video, les serveurs FTP ou le stockage sur disque en sont des exemples.

Les composants Actor dans le système d'exploitation Linux ne prennent pas en charge les chemins UNC pour les sources et destinations CIFS. En revanche, vous pouvez définir un chemin d'accès local pour un partage SMB monté.

Les chemins UNC sont pris en charge pour les sources/destinations SMB et les disques gérés si le chemin UNC est monté directement sur les composants Actor Windows.

Les sources et destinations qui sont utilisées dans les demandes DIVArchive sont prédéfinies dans la configuration DIVArchive et sont accessibles à l'aide du bouton Sources Destinations de l'onglet Home. Dans la configuration Source/Destination de DIVArchive, chaque type de serveur ou système de fichiers de disque a un nom unique et est configuré comme suit :

Source uniquement: DIVArchive archivera uniquement les fichiers du serveur ou du système de fichiers du disque.
Destination uniquement: DIVArchive restaurera uniquement les fichiers vers le serveur ou le système de fichiers du disque.
Source et destination: DIVArchive archivera et restaurera les fichiers depuis ou vers le serveur ou le système de fichiers du disque.

Bien ce guide ne décrive pas en détail la configuration des source ou destination, il la présente succinctement car les source ou destination peuvent influencer la façon dont les demandes sont émises pour elles ainsi que la façon dont deux demandes simultanées ou plus sont gérées dans la file d'attente des demandes actuelles.

En règle générale, les paramètres suivants sont configurés pour les source et destination. Ils sont communs à toutes les demandes qui concernent ces source/destination.

Le type de source est le protocole ou le mode d'accès utilisé lors de l'interaction avec le périphérique cible.
Le nombre maximum de sessions de transfert en lecture et écriture et le nombre total maximum de sessions de lecture/d'écriture combinées. Ces paramètres identifient les limites imposées au nombre de demandes simultanées que DIVArchive exécutera sur le périphérique cible ou en priorisant les opérations (de restauration) en écriture sur les opérations (d'archivage) en lecture.
Définition de la bande passante maximum disponible pour DIVArchive pour les transferts vers ou depuis le périphérique. Ce paramètre peut être utilisé pour limiter les transferts de données quand le périphérique cible est partagé avec d'autres systèmes de production ou applications tierces.
La qualité de service par défaut (QOS). C'est le paramètre QOS utilisé quand la valeur par défaut est spécifiée dans le champ Quality of Service d'une demande.
Définition des options de connexion à fournir (qui peuvent éventuellement être indiquées) pour le protocole ou le mode d'accès propre au périphérique cible. Les options de connexion sont, par exemple, des sous-dossiers récursifs, des noms ou mots de passe utilisateur ou d'autres options spécifiques du type de source sélectionné. DIVArchive ignore ce paramètre si aucune option n'est spécifiée.
Le chemin racine d'accès aux fichiers à archiver sur la source ou à restaurer sur une destination. Ce paramètre est toujours spécifié en tant que chemin de répertoire absolu sur le périphérique cible. Par exemple, c:\Exported\MPEG2 pour les systèmes de fichiers Windows ou /Movies/MPEG2 pour les systèmes de fichiers Linux. La configuration du chemin racine dépend également du type de source ; il peut être laissé vide dans certains cas (et sera ignoré par DIVArchive).

Pour les types de source Local ou Disque, le chemin racine indique le point de montage du périphérique dans le système de fichiers local.

Si les options de connexion et le chemin racine ont été définis pour la configuration de source/destination , ces paramètres peuvent ne pas être adaptés à chaque demande soumise. DIVArchive permet la spécification de ces paramètres dans une demande DIVArchive pour cette source ou destination (au niveau de la demande). Le remplacement de ces attributs Source/Destination dans une demande dépend du type de source. Pour une liste complète des options et chemins et de leur interaction avec les paramètres spécifiés au niveau de la demande, reportez-vous au tableau des sources et destinations DIVArchive figurant dans le document Oracle DIVArchive Installation and Configuration Guide fourni dans la bibliothèque de documentation de base d'Oracle DIVArchive 7.5.

Le chemin racine d'accès aux fichiers spécifié dans une demande peut être ajouté au chemin racine indiqué dans la configuration Source/Destination ou remplacer complètement le chemin racine s'il est spécifié sous forme de chemin absolu.

Intégration de Data Expedition

DIVArchive peut (éventuellement) s'interfacer avec la source/destination nommée Data Expedition Expedat Source/Destination Server. Le serveur Expedat (également appelé servedat) est très similaire au serveur DIVArchive FTP_STANDARD et aux CIFS et offre des fonctions de chiffrement AES. Le protocole utilisé pour les opérations est la grande différence entre les deux.

L'API client Expedat est intégrée à l'ordinateur du composant Actor et le serveur Expedat est intégré à DIVArchive (soit sur l'ordinateur du composant Actor, soit sur un autre serveur du système) à l'instar du serveur et des CIFS FTP_STANDARD. Toutefois, il est plus rapide quand il est utilisé sur des réseaux à latence élevée avec le protocole Data Expedition Expedat MTP (protocole de transfert de fichiers haute performance) qui assure une meilleure utilisation de la bande passante.

Un enregistrement est créé pour chaque serveur Expedat vers ou depuis lequel DIVArchive déplace des données. Bien que la solution initiale de transfert et de restauration pour DIVAnet soit toujours opérationnelle dans DIVArchive 7.5, cette fonctionnalité a été améliorée et inclut maintenant les objets complexes. Grâce à cette nouveauté, deux étapes sont requises pour l'archivage des objets au moyen de DIVAnet contre trois précédemment.

Remarque :

Configuration de la source et de la destination

Un enregistrement est créé pour chaque serveur Expedat vers ou depuis lequel DIVArchive déplace des données. Voici des exemples et des paramètres relatifs aux sources et destinations Expedat :

Adresse IP

C'est l'adresse IP du serveur Expedat.

Exemple :

10.80.114.21

Type de source

Définissez ce paramètre avec la valeur EXPEDAT.

Options de connexion

Les options de connexion sont les suivantes. Certaines sont obligatoires tandis que d'autres sont facultatives.

-login username: Option obligatoire si le serveur est configuré avec des paramètres d'authentification. Par exemple, -login moon.
-pass password: Option obligatoire si le serveur est configuré avec des paramètres d'authentification. Par exemple, -pass ph4!hi4.
-port portNumber: Ce paramètre est requis car il n'existe aucune valeur par défaut. Par exemple, -port 8080.
-license licenseCode: Option obligatoire car il s'agit du numéro de licence Expedat. Par exemple, -license 46FE464A98.
-encryption: Option facultative et il n'y a pas de paramètres supplémentaires. Par exemple, -encryption.
-seq_buffer_size megabytes: Définit la taille de la mémoire tampon interne Data Expedition pour chaque transfert. La valeur par défaut est 16 Mo et est suffisante pour la plupart des transferts. Une mémoire tampon importante permet à Data Expedition de continuer à transférer des données quand l'expéditeur ou le destinataire ne sont pas en mesure de les traiter. Une petite mémoire tampon consomme moins de mémoire. Par exemple, -seq_buffer_size 16.
-exp_maxrate kilobytes: Cette option définit une limite approximative sur le nombre de kilooctets par seconde, par transfert. La valeur par défaut est illimitée mais peut être utilisée comme méthode alternative de contrôle de la bande passante. Par exemple, -exp_maxrate 1024.
-exp_mindatagram bytes: Ce protocole de transfert est sur UDP. Cette option permet de définir une taille minimum pour les données traitées de datagramme de chaque réseau que Data Expedition enverra. Elle vise à empêcher Data Expedition d'envoyer un paquet trop petit sur le réseau. Définissez cette valeur entre 2848 et 8544 lors de l'utilisation d'un chemin réseau très rapide (gigabit ou supérieur) et si chaque périphérique le long du chemin prend en charge les trames Jumbo (MTU 9000). L'utilisation de datagrammes importants peut considérablement réduire le temps système de CPU. En revanche, l'utilisation de ce paramètre sans trames Jumbo pleinement prises en charge peut provoquer de sérieux problèmes de performance ou perte de connectivité. Par exemple, -exp_mindatagram 2848.

Métasource

Le type de source Métasource permet à plusieurs sources/destinations DIVArchive actuellement définies partageant le même stockage en ligne (ou surveillant le même dossier ou serveur FTP pour Drop Folder Monitor) d'être combinées et considérées comme une seule configuration Source/Destination DIVArchive. Cette fonction unique (et facultative) permet à DIVArchive d'assurer automatiquement l'équilibrage de la charge et le basculement en cas d'incident quand une ou plusieurs sources/destinations passent en mode hors ligne.

Quand des demandes sont envoyées à DIVArchive avec une source/destination utilisant un type de source Métasource, chaque demande d'archivage ou de restauration supplémentaire utilisera le serveur suivant dans la liste des métasources. Si le serveur sélectionné par DIVArchive est hors ligne ou rencontre une erreur, DIVArchive tentera automatiquement d'utiliser le serveur suivant dans la liste des métasources. En cas d'échec de transfert par tous les serveurs, la demande s'arrêtera.

Baies, disques et cache

DIVArchive utilise les technologies de disque dur (HDD) pour le stockage des objets DIVArchive et le stockage non persistant lors des transferts de données (cache disque).

Une baie est affectée à chaque disque que DIVArchive utilise. Une baie est une association logique d'un ou de plusieurs disques pour le stockage des objets DIVArchive. Les disques configurés en tant que disques de cache sont également affectés à une baie, généralement nommée CACHE.

Le stockage d'un objet sur un disque dans DIVArchive est identifié par le nom de la baie plutôt que par le nom du disque. DIVArchive alloue automatiquement les objets à deux disques ou plus au sein d'une baie.

Chaque disque d'une baie peut être connecté à un système DIVArchive, soit directement dans le matériel de l'hôte d'un composant Actor, en tant que stockage connecté au réseau (NAS), ou connecté au moyen d'un réseau de stockage (SAN) à l'aide de Fibre Channel. Dans le cas du SAN, il peut avoir recours à un logiciel de partage de système de fichiers supplémentaire sur les hôtes si de multiples composants Actor doivent accéder simultanément au disque.

Les disques d'une baie peuvent être configurés comme suit :

Stockage uniquement: Le disque sera utilisé uniquement pour le stockage des objets DIVArchive. Ces types de disque ont recours à la technologie des niveaux RAID pour assurer la redondance des données et la protection contre les défaillances de disque dur.
Stockage et mise en cache: Le disque sera utilisé pour le stockage des objets DIVArchive ainsi que pour les opérations de mise en cache. Les deux types utiliseront des sous-dossiers distincts sur le disque. Ces types de disque ont recours à la technologie des niveaux RAID pour assurer la redondance des données et la protection contre les défaillances de disque dur.
Mise en cache uniquement: Le disque sera utilisé uniquement pour les opérations de mise en cache, de copie de bande à bande, de fragmentation de bande et de recompression de bande. Ces types de disque peuvent avoir recours à la technologie RAID pour améliorer les performances (par exemple, RAID 0).
Stockage et Nearline: Le disque sera utilisé pour le stockage des objets DIVArchive ainsi que pour les opérations Nearline. Les deux types utiliseront le même sous-dossier sur le disque. Ces types de disque ont recours à la technologie des niveaux RAID pour assurer la redondance des données et la protection contre les défaillances de disque dur.
Mise en cache, stockage et Nearline: Le disque sera utilisé pour le stockage des objets DIVArchive, la mise en cache et les opérations Nearline. Les types Stockage et Nearline utiliseront le même sous-dossier sur le disque. En revanche, le type Mise en cache utilisera un sous-dossier distinct. Ces types de disque ont recours à la technologie des niveaux RAID pour assurer la redondance des données et la protection contre les défaillances de disque dur.

DIVArchive permet également de configurer les disques pour un accès en lecture/écriture, un accès en lecture seule ou pour une désactivation temporaire.

Le système de fichiers de tout disque géré par DIVArchive ne doit jamais être manipulé directement par un gestionnaire de fichiers ou un utilitaire (tel que l'explorateur Windows) ou équivalent. Si les structures ou les fichiers de dossier sont déplacés, renommés ou supprimés, DIVArchive peut alors marquer le disque comme étant Out of Order (défectueux).

Attention :

L'utilisation, quelle qu'elle soit, d'un utilitaire de ce type risque de détruire le système de fichiers du disque.

Les disques sur lesquels un logiciel de partage de fichiers est installé pour fournir un accès hôte partagé (SNFS ou MetaSAN par exemple) peuvent s'afficher en tant que système de fichiers inconnu ou non initialisé pour des utilitaires tels que Windows Disk Manager.

Liens symboliques

Vous pouvez archiver et restaurer des liens symboliques sur Linux dans DIVArchive 7.5. Les liens symboliques ne sont pris en charge que pour le format AXF. Lors de l'utilisation du format LEGACY, DIVArchive signale une erreur si un lien symbolique est détecté pendant le transfert.

Les liens symboliques ne sont pris en charge que pour une source/destination SFTP sous Windows. Vous devez spécifier les options suivantes lors de la configuration du SFTP :

-login [login] -pass [password] -port 22 -socket_block_size 64

DIVArchive sous Linux prend en charge les sources et destinations CIFS, DISK et LOCAL. Les partages réseau CIFS doivent être montés sur chaque composant Actor Linux pour être pris en charge.

Lors de la restauration d'un objet contenant des liens symboliques vers un serveur de destination qui ne les prend pas en charge, ces derniers sont ignorés et ne sont pas créés sur le serveur de destination.

Les liens symboliques créés à l'aide du système d'exploitation Windows ne sont pas pris en charge. Les raccourcis créés à l'aide du système d'exploitation Windows ne sont pas représentés en tant que liens symboliques car ils sont traités comme des fichiers. Seuls les liens symboliques créés sur les plates-formes UNIX sont archivés et représentés en tant que liens symboliques dans DIVArchive.

Dans l'interface graphique (GUI) de contrôle, le type de fichier s'affiche dans la liste Components de l'onglet Properties de la fenêtre Object Properties. Les types possibles sont File (F), Directory (D) et Symbolic Link (S). Les liens symboliques sont également affichés dans la liste Elements de l'onglet Instances de la fenêtre Object Properties et en tant que fichiers dans l'onglet Components de l'écran Object Properties.

Qualité de service

Le paramètre Quality of Service (QOS) définit la façon dont un fichier est transféré depuis et vers une bande DIVArchive, à partir d'une source ou vers une destination. Les options de demande suivantes correspondent à leur qualité de service logique :

-qos_direct_only
-qos_cache_only
-qos_direct_and_cache
-qos_cache_and_direct
-qos_nearline_only
-qos_nearline_and_direct

Les options de demande ont la priorité sur la spécification de qualité de service normale. En outre, la spécification de qualité de service normale a la priorité sur les options de connexion source/destination.

Les valeurs QOS NEARLINE_ONLY et NEARLINE_AND_DIRECT sont désormais prises en charge dans les options de connexion source/destination. Ces options ne sont valides que pour une demande de restauration. DIVArchive ignore le paramètre et la valeur par défaut est appliquée si un serveur source ou de destination avec l'un ou l'autre des paramètres est utilisé dans tout autre type de demande. La valeur QOS n'est plus sensible à la casse et ne doit plus être spécifiée au début des options.

Par exemple, -login test -pass test qos=nearline_only est une option valide.

Les options pour QOS sont définies comme suit :

Direct Only (-qos_direct_only): Les données sont transférées immédiatement vers la source car elles sont lues depuis la bande. Autrement, DIVArchive écrit les données sur la bande immédiatement car elles sont transférées à partir d'une destination. Si aucun service de transfert direct n'est disponible, la demande prend fin.
Cache Only (-qos_cache_only): Les données sont d'abord transférées intégralement vers le stockage du cache depuis la bande, puis transférées vers la destination. Autrement, les données sont d'abord transférées intégralement de la source vers le stockage du cache, puis écrites sur la bande. Si aucun service de cache n'est disponible, la demande prend fin.
Direct and Cache (-qos_direct_and_cache): Si aucun transfert direct n'est disponible, par exemple aucun composant Actor avec transfert direct activé n'est disponible, un transfert de cache est effectué.
Cache and Direct (-qos_cache_and_direct): Si aucun transfert de cache n'est disponible, par exemple aucun composant Actor avec stockage de cache n'est disponible, un transfert direct est effectué.
Nearline Only (-qos_nearline_only): Cette option n'est disponible que pour les demandes Restore et N-Restore. Si une instance de disque Nearline existe, les données sont transférées du disque Nearline vers la destination. Autrement, les données sont d'abord transférées intégralement vers le stockage Nearline sur disque depuis la bande, puis transférées vers la destination. Si aucun service Nearline n'est disponible, la demande prend fin.
Nearline and Direct (-qos_nearline_and_direct): Cette option n'est disponible que pour les demandes Restore et N-Restore. Si aucun transfert Nearline n'est disponible, par exemple aucun composant Actor avec stockage Nearline n'est disponible, un transfert direct est effectué.
Default: La valeur QOS spécifiée dans la configuration de la source ou destination est utilisée.

Si un objet à restaurer comporte des instances de disque et de bande et que les options QOS Cache Only ou Cache and Direct sont utilisées, DIVArchive peut restaurer l'instance de la bande en priorité sur l'instance de disque. Ce comportement dépend du paramètre DIVAMANAGER_CACHE_QOS_USE_DISK dans la configuration DIVArchive Manager. Si ce paramètre a la valeur true, DIVArchive restaurera l'instance de disque, quelle que soit la valeur QOS spécifiée.

Le mode de transfert Cache s'avère particulièrement important pour une utilisation optimale des ressources DIVArchive quand les vitesses de transfert entre les périphériques de bande et la source/destination varient considérablement. Par exemple, si le lecteur de bande de la demande peut écrire des données à une vitesse de 400 Mbits/s, mais que la source ne peut livrer les données qu'à une vitesse de 100 Mbits/s, le lecteur de bande n'atteindra jamais son taux de transfert optimal. A l'aide de la valeur QOS Cache, le fichier peut être transféré intégralement vers le cache d'abord, et le lecteur peut terminer son opération d'écriture à sa vitesse maximale. Ce mode permet d'utiliser le lecteur pour d'autres demandes plus rapidement que le même transfert à l'aide du paramètre QOS Direct.

Si un objet à restaurer comporte une instance de disque, le paramètre QOS Nearline Only ou Nearline and Direct effectuera la restauration depuis cette instance. Si un objet à restaurer comporte uniquement des instances de bande, le paramètre QOS Nearline Only ou Nearline and Direct tente de créer une instance de disque permanente et d'effectuer la restauration depuis cette instance. Chaque restauration Nearline suivante pour le même objet sera bloquée et attendra que le premier processus de restauration crée une instance de disque. Si la première restauration ne parvient pas à créer une instance de disque, le processus se répète avec la tentative de restauration suivante pour créer une instance de disque. Toutes les autres restaurations sont bloquées jusqu'à ce que l'instance de disque soit créée.

Le paramètre QOS par défaut pour les demandes Restore et N-Restore est Nearline and Direct. Si la demande de restauration est une restauration de transcodage ou si le serveur de destination est un serveur Movie2Me, le Manager passera la valeur QOS de la restauration à Direct Only. Les autres types de QOS ne sont pas pris en charge dans ce cas.

Groupes et jeux de bandes

Les disques sont affectés logiquement à des baies pour le stockage des objets, mais les bandes sont associées ensemble logiquement dans des groupes.

Les bandes sont initialement divisées en jeux et un numéro appelé ID jeu leur est affecté. Un ID jeu permet le partitionnement des pools de bandes dans une bibliothèque et de les affecter pour utilisation avec des groupes spécifiques. Un groupe tire parti des pools en affectant un ID jeu au groupe.

Plusieurs groupes peuvent utiliser le même ID jeu. Une bande inutilisée ne fera pas réellement parti d'un groupe quelconque jusqu'à ce DIVArchive écrive le premier objet sur cette bande. Quand tous les objets ont été supprimés d'une bande affectée à un groupe, elle n'est plus affectée à ce groupe et peut être affectée à un autre groupe à l'aide du même ID jeu.

Comme les groupes sont définis par l'utilisateur, ils peuvent varier d'une installation DIVArchive à une autre. La seule exception est le groupe par défaut qui existe dans toutes les installations et ne peut ni être renommé ni supprimé. Dans un système DIVArchive, les groupes sont créés et gérés dans l'onglet Sets, Groups & Media Mapping de l'utilitaire de configuration.

Lorsqu'un ID jeu 99 est affecté à une bande, il indique à DIVArchive que la bande ne doit pas être utilisée et n'est pas liée à l'opération de DIVArchive. Les bandes qui appartiennent à une application non DIVArchive dans un environnement de bibliothèque partagée ou les bandes de nettoyage de la bibliothèque en sont des exemples.

L'illustration suivante montre comment les jeux et les groupes de bandes sont associés et utilisés :

Exemple de configuration de groupes et jeux

Lecteurs ODA de Sony

Les lecteurs ODA ODS-D55U et ODS-D77F de Sony sont pris en charge par DIVArchive depuis la version 7.2. Ce sont des lecteurs optiques Blu-ray et le média est un média WORM utilisant un format UDS. Seuls les objets au format AXF peuvent être écrits sur des disques Blu-ray. Les lecteurs sont contrôlés par le Robot Manager et le média est affiché en tant que cartouche de bande.

Ces lecteurs sont présentés en tant que Unknown Medium Changer sous la section des périphériques Medium Changer dans Windows Device Manager car il n'existe pas de pilotes de périphérique pour eux. Le lecteur lui-même apparaît comme un Optical SCSI Device avec son numéro de modèle et fabricant sous la section Disk Drives.

Six types de média de disque sont disponibles pour utilisation avec les lecteurs optiques de Sony :

SONY-ODC300R
SONY-ODC300RE
SONY-ODC600R
SONY-ODC600RE
SONY-ODC1200RE
SONY-ODC1500R

Utilisation des disques et lecteurs optiques

La liste ci-après fournit des informations supplémentaires relatives à l'utilisation des disques et lecteurs optiques :

Dans l'interface graphique (GUI) de contrôle de DIVArchive, les disques optiques sont présentés dans l'onglet Drives.
Le média non réinscriptible doit être finalisé de sorte qu'aucun espace restant n'est signalé au Manager.
Les objets sont fragmentés lorsqu'il y a 100 Mo restants sur le disque afin qu'il y ait assez d'espace restant pour finaliser le disque. Une fois qu'un objet est fragmenté, le disque est considéré comme plein et est automatiquement finalisé.
Le composant Actor finalise automatiquement les disques lorsqu'il y a 500 Mo d'espace restant (sauf si un objet a été fragmenté) ; toutefois, vous pouvez finaliser un disque manuellement à l'aide de l'utilitaire d'archivage de disque optique.
Si un lecteur est monté manuellement et affiché dans l'explorateur Windows, la valeur numérique au début du nom de fichier de chaque objet identifie l'emplacement de l'objet sur la bande.

Fragmentation de bandes

Quand un groupe de bandes commence à atteindre sa pleine capacité (autrement dit, l'ID jeu associé au groupe n'a plus de bande vierge à exploiter), DIVArchive peut tenter d'optimiser l'utilisation du stockage des bandes existantes du groupe en remplissant l'espace libre restant de chaque bande en segmentant l'objet entre deux bandes ou plus (fragmentation de bandes).

Par défaut, la fonction de fragmentation de bandes est configurée dans le fichier de configuration de DIVArchive Manager pour une fragmentation sur deux bandes. Si un objet ne peut pas être fragmenté en fonction de l'espace libre restant de deux bandes au sein de ce groupe, la demande sera interrompue par DIVArchive. La fragmentation de bandes peut être définie pour un fractionnement sur plus de deux bandes sur votre site ou être désactivée dans le fichier de configuration manager.conf.

Pendant la restauration d'un objet fragmenté, DIVArchive monte toutes les bandes fragmentées associées et réunit automatiquement l'objet fragmenté. Comme il ne peut pas procéder directement, il doit copier tous les segments du fichier fragmenté vers un disque de cache d'abord. En conséquence, la restauration d'un objet fragmenté doit utiliser un paramètre QOS Cache Only ou Cache and Direct. Avec un paramètre QOS Direct, la demande prend fin.

Pour un média non réinscriptible, les objets sont fragmentés lorsqu'il y a 100 Mo restants afin qu'il y ait assez d'espace restant pour que le disque puisse être finalisé. Une fois qu'un objet est fragmenté, le disque est considéré comme plein et est automatiquement finalisé.

Remarque :

La fragmentation de bandes n'est pas compatible avec la fonction Associative Copy.

Mode protégé

Quand une bande est éjectée de la bibliothèque, elle est automatiquement définie avec la valeur Protected Mode (Mode protégé). Quand cet attribut est défini, il empêche l'exécution d'opérations d'archivage futures sur la bande et empêche la bande d'être recompressée.

DIVArchive suppose que lorsqu'une bande préalablement éjectée est réinsérée dans une bibliothèque pour effectuer une opération de restauration, elle sera ensuite éjectée et remise en stockage hors ligne. Sans la fonction Mode protégé, de nouveaux objets DIVArchive pourraient être écrits sur la bande alors qu'elle se trouve temporairement dans la bibliothèque et l'empêcher d'être éjectée sans d'abord déplacer ces objets requis vers une autre bande.

Aucune opération d'écriture n'est autorisée sur une bande protégée sauf si l'attribut protected reprend la valeur false dans l'utilitaire de configuration DIVArchive une fois la bande réinsérée dans la bibliothèque. Cet attribut n'empêche pas les opérations de suppression sur des instances situées sur ces bandes (qu'elles soient internalisées ou externalisées).

Vous pouvez également avoir à réinitialiser cet attribut sur une bande si la bande a été éjectée par erreur d'une bibliothèque ou si la bande était coincée dans un lecteur de bande et a été retirée en ouvrant la porte de la bibliothèque et éjectée manuellement. Quand la bibliothèque est ensuite resynchronisée avec la base de données DIVArchive, la bande absente sera considérée comme externalisée et le paramètre Protected Mode défini avec la valeur true (la bande est protégée).

Gestion des étiquettes de bande

Quand une bande est montée pour la première fois et que des objets sont écrits dessus, DIVArchive écrit une étiquette au début de cette bande. L'étiquette contient des informations importantes relatives à la gestion des objets écrits sur ou supprimés de la bande lors des opérations d'archivage. Dans une perspective opérationnelle, les informations les plus importantes de l'étiquette de la bande sont celles du numéro de code à barres de cette bande. Le code à barres est un numéro alphanumérique figurant sur l'étiquette physique collée au dos de la cartouche et est également écrit sur l'étiquette du média magnétique de la bande.

Chaque fois qu'une bande est montée, DIVArchive consulte automatiquement l'étiquette écrite sur la bande pour vérifier qu'elle correspond à l'étiquette du code à barres de la bande indiquée par la bibliothèque de bande pour le montage.

Ce mécanisme assure les deux fonctions de sécurité suivantes :

Confirmation que le mappage entre les lecteurs physiques de la bibliothèque correspond à ceux des connexions logiques à chaque lecteur de bande provenant du composant Actor. Ceci empêche les données d'être écrites sur la mauvaise bande en cas de divergence de configuration entre lecteurs physiques de la bibliothèque.
Il empêche les bandes portant des étiquettes étrangères (bandes préalablement utilisées par un autre système d'archivage) d'être écrasées par erreur. Ce mécanisme est destiné aux environnements où DIVArchive partage une bibliothèque avec une autre application d'archivage et où les bandes utilisées par cette application n'ont pas été définies avec un ID jeu 99.

Si DIVArchive identifie une divergence entre l'étiquette attendue et celle de la bande, il génère une erreur d'étiquette d'E/S. La bande est alors définie comme non inscriptible et ne sera pas sélectionnée pour d'autres opérations d'écriture ultérieures.

Instances

Le stockage géré par DIVArchive se compose de trois catégories distinctes :

Stockage en ligne (bandes dans une bibliothèque)
Stockage Nearline (disques)
- Reportez-vous à l'Annexe A pour consulter les informations de licence de DIVArchive.
Stockage hors ligne (bandes externalisées)

Le nom et la catégorie d'un objet dans DIVArchive doivent être uniques. En revanche, plusieurs copies de cet objet peuvent être créées dans l'une ou les trois classes ci-dessus. Chaque copie d'un objet (notamment l'objet archivé original lui-même) est appelée instance.

A part la création de copies de sauvegarde, le concept des instances d'objet couvre également la gestion du cycle de vie du contenu dans DIVArchive. Un objet peut initialement être créé dans le stockage en ligne pour un accès rapide et sauvegarder également des instances créées sur une ou plusieurs bandes. Quand l'objet n'est plus requis pour l'accès en ligne ou Nearline, l'instance de disque peut être supprimée et la bande externalisée. La gestion automatique du cycle de vie des objets, basée sur leur ancienneté et leur emplacement dans l'archive, peut être assurée par l'option DIVArchive Storage Plan Manager (SPM).

La première instance d'un objet est créée quand il est archivé pour la première fois dans DIVArchive. Des instances supplémentaires de l'objet archivé peuvent ensuite être créées à l'aide des commandes Copy et Associative Copy.

Il n'est pas possible de recréer une instance supplémentaire d'un objet en réarchivant l'objet original avec les mêmes nom et catégorie. Cette demande est automatiquement arrêtée par DIVArchive qui génère une erreur du type L'objet existe déjà dans DIVArchive.

Les instances sont initialement numérotées dans l'ordre séquentiel, l'objet original qui est archivé dans DIVArchive étant l'instance 0. A mesure que de nouvelles instances sont créées et que d'anciennes instances sont supprimées, la numérotation des instances peut ne plus être séquentielle quand les propriétés d'un objet sont affichées dans la vue Objets (Objects View) (sous l'onglet Manage) de l'interface graphique (GUI) de contrôle. En revanche, le numéro d'une instance provenant d'une instance préalablement supprimée peut ensuite être réutilisé par DIVArchive dans d'autres demandes de copie.

Les restrictions suivantes s'appliquent à la création de nouvelles instances d'un objet dans DIVArchive :

Un groupe de bandes peut contenir deux instances du même objet si les deux sont situées sur des bandes distinctes. Si aucune bande supplémentaire pour ce groupe n'est disponible pour stocker la seconde instance, la demande de copie est interrompue.
Une baie de disques peut contenir deux instances du même objet si les deux sont situées sur des disques distincts dans la baie. Si aucun disque supplémentaire n'est disponible, la demande de copie est interrompue.

Si un objet comporte plusieurs instances dans l'archive et qu'une demande de restauration est émise, DIVArchive procède comme suit :

Si aucun numéro d'instance n'est spécifié dans la demande, DIVArchive sélectionne l'instance permettant de terminer la demande dans le délai le plus rapide. Une instance de disque est privilégiée par rapport à une instance de bande. En revanche, une instance de bande peut être sélectionnée dans certaines configurations si le paramètre QOS spécifié dans la demande a la valeur Cache Only ou Cache and Direct.
Si aucun numéro d'instance n'est spécifié dans la demande de restauration et qu'une instance de disque existe mais que le disque est hors ligne, l'instance de bande est automatiquement sélectionnée.
Si deux instances ou plus sont présentes sur la bande et qu'aucune instance de disque n'existe, et qu'une bande est actuellement en cours d'utilisation dans une autre demande (ou est externalisée), la bande contenant l'autre instance est automatiquement sélectionnée.
Si deux instances ou plus existent sur la bande et qu'une erreur de lecture se produit sur la première instance sélectionnée, la demande est automatiquement tentée sur les autres instances jusqu'à ce qu'elle aboutisse. Si aucune instance ne peut être lue, la demande est interrompue.
Si un numéro d'instance spécifique est indiqué dans la demande de restauration, DIVArchive utilise uniquement cette instance. Si le média contenant l'instance est hors ligne (pour les disques), externalisé (pour les bandes), ou si une erreur d'E/S ou de lecture se produit, la demande est abandonnée.

L'illustration suivante présente un workflow possible pour plusieurs instances d'objet :

Exemple de workflow d'instances d'objets multiples

Réquisition et libération d'instances

La réquisition et la libération d'instances permet à une application, telle qu'un système MAM (Media Asset Management) tiers, ou à un utilisateur DIVArchive, de marquer les objets (ou instances) DIVArchive qui sont externalisés mais doivent être restaurés (Required), et les instances qui ne sont plus nécessaires et peuvent être externalisées (Released). Le mécanisme de libération est une alternative plus précise que l'approche d'externalisation de groupe pour l'externalisation des instances.

La vue Required Release de l'onglet Manage dans l'interface graphique (GUI) de contrôle est fournie pour permettre la vérification des instances dont le statut Internalized/Externalized diffère du statut Released/Required. Cette vue fournit en outre une méthode rapide et aisée pour identifier quelles bandes doivent être insérées dans la bibliothèque ou peuvent être externalisées.

Par défaut, les instances d'objet sont supposées être disponibles dans DIVArchive. La commande Release doit être appelée sur les instances avant l'éjection de leurs bandes correspondantes. Toutefois, la commande Eject offre une option qui effectue automatiquement la libération sur chaque instance intégralement située sur les bandes à éjecter.

Après avoir été créée par une copie ou une demande d'archivage, une instance est supposée être requise pour être disponible, de sorte que son statut est INSERTED et REQUIRED. L'exécution d'une commande Require sur une instance libérée donne lieu à une instance requise. Parallèlement, la libération d'une instance requise donne lieu à une instance libérée.

Vérification du contenu

Le programme Checksum Support and Content Verification vise à fournir des niveaux supplémentaires de vérification au système DIVArchive. Cette fonction présente la génération de checksum et la vérification de chaque fichier géré par DIVArchive. Les algorithmes de checksum actuellement pris en charge dans DIVArchive incluent MD2, MDC2, MD5, SHA, SHA-1 et RIPEMD160.

Remarque :

La vérification de checksum supplémentaire est effectuée au niveau Oracle Storage Cloud. Pour plus d'informations, reportez-vous à la documentation d'Oracle Storage Cloud.

L'algorithme de checksum par défaut et recommandé est MD5. Bien que les autres algorithmes soient conservés pour la compatibilité amont, seuls les algorithmes MD5 et SHA-1 sont recommandés pour des résultats optimaux.

Quand un objet contient de multiples fichiers, un checksum est généré puis vérifié pour chacun des éléments le composant. Il existe trois types de sources de checksum :

Checksum authentique
Checksum d'archive
Checksum différé

Le mode TEXT Genuine Checksum permet à DIVArchive d'archiver tous les fichiers et sous-dossiers dans un dossier spécifique tout en comparant leurs valeurs de checksum à d'autres valeurs connues stockées dans un fichier checksum externe. Les fichiers qui n'ont pas de checksum correspondant dans le fichier checksum externe sont archivés à l'aide du checksum calculé par DIVArchive et le fichier checksum externe n'est pas archivé.

Remarque :

Le mode TEXT Genuine Checksum est une implémentation spécifique d'un client qui prend uniquement en charge l'algorithme MD5. Unicode n'est pas pris en charge et les checksums doivent figurer dans un fichier texte .md5.

Instructions d'archivage

Procédez comme suit pour archiver des objets à l'aide de la vérification de checksum au moyen de l'interface graphique (GUI) de contrôle :

Dans l'interface graphique (GUI) de contrôle du Manager, accédez à Action et sélectionnez Archive.
Dans la liste déroulante Source, sélectionnez l'entrée Source/Destination qui a été créée lors de l'étape de configuration.
Entrez le chemin de fichier racine dans le champ File Path Root.
Entrez le chemin d'accès à l'emplacement des fichiers checksum dans le champ Files et ajoutez un caractère générique (astérisque) à la fin de votre entrée.
Entrez -r dans le champ Options.
Entrez les paramètres restants dans le formulaire de demande et cliquez sur Send.

Limites

Les limites suivantes s'appliquent lors de la vérification de checksum. Pour plus d'informations, reportez-vous au document Oracle DIVArchive Checksum Support User's Guide dans la bibliothèque Oracle DIVArchive Additional Features documentation.

DIVArchive ne peut pas ouvrir ni créer des fichiers sur un système de fichiers Windows si leur nom de chemin absolu dépasse 256 caractères. Le chemin racine ne doit pas dépasser un total de 256 caractères.
Seuls les fichiers checksum encodés en ASCII, qui ne sont pas au format UTF-8, sont pris en charge.
Chaque ligne de fichier checksum doit commencer par un checksum MD5, suivi de 2 espaces, puis du chemin de fichier d'accès au fichier référencé.

Genuine Checksum avec transfert AXF

Le mode AXF Genuine Checksum permet à DIVArchive d'archiver tous les fichiers et sous-dossiers dans un fichier AXF spécifié tout en comparant leurs valeurs de checksum à d'autres valeurs connues stockées dans le fichier AXF. Ce type de workflow est généralement combiné à une demande de restauration ayant la valeur -axf dans le champ Request Options.

Conditions requises

L'objet AXF contenant les fichiers à archiver doit comporter les informations de checksum pour chaque fichier. Le checksum fourni dans l'objet AXF doit avoir le type attendu défini dans la configuration.

Paramètres de l'utilitaire de configuration de DIVArchive

Utilisez la procédure suivante pour définir correctement la configuration dans l'utilitaire de configuration de DIVArchive :

Créez une nouvelle entrée Source/Destination avec un type de source défini avec la valeur DISK, FTP_STANDARD ou EXPEDAT, selon le cas.
Spécifiez un chemin racine, le cas échéant. Ce chemin, et les fichiers d'entrée spécifiés lors de la demande d'archivage, déterminent l'emplacement du fichier de checksum.

Par exemple, si le type de source est DISK, le chemin racine peut être D:\root. Si le type de source est FTP_STANDARD, le chemin racine peut être /root.
Définissez le champ External Checksum Source avec la valeur YES.
Définissez le champ Checksum Type avec la valeur de type de checksum attendu (par exemple, MD5).
Définissez le champ GC Mode avec la valeur AXF.
Cliquez sur OK.
Sélectionnez Tools, puis Notify Manager dans le menu pour notifier la configuration au Manager.

Instructions d'archivage

Procédez comme suit pour archiver un objet avec le mode Genuine Checksum au moyen d'un transfert AXF :

Dans l'interface graphique (GUI) de contrôle du Manager, accédez à Action et sélectionnez Archive.
Dans la liste déroulante Source, sélectionnez l'entrée Source/Destination qui a été créée dans la procédure de configuration.
Définissez la racine de chemin de fichier voulue dans File Path Root.
Entrez le chemin d'accès à l'emplacement du fichier AXF dans le champ Files. L'extension de fichier doit être .axf.
Entrez les paramètres restants dans le formulaire de demande et cliquez sur Send.

Limites

Le workflow décrit fonctionne uniquement avec des demandes AXF générées par DIVArchive.

Verify Following Restore (VFR) n'est pas compatible avec l'option -axf. VFR a été conçu pour lire le contenu restauré depuis un serveur vidéo afin de vérifier qu'il n'était pas altéré. L'option -axf ne crée pas une restauration réelle mais plutôt une exportation d'objet dans un wrapper AXF. Ces options s'excluent mutuellement et ne doivent pas faire partie d'un même workflow.

Pour plus d'informations, reportez-vous au document Oracle DIVArchive Checksum Support User's Guide dans la bibliothèque Oracle DIVArchive Additional Features documentation.

Gestion des plans de stockage

Attention :

Une configuration incorrecte d'Oracle DIVArchive Storage Plan Manager (SPM) peut entraîner des résultats inattendus et potentiellement désastreux. Des modifications mineures peuvent avoir des conséquences catastrophiques. Par exemple, la suppression de centaines de milliers d'instances sur des bandes ou l'altération de la base de données. Si vous ne disposez pas d'une formation spécifique ou si vous ne connaissez pas le produit, il est recommandé de contacter le support technique Oracle avant d'apporter des modifications à SPM. Dans le cas contraire, vous risquez d'endommager sérieusement le système DIVArchive ou une perte de données permanente.

Le logiciel Oracle DIVArchive Storage Plan Manager (SPM) permet la gestion du cycle de vie d'un objet (interagissant avec DIVArchive Manager) et est généralement installé sur le même système que DIVArchive Manager. Par exemple, un objet archivé peut résider sur un média spécifique le premier jour puis migrer (à terme) vers un autre média en fonction des stratégies et règles établies par l'utilisateur. DIVArchive exécute la migration du cycle de vie d'objet comme une activité en arrière-plan en suivant les stratégies et règles définies dans le plan de stockage correspondant.

La nouvelle version de SPM prend en charge le nettoyage des disques en fonction de la date d'archivage de l'objet. Dans les précédentes versions de SPM, la fonction de nettoyage des disques prenait uniquement en charge le nettoyage en fonction de la dernière heure d'accès et de la taille de l'objet.

Types de demande DIVArchive

Cette section décrit les différents types de demande DIVArchive disponibles.

Quand vous êtes connecté à DIVArchive Manager, vous pouvez accéder à l'onglet Action à partir de n'importe quelle vue de l'interface graphique (GUI) de contrôle. Cet onglet permet d'exécuter les demandes à envoyer à DIVArchive. Vous pouvez utiliser une application initiatrice tierce (telle qu'un système d'automatisation) à la place ou en plus de l'interface graphique (GUI) de contrôle. Les options de cette zone ne sont accessibles que si vous êtes connecté avec un profil Administrateur.

Les différentes demandes disponibles sous l'onglet Action de l'interface graphique (GUI) de contrôle sont les suivantes :

Archive: Copie un fichier d'une source vers DIVArchive.
Delete: Supprime toutes les instances, ou une instance sélectionnée, d'un objet DIVArchive.
Require: Définit le statut d'un objet à la valeur Required (requis). La bande associée doit être insérée dans une bibliothèque gérée par DIVArchive.
Release: Définit le statut d'un objet à la valeur Released (libéré). Une fois qu'un objet est libéré, il peut être externalisé.
Cancel: Annule une demande préalablement soumise en spécifiant l'ID de la demande (Request ID) ou en sélectionnant une demande au préalable dans la vue Current Requests (Demandes actuelles).
Change Priority: Augmente ou diminue la priorité du planificateur des demandes en attente.
Assign Storage Plan: Affecte un plan de stockage à l'objet sélectionné.
Restore: Copie un fichier de DIVArchive vers une destination unique.
Partial Restore: Ne copie qu'une partie d'un fichier (en fonction du code horaire, des positions d'octet, des dossiers ou des images DPX) à partir de DIVArchive vers une destination.
Multiple Restore (ou N-Restore): Restaure un objet depuis DIVArchive vers plusieurs destinations simultanément.
Copy: Permet à un objet existant d'être copié vers un autre groupe.
Copy As: Permet à un objet existant d'être copié sous un autre nom, groupe ou catégorie.
Associative Copy: Permet à plusieurs objets de différents emplacements dans l'archive d'être tous copiés vers une seule bande au moyen d'une commande unique.
Repack Tape: Envoie une demande de recompression manuelle pour la bande sélectionnée.
Verify Tape: Envoie une demande de vérification de bande pour la bande sélectionnée.
Insert Tape: Permet d'insérer des bandes dans une bibliothèque DIVArchive au moyen de son CAP.
Eject Tape: Ejecte la ou les bande(s) sélectionnée(s) de la bibliothèque vers le CAP.
Export Tape: Permet d'exporter une bande (et ses objets) d'un système DIVArchive vers un autre.
Migrate Content: Transfère le contenu existant d'un groupe de bande vers un autre groupe ou baie.
Automatic Repack: Envoie une demande de recompression automatique pour la bande sélectionnée.

Transferts Oracle Storage Cloud

Oracle Storage Cloud est une solution de stockage d'objet qui offre deux types de comptes utilisables avec DIVArchive : les comptes facturés à l'usage et les comptes non facturés à l'usage. Pour plus d'informations sur les comptes de stockage Oracle Storage Cloud, visitez http://docs.oracle.com/cd/E60880_01/VLPFN/whatis.htm#BABDADAE

Le compte non facturé à l'usage permet la création de conteneurs de classe standard. Les objets écrits dans des conteneurs standard sont accessibles immédiatement et à tout moment.

Avec un compte facturé à l'usage, DIVArchive peut effectuer l'archivage vers des conteneurs de classe standard et de classe d'archivage. Avec des conteneurs d'archivage, les objets écrits sur un périphérique de stockage d'archivage profond requièrent un processus de restauration avant d'être téléchargés.

Un objet situé dans un archivage profond requiert au maximum 4 heures pour être restauré vers une destination DIVArchive configurée car le contenu sera d'abord transféré de la bande vers le cache Cloud, puis transféré du cache vers la destination finale.

Quand une demande de restauration est effectuée pour un objet avec une instance cloud, DIVArchive tentera toujours de restaurer une instance locale (non cloud) de l'objet. Si toutes les instances locales sont hors ligne, qu'aucune instance locale n'existe, ou qu'une instance cloud est explicitement demandée (demande de restauration d'instance), alors DIVArchive effectuera la restauration à partir d'une instance cloud.

Seuls les composants Actor configurés pour CLOUD ARCHIVE peuvent transférer du contenu vers le cloud. Seuls les composants Actor configurés pour CLOUD RESTORE peuvent transférer du contenu depuis le cloud. Reportez-vous à l'Annexe A pour consulter les informations de licence de DIVArchive.

Taille de bande restante réelle et dernière position écrite

Pour certains lecteurs de bande spécifiques (Oracle T10K et IBM LTO), le composant Actor renvoie désormais la taille restante réelle sur la bande et la dernière position écrite sur la bande au Manager lors d'un transfert de contenu vers la bande. La taille restante est indiquée en nombre d'octets de données non compressées.

Le Manager utilise la taille restante et la dernière position écrite (au lieu de s'appuyer sur la taille du type de bande) pour obtenir le total réel et la taille restante sur la bande dans toutes les opérations basées sur bande.

Les opérations d'exportation et d'importation incluent désormais la taille totale de la bande.

Demandes d'archivage

Une opération d'archivage est définie comme un transfert de fichiers pour DIVArchive. Les fichiers sont ensuite stockés comme objet DIVArchive. Pour envoyer une demande d'archivage, sélectionnez l'option Archive dans l'onglet Action de l'interface graphique (GUI) de contrôle. La demande soumet une demande d'archivage d'objet au DIVArchive Manager pour traitement.

Les champs suivants sont inclus dans l'écran Send Archive Request :

Object Name

Nom de l'objet à archiver.

Category

Catégorie de l'objet à archiver.

Source

Nom de la source (par exemple, un serveur vidéo, serveur de navigation, etc.). Ce nom doit être connu dans la configuration DIVArchive.

Media

Ce champ désigne un groupe de bandes ou une baie de disques déclaré dans la configuration où l'instance doit être créée. Si ce paramètre est une chaîne NULL, le groupe de bandes par défaut nommé DEFAULT est utilisé.

Files Path Root

Dossier racine pour les fichiers (voir les exemples de la section suivante).

Storage Plan

Ce champ définit le plan de stockage à utiliser pour cet objet. Si aucun plan de stockage n'est affecté, le plan de stockage par défaut est utilisé.

Add. Service

Cochez cette case pour supprimer le fichier original une fois qu'il a été archivé.

Remarque :

La suppression à la source n'est pas prise en charge pour les serveurs de diffusion.

Quality of Service

L'un des codes suivants :

DIVA_QOS_DEFAULT

L'archivage est effectué en fonction de la qualité de service par défaut (actuellement direct et cache pour les opérations d'archivage).

DIVA_QOS_CACHE_ONLY

Utiliser l'archivage de cache uniquement.

DIVA_QOS_DIRECT_ONLY

Utiliser l'archivage direct uniquement ; aucune instance de disque n'est créée.

DIVA_QOS_CACHE_AND_DIRECT

Utiliser l'archivage de cache si disponible ou l'archivage direct si l'archivage de cache n'est pas disponible.

DIVA_QOS_DIRECT_AND_CACHE

Utiliser l'archivage direct si disponible ou l'archivage de cache si l'archivage direct n'est pas disponible.

Des services supplémentaires et facultatifs sont disponibles. Pour demander ces services, utilisez un opérateur logique OR entre le paramètre QOS préalablement documenté et la constante suivante :

DIVA_ARCHIVE_SERVICE_DELETE_ON_SOURCE

Suppression des fichiers source quand la migration de la bande est terminée. Disponible pour les sources locales, les sources disque et les sources FTP standard. Cette fonction n'est pas disponible pour les objets complexes.

Priority

Niveau de priorité pour cette demande. Le niveau peut être compris entre 0 et 100 ou être la valeur DEFAULT. La valeur 0 représente la priorité la plus faible et la valeur 100 la priorité la plus élevée. Déplacez le curseur pour augmenter ou diminuer la priorité de la demande.

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Files

Noms de fichier à archiver depuis la source. Si plusieurs noms de fichier sont spécifiés, tous sont référencés par le nom d'objet DIVArchive.

Comments

Informations facultatives décrivant l'objet. Ce champ est facultatif et peut rester vide.

Options

Options supplémentaires pour effectuer le transfert des données de la source vers DIVArchive. Ces options remplacent les options spécifiées dans la base de données de la configuration de DIVArchive. Les valeurs possibles pour Options sont actuellement les suivantes :

No Entry: Aucune saisie dans ce champ indique aucune option.
-r: L'utilisation de l'option -r indique que chaque nom figurant dans filenamesList faisant référence à un dossier doit être scanné de manière récursive. Ceci s'applique également quand FilesPathRoot est spécifié et qu'un astérisque désigne les fichiers à archiver. Cette option peut être utilisée lors de l'archivage à partir d'une source locale ou d'un serveur FTP standard.
-login: Un nom d'utilisateur et un mot de passe sont requis pour la connexion à certaines sources. Cette option remplace l'option -gateway des versions précédentes.
-pass: Mot de passe utilisé avec -login.

Paramètres Files Path Root et Files de demande d'archivage

Les paramètres Files Path Root et Files figurant dans la fenêtre Archive Request déterminent l'emplacement du dossier principal et les sous-dossiers et fichiers à archiver. Si chacun sert une fin différente, les deux paramètres fonctionnent ensemble. Identifiez un objet métier logique avant de renseigner ces paramètres et d'exécuter la demande.

Le champ Files Path Root identifie le chemin d'accès au dossier de fichiers principal (dossier racine). Par exemple, c:\DROPFOLDER\Media\Object1\.

La valeur que vous entrez dans le champ Files identifie les différents fichiers sous le dossier principal (Files Path Root identifié) ainsi que tous les autres sous-dossiers et fichiers. Par exemple, subfolder1\file3.

Le champ Files peut contenir un chemin absolu. Toutefois, il n'est pas recommandé de définir cette valeur car elle empêche la restauration de l'objet vers un autre dossier racine.

Si une valeur est identifiée pour Files Path Root, vous ne devez pas indiquer le chemin de fichier complet dans le champ Files. Vous devez uniquement utiliser les noms de dossier et les noms de fichier qui sont situés sous le dossier Files Path Root identifié. Autrement, le champ Files Path Root peut ne pas être renseigné et le chemin et le nom du fichier complet peuvent être saisis dans le champ Files.

Les exemples suivants montrent comment ces paramètres peuvent être utilisés :

Exemples corrects

Les entrées suivantes archivent uniquement les fichiers spécifiés figurant dans C:\DROPFOLDER\Media\Object1\ et dans subfolder1\file3.

Files Path Root: C:\DROPFOLDER\Media\Object1\
Files: file1
file2
subfolder1\file3

Les entrées suivantes archivent tous les dossiers et fichiers figurant dans C:\DROPFOLDER\Media\Object1\.

Files Path Root: C:\DROPFOLDER\Media\Object1\
Files: *

Les entrées suivantes sont correctes mais ne sont pas recommandées car dans le futur, l'objet ne pourra pas être restauré dans un emplacement différent. La flexibilité du système et la compatibilité avec les autres périphériques de stockage seraient réduites et dans certains cas, les fonctions de transcodage et de restauration de fichiers partielle seraient également limitées. Dans cet exemple, le champ Files Path Root n'est pas renseigné et les chemins absolus sont indiqués dans le champ Files.

Files Path Root
Files: C:\DROPFOLDER\Media\Object1\file1
C:\DROPFOLDER\Media\Object1\file2
C:\DROPFOLDER\Media\Object1\subfolder1\file3

Exemple incorrect

Les entrées suivantes se traduiront par une erreur et la demande d'archivage ne sera pas effectuée.

Files Path Root: C:\DROPFOLDER\Media\Object1\
Files: C:\DROPFOLDER\Media\Object1\file1
C:\DROPFOLDER\Media\Object1\file2
C:\DROPFOLDER\Media\Object1\subfolder1\file3

Demande d'archivage avec suppression à la source

Dans certains cas, vous devez supprimer le contenu et éventuellement le dossier parent sur un serveur. Deux options sont disponibles pour répondre à tous les scénarios possibles :

-r: Suppression récursive
-delete_fpr: Suppression récursive incluant le dossier parent

Les deux options fonctionnent séparément ou ensemble comme indiqué dans les exemples de workflow suivants :

Exemple 1

Files Path Root: C:\source\root
Files: *
Options: -r

DIVArchive supprimera le contenu de C:\source\root de manière récursive à cause de ces paramètres.

Exemple 2

Files Path Root: C:\source\root
Files: *
Options: -r -delete_fpr

DIVArchive supprimera le contenu de C:\source\root de manière récursive et le dossier parent (root) à cause de ces paramètres.

Exemple 3

Files Path Root: C:\source\root
Files: *
Options

DIVArchive supprimera uniquement le contenu de C:\source\root à cause de ces paramètres.

Exemple 4

Files Path Root: C:\source\root
Files: *
Options: -delete_fpr

DIVArchive supprimera uniquement le contenu de C:\source\root et finalement le dossier parent (root) s'il est vide, à cause de ces paramètres.

Exemple 5

Files Path Root: C:\source\root
Files: object\*
Options: -r

DIVArchive supprimera le contenu de C:\source\root\object de manière récursive et le dossier parent (object) à cause de ces paramètres.

Exemple 6

Files Path Root: C:\source\root
Files: object\*
Options: -r -delete_fpr

DIVArchive supprimera le contenu de C:\source\root\object de manière récursive, puis supprimera C:\source\root\object et enfin C:\source\root s'il est vide à cause de ces paramètres.

Exemple 7

Files Path Root: C:\source\root
Files: object1\*
object2\*
Options: -r

DIVArchive supprimera le contenu de C:\source\root\object1 de manière récursive, supprimera C:\source\root\object1, supprimera le contenu de C:\source\root\object2, de manière récursive, et supprimera C:\source\root\object2 à cause de ces paramètres.

Exemple 8

Files Path Root: C:\source\root
Files: object1\*
object2\*
Options: -r -delete_fpr

DIVArchive supprimera le contenu de C:\source\root\object1 de manière récursive, supprimera C:\source\root\object1, supprimera le contenu de C:\source\root\object2 de manière récursive, supprimera C:\source\root\object2 et supprimera C:\source\root s'il est vide, à cause de ces paramètres.

Exemple 9

Files Path Root: C:\source\root
Files: object1\*
object2\*
Options: -r -delete_fpr

DIVArchive supprimera le contenu de C:\source\root\object1 de manière récursive, supprimera C:\source\root\object1, supprimera C:\source\root\object2\subfolder\clip.mov, supprimera C:\source\root\object2\subfolder s'il est vide, supprimera C:\source\root\object2 s'il est vide et supprimera C:\source\root s'il est vide à cause de ces paramètres.

Demandes de suppression et de suppression d'instance

Utilisez la commande Delete pour supprimer toutes les instances d'un objet, ou uniquement une instance spécifique de l'objet de DIVArchive. Vous devez utiliser cette commande avec circonspection. Cette commande soumet une demande de suppression d'objet à DIVArchive Manager qui supprime chaque instance de l'objet (sauf spécification contraire).

Le champ Instance de la demande de suppression détermine exactement ce qui sera supprimé de DIVArchive. Si ce champ est laissé vide, toutes les instances de cet objet seront supprimées. Si un numéro spécifique est entré dans ce champ, seule l'instance correspondante est supprimée.

Pour lancer la demande de suppression, cliquez sur le bouton Delete dans la barre de ruban. Vous pouvez également la lancer depuis la vue Objects de l'onglet Manage en faisant un clic droit sur l'objet à supprimer et en sélectionnant Delete dans le menu qui s'affiche. Si la commande Delete est sélectionnée à partir de la vue Objects, le champ de l'instance est mis à jour automatiquement avec l'instance sélectionnée. Seule la suppression d'instance spécifique est prise en charge à partir de cette vue.

Remarque :

Les suppressions et les recompressions n'effacent pas le média WORM car ces médias ne sont pas réinscriptibles. Les instances sont supprimées mais l'espace n'est pas récupérable.

Les champs suivants sont inclus dans l'écran Send Delete Request :

Object Name

Nom de l'objet à supprimer.

Category

Catégorie affectée à l'objet quand il a été archivé. Ce paramètre peut être une chaîne NULL mais cela peut provoquer une erreur si plusieurs objets ont le même nom.

Instance

Si plusieurs instances de l'objet sont présentes dans DIVArchive, vous pouvez indiquer les instances à supprimer. Si aucun numéro n'est saisi dans ce champ, DIVArchive supprime toutes les instances de cet objet.

Media

Le média peut être un groupe de bandes existant ou une baie de disques. La liste déroulante ne contient que les éléments déjà configurés dans DIVArchive.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Demandes de réquisition et de libération

La réquisition ou la libération d'objets est principalement une entrée de base de données pour les instances qui sont ou peuvent être externalisées à partir de la bandothèque. Les bandes qui peuvent ou doivent être externalisées sont déterminées au moyen de la vue Require Instances.

Une demande Require indique à DIVArchive Manager que cette instance doit être insérée. Cette demande n'a aucune incidence si l'instance est déjà requise. Vous pouvez extraire une liste des instances REQUIRED et EJECTED à partir de l'interface graphique (GUI) de contrôle.

Pour lancer une demande Require ou Release, cliquez sur le bouton Require/Release dans la barre de ruban. Vous pouvez également utiliser la vue Objects de l'onglet Manage en cliquant avec le bouton droit de la souris sur l'objet voulu et en sélectionnant Require ou Release dans le menu qui s'affiche.

Les champs suivants sont inclus dans l'écran Send Require Request :

Object Name: Nom de l'objet requis.
Category: Catégorie affectée à l'objet quand il a été archivé. Ce paramètre peut être laissé vide mais cela peut provoquer une erreur si plusieurs objets ont le même nom.
Instance: Si aucune valeur n'est entrée ici, la fonction s'applique de force à chaque instance de l'objet indiqué.

Une demande Release indique à DIVArchive Manager que cette instance peut être externalisée. Cette demande n'a aucune incidence si l'instance a déjà été libérée. Vous pouvez extraire une liste des instances RELEASED et INSERTED à partir de l'interface graphique (GUI) de contrôle. Une bande libérable est une bande qui contient uniquement des instances libérées.

Les champs suivants sont inclus dans l'écran Send Release Request :

Object Name: Nom de l'objet requis.
Category: Catégorie affectée à l'objet quand il a été archivé. Ce paramètre peut être laissé vide mais cela peut provoquer une erreur si plusieurs objets ont le même nom.
Instance: Si aucune valeur n'est entrée ici, la fonction s'applique de force à chaque instance de l'objet indiqué.

Demandes de restauration

Une demande Restore est définie comme le transfert d'un objet DIVArchive vers une destination. Vous pouvez lancer une demande de restauration depuis l'onglet Action de l'interface graphique (GUI) de contrôle. Vous pouvez également utiliser la vue Objects de l'onglet Manage en faisant un clic droit sur l'objet à restaurer et en sélectionnant Restore dans le menu qui s'affiche.

Cette demande soumet une demande de restauration d'objet à DIVArchive Manager qui choisit l'instance appropriée à restaurer. La demande échoue si l'objet demandé se trouve sur un média qui n'est pas disponible.

Les champs suivants sont inclus dans l'écran Restore Request :

Object Name

Nom de l'objet à restaurer.

Category

Catégorie affectée à l'objet quand il a été archivé. Ce paramètre peut être laissé vide mais cela peut provoquer une erreur si plusieurs objets ont le même nom.

Instance

Si plusieurs instances d'un objet sont présentes dans DIVArchive, vous pouvez indiquer l'instance spécifique à restaurer. Si ce champ est vide, DIVArchive sélectionne l'instance offrant le transfert le plus optimal.

Destination

Destination (par exemple, un serveur vidéo ou un serveur de navigation) pour les fichiers d'objet. Ce nom doit être connu par la configuration DIVArchive. Utilisez la liste déroulante pour sélectionner la destination voulue.

Files Path Root

Dossier racine sur la destination où les fichiers d'objet seront placés. Cette option ajoute ou remplace la valeur FPR utilisée dans la demande d'archivage originale. Si ce champ est laissé vide, les fichiers sont placés dans le dossier Files Path Root spécifié lors de l'archivage de l'objet.

Options

Options supplémentaires pour effectuer le transfert des données de DIVArchive vers la destination. Ces options remplacent les options spécifiées dans la base de données de la configuration de DIVArchive. Les valeurs possibles pour Options sont actuellement les suivantes :

No Entry: Aucune saisie dans ce champ indique aucune option.
-login: Un nom d'utilisateur et un mot de passe sont requis pour la connexion à certaines sources. Cette option remplace l'option -gateway des versions précédentes.
-pass: Mot de passe utilisé avec -login.

Quality of Service

L'un des codes suivants :

DIVA_QOS_DEFAULT

La restauration est effectuée en fonction de la qualité de service par défaut (actuellement direct et cache pour les opérations de restauration).

DIVA_QOS_CACHE_ONLY

Utiliser la restauration de cache uniquement.

DIVA_QOS_DIRECT_ONLY

Utiliser la restauration directe uniquement ; aucune instance de disque n'est créée.

DIVA_QOS_CACHE_AND_DIRECT

Utiliser la restauration de cache si disponible ou la restauration directe si la restauration de cache n'est pas disponible.

DIVA_QOS_DIRECT_AND_CACHE

Utiliser la restauration directe si disponible ou la restauration de cache si la restauration directe n'est pas disponible.

DIVA_QOS_NEARLINE_ONLY

Utiliser la restauration Nearline uniquement. La restauration Nearline effectue la restauration depuis une instance de disque s'il en existe une. Dans le cas contraire, elle crée une instance de disque et effectue la restauration depuis l'instance de disque créée.

DIVA_QOS_NEARLINE_AND_DIRECT

Utiliser la restauration Nearline si disponible ou la restauration directe si la restauration Nearline n'est pas disponible.

DIVA_RESTORE_SERVICE_DO_NOT_OVERWRITE

Ne pas écraser les fichiers existants sur le serveur de destination.

DIVA_RESTORE_SERVICE_DO_NOT_CHECK_EXISTENCE

Ne pas vérifier l'existence du clip sur le serveur.

DIVA_RESTORE_SERVICE_DELETE_AND_WRITE

Forcer la suppression et la réécriture si l'objet existe sur le serveur.

DIVA_RESTORE_SERVICE_DEFAULT

Effectuer l'opération à l'aide du paramètre par défaut de la configuration Manager.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Services supplémentaires

Utilisez la liste du menu pour sélectionner si DIVArchive doit interrompre la demande si le nom du fichier existe déjà sur la destination.

Archivage et restauration en mode AXF

Dans DIVArchive 7.5, quand une demande d'archivage pour un fichier AXF est envoyée, DIVArchive détecte automatiquement si le fichier est un fichier AXF. Au lieu d'archiver le fichier AXF lui-même, DIVArchive archive le contenu du fichier AXF, en extrayant les checksums et la provenance de l'objet.

Le paramètre facultatif de demande de restauration -axf indique à DIVArchive de restaurer l'élément original dans un fichier AXF. Au lieu de simplement restaurer le contenu d'un objet vers la destination, DIVArchive restaure le contenu dans un nouveau wrapper AXF. Combinée avec -rm ou -rxml, cette option vous permet d'exporter un objet avec des informations de métadonnées puis de le déposer dans un dossier de surveillance DFM.

La fonction d'archivage et de restauration AXF comprend les éléments suivants :

Archivage du contenu d'un fichier AXF à l'aide de la détection automatique
- Identification de l'extension .axf du nom de fichier
- Confirmation qu'il s'agit d'un fichier unique
- Vérification du début du fichier pour des propriétés AXF spécifiques
- Vérification des informations de métadonnées
Restauration d'un objet dans un nouveau fichier AXF unique. Au préalable, cette opération aurait donné lieu à des fichiers multiples.
Préservation des checksums
Préservation des métadonnées
Préservation des provenances
Prise en charge des objets complexes

Cette option fonctionne avec les sources/destinations FTP_STANDARD, LOCAL, DISK, CIFS et EXPEDAT.

Demandes de restauration de fichiers partielle Oracle DIVArchive

DIVArchive prend en charge quatre types de restauration de fichiers partielle. Le type implémenté est déterminé par le paramètre format dans la demande. Cette demande soumet une demande de restauration d'objet partielle à DIVArchive Manager qui choisit l'instance appropriée à restaurer. Si l'objet demandé se trouve sur un média qui n'est pas disponible, la demande échoue.

La liste ci-après décrit chaque type de restauration de fichiers partielle :

Fichiers et dossiers

Ce type de restauration de fichiers partielle permet d'extraire des fichiers entiers de l'archive ou d'extraire des répertoires complets et leurs contenus. Il est possible d'extraire plusieurs fichiers et répertoires dans la même demande. Les fichiers sont restaurés avec les noms et chemins de fichier qui ont été spécifiés dans l'archive. Aucune option valide ne permet de renommer les fichiers et dossiers dans une restauration de fichiers partielle de fichiers et dossiers. Par exemple, un fichier archivé sous misc/12-2012/movie.avi sera partiellement restauré vers un sous-répertoire misc/12-2012 portant le nom movie.avi.

Quand un dossier est spécifié dans une restauration de fichiers partielle de fichiers et dossiers, tous les fichiers de ce dossier (et le dossier lui-même) sont restaurés. En outre, chaque répertoire à restaurer peut inclure l'option -r pour une restauration de tous les dossiers imbriqués dans le dossier cible, de manière récursive.

Position d'octet (Byte Offset)

Ce type permet d'extraire une plage d'octets d'un fichier donné dans l'archive. Par exemple, vous pouvez extraire les octets 1 à 2000 (les premiers 2000 octets du fichier), ou l'octet 5000 à la fin du fichier (ou les deux) et les stocker dans un fichier de sortie tel que movie.avi.

Remarque :

Le résultat d'une restauration de fichiers partielle de position d'octet n'est généralement pas lisible s'il est appliqué aux fichiers vidéo. Le composant Actor n'appliquera pas l'en-tête, le pied de page, etc., en fonction du format vidéo.

Code horaire (Timecode)

Ce type de restauration de fichiers partielle permet de sélectionner une partie d'un fichier média donné en fonction d'un code horaire (timecode). Par exemple, vous pouvez extraire de 00:00:04:00 à 00:10:04:00 (segment de 10 minutes commençant au bout de 4 secondes et se terminant au bout de 10 minutes et 4 secondes), et placer ce segment dans un fichier de sortie tel que movie.avi. Le fichier en résultant est une version plus petite du fichier movie original.

Remarque :

Le résultat d'une restauration de fichiers partielle de code horaire est un clip valide s'il est appliqué aux fichiers vidéo. Le composant Actor appliquera l'en-tête, le pied de page, etc., en fonction du format vidéo. Si le composant Actor ne peut pas analyser le format, la demande est interrompue. Ce type de restauration de fichiers partielle peut uniquement s'appliquer à un clip vidéo valide.

DPX

Ce type de restauration de fichiers partielle permet d'extraire une plage de fichiers DPX de l'archive. L'objet entier est considéré comme un seul élément média, avec un fichier DPX représentant une image du média. Seuls les fichiers ayant des extensions .dpx, .tif et .tiff dans l'archive sont considérés comme des images aux fins de cette commande.

Le premier fichier .dpx (ou fichier .tif ou .tiff) dans l'objet archivé est considéré comme l'image 1 (frame 1), le deuxième .dpx dans l'archive est l'image 2 (frame 2), etc.

Dans le cas peu probable où les fichiers .dpx, .tif, et (ou) .tiff seraient mélangés, le premier fichier séquentiel de l'une des trois extensions déterminerait quels fichiers seraient considérés comme faisant partie de la séquence. Par exemple, si un fichier .tif isolé est mélangé à un ensemble de fichiers .dpx et qu'il arrive en premier dans la séquence, la séquence est interprétée comme une séquence .tif et les fichiers .dpx sont ignorés, même si ce n'était pas le but recherché.

Par exemple, pour extraire les images 10 à 15 à l'aide de la restauration de fichiers partielle DPX, il restaure le dixième fichier .dpx figurant dans l'archive, le onzième fichier .dpx, etc., jusqu'au quinzième fichier .dpx, pour un total de six fichiers. Tous les autres fichiers (tels que les fichiers .wav) sont ignorés par la restauration de fichiers partielle DPX.

Des numéros d'image spéciaux 0 et -1 peuvent être utilisés pour la première et la dernière images respectivement. La valeur Frame 0 est valide comme début d'une plage d'images et la valeur Frame -1 comme fin d'une plage.

Les images et plages valides sont les suivantes :

Frame 0 = première image (cochez la case Start of File)
Frame 1 = première image de la séquence
Frame n = énième image de la séquence
Frame -1 = dernière image (cochez la case End of File)
La spécification de Frame 0 comme dernière image est considérée comme non valide.
La spécification de Frame 0 to 0 n'est actuellement pas valide et ne renverra pas la première image comme prévu.
La spécification de Frame 0 to 1 ou de Frame 1 to 1 renverra la première image.
La spécification de Frame -1 dans la première image produit actuellement une erreur. En outre, vous ne pouvez pas spécifier Frame -1 to -1 pour renvoyer la dernière image si le numéro de la dernière image est inconnu.

Exemples :

startRange=0 - endRange=1: Restaure uniquement la première image.
startRange=600 - endRange=635, startRange=679 - endRange=779: Restaure les images 600 à 635, et les images 679 à 779.
startRange=810 - endRange=-1: Restaure toutes les images de l'image 810 à la fin de l'archive.

Le nom du fichier réel peut (ou peut ne pas) correspondre au numéro de l'image dans DIVArchive. Après la restauration, DIVArchive interroge l'archive, trouve l'ordre des fichiers et détermine le numéro d'image à partir de l'ordre du fichier résultant trouvé, sans tenir compte du nom de fichier. Le premier fichier .dpx, .tif ou .tiff trouvé est considéré comme l'image 1 (Frame 1).

Lors de l'archivage de fichier DPX, vous devez vous assurer que ces fichiers peuvent être restaurés partiellement, de manière correcte, car la restauration de fichiers partielle DPX n'examine pas le nom du fichier ni les informations d'en-tête DPX pour déterminer quel fichier est affecté à quelle image. L'affectation se base simplement sur l'ordre dans lequel les fichiers .dpx apparaissent dans l'archive. Par défaut, ce dernier est basé sur l'ordre établi par la source et est généralement alphanumérique. Par exemple, les sources/destinations NTFS DISK classent, en général, les fichiers et dossiers sans respect des majuscules/minuscules, à l'exception de ceux où des marques diacritiques telles que ', `, ˆ, etc., sont appliquées.

Par défaut, quand DIVArchive détecte un sous-dossier, il traite tous les enfants de ce dossier (y compris les sous-dossiers) de manière récursive avant de poursuivre avec les autres fichiers. Si un dossier apparaît dans la liste des dossiers alphanumériques, il est archivé de manière récursive dans l'ordre dans lequel il apparaît, mais cela peut potentiellement créer des problèmes. Par exemple, si vous voulez que tous les sous-répertoires d'un répertoire donné soient traités en premier, suivis par les fichiers du répertoire. Vous pouvez aussi vouloir que tous les fichiers soient traités en premier, puis les sous-répertoires.

La restauration de fichiers partielle DPX considère un objet entier comme un seul élément de média. Si plusieurs bobines ou clips apparaissent dans une archive, ils peuvent être stockés dans des dossiers et restaurés partiellement à l'aide de la restauration de fichiers partielle des fichiers et dossiers. En revanche, pour la restauration de fichiers partielle DPX, ils sont considérés comme un seul clip vidéo long. Si c'est ce que vous recherchez, vous devez vous assurer que les répertoires sont triés par ordre alphanumérique dans l'ordre dans lequel les images devraient être agencées.

DIVArchive n'effectue aucun traitement audio spécial pour les média DPX (autre que ceux intégrés aux fichiers DPX). DIVArchive peut prendre en charge le transcodage de média DPX, mais un transcodeur peut modifier les noms de fichier et (ou) l'ordre des fichiers de l'archive DPX.

Soumission d'une demande de restauration de fichiers partielle

Pour soumettre une demande de restauration de fichiers partielle, cliquez sur le bouton Partial Restore de l'onglet Action. Vous pouvez également utiliser la vue Archived Objects de l'onglet Manager en faisant un clic droit sur l'objet voulu et en sélectionnant Partial Restore dans le menu qui s'affiche.

L'une ou l'autre méthode affiche l'Assistant de restauration partielle. Si aucun objet n'est sélectionné et que l'icône Partial Restore (de l'onglet Action) est utilisée, l'Assistant s'ouvre dans l'étape 1 (de 3) et les champs Object Name et Category doivent être renseignés manuellement.

Si un objet a été sélectionné et que le menu contextuel (clic droit) a été utilisé, l'Assistant s'ouvre dans l'étape 1 (de 2). Cette étape est similaire à l'étape 2 de la méthode précédente qui ouvre la fenêtre de l'Assistant.

Pour naviguer dans l'Assistant, procédez comme suit :

Renseignez les champs Object Name et Category ou sélectionnez l'objet dans le panneau de gauche.
Cliquez sur Next pour poursuivre.
Sélectionnez le type de restauration de fichiers partielle à effectuer dans la liste du menu.

Chaque type de restauration de fichiers partielle offre différentes options, à l'exception de la restauration de fichiers partielle des fichiers et dossiers, à laquelle aucune option spécifique n'est associée.
Glissez-déposez les objets du panneau de gauche vers le panneau de droite pour les ajouter à la demande.
Cliquez sur Next pour poursuivre.
Vous devez inclure des paramètres supplémentaires pour les types de restauration de fichiers partielle suivants en cliquant deux fois sur le nom de l'objet après l'avoir déplacé vers le panneau de droite.

Position d'octet (Byte Offset)

Aucune position n'est indiquée tant que vous n'avez pas ouvert la boîte de dialogue Options pour en saisir une manuellement. Ajoutez les paramètres de position (Offset) requis et cliquez sur Add pour les inclure dans la demande.

Code horaire (Timecode)

La liste des formats de fichier est activée une fois que vous avez sélectionné la restauration de fichiers partielle de code horaire. Sélectionnez le format de fichier approprié dans la liste déroulante.

Cliquez deux fois sur l'objet pour ouvrir la boîte de dialogue Options. Ajoutez les paramètres de position (Offset) requis et cliquez sur Add pour les inclure dans la demande.

DPX

Cliquez deux fois sur DPX Frames dans le panneau droit pour ouvrir la boîte de dialogue Options. Ajoutez les paramètres de position (Offset) requis et cliquez sur Add pour les inclure dans la demande.
Après la sélection du type de restauration de fichiers partielle et des options associées à chaque objet, cliquez sur le bouton Next pour accéder à l'écran final.
Renseignez les informations requises dans l'écran final et cliquez sur Send pour envoyer la demande.

Remarque :

Les demandes de restauration de fichiers partielle pour les fichiers au format AVI doivent inclure la même plage de positions (TCin, TCout) pour tous les composants de l'objet (par exemple, clip.avi, clip_1.wav, clip_2.wav).

La liste suivante décrit les paramètres de l'écran final de la demande Send Partial File Restore :

Instance

S'il existe plusieurs instances d'un objet, DIVArchive sélectionnera l'instance qui exécutera la demande le plus rapidement possible (par exemple, une instance de disque sera privilégiée à une instance de bande). La spécification d'un numéro d'instance dans ce champ remplacera ce comportement et ciblera l'instance spécifique identifiée.

Destination

Files Path Root

Dossier racine sur la destination où les fichiers d'objet seront placés. Si ce champ est laissé vide, les fichiers sont placés dans le dossier Files Path Root spécifié lors de l'archivage de l'objet.

Options

No Entry: Aucune saisie dans ce champ indique aucune option.
-login: Un nom d'utilisateur et un mot de passe sont requis pour la connexion à certaines sources. Cette option remplace l'option -gateway des versions précédentes.
-pass: Mot de passe utilisé avec -login.

Quality of Service

L'un des codes suivants :

DIVA_QOS_DEFAULT

La restauration est effectuée en fonction de la qualité de service par défaut (actuellement direct pour les opérations de restauration).

DIVA_QOS_CACHE_ONLY

Utiliser la restauration de cache uniquement.

DIVA_QOS_DIRECT_ONLY

Utiliser la restauration directe uniquement ; aucune instance de disque n'est créée.

DIVA_QOS_CACHE_AND_DIRECT

Utiliser la restauration de cache si disponible ou la restauration directe si la restauration de cache n'est pas disponible.

DIVA_QOS_DIRECT_AND_CACHE

Utiliser la restauration directe si disponible ou la restauration de cache si la restauration directe n'est pas disponible.

DIVA_RESTORE_SERVICE_DO_NOT_OVERWRITE

Ne pas écraser les fichiers existants sur le serveur de destination.

Services supplémentaires

Utilisez la liste du menu pour sélectionner si DIVArchive doit interrompre la demande si le nom du fichier existe déjà sur la destination.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Demandes de restauration multiple (N-Restore)

Si un objet est requis sur de multiples destinations simultanément, la demande Multiple Restore (ou N-Restore) permet de spécifier toutes les destinations nécessaires dans une seule commande et de la soumettre comme une seule demande (au lieu de multiples demandes de restauration standard pour chaque destination). Cette commande offre également des avantages quand la restauration concerne une instance de bande car l'accès à la bande se fait une seule fois pour le transfert au lieu des multiples opérations de lecture nécessaires pour des demandes de restauration uniques du même objet. Cinq destinations simultanées au maximum sont actuellement prises en charge.

Si l'objet à restaurer fait partie d'un ensemble de bandes fragmentées, il doit d'abord être restauré vers le cache avant le transfert vers toutes les destinations. Si le transfert vers l'une des destinations échoue, les autres se poursuivront (si possible) et la demande prendra le statut Partially Aborted.

Si plusieurs règles de modification de nom sont définies, DIVArchive traite la règle pour chaque source/destination indépendamment.

Pour exécuter une demande Multiple Restore, procédez comme suit :

Dans l'onglet Action de la barre de ruban, cliquez sur le bouton Multiple Restore pour ouvrir la boîte de dialogue Multiple Restore Request.
Entrez les paramètres requis dans les champs appropriés.

Pour ajouter des destinations multiples, sélectionnez la destination voulue dans la liste du menu Destination et cliquez sur la flèche double droite pour ajouter la destination sélectionnée dans la zone de texte de la liste des destinations. Répétez cette procédure jusqu'à ce que toutes les destinations voulues soient ajoutées à la liste.
Cliquez sur Send pour traiter la demande.

Demandes de copie

Utilisez la commande Copy pour créer une instance d'un objet existant dans le même groupe ou baie ou dans un autre. Ceci est utile pour créer une copie de sauvegarde de l'objet sur un autre média.

Cette demande soumet une demande de copie d'un objet archivé vers un nouvel objet, avec un autre nom et (ou) catégorie à DIVArchive Manager qui choisit l'instance appropriée comme source de la copie. Tous les types de transfert (disque vers disque, disque vers bande, bande vers disque et bande vers bande) sont pris en charge.

Si l'objet demandé se trouve sur un média qui n'est pas disponible, la demande échoue.

Quand une demande de copie est émise sans aucune instance spécifiée, et qu'il existe plusieurs instances de cet objet, DIVArchive sélectionnera l'instance qui exécutera l'opération de copie le plus rapidement possible (par exemple, une instance de disque sera privilégiée à une instance de bande). Si un numéro d'instance est saisi dans le champ Instance de la demande, l'opération de copie utilise uniquement cette instance.

Pour lancer une demande de copie, cliquez sur le bouton Copy de la barre de ruban, ou sur Objects View dans l'onglet Manage en faisant un clic droit sur l'objet à copier et en sélectionnant Copy dans le menu qui s'affiche.

Les champs suivants sont inclus dans l'écran Copy Request :

Object Name

Nom de l'objet source.

Category

Catégorie de l'objet source.

Instance

Si plusieurs instances de l'objet sont présentes dans DIVArchive, vous pouvez indiquer l'instance spécifique à copier. Si aucune instance n'est spécifiée, DIVArchive sélectionne l'instance offrant le délai d'exécution le plus optimal.

Destination Media

Le média de destination peut être un groupe de bandes ou une baie de disques. Si la nouvelle instance est créée dans le même groupe ou baie, la demande aboutira uniquement si cette instance peut être copiée vers une bande ou un disque distinct.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Demandes de copie en tant que

Quand un objet est archivé dans DIVArchive, il est identifié de façon univoque par les valeurs Object Name et Object Category. Ni le nom ni la catégorie ne peuvent être modifiés une fois que l'objet existe dans la base de données DIVArchive. La commande Copy As permet de créer un nouvel objet dans DIVArchive avec un nouveau nom d'objet et (ou) catégorie, et de supprimer l'objet original si nécessaire (cette opération doit être effectuée manuellement).

Pour lancer la demande Copy As, cliquez sur le bouton Copy As dans la barre de ruban. Vous pouvez également utiliser la vue Objects de l'onglet Manage en faisant un clic droit sur l'objet et en sélectionnant Copy As dans le menu qui s'affiche.

Pour tout objet DIVArchive, le nom d'objet ne doit pas forcément correspondre au nom du fichier sous lequel il est stocké. Si vous utilisez la commande Copy As pour créer un objet DIVArchive, ce dernier sera restauré avec le même nom que celui sous lequel il a été initialement archivé.

Exemple :

Si un fichier nommé xyz est archivé à partir d'un serveur, quel que soit le nom d'objet qui lui a été donné dans DIVArchive, il sera toujours restauré vers une destination en tant que xyz, quel que soit son nom d'objet dans DIVArchive.

Quand une demande Copy As est émise directement depuis la vue Objects, le champ Instance de la demande est automatiquement laissé vide (vous pouvez entrer un numéro d'instance manuellement avant l'émission de la demande). Si ce champ est vide quand la demande est soumise et qu'il existe plusieurs instances de cet objet, DIVArchive sélectionnera l'instance qui exécutera le transfert le plus rapidement possible par défaut (autrement dit, une instance de disque sera privilégiée à une instance de bande). Ceci dépend du paramètre QOS spécifié et de la configuration DIVArchive.

Quand la demande Copy As est émise directement depuis la vue des propriétés d'objet (Object Properties View), le champ Instance de la demande est automatiquement mis à jour avec le numéro de l'instance sélectionnée et seule cette instance est copiée. Les commandes qui sont émises à partir de la vue des propriétés d'objet doivent toujours spécifier un numéro d'instance.

Les champs suivants sont inclus dans l'écran Copy As Request :

Source Object Name

Nom de l'objet source.

Source Object Category

Catégorie de l'objet source.

Destination Object Name

Nom de l'objet de destination.

Destination Object Category

Catégorie de l'objet de destination.

Instance

La sélection de l'option Performance Optimized Instance indique à DIVArchive d'utiliser l'instance qui exécutera la demande le plus rapidement possible, (par exemple, une instance de disque sera privilégiée à une instance de bande).

Destination Media

Destination Storage Plan

Plan de stockage à affecter au nouvel objet sur la destination.

Comments

Les commentaires ajoutés ici seront ajoutés aux propriétés du nouvel objet.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Demandes de copie groupée

La demande Associative Copy fonctionne avec la vue Archived Objects et permet de copier de multiples objets séquentiellement vers une seule bande dans un groupe spécifié. La sauvegarde des objets sélectionnés vers une bande unique afin de pouvoir ensuite l'externaliser en est un exemple.

Pour lancer la demande Associative Copy, cliquez sur le bouton Associative Copy dans la barre de ruban. Vous pouvez également utiliser la vue Objects de l'onglet Manage en faisant un clic droit sur l'objet à copier et en sélectionnant Associative Copy dans le menu qui s'affiche.

Les objets DIVArchive disponibles pour une demande Associative Copy doivent d'abord être obtenus au moyen d'une requête exécutée dans la vue Archive Objects. Vous pouvez cibler un objet spécifique par nom, catégorie, et (ou) date de création.

La copie groupée implique la lecture et l'écriture des fichiers du ou des groupe(s) source vers le groupe de destination, fichier par fichier. DIVArchive garantit que ces instances sont stockées séquentiellement sur les bandes sauf dans les cas suivants :

Cette opération n'est pas compatible avec la fragmentation de bandes. Si aucune bande n'est disponible pour la copie de tous les objets sélectionnés vers une seule bande, la demande est interrompue (et est retentée une fois) au lieu de la fragmentation. Si la somme de la taille des objets à copier dépasse la capacité de chaque bande individuelle présente dans la bibliothèque, la demande est interrompue.
Il n'est pas permis d'avoir deux instances ou plus d'un objet sur la même bande. Ces limites peuvent réduire la plage des bandes pouvant être sélectionnées pour la copie groupée. Si aucune bande appropriée n'est disponible pour satisfaire cette condition, la demande est interrompue.
La demande est terminée uniquement quand chaque objet a été copié sur la même bande.
Si une défaillance de disque ou de bande se produit pendant une opération d'écriture, les instances actuellement écrites sont effacées et la demande est retentée une fois.
Le choix de la bande à utiliser pour la copie suit la stratégie utilisée pour l'opération d'archivage (bandes écrites offrant une taille restante suffisante indépendamment des optimisations).

Les champs suivants sont inclus dans l'écran Associative Copy Request :

Main Display Field

Tous les objets renvoyés par la requête dans la vue Archived Objects sont affichés dans la demande Associative Copy. En revanche, seuls ceux sélectionnés lorsque la commande a été émise sont mis en évidence. Les entrées mises en évidence peuvent ensuite être sélectionnées ou désélectionnées à l'aide des touches CTL ou MAJ combinées avec la souris.

Destination Group

Seuls les groupes de bandes actuellement configurés dans l'utilitaire de configuration sont affichés dans cette liste. Vous devez sélectionner le groupe de destination dans la liste.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Demandes de recompression de bande

La demande Repack Tape envoie une demande de recompression pour la bande sélectionnée ou spécifiée. Une opération de recompression de bande récupère l'espace inutilisable sur une bande en raison des suppressions d'objet et supprime la fragmentation.

Attention :

La fonction de recompression de bande n'est pas destinée à déplacer le contenu d'une bande qui est déjà connu comme générant des erreurs de lecture. Contactez le support Oracle pour obtenir des conseils dans ces cas.

Pour lancer une demande de recompression de bande, cliquez sur le bouton Repack Tape dans la barre de ruban ou sur Tapes View dans l'onglet Home en faisant un clic droit sur la bande à recompresser et en sélectionnant Repack Tape dans le menu qui s'affiche.

La recompression de bande est un processus lent et DIVArchive considère, par défaut, les recompressions de bande comme une opération à priorité faible. Si des demandes ayant une priorité supérieure sont émises, la demande de recompression de bande peut être temporairement suspendue jusqu'à la fin des opérations plus prioritaires. Si des demandes ayant une priorité supérieure sont émises sporadiquement, cela peut donner lieu à des opérations de montage et de démontage fréquentes du lecteur exécutant la recompression. En conséquence, Oracle recommande que les opérations de recompression de bande soient exécutées en dehors des périodes de pointe quand la fréquence des demandes à priorité supérieure est restreinte. Pour prévenir ce type de situation, certaines installations peuvent avoir un lecteur dédié exclusivement aux opérations de recompression de bande.

Le processus de recompression implique les tâches suivantes (dans l'ordre indiqué) :

Montage de la bande source et lecture de tous les objets vers un cache de disque temporaire d'un composant Actor activé pour les opérations de recompression.

Remarque :
Si le cache de disque temporaire est rempli avant la lecture de tous les objets depuis la bande source, DIVArchive passe à l'étape 2 jusqu'à ce que le cache soit vidé. DIVArchive poursuivra ensuite la lecture des objets restants à partir de la bande source. Cette étape se répète jusqu'à ce que tous les objets soient lus.
Montage d'une bande depuis le pool Unused Tapes Sets (Jeux de bandes inutilisées) associé à l'ID jeu du groupe de la bande source.
Ecriture de tous les objets à partir du cache temporaire indiqué dans l'étape 1.
Suppression des objets du cache temporaire après que tous les objets ont été écrits vers la nouvelle bande.
La bande source originale est libérée pour le pool Unused Tapes Sets et n'est plus affectée au groupe.

Si une erreur se produit à un moment ou un autre au cours du processus de recompression à partir de la bande source ou qu'une erreur d'écriture survient sur la bande de destination, la demande de recompression dans son ensemble est interrompue et aucun objet provenant de la bande source n'est supprimé. Si le cache a été rempli lors de la demande de recompression et que les objets ont été écrits avec succès vers une autre bande avant que le cache ne soit vidé, ces objets resteront sur la bande de destination.

Si une erreur de lecture se produit, le statut de recompression et le statut d'écriture de la bande source seront désactivés. Si une erreur de lecture se produit, le statut d'écriture de la bande de destination sera désactivé et la bande ne sera utilisée pour aucune autre opération d'écriture. Vous pouvez consulter le statut d'écriture et de recompression des deux bandes dans l'écran Tape States de l'utilitaire de configuration.

Lors de la recompression d'un média WORM, les boîtes de dialogue normales s'affichent mais un avertissement vous informe que l'espace du média source ne sera pas récupérable une fois la recompression terminée. Les suppressions et les recompressions n'effacent pas le média WORM car ces médias ne sont pas réinscriptibles. Les instances sont supprimées mais l'espace n'est pas récupérable.

Les champs suivants sont inclus dans l'écran Repack Tape Request :

Repack WORM (Write-Once media) with barcode

Code à barres de la bande à recompresser.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Demandes de vérification de bande

La demande Verify Tape lance une relecture de chaque objet sur la bande sélectionnée, un par un, et vérifie les valeurs de checksum.

Pour lancer une demande de vérification de bande, cliquez sur le bouton Verify Tape dans la barre de ruban ou sur Tapes View dans l'onglet Home en faisant un clic droit sur la bande à vérifier et en sélectionnant Verify Tape dans le menu qui s'affiche.

Les champs suivants sont inclus dans l'écran Verify Tape Request :

Verify Tape with barcode

Code à barres de la bande à vérifier.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Demandes d'insertion de bande

Cette demande permet d'insérer des bandes dans une bibliothèque au moyen de son CAP. Vous pouvez uniquement insérer la ou les bande(s) dans le CAP une fois cette commande émise dans certaines configurations de bibliothèque.

Remarque :

Contactez le support technique Oracle pour obtenir des instructions concernant le chargement de bandes en masse dans une bibliothèque.

Pour lancer une demande d'insertion de bande, cliquez sur le bouton Insert Tape situé dans l'onglet Action de la barre de ruban et cliquez sur le bouton Tape Actions.

Le logiciel Sony PetaSite PSC permet d'insérer une bande dans son CAP et de la placer manuellement dans le PetaSite. Dans ce cas, DIVArchive n'est pas informé de l'action par le PSC et ne reconnaît pas la bande tant que la bibliothèque n'est pas auditée à l'aide de l'utilitaire de configuration.

Les champs suivants sont inclus dans l'écran Insert Tape Request :

Require instances on tape

Si cette option est sélectionnée, toutes les instances libérées (Released) sur la bande insérée prennent le statut Requis (Required).

Robot Manager Name

Cette liste spécifie le composant DIVArchive Robot Manager contrôlant la bibliothèque associée pour l'insertion des bandes. Reportez-vous à l'Annexe A pour consulter les informations de licence de DIVArchive.

CAP ID

Cette liste concerne les bibliothèques comportant de multiples CAP. Certaines bibliothèques ne déverrouillent pas le CAP, pour permettre l'insertion de la bande, tant que la commande Insert Tape n'est pas émise. Cette liste permet d'indiquer quel CAP doit être déverrouillé.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Demandes d'éjection de bande

La demande Eject Tape éjecte les bandes sélectionnées de la bibliothèque associée. Vous pouvez sélectionner plusieurs bandes simultanément. Pour lancer une demande d'éjection de bande, cliquez sur le bouton Eject Tape dans la barre de ruban ou sur Tapes View dans l'onglet Home en faisant un clic droit sur la bande à éjecter et en sélectionnant Eject Tape dans le menu qui s'affiche.

Les champs suivants sont inclus dans l'écran Eject Tape Request :

Comments

Il est possible d'ajouter des commentaires quand la bande est éjectée. Ceux-ci permettent d'indiquer son emplacement ou d'autres informations. Vous pouvez afficher les commentaires ultérieurement en consultant les propriétés de cette bande dans la section Tapes View.

Release instances on tape(s)

Si cette option est sélectionnée, toutes les instances d'objet DIVArchive figurant sur la bande en cours d'éjection sont libérées.

Priority

Six valeurs sont prédéfinies comme suit :

MIN
LOW
NORMAL
HIGH
MAX
DEFAULT

Si la case DEFAULT est cochée, le curseur devient inactif et la priorité définie dans la configuration du Manager est utilisée.

Demandes d'exportation et d'importation de bande

La demande Export Tape permet d'exporter une ou plusieurs bandes contenant des objets DIVArchive vers une autre plate-forme DIVArchive indépendante (par exemple, sur un site partenaire ou un site de récupération après sinistre distant). Reportez-vous à l'Annexe A pour consulter les informations de licence de DIVArchive.

Les métadonnées de chaque bande (autrement dit, les noms et catégories d'objet qu'elle contient et leur emplacement sur la bande elle-même) sont conservées dans la base de données Oracle DIVArchive. Pour les objets complexes, ces informations figurent également dans la base des métadonnées. En outre, les métadonnées de chaque bande sont enregistrées dans un fichier XML quand les bandes sont exportées. Le fichier XML transfère les métadonnées de chaque bande vers la base de données de l'autre plate-forme DIVArchive quand les bandes sont importées.

La commande Export Tapes n'est pas utilisée pour le transfert de bandes entre deux bibliothèques ou plus contrôlées par le même composant DIVArchive Manager. Les bandes (et les instances qu'elles contiennent) exportées à partir de DIVArchive à l'aide de cette commande sont également supprimées de la base de données DIVArchive. Si l'objet exporté est la dernière (ou la seule) instance de cet objet, il sera intégralement supprimé de la base de données.

Les nouveaux paramètres suivants ont été ajoutés pour les fonctions d'exportation et d'importation de bande. Tous les fichiers de métadonnées XML exportés à partir de versions DIVArchive précédentes ne seront plus pris en charge.

Pour l'exportation et l'importation d'un média WORM, le fichier XML exporté indique si le média est non réinscriptible ou s'il s'agit d'une cartouche. Ces informations sont importées avec les attributs isWriteOnce et isCartridge définis avec les valeurs true ou false.

L'importation de média WORM est prise en charge par DIVArchive 7.2 et les versions ultérieures. En revanche, si une exportation DIVArchive 7.2 (ou version ultérieure) contenant un média WORM est importée dans une version DIVArchive antérieure (à la version 7.2), le média WORM est ignoré (l'attribut isWriteOnce est défini avec la valeur false) et l'événement est consigné dans le journal du Manager. Le périphérique sera visible dans l'interface graphique (GUI) de contrôle en tant que bande mais sera inutilisable s'il est finalisé ou si aucun lecteur WORM n'est connecté au système.

Le tableau suivant décrit les paramètres d'exportation et d'importation :

Tableau 2-1 Paramètres d'exportation et d'importation

Paramètre	Elément ou attribut XML	Remarques
`objectId`	Attribut de l'élément "object"	Non importé. Un nouvel ID objet est généré lors de l'importation.
`uuid`	Attribut de l'élément "object"	Importé s'il est présent, autrement un nouvel UUID sera généré.
`numFolders`	Attribut de l'élément "object"
`format`	Attribut de l'élément d'objet et attribut de l'élément de bande	`0` = legacy `1` = AXF `-1` = unknown
`numFolders`	Attribut de l'élément "object"
`isHeaderValid`	Attribut de l'élément "object"
`isComplex`	Attribut de l'élément "object"
`footerBeginPos`	Attribut de l'élément	S'il existe dans la base de données
`footerEndPos`	Attribut de l'élément	S'il existe dans la base de données
`compOrderNumBegin`	Attribut de l'élément	S'il existe dans la base de données
`compOrderNumEnd`	Attribut de l'élément	S'il existe dans la base de données
`fileFolderMetadataInfo`	Elément	Valide pour les objets complexes
`fileFolderMetadataInfo-elem`	Elément	Valide pour les objets complexes
`checksums` et `checksum`	Elément	Non valide pour les objets complexes

Pour lancer une demande d'exportation de bande, cliquez sur le bouton Export Tape dans la barre de ruban ou sur Tapes View dans l'onglet Home en faisant un clic droit sur la bande à exporter et en sélectionnant Export Tape dans le menu qui s'affiche.

Les champs suivants sont inclus dans l'écran Eject Tape Request :

Comments: Saisissez des commentaires dans ce champ.
Delete from DB: Si cette option est sélectionnée, la ou les bande(s) sélectionnée(s) sont supprimées de la liste Exported Tapes.
Exported Tapes: Cette zone affiche les bandes sélectionnées pour l'exportation. Ces bandes (et les instances qu'elles contiennent) seront supprimées de la base de données DIVArchive après avoir été exportées. Le cas échéant, sélectionnez les bandes à supprimer dans la listeExported Tapes et cliquez sur Remove Selected.

Fichiers de métadonnées de bande exportée

DIVArchive écrit les métadonnées de chaque bande dans un fichier XML quand les bandes sont exportées depuis votre système. Si un objet est fragmenté entre deux bandes (ou plus), le fichier XML englobe chaque bande de l'ensemble fragmenté. Le format de dénomination du fichier XML des métadonnées de chaque bande est Tapeset-<Barcode>.xml (par exemple, Tapeset-000131.xml).

Le chemin racine sous lequel les fichiers XML sont enregistrés est défini par le paramètre DIVAMANAGER_EXPORT_ROOT_DIR dans le fichier de configuration de DIVArchive Manager (pour ces détails, consultez votre document Configuration de site). Par défaut, le chemin absolu du répertoire racine d'exportation est %DIVA_HOME%\Program\Manager\bin\exported\. A partir de ce chemin racine, les fichiers XML de chaque commande Export Tapes sont enregistrés dans des sous-dossiers en fonction des date et heure de la dernière exécution de la commande.

Workflow d'importation de bande

Pour utiliser la commande importtapes, assurez-vous d'abord que le fichier des métadonnées XML et les fichiers .ffm qui ont été exportés existent dans le système DIVArchive dans lequel ils doivent être importés. Les fichiers doivent exister dans un format non compressé (dézippé) dans le répertoire bin (par défaut) du composant DIVArchive Manager. Le groupe de bandes doit également exister sur le système cible afin que l'importation commence. Ce groupe de bandes n'est pas nécessairement le même groupe que celui auquel la bande a été affectée dans le système source.

Un objet de bande peut être traité de trois façons lors du processus d'importation :

Importé en tant que nouvel objet
Ignoré si l'objet est déjà présent dans le système
Importé en tant qu'instance d'un objet préexistant (dans le base de données DIVArchive) Cette option ne fonctionne correctement que si les checksums correspondent.

Pour plus d'informations, reportez-vous au document Oracle DIVArchive Export/Import User's Guide dans la bibliothèque de documentation de base d'Oracle DIVArchive 7.5

Importation des bandes

Les fichiers XML associées des bandes exportées doivent être copiés dans le répertoire bin de DIVArchive Manager sur la plate-forme sur laquelle ils doivent être importés. Avant d'insérer les bandes dans la bibliothèque, vous devez importer les métadonnées des bandes dans la base de données DIVArchive. Vous devez exécuter cette opération pour chaque bande (ou jeu fragmenté) à importer.

Ouvrez une fenêtre d'invite de commande.
Exécutez les commandes suivantes, dans l'ordre indiqué :
```
cd \%DIVA_HOME%\Program\Manager\bin
importtapes <destination_group> <metadata_file>
```
destination_group

Groupe de bandes auquel la bande (ou le jeu fragmenté) et ses instances seront affectées dans le système de destination.

metadata_file

Nom du fichier XML pour la bande (ou le jeu fragmenté).

Exemple :

La bande portant le numéro de code à barres 000131 contient également des objets qui sont fragmentés sur la bande portant le code à barres 000120. Quand la bande 000131 est exportée, le fichier XML exporté a pour nom Tapeset-000131.xml. Ce fichier .xml englobe également les objets de la bande 000120 et les deux bandes sont éjectées de la bibliothèque.

Une fois tous les objets des deux bandes exportés vers le fichier XML, toutes les instances sur chaque bande (et les références aux bandes elles-mêmes) sont supprimées de la base de données DIVArchive. Le fichier XML est ensuite copié dans le dossier %DIVA_HOME%\Program\Manager\bin du système DIVArchive de destination où il doit être importé.

Pour importer les métadonnées pour cette bande dans le groupe MOVIES, utilisez la commande suivante :

importtapes MOVIES Tapeset-000131.xml

Une fois l'importation des métadonnées de la bande effectuée dans la base de données (vérifiez la file d'attente Current Requests de l'interface graphique (GUI) de contrôle), les bandes et leurs objets sont considérés comme externalisés et peuvent être insérés dans la bibliothèque avec la commande Insert Tape.

Demandes de migration de contenu

La demande Migrate permet la migration de contenu de bande vers un autre groupe de bandes ou baie de disques. Par exemple, si vous effectuez une mise à niveau vers un nouveau type de média dans votre bibliothèque et que vous voulez déplacer le contenu des bandes à l'ancien format hérité vers le nouveau format AXF.

Remarque :

DIVArchive inclut un service de migration intégré (DIVAmigrate). Il s'agit d'un nouveau service interne et distinct (de DIVArchive) qui aide les utilisateurs à planifier et exécuter des travaux pour migrer du contenu entre différents médias au sein d'un système DIVArchive. Vous pouvez utiliser l'interface graphique (GUI) de contrôle ou le client de ligne de commande. Pour plus d'informations, contactez le support technique Oracle.

Ce type de demande est disponible uniquement dans l'écran Tapes View de l'interface graphique (GUI) de contrôle. Il utilise également l'option Oracle DIVArchive Storage Plan Manager (SPM) pour effectuer la migration (SPM doit être installé - Reportez-vous à l'Annexe A pour les informations de licence de SPM). Les emplacements appropriés doivent être configurés pour la migration dans l'onglet Slots de l'utilitaire de configuration. Les emplacements indiquent à DIVArchive quand les opérations de migration doivent être effectuées.

Pour plus d'informations, reportez-vous au document Oracle DIVArchive Storage Plan Manager (SPM) Guide dans la bibliothèque Oracle DIVArchive 7.5 Additional Features Documentation. Reportez-vous également à l'Annexe A pour consulter les informations de licence de DIVArchive.

Une demande de migration effectue les fonctions suivantes (dans l'ordre indiqué) :

Montage des bandes source et émission des demandes de copie à DIVArchive pour effectuer une copie de la bande source vers le média de destination (disque ou bande). Pour tous les objets fragmentés, l'objet doit d'abord être copié vers le cache.
Suppression de l'instance source après que tous les objets ont été copiés vers le nouveau média.
Les objets DIVArchive sont effacés des bandes sources et celles-ci sont renvoyées dans le pool Unused Tapes Sets.

Pour lancer une demande de migration, cliquez sur le bouton Migrate dans la barre de ruban ou sur Tapes View dans l'onglet Home en faisant un clic droit sur la bande dont le contenu doit être migré et en sélectionnant Migrate Content dans le menu qui s'affiche.

Les champs suivants sont inclus dans l'écran Migrate Content Request :

Task Name: Entrez le nom de la tâche de migration dans le champ.
Migrate content from tapes: Cette liste identifie les codes à barres des bandes sélectionnées pour la migration.
Migrate Slot: Sélectionnez l'emplacement de migration à utiliser dans la liste. L'emplacement est défini dans le cadre Slots de l'onglet Storage Plans dans l'utilitaire de configuration. Les emplacements régissent quand les demandes de migration seront envoyées à DIVArchive.
Dest. Medium: Média de destination (groupe de bandes ou baie de disques) pour le contenu migré.

Les travaux du service de migration sont désormais associés à des événements. Tous les événements associés aux travaux sont affichés dans l'onglet Job Events de la boîte de dialogue Job Properties. Par défaut, les événements sont chargés par ordre décroissant, par heure et ID événement. Le tableau Events de l'onglet Job Events associe les événements à différentes couleurs en fonction de leur gravité. La couleur rouge indique une erreur, la couleur jaune indique un avertissement et la couleur blanche indique une information. Si vous cliquez sur le bouton Refresh, vous actualisez l'ensemble de la boîte de dialogue Job Properties.