La fonction d'archivage sécurisé externe d'ELS (ELS Vault) remplace et améliore considérablement la fonction précédente, VSM Offsite Vault. La fonction ELS Vault offre les améliorations suivantes en matière d'archivage sécurisé des volumes de bande réels :
Utilisation du CDS HSC pour le stockage de l'archivage sécurisé et des données de volume archivées. L'utilisation des informations d'archivage sécurisé du CDS à la place du TMS évite :
le risque d'erreur humaine lors du renvoi des volumes vers l'environnement automatisé ;
l'arrivée de volumes dans l'emplacement d'archivage sécurisé lorsqu'ils ne figurent pas sur la liste déroulante de renvoi ;
de laisser accidentellement les volumes d'archivage sécurisé renvoyés dans l'environnement automatisé.
Utilisation de LCM pour gérer le processus d'archivage sécurisé, qui dispose de trois méthodes :
archivage sécurisé des MVC pour la récupération après sinistre (DR) ; pour plus d'informations, voir "Archivage sécurisé de MVC pour la récupération après sinistre".
archivage sécurisé des MVC pour la conservation à long terme (LTR) ; pour plus d'informations, voir "Archivage sécurisé de MVC pour la conservation à long terme".
éjection de volumes vers un archivage sécurisé au sol ; pour plus d'informations, voir "Ejection de volumes spécifiques vers un espace d'archivage sécurisé local (sol)".
La première étape consiste à définir la zone de volumes d'archivage sécurisé du CDS HSC. Pour ce faire, exécutez l'utilitaire SLUADMIN SET VAULTVOL. Par exemple :
SET VAULTVOL NBRVOLS(40000)
Remarque :
Si vous avez besoin d'ajouter ultérieurement des volumes d'archivage sécurisé supplémentaires, vous devez utiliser MERGEcds. Il convient donc de définir suffisamment de volumes lors de la définition initiale pour répondre en amont à vos besoins futurs.
Vous devez disposer d'un nombre suffisant de blocs LIBRES dans votre CDS pour pouvoir accueillir le nombre de volumes que vous prévoyez d'archiver (volumes de bande réels), sans oublier un espace supplémentaire pour répondre aux augmentations de volume. Pour plus d'informations sur le calcul de l'espace pour les volumes d'archivage sécurisé, voir Configuration du HSC et du VTCS. Pour savoir comment développer la taille du CDS si elle n'est pas suffisamment vaste pour contenir les volumes archivés, voir Gestion du HSC et du VTCS.
La deuxième étape consiste à définir les espaces d'archivage sécurisé qui contiendront vos volumes archivés. Pour ce faire, exécutez l'utilitaire SLUADMIN SET VAULT pour chaque espace d'archivage sécurisé. Par exemple :
SET VAULT ADD NAME(DRVLT1) SLOTS(10000) DESC(’DR Vault’) SET VAULT ADD NAME(LTRVLT1) SLOTS(20000) DESC(’LTR Vault’) SET VAULT ADD NAME(FLOOR) SLOTS(500) DESC(’Floor Vault’)
Remarque :
Le nombre total d'emplacements dans l'ensemble des espaces d'archivage sécurisé que vous définissez ne doit pas être supérieur au nombre de volumes indiqué dans l'instructionVAULTVOL.Alors que HSC définit les espaces d'archivage sécurisé et les volumes archivés, LCM est responsable de leur gestion. Vous devez particulièrement prendre en compte les paramètres d'archivage sécurisé LCM suivants :
Nombre de jours entre la sélection d'un volume en vue de son renvoi par l'espace d'archivage sécurisé et son renvoi effectif vers l'environnement automatisé. Le délai de grâce offre une marge de sécurité afin que les nouveaux volumes arrivent dans l'espace d'archivage sécurisé avant le renvoi des anciens volumes. Si aucune valeur n'est indiquée, la valeur par défaut est trois jours.
Les paramètres DEFAULT et GRACEPERIOD s'excluent mutuellement. Le premier est généralement utilisé pour l'espace d'archivage sécurisé "au sol" (armoire manuelle), qui contient automatiquement tous les volumes éjectés de l'environnement automatisé à l'aide de LCM EJECT(ASNEEDED). D'autres volumes éjectés de l'ACS peuvent également être affectés à cet espace d'archivage sécurisé ; par exemple, un volume qui est actif mais qui ne constitue plus un bon candidat à l'automatisation. Il s'agit en général d'un espace d'archivage sécurisé défini, qui est constitué d'armoires placées sur le sol du centre de données. DEFAULT représente un délai de grâce de zéro jour, afin de permettre à ces volumes d'être à nouveau entrés dans l'ACS à tout moment.
Notez également que des options d'éjection standard sont disponibles pour tous les volumes d'archivage sécurisé. Elles indiquent par exemple quels CAP utiliser, la définition d'un message d'éjection, le mode utilisé pour les éjections et si ces dernières s'effectueront selon l'ordre des emplacements ou des séries de volume.
Lorsque des MVC sont archivées de façon sécurisée pour la récupération après sinistre, vous devez réaliser au moins deux copies de chaque VTV sur des MVC distinctes, l'une restant sur site, tandis que l'autre est éjectée et placée dans un espace d'archivage sécurisé externe. Cette opération est effectuée en affectant deux classes de stockage sur la classe de gestion qui est affectée au VTV.
Vous souhaitez protéger vos données mais vous voulez utiliser le moins d'espace MVC possible, comme suit :
Définissez un nombre de classes de stockage aussi bas que possible. Un nombre trop élevé de classes de stockage signifie généralement un nombre trop important de MVC et/ou MVC avec peu de VTV.
Utilisez un nombre de VTSS aussi bas que possible pour créer des MVC. Si vous le pouvez, utilisez un seul VTSS pour créer la totalité des MVC d'archivage sécurisé.
Quels sont les autres facteurs à prendre en compte lors de la création et de l'archivage sécurisé des MVC ? Prenez les éléments suivants en considération :
Tout d'abord, les VTV doivent être migrés dès que possible vers des MVC d'archivage sécurisé afin de pouvoir être éjectés et déplacés vers l'espace d'archivage sécurisé, car ces VTV ne sont généralement pas utilisés en entrée pour d'autres étapes du travail.
Ensuite, les VTV de récupération après sinistre expirant à des dates différentes, pensez à les regrouper par dates d'expiration sur les MVC. Toutefois, pour réduire le nombre total de MVC créées à envoyer vers l'espace d'archivage sécurisé, limitez le nombre de ces groupes. Comme une opération visant à consolider les VTV sur un nombre inférieur de MVC aura déjà eu lieu, l'avantage représenté par l'utilisation de plus de deux groupes est minime, à savoir un pour les VTV avec des dates d'expiration très proches, 7 jours par exemple, et l'autre pour tous les autres volumes. Les VTV sous le contrôle du catalogue doivent être considérés comme faisant partie du deuxième groupe, car il n'existe aucun moyen de connaître leur date d'expiration réelle.
Enfin, alors qu'il n'est pas nécessaire de disposer d'espaces d'archivage sécurisé distincts pour la récupération après sinistre et la conservation à long terme, il peut être intéressant de placer les MVC de récupération après sinistre dans un espace d'archivage sécurisé distinct. Cela permet de regrouper ces volumes pour les envoyer au besoin vers le site DR.
Pour les données LTR, les éléments à prendre en compte sont légèrement différents. Tout d'abord, par définition, les données de conservation à long terme n'expireront pas avant t une longue période. Ainsi, contrairement aux données de récupération après sinistre qui expireront à terme, les MVC de conservation à long terme ne seront pas fragmentées. Un traitement périodique initial de ces MVC tentera de remplir autant que possible les MVC archivées, comme c'est le cas pour les MVC de récupération après sinistre, mais une fois qu'elles seront suffisamment remplies, ces MVC resteront statiques. Il n'est pas nécessaire de disposer de plusieurs classes de stockage pour ces volumes. Notez toutefois que vous pouvez vouloir migrer immédiatement certaines données LTR, tandis que d'autres données peuvent être migrées une fois qu'elles auront été sélectionnées par la migration automatique VTCS. Par conséquent, vous voudrez donc peut-être disposer d'une classe de stockage mais de deux classes de gestion pour les données LTR.
Utilisez le paramètre DELSCR de l'instruction MGMTclas pour indiquer si VSM doit supprimer les VTV mis à l'état provisoire (DELSCR(YES)) afin de libérer de l'espace sur le tampon VTSS et de l'espace MVC. Spécifiez DELSCR(YES) pour les classes de gestion DR et LTR. Si vous spécifiez DELSCR(YES), utilisez uniquement la fonction LCM SYNCVTV pour la synchronisation de volumes provisoires. Pour plus d'informations sur l'utilisation de la fonction LCM pour gérer la synchronisation de volumes provisoires, consultez le Guide de l'utilisateur LCM.
Le processus d'entrée de HSC a été modifié pour la fonction d'archivage sécurisé d'ELS, de sorte que chaque volume entré soit vérifié afin de déterminer s'il s'agit d'un volume archivé de façon sécurisée en externe. Pour ce type de volumes, l'une des deux actions suivantes sera exécutée en fonction de la date de renvoi figurant dans l'enregistrement de l'espace d'archivage sécurisé du CDS :
Si la date de renvoi est passée, le volume est entré, les métadonnées de volume stockées qui proviennent du processus d'éjection sont restaurées et le volume est supprimé des enregistrements de l'espace d'archivage sécurisé.
Si la date de renvoi n'est pas passée ou qu'aucune date de renvoi n'a été définie pour le volume, le volume est entré, les métadonnées de volume stockées qui proviennent du processus d'éjection sont restaurées, mais le volume est conservé dans les enregistrements de l'espace d'archivage sécurisé et sera automatiquement éjecté lors du prochain processus d'éjection. Pourquoi cela se passe-t-il ainsi ? Il existe plusieurs raisons à cela, les deux les plus courantes étant les suivantes : le volume a été renvoyé pour un processus de récupération des données, ou le volume incorrect a été retiré de l'espace d'archivage sécurisé (cause très fréquente). Quelle qu'en soit la raison, le volume appartient à l'espace d'archivage sécurisé et sera renvoyé vers cet emplacement, où il reprendra son statut protégé.
Notez qu'il s'agit du processus pour les volumes archivés dans un espace d'archivage sécurisé physique. Pour les volumes archivés dans une bibliothèque distante, le processus est légèrement différent ; voir "Archivage sécurisé DR avec des MVC dans une bibliothèque distante".
Dans un scénario de récupération après sinistre, vous cherchez globalement à optimiser l'utilisation du tampon VTSS, en garantissant une migration rapide des données critiques, tout en conservant la disponibilité des données.
Dans cette approche, des volumes DR sont créés chaque jour. Par conséquent, le traitement de leur déplacement vers l'espace d'archivage sécurisé DR s'effectue chaque jour pour s'assurer que les MVC sont déplacées hors site et protégées en toute sécurité.
Remarque :
Tous les VTV créés à des fins de récupération après sinistre et toutes les bandes natives, notamment la bande du fichier manifeste créée à l'Etape 2 – Exportation des MVC d'archivage sécurisé, sont contrôlés par le TMS du site (pour l'expiration de volume).Ce processus se limite à l'archivage sécurisé des MVC connexes et des volumes natifs sélectionnés impliqués.
Les MVC ne peuvent être affectées qu'à un seul espace d'archivage sécurisé. Pour affecter un volume à un nouvel espace d'archivage sécurisé, son affectation à un espace d'archivage sécurisé antérieur doit d'abord être supprimée.
L'Etape 7 – Préparation des MVC archivées pour le renvoi démarre le traitement périodique, qui permet le recyclage des MVC de récupération après sinistre qui ont été fragmentées ou uniquement remplies partiellement lors de leur création. Pour ce faire, effectuez des purges MVC "logiques" des MVC archivées, en utilisant les copies des VTV toujours actifs qui se trouvent sur les MVC locales. Le traitement périodique réduit le nombre total de volumes dans l'espace d'archivage sécurisé, tout en garantissant que l'ensemble des activités connexes est réduit au minimum grâce à l'utilisation de critères de sélection propres à l'environnement en question. Une fois que la purge "logique" d'une MVC archivée a abouti, la date de renvoi est définie dans le CDS pour ce volume. Dans le cas de volumes natifs, tels que les bandes du fichier manifeste, les volumes qui sont passés à l'état provisoire dans le TMS sont sélectionnés et définis pour le renvoi. Choisissez la fréquence d'exécution du traitement périodique, qui peut être quotidienne ou mensuelle.
Les VTV d'archivage sécurisé de récupération après sinistre sont créés à l'aide d'une classe de gestion qui pointe vers deux classes de stockage, l'une créant des MVC qui resteront dans l'environnement local et l'autre créant des MVC qui sont archivées de façon sécurisée. Par exemple :
STOR NAME(DRLOC)ACS(00) MEDIA(STK1RD) STOR NAME(DRVLT1) ACS(00) MEDIA(STK1RD)
Exportez les MVC d'archivage sécurisé via un fichier de paramètres LCM, comme indiqué dans l'exemple suivant.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
NoSync
GracePeriod(3)
;
Action
Export
Control(Serial )
MVC
DSN(DRVAULT.MANIFEST)
Storageclass(DRVLT1)
Vault('DRVLT')
;
Dans cet exemple :
L'instruction OPTIONS indique NOSYNC et NOTMS, car l'archivage sécurisé n'utilise pas les informations de TMS et aucune métadonnée TMS n'est requise.
L'instruction VAULT indique DRVLT comme espace d'archivage sécurisé de récupération après sinistre.
L'instruction ACTION EXPORT spécifie :
qu'elle exporte des MVC par volser ;
qu'elle crée un fichier manifeste d'exportation (DRVAULT.MANIFEST), ici, un volume de l'ACS qui est éjecté et stocké avec les MVC de récupération après sinistre ;
qu'elle renvoie vers la classe de stockage d'archivage sécurisé créée à l'Etape 1 – Création de VTV/MVC d'archivage sécurisé ;
qu'elle définit l'espace d'archivage sécurisé DR (DRVLT) et lui affecte des MVC qui ne lui étaient pas affectées auparavant.
Remarque :
Les MVC exportées sont marquées en lecture seule par le processus d'exportation.Vous pouvez créer plusieurs classes de stockage d'archivage sécurisé (par exemple, pour séparer les MVC dont les VTV portent des dates d'expiration différentes). Vous pouvez affecter différentes classes de stockage d'archivage sécurisé au même espace d'archivage sécurisé dans une seule instruction ACTION EXPORT. Par exemple, les instructions suivantes affectent les classes de stockage DRVLT1 et DRVLT2 au même espace d'archivage sécurisé (DRVLT) :
Action
Export
Control(Serial )
MVC
DSN(DRVAULT.MANIFEST)
Storageclass(DRVLT1
DRVLT2)
Vault('DRVLT')
;
Une fois que vous avez créé la bande du fichier manifeste à l'Etape 2 – Exportation des MVC d'archivage sécurisé, vous pouvez exécuter un travail qui copie le jeu de données de contrôle (CDS) HSC, le catalogue TMS, le catalogue système et d'autres jeux de données "ponctuels" importants sur la bande du fichier manifeste afin de fournir des points de reprise DR supplémentaires.
Ejectez des MVC d'archivage sécurisé via un fichier de paramètres LCM, comme indiqué dans l'exemple suivant.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Eject
When(
(inLsm)
and
(VaultName EQ 'DRVLT')
Control(Serial)
Ejmsg('Move to DR Vault')
;
Dans cet exemple :
L'instruction OPTIONS indique NOSYNC et NOTMS, car l'archivage sécurisé n'utilise pas les informations de TMS et aucune métadonnée TMS n'est requise.
L'instruction VAULT indique DRVLT comme espace d'archivage sécurisé de récupération après sinistre.
L'instruction ACTION EJECT spécifie :
qu'elle éjecte par volser les MVC affectées à DRVLT ;
le message d'éjection.
Ejectez des volumes natifs (y compris la bande du fichier manifeste) à l'aide d'un fichier de paramètres LCM, comme indiqué dans l'exemple suivant.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Eject
When(
(InLsm)
and
(DataSetName EQ 'DRVLT.MANIFEST')
and
(TMSScratch EQ False)
)
Control(Serial)
Ejmsg('Move to DR Vault')
;
Dans cet exemple :
L'instruction OPTIONS indique NOSYNC, car l'archivage sécurisé n'utilise pas les informations de TMS.
L'instruction VAULT indique DRVLT comme espace d'archivage sécurisé de récupération après sinistre.
L'instruction ACTION EJECT spécifie :
Ejectez la bande du fichier manifeste.
Ejectez les volumes natifs qui n'ont pas été supprimés par le TMS.
le message d'éjection.
Créez une liste déroulante à l'aide d'un fichier de paramètres LCM, comme indiqué dans l'exemple suivant.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Report
Volume
Sysout(*)
Title('Return Report')
When(
(VaultName EQ 'DRVLT')
and
(VaultReturnDate LE TODAY)
and
(VaultReturnDate NE MISSING)
)
Column (Serial,
VaultSlot)
;
Dans cet exemple :
L'instruction OPTIONS indique NOSYNC et NOTMS, car l'archivage sécurisé n'utilise pas les informations de TMS et aucune métadonnée TMS n'est requise.
L'instruction VAULT indique DRVLT comme espace d'archivage sécurisé de récupération après sinistre.
L'instruction REPORT VOLUME crée un rapport qui répertorie les volumes dans l'espace d'archivage sécurisé qui ont atteint la date de retour qui leur a été précédemment affectée. Il s'agit d'un exemple simple, mais vous pouvez ajouter des critères de sélection supplémentaires pour les volumes à renvoyer.
Remarque :
TODAY et MISSING sont des valeurs de date uniques. TODAY correspond à la date d'exécution de LCM. MISSING indique qu'il n'y a pas de valeur de date. Dans cet exemple, aucune date n'a été définie. Les deux conditions sont requises car une absence de date reviendrait à indiquer Less Than (antérieure à la date actuelle).
Les étapes 4, 5 et 6 peuvent être combinées au sein d'une étape de travail unique. Dans certains cas, l'étape 6 est exécutée périodiquement, en général la veille de la date prévue pour le renvoi des volumes par l'espace d'archivage sécurisé.
Préparez les MVC archivées pour le renvoi via un fichier de paramètres LCM, comme indiqué dans l'exemple suivant.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Drain
When(
(MVC EQ True)
and
(VaultName EQ 'DRVLT')
and
(MVCVTVCount LE 30)
and
(MVCInUse LE 30)
and
(Days_Since(VaultAssignmentDate) GT 7)
)
Control(MVCVTVCount
Ascending)
Limit(30)
;
Dans cet exemple :
L'instruction OPTIONS indique NOSYNC et NOTMS, car l'archivage sécurisé n'utilise pas les informations de TMS et aucune métadonnée TMS n'est requise.
L'instruction VAULT indique DRVLT comme espace d'archivage sécurisé de récupération après sinistre.
Pour les MVC qui se trouvent actuellement dans l'espace d'archivage sécurisé DR, l'instruction ACTION DRAIN spécifie une purge des MVC qui :
contiennent moins de 30 VTV ;
sont utilisés moins de 30 % du temps ;
sont restés dans l'espace d'archivage sécurisé pendant au moins 7 jours ;
limitent le nombre de MVC renvoyées à 30 au maximum ;
comportent une date de renvoi définie sur 3 jours par le paramètre GracePeriod.
Lorsque vous créez un fichier de paramètres pour purger des MVC, vous voulez définir un juste milieu entre les cycles de traitement de la purge et le recyclage nécessaire des MVC fragmentées ou partiellement remplies. Les paramètres MVCVTVCount, MVCInUse, Days_Since et LIMIT permettent de trouver un équilibre entre ces conditions requises.
Préparez les volumes natifs pour le renvoi via un fichier de paramètres LCM, comme indiqué dans l'exemple suivant.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Vault
Return
When(
Not (MVC)
and
(VaultName EQ 'DRVLT')
and
(TMSScratch EQ True)
)
;
Dans cet exemple :
L'instruction OPTIONS indique NOSYNC, car l'archivage sécurisé n'utilise pas les informations de TMS.
L'instruction TMS RMM est nécessaire pour ajouter le traitement des métadonnées TMS.
L'instruction VAULT indique DRVLT comme espace d'archivage sécurisé de récupération après sinistre.
L'instruction ACTION VAULT RETURN définit une date de renvoi (à l'aide du paramètre GracePeriod) pour les volumes qui ne sont pas des MVC et qui sont à l'état provisoire dans le TMS.
Les volumes qui apparaissent sur le rapport créé à l'Etape 6 – Création d'une liste déroulante de volumes pour renvoi à partir de l'espace d'archivage sécurisé sont supprimés de l'espace d'archivage sécurisé DR et renvoyés vers l'environnement local. Lorsque vous entrez ces volumes dans l'ACS, HSC vérifie pour chaque volume si la date de renvoi affectée pour l'espace d'archivage sécurisé est passée. Si tel est le cas, le volume a atteint sa date de renvoi planifiée et est supprimé de l'espace d'archivage sécurisé. Les MVC renvoyées sont ensuite éligibles pour la migration et les volumes natifs sont mis à l'état provisoire dans le CDS lors du traitement LCM SYNC suivant. Si la date de renvoi pour l'espace d'archivage sécurisé n'est pas passée, le volume est éjecté par l'Etape 4 – Ejection de MVC d'archivage sécurisé.
Si vous le souhaitez, vous pouvez combiner les étapes 7 et 8 dans un fichier de paramètres LCM unique, comme indiqué dans l'exemple suivant :
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Drain
When(
(MVC EQ True)
and
(VaultName EQ 'DRVLT')
and
(MVCVTVCount LE 30)
and
(MVCInUse LE 30)
and
(Days_Since(VaultAssignmentDate) GT 7)
)
Control(MVCVTVCount
Ascending)
Limit(30)
;
Action
Vault
Return
When(
Not (MVC)
and
(VaultName EQ 'DRVLT')
and
(TMSScratch EQ True)
)
;
Certains sites peuvent choisir d'utiliser un processus qui dure plusieurs semaines, dans lequel le traitement de la récupération après sinistre inclut une sauvegarde hebdomadaire des données critiques sur la totalité des volumes, suivie de sauvegardes incrémentielles quotidiennes les six jours suivants. Le processus d'archivage sécurisé externe déplace les volumes hors site le jour de sa création. Ce processus suppose un cycle de quatre semaines qui conserve les données de récupération après sinistre hors site et se termine au début de la quatrième semaine. Notez que la seule modification entre la procédure Archivage sécurisé DR de base avec des MVC et le processus qui dure plusieurs semaines réside dans la différence de critères de sélection pour les étapes 7 et 8, comme indiqué ci-dessous. Pour ce faire, définissez les dates d'expiration de sorte que les VTV d'archivage sécurisé sur les MVC associées et les bandes du fichier manifeste (ainsi que toute autre bande native impliquée) expirent tous 22 jours après leur création.
L'échéancier sur plusieurs semaines se présente comme suit :
Jour 1 – Sauvegardes sur la totalité des volumes (expiration le jour 22).
Jour 1 – Sauvegarde incrémentielle n°1 (expiration le jour 22).
Jour 3 – Sauvegarde incrémentielle n°2 (expiration le jour 22).
Jour 4 – Sauvegarde incrémentielle n°3 (expiration le jour 22).
Jour 5 – Sauvegarde incrémentielle n°4 (expiration le jour 22).
Jour 6 – Sauvegarde incrémentielle n°5 (expiration le jour 22).
Jour 7 – Sauvegarde incrémentielle n°6 (expiration le jour 22).
Jours 8 à 21 – Les volumes restent hors site.
Jour 22 – Les sauvegardes et les bandes du fichier manifeste réalisées entre les jours 1 à 7 expirent et les VTV passent en mode provisoire dans le CDS via le processus LCM VTVSYNC. Les MVC sont purgées à l'aide du paramètre suivant dans les critères de sélection de l'Etape 7 – Préparation des MVC archivées pour le renvoi et de l'Etape 8 – Préparation des volumes natifs archivés pour le renvoi.
DAYS SINCE (VaultAssignmentDate) GT 15
La date de renvoi pour les MVC purgées et les bandes du fichier manifeste est définie sur le jour 25.
Remarque :
Toutes les MVC affectées à l'espace d'archivage sécurisé au cours des 7 premiers jours du cycle sont purgées. Si la date d'expiration des VTV de récupération après sinistre a été définie correctement, il ne doit y avoir aucun VTV en cours à ce stade et le processus de purge logique s'exécutera rapidement. Si les VTV en cours sont écrits sur une nouvelle cartouche MVC, une date d'expiration incorrecte a peut-être été définie.Jours 23 et 24 – Les volumes restent hors site.
Jour 25 – Les volumes archivés entre les jours 1 à 7 sont renvoyés, sortent de l'état archivé et sont disponibles pour la réutilisation.
Jour 29 – Le cycle se répète.
Remarque :
Certains sites peuvent choisir de ne prendre hors site que les sauvegardes sur la totalité des volumes, en conservant les sauvegardes incrémentielles sur site. Dans ce cas, placez les MVC incrémentielles, ainsi que les volumes natifs et de fichier manifeste connexes dans un conteneur verrouillé et non rouvert jusqu'à son renvoi le jour 25. A ce stade, tous les volumes créés le jour 1 doivent avoir expiré.Dans ce processus, les volumes sont archivés dans une bibliothèque distante (ACS) au lieu d'être archivés dans un espace d'archivage sécurisé physique. Ce processus est similaire à celui présenté à la section Archivage sécurisé DR de base avec des MVC, avec les exceptions suivantes :
Etapes 1 à 3 - Aucune modification.
Etape 4 - Supprimée car aucune MVC archivée n'est éjectée.
Etape 5 - Comme dans l'étape 4, les volumes natifs ne sont pas éjectés. A la place, une instruction Action Vault Assign affecte des volumes natifs à l'espace d'archivage sécurisé à l'aide des mêmes critères de sélection que ceux utilisés pour l'exécution et l'éjection de ces volumes natifs, comme indiqué dans l'exemple suivant.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Vault
Assign
Vault('DRVLT')
When(
(InLsm)
and
(DataSetName EQ 'DRVLT.MANIFEST')
and
(TMSScratch EQ False)
)
;
Etape 6 - Supprimée car aucun volume n'est réentré.
Etape 7 - Aucune modification.
Remarque :
Le traitement de la purge s'effectuant au sein de la bibliothèque distante, les purges s'exécutent plus efficacement que le traitement de la purge logique des volumes dans un espace d'archivage sécurisé manuel.Etape 8 - Aucune modification.
Etape 9 - Dans le processus de base, l'affectation de l'espace d'archivage sécurisé est supprimée par le traitement de l'entrée qui n'a pas lieu dans le scénario de bibliothèque distante. Pour supprimer le volume archivé, utilisez l'instruction Action Vault Release. Les volumes archivés à libérer sont sélectionnés par le biais des paramètres Vault Name et Return Date,comme c'était le cas précédemment pour la génération d'une liste déroulante. L'instruction Action Vault Release ne traite que les volumes archivés dont la date de renvoi (Return Date) est passée.
Vous trouverez ci-dessous un exemple d'instruction Action Vault Release.
Options
NoSync
NoTMS
;
Vault
Name('DRVLT')
GracePeriod(3)
;
Action
Vault
Release
When(
(VaultName EQ 'DRVAULT')
and
(VaultReturnDate LE TODAY)
and
(VaultReturnDate NE MISSING)
)
;
Le processus d'utilisation des MVC dans la conservation à long terme (LTR) est pratiquement identique à celui décrit dans le processus de base pour la récupération après sinistre, qui est présenté à la section "Archivage sécurisé DR de base avec des MVC". Les deux principaux éléments à prendre en compte pour la conservation à long terme sont les suivants :
Il est possible que le déplacement vers l'espace d'archivage sécurisé, Etape 2 – Exportation des MVC d'archivage sécurisé à "Etape 5 - Ejection de volumes natifs (y compris de la bande du fichier manifeste)", ne soit pas effectué quotidiennement, afin que davantage de volumes LTR soient complètement remplis avant leur archivage sécurisé.
Les VTV de conservation à long terme n'expirant pas avant une longue période, le processus périodique décrit risque de se produire à des intervalles moins fréquents. Etant donné qu'il y aura toujours des MVC LTR qui ne seront que partiellement remplies, ce type de MVC, qui contient moins de VTV et utilise moins de MVC, devra être traité à un moment, afin que les VTV situés sur les MVC partiellement remplies soient consolidés sur un nombre inférieur de MVC LTR.
Il sera peut-être nécessaire d'effectuer les purges logiques des MVC LTR ultérieurement pour déplacer les données archivées vers un nouveau média. Le processus de base exécute facilement cette activité en sélectionnant simplement les critères appropriés et en limitant le nombre de MVC LTR archivées qui sont traitées simultanément. Lors de chaque exécution, les VTV encore actifs sont déplacés vers le nouveau média, les nouvelles MVC sont déplacées vers l'espace d'archivage sécurisé et les MVC purgées logiquement sont renvoyées en vue de leur réutilisation ou destruction.
De nombreux sites demandant la suppression de volumes spécifiques dans l'environnement automatisé, ils doivent stocker efficacement ces volumes dans des armoires au sein de l'environnement local. Cette exigence peut venir du fait qu'ils ne souhaitent plus utiliser certains volumes, ou qu'ils désirent garder les volumes disponibles pendant un certain temps. Plusieurs espaces d'archivage sécurisé locaux/au sol peuvent être définis. Des volumes spécifiques peuvent être envoyés vers différents espaces d'archivage sécurisé, mais un seul espace d'archivage sécurisé local/au sol peut être défini en tant qu'espace d'archivage sécurisé par défaut. La date en cours est automatiquement affectée comme date de renvoi à tous les volumes placés dans un espace d'archivage sécurisé local/au sol. Ainsi, ces volumes peuvent être renvoyés vers l'environnement automatisé et supprimés de l'espace d'archivage sécurisé qui leur a été affecté sans qu'aucune action supplémentaire ne soit nécessaire.
L'exemple suivant présente un exemple de fichier de paramètres LCM pour l'éjection de volumes spécifiques vers un espace d'archivage sécurisé au sol.
Options
NoSync
;
TMS
RMM
Dateform(J)
DDname(LCMTMSDB)
;
Vault
Name('FLOOR')
Default
;
Action
Eject
When(
(InLsm EQ True)
and
(DaysSinceReference GT 100)
and
(MVC EQ False)
and
Not
(DataSetName Matches 'HMIG.**')
)
Control(
VaultSlot
Ascending
)
Ejmsg('Move to Floor Vault')
;
Manage
ACSID(00)
Numfree(500)
;
Dans cet exemple :
L'instruction OPTIONS indique NOSYNC, car l'archivage sécurisé n'utilise pas les informations de TMS.
L'instruction TMS RMM est nécessaire pour ajouter le traitement des métadonnées TMS.
L'instruction VAULT indique FLOOR comme espace d'archivage sécurisé au sol par défaut.
L'instruction ACTION EJECT indique d'éjecter vers l'espace d'archivage sécurisé au sol les volumes qui :
se trouvent dans le LSM ;
n'ont pas été référencés depuis plus de 100 jours ;
ne sont pas des MVC ;
ont pour masque de nom de jeu de données HMIG.**.
L'instruction ACTION EJECT spécifie également :
que les volumes sont traités par ordre volser croissant ;
que l'éjection s'effectue par numéros d'emplacement TMS.
le message d'éjection.
L'instruction MANAGE spécifie :
que les volumes situés dans l'ACS 00 sont gérés ;
que la présence de 500 cellules libres est garantie dans l'ACS.