NetWorker: come eseguire il debug delle operazioni di backup (in inglese)

File di registro:

I registri principali per il debug degli errori di backup sono i file di registro delle policy che si trovano nella seguente posizione.

Linux: /nsr/logs/policy_name/workflow_name/action_name
Windows: ..Program FilesEMC NetWorkersrlogs policy_nameworkflow_nameaction_name

Sono disponibili file di log del flusso di lavoro in formato raw in /nsr/logs/policy/policy_name/workflow_name/jobid.raw e una sottodirectory per ogni azione. Ogni azione figlio di un'azione dispone di un proprio file di log con il jobid del job figlio. Quando l'azione padre avvia un'azione figlio, NetWorker crea una directory per questi log delle azioni figlio.

Esempio:

Qui è possibile vedere la posizione dei log delle policy e che i log sono di dimensioni diverse a seconda del livello di debug utilizzato durante il backup.  I file raw sono i log del flusso di lavoro, mentre le directory backup_[jobid]_logs contengono i log delle azioni e i log delle azioni figlio.

Il file di log principale di NetWorker per tutte le operazioni di NetWorker è il file di log daemon.raw . 

Si trova in [NetWorker_install_dir]logs.
 

Per leggere questo registro, utilizzare il comando nsr_render_log .

Esempio:

Altre risorse:

Salvare sul client NetWorker

I backup basati su client NetWorker utilizzano il processo di salvataggio. Il processo di salvataggio comunica con il server NetWorker, lo storage node (ove applicabile) o il supporto del dispositivo di backup di destinazione. È possibile abilitare il debug nel processo di salvataggio passando il flag -D debug al processo di salvataggio tramite NetWorker Management Console (NMC) o il comando nsradmin.

In NMC, modificare il campo "Backup command" nelle proprietà del client pertinenti in "save -D9":

Esempio:

È possibile eseguire la stessa operazione utilizzando il comando nsradmin:

Esempio:

In alternativa, su un sistema Linux, è possibile utilizzare il comando printf per eseguire questa modifica nsradmin in una riga:

Esempio:

printf "show 
 . type : NSR Client; name : vm-lego-231; save set : /alice
 update backup command : save -D9
" | nsradmin -i -

Altre risorse:

Guida
di riferimento ai comandi di NetWorker Come utilizzare il controllo della convalida nsradmin di NetWorker
Utilizzi speciali per il programma NetWorker nsradmin Nota tecnica

Operazione del flusso di lavoro sul server NetWorker 

È necessario eseguire il debug dell'avvio di un'operazione del flusso di lavoro e l'output di debug dettagliato.

nsrworkflow -D9 -p [criterio] -w [flusso di lavoro]

In questo modo l'output di debug del job del flusso di lavoro viene registrato nel file raw in:

/nsr/logs/policy/policy_name/workflow_name/

Esempio:

L'esecuzione del comando nsrworkflow avvia il processo manualmente, ma utilizza le stesse opzioni di pianificazione e configurazione del livello utilizzate per i backup automatici pianificati.  Un'altra possibilità consiste nell'utilizzare il flag -a per definire l'esecuzione di nsrworkflow come backup ad hoc, che consente di sovrascrivere la pianificazione o il livello di backup.  Per specificare il livello di backup desiderato (non quello impostato per l'esecuzione odierna del flusso di lavoro), utilizzare -l (o -L per i backup delle macchine virtuali).

Esempio:

nsrworkflow -p [policy] -w [workflow] -A "'[azione]' -l [livello]" -a
nsrworkflow -p Mona -w Bokonon_wf -A "'backup' -l full" -a

Altre risorse:

516616 : Come utilizzare il comando
nsrworkflow di NetWorker513030 :                                                                     Come usare il comando
nsrpolicy di NetWorkerNote di rilascio di NetWorker 9.1.x: 
Guida di riferimento ai comandi di NetWorker

Savefs sul client NetWorker

Il comando savefs viene utilizzato durante i backup basati su client. Viene inviato al client NetWorker dopo l'avvio del backup sul server NetWorker.  savefs è un processo responsabile della determinazione dei file e delle directory di cui eseguire il backup per l'esecuzione di questo backup specifico su questo client.

È possibile ottenere il comando savefs esatto in esecuzione sul lato client dal file raw nei registri delle policy (/nsr/logs/policy/[policy name]/[workflow name]).  Quindi eseguire questa operazione sul lato client, aggiungendo l'opzione -D9:

Esempio:

Sul server NetWorker: 

Sul lato client:

Altre risorse:

Assegnazione del supporto di destinazione sul server NetWorker

L'assegnazione del volume di destinazione corretto per un backup è gestita dal processo nsrd sul server NetWorker.  Per eseguire il debug di questa funzionalità, è necessario aumentare temporaneamente il livello di debug del processo nsrd sul server NetWorker utilizzando il comando dbg.

Esempio:

Al termine del debug, è necessario disattivare il debug in questo modo:

Altre risorse:

336123 : NetWorker Debug

Backup in attesa di volume scrivibile

Se il server NetWorker non riesce a trovare un volume NetWorker adatto su cui scrivere, smetterà di rispondere e genererà un avviso.  In questo caso, il lavoro sarà nello stato "active".  È possibile controllare lo stato del lavoro utilizzando il comando nsrpolicy monitor .

Esempio:

L'avviso in NetWorker Management Console fornisce ulteriori dettagli sul tipo di volume cercato e sullo storage node.

Esempio:

Altre risorse:

I backup hanno smesso inaspettatamente di rispondere a causa del parallelismo

Se il server NetWorker determina che non può continuare con il backup perché non esiste uno slot di parallelismo libero.  In questo caso, il processo è nello stato

"queued".Per eseguire il debug del parallelismo, è necessario aumentare il livello di debug del processo nsrjobd sul server NetWorker, come illustrato di seguito.  Il file di log del daemon genera molti dati di debug relativi al parallelismo.

Esempio:

Altre risorse:

Guida
alla pianificazione dell'ottimizzazione delle prestazioni di NetWorkerParallelismo e sessioni di destinazione

Il backup Client Direct non funziona come previsto

Un backup "Client Direct" invia i dati direttamente dal client NetWorker al supporto di destinazione senza prima scrivere sullo storage node NetWorker.

È possibile definire nelle proprietà del client se è necessario utilizzare o meno il backup client direct per questa istanza client.

Per risolvere i problemi relativi al funzionamento o meno di Client Direct, è necessario ispezionare i registri come indicato nell'esempio seguente:

Esempio:

Output del registro: Client Direct in funzione.

File di log dei daemon sul server NetWorker:

91787 01/08/2014 13:37:35 nsrmmd NSR notice L'ID saveset '4091251191' (vm-lego-231:/NetWorker) usa il salvataggio diretto dei file con il dispositivo Data Domain 'dd4500-dd.local_onetwoone'.

lsof sul client NetWorker

[root@vm-lego-231 ~]# lsof -i TCP | grep save
save 9831 root 3u IPv4 111668 0t0 TCP vm-lego-231:23178-vm-lego-121>:8985 (ESTABLISHED)
save 9831 root 5u IPv4 111695 0t0 TCP vm-lego-231:19752-vm-lego-121>:9417 (STABILITO)
save 9831 root 7u IPv4 111720 0t0 TCP vm-lego-231:31095-vm-lego-121>:9035 (STABILITO)
save 9831 root 8u IPv4 111728 0t0 TCP vm-lego-231:12421-vm-lego-121>:9653 (STABILITO)
save 9831 root 9u IPv4 111731 0t0 TCP vm-lego-231:33739-dd4500-dd.local>:nfs (ESTABLISHED)
save 9831 root 10u IPv4 111736 0t0 TCP vm-lego-231:60278-dd4500-dd.local>:midnight-tech (STABILITO)

Nota: Possiamo vedere che sono presenti connessioni TCP aperte dal client sia al server NetWorker che a DD.  Se è necessario sapere a quali processi sono connessi esattamente sul server NetWorker, è possibile eseguire un controllo incrociato con lsof sul server.  La quarta colonna è il descrittore di file in uso. 

Su un sistema Windows, è possibile visualizzare un output simile utilizzando resmon:  Start - Esegui - resmon - Scheda Rete - Connessioni TCP

Output del registro:  Il backup non utilizza Client Direct.

File di log dei daemon sul server NetWorker:

91797 01/08/2014 13:57:51 nsrmmd NSR grave Impossibile eseguire il salvataggio diretto dei file con il dispositivo Data Domain 'ONETWOONE'; impostazione del salvataggio tradizionale per l'ID saveset '4024143566' (vm-lego-231:/NetWorker)

Nota:  La ricerca della parola tradizionale nel registro ti dà questo output rapidamente.  Per scoprire il motivo per cui non utilizza Client Direct, iniziare con l'elenco delle condizioni che devono essere soddisfatte per il funzionamento di Client Direct presente nella Guida all'amministrazione di NetWorker.  I motivi più comuni potrebbero essere che il client non ha accesso diretto alla rete a DD dalla scheda di rete che utilizza o che la risoluzione dei nomi non funziona correttamente dal client.

lsof sul client NetWorker:

[root@vm-lego-231 ~]# lsof -i TCP | grep save
save 10114 root 3u IPv4 123335 0t0 TCP vm-lego-231:46461-vm-lego-121>:8985 (ESTABLISHED)
save 10114 root 5u IPv4 123369 0t0 TCP vm-lego-231:12593-vm-lego-121>:9417 (ESTABLISHED)
save 10114 root 7u IPv4 123392 0t0 TCP vm-lego-231:63952-vm-lego-121>:9035 (ESTABLISHED)
save 10114 root 8u IPv4 123400 0t0 TCP vm-lego-231:29597-vm-lego-121>:9653 (STABILITO)

Nota:  Qui sono aperte solo le connessioni TCP al server NetWorker (che in questo esempio è anche lo storage node).  Non vi è alcuna connessione TCP aperta a DD.  Tutti i dati vengono inviati allo storage node.

Altre risorse:

NetWorker Performance Optimization Planning Guide

Backup paralleli del flusso di salvataggio

Per eseguire il debug dei backup PSS. Assicurarsi che la proprietà 'parallel save stream' sia selezionata nella risorsa client in NetWorker Management Console.  Modificare il comando di salvataggio per metterlo in debug come indicato al numero 1 riportato sopra.  Inoltre, creare un file vuoto in .. /nsr/debug chiamato 'mbsdopen'.  Ciò fornisce una registrazione di debug aggiuntiva sia sul client in /nsr/tmp che nei log delle policy sul server NetWorker (vedere il numero 1 sopra).

Esempio:

Altre risorse:

Come risolvere i problemi relativi ai
backup NetWorker Parallel Save StreamGuida alla pianificazione dell'ottimizzazione delle prestazioni di NetWorker

Il processo nsrmmd dello storage node NetWorker non funziona come previsto durante la scrittura sul supporto di destinazione.

È possibile aumentare il livello di debug dei processi nsrmmd usando il comando dbg(descritto nel numero 7 sopra).  È possibile aumentare il livello di debug di tutti i processi nsrmmd oppure usare gli strumenti del sistema operativo per identificare quale processo nsrmmd è attivo:

Altre risorse:

479665 : Triage Article: Risoluzione dei problemi relativi alle librerie a nastro in NetWorker
Guida all'integrazione di NetWorker Data Domain Boost

Altri suggerimenti di debug per tecnologie NetWorker specifiche:

• ottimizzazione del server NetWorker per prestazioni ottimali (in inglese)

• NVP-vProxy: Come abilitare la registrazione di debug  

• Come testare la comunicazione client-server NetWorker tramite un firewall 

• Come risolvere gli errori di clonazione pianificata di NetWorker

• Guida alla risoluzione dei problemi di NetWorker: Arresti anomali dei processi e core dump

• NetWorker NMC 9.x: Procedura: Come abilitare i registri di debug

• Come abilitare il debug per NMDA

• Guida dettagliata alla risoluzione dei problemi di NMM

• Come eseguire il debug degli errori dei job di ripristino da NMC          

• NDMP Triage Guide           

• 479591 : Recupero di spazio dalla guida alla valutazione dei dispositivi Data Domain