Practical RAID 5 Data Recovery and XOR Mathematics in NTFS 5 (Part 1)

The multitudes of RAID 5 setups are not isolated in the world of Enterprise Servers, home and small business users use them as well. This fact has brought an interesting quandary to the RAID 5 data recovery specialist.

RAID 5, is without a doubt one of, if not the single most difficult recovery procedures in the industry. Along with that difficulty comes a very hefty price tag ranging from as little as $2500.00 to as much as $7500.00 for a three drive RAID 5 data recovery. The pricing range is based on drive size, operating system type, extent of damage, virtualization such as VMWare, and finally time allocated to recover the RAID. The small business, and or home user normally does not have that kind of ready cash to recover the RAID, but, the data to them may be just as important to them as any high end five star enterprise business. There are times when a ‘Do It Yourself’ solution can defray a great deal of the cost and ultimately allow a recovery for pennies on the dollar.

Which Windows Server Version Is Right For You?

After 12 years of service, Microsoft is finally pulling the plug on Windows Server 2003 with extended support for Microsoft Windows Server 2003 ending on the 14th of July – next month. To avoid problems with software compatibility, security weaknesses and general operating system failures, any business still reliant on Server 2003 needs to upgrade to a newer version sooner rather than later. Because maintaining the status quo is not an option.

Here we outline the pros and cons for each of the available operating systems so you have the information you need to make a more informed purchasing decision.

Windows Server 2008

Offering support for both i386 and x64 architectures, Windows Server 2008 was the last Microsoft operating system to work with 32-bit processors.

As the second oldest Microsoft operating system still in use, there is little to recommend Server 2008 for anything other than the oldest hardware.

Pros

  • Windows Server 2008 still supports 32-bit architecture, making it the only “up to date” option for old i386 systems.
  • Provides native support for Windows XP and Vista clients.

SQL FAQ – How Does A Page Level Restore Improve SQL Server Recovery Provisions?

For very large Microsoft SQL Server databases, a complete restore operation can take many hours. During this time the database cannot be used to prevent data being entered and lost as information is copied back from tape or disk. Obviously in a high-availability environment any downtime is costly, so keeping it to a minimum is essential.

Fortunately page level restore techniques can be used to keep recovery times to a minimum by reducing the amount of data that needs to copied back from the backup media. Since the release of Microsoft SQL Server 2005, DBAs have had the option of carrying out a ‘page level restore’ which allows them to recover a ‘handful’ of pages, rather than having to restore entire datasets and copy information back into the original database.

The page level restore operation is perfect for situations where data becomes corrupted during writes through a faulty disk controller, misconfigured antivirus software or an IO subsystem. Better still, restore level operations can be performed online for Enterprise editions of Microsoft SQL Server.

Prerequisites

As with any database recovery operation, page level restores are reliant on having a complete backup from which to work. If such a backup is not available, you will need to investigate an alternative method of recovering data from the server disks direct.

And although you can carry out the page level restore with the database online, you may decide to keep things safe by switching to single user mode whilst you transfer data using:

ALTER DATABASE <DBName> SET SINGLE_USER
WITH ROLLBACK AFTER 10 SECONDS
GO

This command ensures that everyone is out of the system and cannot enter until you change the mode back again. You will also want to ensure that you have the end of the log file backed up so that you have all transactions fully accounted for and to prevent any further data loss:

BACKUP LOG DBName
TO DISK = N'X:\SQLBackups\DBName_TailEnd.trn'
GO

VMware Data Recovery step-by-step for newbie’s

VMware Data Recovery works with entire virtual machines, backing them up and restoring them in their entirety. These backup and restore operations are conducted using a backup appliance which stores the virtual machines to a location called the deduplication store. The virtual machines that are backed up are stored in a form that can be read by solutions such as Data Recovery, but the contents of these virtual machine backups are not otherwise easily readable. For example, the contents of the virtual machine backups in the deduplication store are not readable by users browsing through files using their operating system. There is no convenient mount point that can be used by operating systems like Windows to read the contents of these backups. Users may want to restore a previous version of a single file. Perhaps the file has been deleted or information from a previous version is required. In such a case, users can restore an entire previous version of the virtual machine that contained the file, but this may be cumbersome. Rolling back to previous versions may overwrite the existing virtual machine and even if the restored virtual machine is restored to an alternate location, the process may not be as fast as customers want. FLR addresses these issues by providing a way to access individual files within a restore point. With this access, you can choose to read copies of the files or restore them from within restore points to any other available location. For example, you could create two copies of the file in question to compare them, or you could overwrite an existing file with an older version contained within the restore point, thereby reverting to a previous version. Note that accessing these files only provides a way to read their contents. You cannot write to files that are made available in restore points through FLR.

Recommended actions for corrupt or suspect databases

Overview

Encountering a suspect database or corruption in a database is a rare thing. It can happen, however, most often due to faulty hardware or operational mistakes (like deleting a transaction log file).

More information

The points below are recommendations for handling a situation where you have some type of corruption in a database or if the database goes into suspect status.

Details

Get Help Now

Thank you for contacting us.
Your Private Investigator will call you shortly.