Devo eseguire una verifica sui backup su nastro LTO anche se le unità stesse eseguono la verifica mentre scrivono?

Abbiamo un'unità nastro LTO-3 in una libreria multimediale Dell che utilizziamo per i nostri backup su nastro. L' articolo su LTO su Wikipedia afferma che:

LTO utilizza una tecnologia di verifica dopo scrittura automatica per controllare immediatamente i dati mentre vengono scritti, ma alcuni sistemi di backup eseguono esplicitamente un'operazione di lettura del nastro completamente separata per verificare che il nastro sia stato scritto correttamente. Questa operazione di verifica separata raddoppia il numero di passaggi end-to-end per ciascun backup pianificato e riduce la durata del nastro della metà.

Quello che vorrei sapere è: ho bisogno del mio software di backup (Backup Exec in questo caso) per eseguire una verifica su questi nastri o è sufficiente la tecnologia di verifica dopo scrittura inerente alle unità LTO?

Sarei anche curioso di sapere se Backup Exec comprende la tecnologia di verifica dopo scrittura abbastanza per avvisarmi se tale tecnologia non è in grado di verificare i dati o semplicemente li ignorerà rendendoli comunque inutili poiché anche se l'unità rileva un problema non avrei mai saperlo.

backup tape

— Chris Magnuson
fonte

Risposte:

Ottima domanda!

Mentre direi che sì, dovresti testarli, direi che testare i nastri / le unità in sé è importante, ciò che è molto più vitale è testare il processo di restauro end-to-end .

Non posso raccomandare abbastanza restauri di sistema completi regolari e test di servizio, è l'unico modo per sapere con certezza che l'intero sistema sta facendo quello per cui lo hai acquistato. Non devi guardare lontano su questo sito per vedere le persone che lottano per ripristinare il loro servizio anche se pensavano di aver coperto tutti i passaggi individualmente.

Spero che sia di aiuto.

— Chopper3
fonte

+1 per il ripristino. È a questo punto che mi interesso con "macchine virtuali!" - il ripristino su una macchina virtuale può essere un buon indicatore non distruttivo che il backup è utile

— Sirex,

Quello che dici è sicuramente una buona idea e dovremmo iniziare a farlo, ma non sono ancora sicuro che la tecnologia di verifica in scrittura nelle unità LTO 3 causerà il fallimento del mio backup se per qualche motivo i dati non possono essere verificati proprio come si verifica se il mio software di backup ha eseguito una verifica sui dati. Mi piace l'idea di fare qualcosa di più, ma ho ancora bisogno di sapere se sto facendo qualcosa di ridondante che non è necessario. Grazie

— Chris Magnuson, il

Assicurati anche di eseguire un ripristino utilizzando un'unità nastro diversa da quella con cui è stato eseguito il backup poiché alcuni nastri possono essere letti solo sull'unità che li ha creati (o almeno questo era possibile in passato).

— James,

@ChrisMagnuson Hai mai scoperto cosa succede se l'unità rileva un errore utilizzando il proprio schema di verifica dopo scrittura?

— alx9r,

@ alx9r Temo di no. Sembra che nessuno lo sappia con certezza e non sono sicuro di come si possa incasinare intenzionalmente i dati subito dopo che sono stati scritti dalla testina del nastro, ma prima che vengano letti da qualsiasi meccanismo fa la verifica dopo scrittura in modo da poter vedere come il tuo software di backup risponde al rilevamento di un errore.

— Chris Magnuson,

Prima di tutto questa verifica automatica non sostituisce la verifica end-to-end. Ho visto unità fornite con un bug del firmware che ha reso la lettura del ripristino meno affidabile della lettura di verifica.

Il risultato fu che potevi scrivere i nastri senza che fosse riportato alcun errore, ma quando provavi a ripristinarti vedevi che le letture ottenevano errori o diminuivano di velocità di diversi ordini di grandezza.

La maggior parte dei clienti non ha mai notato questo bug del firmware. Secondo il venditore perché i clienti non hanno effettivamente eseguito ripristini di prova. Questo particolare bug è stato corretto. Ma sono sicuro che non abbiamo visto l'ultimo bug del firmware e alcuni bug del firmware verranno scoperti solo se testerai effettivamente letture reali.

Ciò che accade quando la verifica fallisce è che il firmware scrive automaticamente una seconda copia (e durante il ripristino del firmware in modo trasparente sull'host restituisce solo una delle due copie). Ciò significa che la capacità disponibile varia a seconda dell'integrità dell'unità e della qualità dei media.

Se troppi tentativi di scrittura falliscono nella lettura di verifica, viene riportato un errore a livello SCSI. Si potrebbe pensare che un errore segnalato in questo modo sia difficile da perdere a livello di software, ma i bug nei percorsi di codice che sono solo innescati da hardware instabile sono notoriamente difficili da testare.

— kasperd
fonte