Riparazione lotti di memoria dai volumi di lotto di memoria di copia contenitore dopo un disastro

Modifica in linea

Se si verifica un disastro su un server di origine, è possibile riparare le estensioni dei dati deduplicati in un pool di archiviazione contenitore di memorie da contenitore di memoria offsite. Il lotto di memoria contenitore - contenitore viene riparato su un server di destinazione in un sito di recupero.

Prima di iniziare

Completare i seguenti passi:

Eseguire il backup del database del server IBM Storage Protect utilizzando uno dei seguenti metodi:
- Nella pagina Operations Center Panoramica , selezionare Server, selezionare un server e fare clic su Backup.
- Immettere il comando di gestione, BACKUP DB.
Esaminare le ultime informazioni sulla riparazione e il recupero dei dati nella technote 2013682.
Per pianificare i passi successivi, esaminare le seguenti limitazioni relative all'uso del comando AUDIT CONTAINER .
Attenzione:
- Se si immette il comando AUDIT CONTAINER con l'impostazione ACTION=MARKDAMAGED per un intero pool di archiviazione, i dati di riferimento non sono disponibili per le operazioni di ripristino fino a quando il pool di archiviazione non viene riparato. A seconda della dimensione del database, della larghezza di banda della rete, della velocità del supporto e di altri fattori, il comando REPAIR STGPOOL potrebbe essere eseguito per ore o giorni. Per questo motivo, se alcuni dati presenti nel lotto di memoria sono disponibili o lo stato dei dati nel lotto di memoria è sconosciuto, seguire queste indicazioni:
  1. Eseguire prima il comando AUDIT CONTAINER con l'impostazione ACTION=SCANALL . L'impostazione ACTION=SCANALL identifica i record del database che fanno riferimento alle estensioni dati con incongruenze. Solo quelle estensioni di dati sono contrassegnate come danneggiate nella banca dati.
  2. Una volta contrassegnate le estensioni come danneggiate, è possibile eseguire il comando REPAIR STGPOOL .
- Se si pianifica di eseguire il comando AUDIT CONTAINER con l'impostazione ACTION=REMOVEDAMAGED , seguire queste linee guida:
  1. Considerare l'esecuzione del comando QUERY DAMAGED per determinare l'ambito delle estensioni dati danneggiate nel lotto di memoria.
  2. Successivamente, è possibile eseguire il comando REPAIR STGPOOL per riparare le estensioni danneggiate nel lotto di memoria.
  3. Infine, è possibile eseguire il comando AUDIT CONTAINER con l'impostazione ACTION=REMOVEDAMAGED per rimuovere eventuali estensioni dati danneggiate che rimangono nel lotto di memoria.

Informazioni su questa attività

Utilizzare la procedura per riparare i seguenti tipi di danni maggiori:

Completa perdita di tutti i lotti di memoria contenitore sul server di origine
Perdita completa del sito principale

Le seguenti ipotesi sono fatte per questo scenario di disaster recovery:

Si stava utilizzando il comando PROTECT STGPOOL per eseguire il back up dei dati in pool di archiviazione copie contenitore offsite da un server di origine. Hai recuperato i volumi di nastro offsite e li hai al tuo sito di recupero.
Non si stava utilizzando il comando PROTECT STGPOOL per eseguire il backup dei dati su un server di replica di destinazione.
Sono stati utilizzati IBM Storage Protect Blueprints per configurare il server di origine IBM Storage Protect e gli script di configurazione Blueprint per ripristinare l'ambiente impostando un nuovo server di destinazione su un sito di ripristino. Gli script hanno copiato le versioni di backup del database IBM Storage Protect , il file delle opzioni del server (dsmserv.opt), il file di cronologia del volume (volhist.out) e il file di configurazione delle unità (devconfig.out) nelle relative ubicazioni originali sul server di recupero. Dopo l'esecuzione degli script, si vedono le directory di nuova creazione, vuote sul server di recupero.

Quando si tenta di riparare un pool di archiviazione contenitore directory da pool copia contenitore, il comando REPAIR STGPOOL non riesce se si verifica una delle seguenti condizioni:

Il pool di archiviazione copie contenitore non è disponibile.
Il pool di archiviazione copie contenitore è danneggiato.
I volumi del lotto di memoria di copia contenitore non sono disponibili o danneggiati.

Procedura

Contrassegnare tutte le estensioni dati nel lotto di memoria del contenitore come danneggiate emettendo il comando AUDIT CONTAINER per il lotto di memoria del contenitore a livello del lotto di memoria e specificando il parametro ACTION=MARKDAMAGED .
Ad esempio, per controllare un pool di archiviazione che si chiama STGPOOL1 e contrassegnarlo come danneggiato, emettere il seguente comando:
```
audit container stgpool=stgpool1 action=markdamaged
```
Se è stato protetto il pool di archiviazione contenitore directory utilizzando sia pool di archiviazione onsite che pool di archiviazione copia contenitore offsite, emettere il comando UPDATE STGPOOL per la copia onsite dei pool di archiviazione copia contenitore e specificare il parametro ACCESS=UNAVAILABLE .
Quando i volumi del pool di archiviazione copia contenitore offsite sono di nuovo onsite, integrarli nella libreria immettendo il comando CHECKIN LIBVOLUME e specificando il parametro STATUS=PRIVATE .
Aggiornare lo stato dei volumi immettendo il comando UPDATE STGPOOL e specificando il parametro ACCESS=READWRITE .
Riparare il lotto di memoria immettendo il comando REPAIR STGPOOL e specificando il parametro SRCLOCATION=LOCAL .
Ad esempio, per riparare un pool di archiviazione che si chiama STGPOOL1 dai lotti di memoria di copia offsite, emettere il seguente comando:
```
repair stgpool stgpool1 srclocation=local
```
Quando si immette il comando REPAIR STGPOOL , le estensioni danneggiate vengono eliminate dal volume immediatamente dopo essere state riparate. Le estensioni danneggiate non vengono conservate in base al valore specificato dal parametro REUSEDELAY .
Confermare che non vi siano ulteriori estensioni danneggiate emettendo il comando QUERY DAMAGED .
Ripetere questa procedura per riparare tutti i tuoi lotti di memoria.