DTI Data Recovery receives several requests for data recovery quotes each and every day. Many times the quotes are self-explanatory and we can offer an accurate solution as well as an upfront price for almost any recovery. With that being said, there are times when a more complex solution is necessary and some additional information is needed in order to offer an accurate quote and estimate the possibility of recovery. One of these instances is the deletion of data, any data. The possibility of recovery hinges on so many factors that a phone conversation is normally necessary in order to gather more information and make sure that the Deleted VMWare VMDK can be recovered.

Some of the most complex situations when dealing with deleted data involves virtual technology. Although this technology has been a real life safer when it comes to optimizing hardware resources it is a real nightmare when it comes to unraveling the mystery that involves a deleted VMWare VMDK. That being said, I received a request for a deleted VMWare VMDK recovery quote  recently. The person inquiring could not be contacted by phone so I could not speak to them. The description of the problem was so vague that I decided to send a list of questions that would enable me to make an educated and informed assessment of the recovery as well as the pricing for that recovery. The following are those questions and the reasons why they were asked. The questions were designed for a VMWare server.

1. What version of ESXi are you running on the server?
This is important in as much as some of the older versions of ESXi had file size limitations. In addition there are some utility functions for more recent versions that do not exist on the older versions of the operating system. These types of version discrepancies can and do affect the possibility of recovery.

Windows Server 2003 support ends July 14th 2015. While you’ve probably heard this a multitude of times, the severity of support no longer being offered by Microsoft for this aging server offering could be detrimental security wise to the organization you support. The following are 25 steps that I have been walking our customers through at a high level to fast track them off of their aging infrastructure and into Windows Server 2012 R2.

Let’s take a Server that is running Windows 2003 and is a Domain Controller, DHCP, DNS, and some File Services.

1. Build a new Windows 2012 R2 Server, install all necessary patches and join it to the Domain
    
2. Install the AD, DHCP, DNS, and File Services (Including De-Duplication) Roles
    
3. Logon to the Existing Windows 2003 Domain Controller and stop the DHCP Server Service 

4. Copy the DHCP Database from the from Windows 2003 (%windir%\system32\dhcp\dhcp.mdb) to the new Windows 2012 R2 Server (c:\Export\DHCP\dhcp.mdb)
    
   NOTE: Only grab the DHCP Database and not the associated log files. This will take all of the associated Scopes from the old server to the new one. It is a complete cutover. If you need to take individual scopes you should use NETSH or the Server Migration Toolkit.
    

If your only exposure to the world of data storage has been in the context of a small to medium-sized business or a startup, you’d be forgiven for thinking that magnetic tape is a relic from another era of enterprise computing. Once the de facto standard for long-term data retention, the format no longer gets much airtime in an age of cloud backups and tumbling HDD prices.

Nonetheless, rumours of the magnetic tape’s demise have been greatly exaggerated. According to an Information Age article from September 2014, all ten of the world’s biggest banks and telecoms firms, as well as eight of the world’s ten biggest pharmaceutical companies, are tape users. And as trends like big data pick up steam, there’s more interest than ever for organisations to invest in low-cost, high-volume storage for offline data.

For all their advantages, though, tape archives need to be looked after. It can be tempting to think that business records are out of sight, out of mind once they’re filed away in a format proven to last upwards of decades, but this is a mistake. The reasons for creating a tape archive aren’t trivial – regulatory compliance, mainly, and disaster recovery – and you don’t want to discover at the critical moment that your records are patchy.

Hello Folks,
You might have seen my last blog post, which was a brief introduction about DBCC CHECKDB. If you want to refer it again, then please check the link;

Well I have concentrated this blog-post mainly on how to repair the database Using DBCC CHECKDB.

I have made some keynotes about it:

• If there’s an error and DBCC CHECKDB can fix it up, then DBCC CHECKDB indicates the repair level that is needed to repair the specific errors.
• Most of the times if the error is reported by DBCC CHECKDB, it is recommended to restore the database from a known good backup.
• If there’s happen to be no good backup, then you have to use the repair option with DBCC CHECKDB.
• You should also keep in mind that repairing the database is a separate operation from the normal DBCC CHECKDB because the database needs to be placed in a single user-mode with the ALTER DATABASE command before a DBCC CHECKDB can be executed with the REAPIR option.
• So now if you want to place AdventureWorks2008R2 sample database in a single-user mode, then write the code: