Unix e Linux: come avviene il recupero dati

martedì 10 maggio 2016 di Ontrack Italia

Prima di tutto, cos’è esattamente UNIX?

Unix è un sistema operativo multi-user e multi-tasking sviluppato negli anni 60 dai laboratori AT&T Bell. La maggior parte dei sistemi UNIX è scritta nel linguaggio di programmazione C e per questo è in grado di funzionare su un ampio numero di computer. I fornitori di hardware come SCO, SGI, IBM, Hewlett Packard e Sun forniscono ciascuno le proprie versioni UNIX da utilizzare sui loro high end server.

Linux, cos’è?

Linux, alle volte chiamato GNU/Linux è un sistema operativo open source gratuito simile a Unix. Il progetto GNU è iniziato nel 1984 con lo scopo di creare una versione free di UNIX. A questo progetto, però, mancava  un kernel, il nucleo del sistema operativo, completamente funzionante fino a quando nel 1991 fu rilasciato da Linus Torvalds un kernel chiamato Linux. Il kernel Linux viene normalmente fornito insieme ad altri pacchetti del progetto GNU e ad altri sorgenti.

Un’occhiata più approfondita ai loro file system

Fast File System, EXT 2, 3 & 4

Il file system EXT2 (alle volte conosciuto come secondo Extended  File System) era stato originariamente creato per la piattaforma Linux e venne distribuito sul mercato nel 1993. Da allora questo file system è stato sostituito da EXT3 che aggiungeva alla precedente versione nuove funzionalità tra cui il journaling.  EXT4 è attualmente il file system predefinito per le distribuzioni Linux più popolari.

Come per molti altri file system UNIX  la struttura principale è molto simile a quella del Fast File System (FFS) originale di UNIX. La partizione è suddivisa in Cylinder Group e ciascuno di questi gruppi contiene: SuperBlock, Group Table, Data Bitmap, Inode Bitmap, Inode e infine i dati.

Alcune versioni EXT2 e EXT3 hanno invece degli Sparse Cylinder Group che contengono solo Inode e dati.

I file system EXT 2, 3 e 4 hanno un numero fisso di inode e questi vengono mappati sulla partizione dai Superblock e dai group table.

Questi inodes vengono utilizzati per rappresentare sia i file che le directory e contengono:

  • Tipologia dei file
  • Diritti di accesso
  • Proprietari
  • Timestamps
  • Dimensione
  • Puntatori ai blocchi di dati

Quando un Cylinder Group viene cancellato può essere sostituito da un altro Cylinder Group che protegge i dati.

Come potete vedere dall'immagine qui sopra, nell’EXT 3 i puntatori ai blocchi di dati fanno parte dell’inode che indirizza i file dati sul drive.

I primi dodici puntano ai blocchi fisici che contengono i dati mentre gli ultimi tre puntano indirettamente ai blocchi di dati (single indirect, double indirect e triple indirect). Il single indirect contiene l’address di un blocco che a sua volta contiene i puntatori diretti come mostrato nel diagramma. Il double indirect punta ad un blocco che contiene puntatori single indirect e di conseguenza il triple indirect punta ai blocchi che contengono i puntatori double indirect. Questa organizzazione può essere complessa da visualizzare ma fondamentalmente ogni step di indirizzamento indiretto permette ai volumi di dati di essere indirizzati per poter aumentare esponenzialmente.

Vale la pena sottolineare che il recupero dati da EXT3 è un processo molto complesso e i risultati tendono a non essere così buoni quanto quelli che possono essere raggiunti in altri file system.

La struttura dei dati nei file system EXT4 è simile a quella di EXT3. La differenza principale sta nel fatto che gli Extent hanno sostituito i puntatori diretti e indiretti ai blocchi di dati, migliorando in maniera significativa le performance sui file di grandi dimensioni. Quando i dati vengono cancellati da un file system EXT 4 il loro recupero tende ad avere maggiore successo poiché gli Extent stessi non vengono cancellati e ciò rende possibile il rebuild dei file persi.

XFS

XFS venne sviluppato da SGI nel 1993 per superare alcune limitazioni dell’FFS in termini di performance e scalabilità. Questo file system venne distribuito per la prima volta nel 1994 insieme a IRIX v5.3 e nel 2000 SGI ha reso disponibile il codice come open source. In seguito, a partire dal 2003, è stato ufficialmente incluso nel kernel Linux. La struttura del file system XFS a prima vista è molto simile a quella dell’FFS. Questa infatti conserva il sistema di cylinder group per la suddivisione della partizione che ora vengono chiamati allocation group, mantiene i superblock e utilizza gli inode per contenere i metadata dei file tuttavia qui le somiglianze finiscono.

Diversamente da FFS, XFS non ha un numero fisso di Inode pre-allocati sul drive, al contrario è compito di ciascun gruppo di allocazione monitorare lo spazio libero e allocare dinamicamente gli inode come richiesto dal file system.

Questi Inode sono organizzati in una struttura ad albero B+ bilanciata che rende il passaggio alla struttura di directory più veloce rispetto al sistema di lista tradizionale implementato su FFS. Tuttavia per mantenere alti livelli di performance la struttura B+ deve rimanere bilanciata man mano che vengono allocati più inode e questo richiede un algoritmo relativamente avanzato.

Gli Inode XFS utilizzano anche gli extent per indirizzare i dati invece di indirizzare singoli blocchi di dati come FFS poichè in questo modo si ottiene una migliore scalabilità sui file di grandi dimensioni.

XFS include anche la funzione journaling per offrire al file system la possibilità di recupero in caso di crash del sistema o di problemi di alimentazione. Tuttavia XFS prevede solo il journaling dei metadati del file system così mentre il volume può essere riparato e montato rimane comunque la possibilità che si verifichi una perdita dati per l’utente.

Un’altra caratteristica dell’XFS è l’allocazione ritardata, un metodo di allocazione dei blocchi per file di dati quando i dati stessi si trovano nella memoria cache. Questi dati vengono quindi scritti sul file system solo nel momento in cui la cache viene svuotata dal sistema operativo. I principali vantaggi di questo approccio stanno nel fatto che questo processo può spesso ridurre drasticamente la frammentazione dei dati soprattutto nei file che si espandono lentamente e inoltre spesso riduce il carico per la CPU.

Nella seconda parte di questo articolo vi forniremo maggiori informazioni sui file system Linux/Unix, vi descriveremo i pro e i contro dell’uno o dell’altro, spiegando le differenze nel processo di recupero dati da Linux/Unix e i più comuni sistemi operativi come Windows e Mac.

JFS (Journaled File System)

Nel 1990 IBM ha distribuito per la prima volta JFS con AIX versione 3.1. Più tardi, nel 1999 IBM lo ha portato su OS/2 e ha rilasciato una versione di JFS alla comunità open source, dal 2006 vi è una versione stabile per Linux.

La filosofia di progettazione alla base di JFS è comparabile a quella di XFS e supera molti dei limiti in termini di performance dell’FFS sebbene le implementazioni finali siano differenti. Entrambi utilizzano il journaling dei metadati per offrire al file system maggiori possibilità di recupero, inode allocati in maniera dinamica, extent che indirizzano le aree dati e infine un’alberatura B+.

ReiserFS e LVM (Logical Volume Management)

Il Logical Volume Management è una soluzione in grado di superare alcune delle limitazioni di utilizzo dei tradizionali metodi di partizione per allocare lo spazio di storage sui media. Le caratteristiche di questa soluzione sono:

  • file system spanning e software RAID (Livello 0, 1 & 5)
  • ridimensionamento dei volume group e dei volumi logici
  • snapshot

Solitamente lo spazio sugli hard disk viene suddiviso in partizioni su cui vengono scritti direttamente i file system. Il sistema LVM tuttavia opera in modo leggermente diverso: i dischi vengono ancora allocati utilizzando le partizioni ma queste vengono viste e riconosciute dall’LVM come volumi fisici.

Questi volumi fisici vengono poi raggruppati insieme come RAID oppure attraverso lo spanning per formare un Volume Group. Il Volume Group può essere poi allocato per formare volumi logici su cui risiedono di fatto i file system. L’immagine qui sotto mostra un esempio di come un LVM dovrebbe essere utilizzato.

Le versioni più recenti di Unix hanno ognuna le proprie variazioni di LVM e, in base al vendor, hanno diversi nomi e funzioni configurate.

Linux ha un sistema LVM che si basava originariamente sulla versione UNIX di Hewlett Packard. Un elemento fondamentale che manca sia su HP sia su LVM Linux è il fatto che entrambi non implementano una gestione per la tolleranza degli errori di parità (parity fault), quindi nessun supporto a software RAID 5.

Windows 2000, 2003, XP e Vista hanno un sistema equivalente chiamato Logical Disk Manager che fornisce questo genere di funzione.

I pro e i contro di Unix e Linux

Sebbene Unix e Linux non siano popolari quanto altri sistemi operativi questi sono in grado di fornire notevoli vantaggi per specifiche esigenze.

Linux può non essere di facile utilizzo come altri sistemi (parliamo a voi, utenti Windows e Mac) ma coloro che hanno una certa conoscenza a livello di programmazione possono sfruttare questo sistema in open source per adattarlo a specifiche necessità. Il sistema funziona molto rapidamente ed è molto più efficiente per i programmi di produzione.

Dall’altra parte UNIX viene considerato sempre più spesso quando vengono richiesti processi high end. Alcuni esempi di questi casi sono le macchine  nucleari, le centrali elettriche, i sistemi militari, etc. Sicuramente non è il sistema di più facile utilizzo ma è estremamente efficiente quando la necessità principale è un’elevata potenza di elaborazione.

Il processo di recupero dati da Linux e Unix

Se si lavora con Linux o UNIX è importante ricordare che questi sistemi presentano ognuno delle sfide da superare in caso di perdita dati.

Fortunatamente in caso di guasto di tipo fisico la percentuale di successo di un intervento di recupero è alta tanto quanto per gli altri sistemi operativi. Nonostante questo, però, in caso di danno di tipo logico ci sono delle differenze nel processo di recupero dati che vale la pena conoscere. Nel caso in cui doveste aver erroneamente formattato il supporto il recupero sarà più complicato. I dati raw potrebbero essere ancora presenti ma tutte le strutture e gli inode saranno scomparse. In caso di cancellazione accidentale è ancora possibile riuscire a tornare in possesso dei dati. In caso di sistema EXT4, ad esempio, gli extent non vengono cancellati quindi è possibile effettuare il rebuild dei file.

Quindi, ricordate, fate molta attenzione prima di far girare il comando Remove. Assicuratevi che stiate eliminando solo ciò che volete realmente cancellare e prestate molta attenzione nel caso in cui decidiate di formattare i dati.

Servizi di recupero dati

Hai perso i tuoi dati? Contattaci subito per recuperarli.


Cosa pensano i clienti dei nostri servizi: