Drive Rescue
NAS and RAID recovery website of Drive Rescue
Telephone
email
Menu

NAS Data Recovery

NAS Data Recovery -a general overview

We perform data recovery from most brands of NAS device, including:

We can help you recover from single-disk data loss issues, such as:

RAID-level data loss

We recover data from inaccessible RAID arrays in the following scenarios:

We recover from all standard and hybrid RAID levels, including:

To perform data recovery from a NAS device or RAID server, an in-depth understanding of the major files systems is imperative.

We also recover from proprietory file systems, such as:

Background on RAID and file systems types

An in-depth understanding of RAID and file systems is needed for successful recovery from NAS and RAID servers.

RAID types at a glance...

RAID 0 – RAID 0 is the lowest form of RAID and seen by some as not a valid form of RAID at all because there is no redundancy. Data is striped across two or more drives which the user sees as one volume. The main rationale for implementing a RAID 0 setup is enhanced performance. Because there are two drives, data can be written or read at nearly twice the speed of a single drive.

RAID 1 – This RAID level is otherwise known as mirroring. An exact byte-for-byte copy is made on Disk 0 as Disk 1. It offers good redundancy but no performance gain on a write. Reads will be faster than a single disk as parallel reads of data can be performed. One major disadvantage of RAID 1 is that the size of your volume is limited to the size of one drive.

RAID 5 – Protects against single disk failure. Minimum of 3 disks are needed. RAID 5 can give an adequate level of performance for storage and retrieval of documents, images and archiving data. However, when used for applications, where fast write speeds are required, RAID 5 can be extremely slow. It is strongly recommended that enterprise-class hard disks are deployed in a RAID 5 array.

RAID 6 – Protects against 2 drive failures. High read performance, but low write performance. Requires a minimum of 4 disks. You will, however, lose two disks’ worth of capacity due to overhead.

RAID 10 – High read performance and good write performance. Due to all the disks being mirrored, you only get 50 % of your overall usable capacity. RAID 10 can sustain multiple simultaneous disk failures, assuming that you don’t lose both pairs of a mirror. In the context of data retrieval, fast rebuilt times are possible as there is no parity calculation.

File systems - a short overview

Even with a through understanding of RAID, knowledge and experience of working with

the major file systems is needed to successfully recover data from NAS and RAID servers.

The EXT2 File System

When a file in EXT2 is deleted, its inode changes status from “used” to “free” space. However, the inode structure will still contain pointers to the data blocks and the data blocks are not deleted until they get overwritten. This often makes data recovery from EXT2 partitions possible.

The EXT3 File System

The EXT3 file system is commonly used by NAS devices and RAID servers. It is important to understand how EXT3 handles data differently from other file systems and how knowledge of these differences can be used to successfully recover data.

EXT3 uses an indirect block mapping system, where one-to-one mapping of logical blocks to disk blocks takes place. This is very efficient for small files, but incurs a high overhead for larger files.

EXT3 is a journaled version of EXT2. This means that a log file of system changes is recorded before disk writing takes place.

The journal superblock is a data structure that is found 1024 bytes from the start of the EXT file system. It records information as to the block size, journal size, the total number of unused blocks that the journal has for storage, where the journal starts and inode allocation information.

The main advantage of EXT3 over EXT2 is its use of journaling. The usefulness of the information extracted from a journal will be determined by the type of data recovery that is being performed. Old inode data may be present in the journal, which can provide a transaction log of old time stamps or old ownership information. Moreover, old inode data recovered from the journal may contain block pointers which have been wiped from a deleted inode.

The EXT4 File System

While EXT3 has been a very popular file system because of it’s reliability, features and good performance; it has limited ability to scale and work with large configurations. As a result, developers started to work on a new version that would handle large disk sizes better. Enter EXT4.

EXT4 can handle individual file sizes of up to 16TB. The file system itself can support disks up to 1 exabyte. EXT4 uses CRC32 checksumming. For each transaction, the CRC is executed over all of the transaction blocks. But here is the clever bit, if the file system has to perform a recovery and the checksums do not match, then the transaction is regarded as invalid. While checksumming does incur an IOPS overhead on the file system, it is offset by the fact that the actual transaction and journal writing occur simultaneously. This means that the speed of the EXT4 file system over EXT3 can be up to 20 percent faster.

Data Recovery from EXT4

Even though EXT4 has earned the trust of users worldwide as a robust file system, there are occasions when the data on an EXT4 volume will become lost or inaccessible. This can be attributed to a number of reasons, including file system problems (such as inode or metadata corruption) or caused by physical problems with one or more of the disks.

The ability to recover data from a corrupted EXT4 volume is usually determined by the size and fragmentation of the volume’s files. The smaller the file and the fragmentation, the better the probability of recovery. Even if your files do not meet this criteria, all is not lost. Extent headers can often be used to identify index blocks. Extent headers can be used to find exactly where tree hierarchy blocks should be placed. Examination of un-initialised extents and group descriptor growth blocks can also prove fruitful.

Recovering data from the XFS File System (as used by Buffalo, Synology and Iomega-Lenovo)

Introduced by Silicon Graphics International in 1993, the XFS file system is scalable, powerful and fast. It is widely used by the scientific and research community who need to process high volumes of data relatively quickly. For example, the world renowned CERN research institute and NASA both use XFS extensively for their “big data” projects.

There are many attributes of the XFS file system that make it suitable for processing high volumes of data at a relatively fast speed. The use of Allocation Groups means that multiple I/O requests can be executed simultaneously. Using a process known as Direct I/O, data from the file system can be processed directly from the host’s RAM, which negates the need for a cache or processor request. XFS is also very clever in the way that it handles unused file space. A lot of files will just contain zeros. XFS, hating to see wasted space, allocates this space to store metadata. The moment the file is accessed, the file will revert back to its original size. Furthermore, XFS uses online defragmentation. Non-contiguous data blocks are converted to continuous blocks on-the-fly. These attributes make XFS a very efficient file system but, like any file system, it can get corrupted.

Data recovery from the XFS file system

The “xfs_repair” command can be used to successfully repair errors in a corrupt XFS volume. However, when problems exist with the RAID array configuration, or when there are hardware problems with the disks, other avenues to recovery have to be explored.

You can attempt to rebuild the RAID array, but if there are hardware problems with your disks, such as head disk assembly, bad sectors or PCB issue, these will have to be resolved first.

HFS + File System (as used by Apple)

If you’re using your NAS in an Apple-based environment. It is possible that your NAS is formatted using the HFS+ file system.

The backbone of the HFS+ file system is comprised of i) volume header ii) catalog file iii) extents overflow file iv) allocation file and v) start-up file.

After you have eliminated the possibility of defective disks in your NAS, there are a number of other reasons why a HFS+ volume will get corrupted. These include:

Drive Rescue, 6-9 Trinity Street, Dublin 2
Tel.: 01 485 3555 Email: info@nasrecovery.ie

Design by Solasweb