CHKDSK is a great tools for checking the status of your disk but beware if your are using it to attempt a DIY data recovery!

CHKDSK data recovery...

CHKDSK short for ‘check disk’ is a Windows utility which verifies the file system integrity of a volume on your hard drive, fixing logical errors and repairing bad sectors. CHKDSK will search for errors but will only fix them if ordered to do so by the user. In Windows 7 there has been reported problems whereby the CHKDSK /R command can cause a system crash, but we are not able to replicate this at Data Recovery Specialists. But is CHKDSK good enough to test a failed hard drive and should I use it?

If the file system has become corrupted, there is a chance that CHKDSK may recover your lost data. There are options available to ‘automatically fix file system errors’ and’ scan for and attempt the recovery of bad sectors’. However CHKDSK can only run if it is the only application using that hard disk drive and you may have to ‘force a dismount’. It is best to make sure you are not running anything else inadvertently. If your windows operating system is running, CHKDSK will not run. Hence you should run CHKDSK before Windows is loaded and this can be forced by scheduling the disk check and closing down the system. Before it reboots CHKDSK will start verifying files. To see the results of a scheduled CHKDSK, it is necessary to run the event viewer by clicking ‘start’ followed by ‘run’ and then entering ‘eventvwr’ and clicking ‘OK’. Look for ‘Wininit’ under source in the Windows Application Logs.

When it comes to their channel partners' ability to deliver backup as a service, backup vendors have plenty of misconceptions.

Having spent 25 years in data protection, with several early years in channel and field-sales roles, I've noticed three common things that backup vendors don't seem to realize about channel partners.

Not every VAR/SI should become a backup service provider

Some vendors assume that they can help every one of their partners become backup as a service (BaaS) providers. The partners know the products, so with a little extra marketing for "BaaS in a box," they can presumably jump on the cloud bandwagon. There are two problems with this assumption:

• Just because a reseller is outstanding at technology deployment, it does not necessarily mean that it can or should run whole infrastructures as your "data of last resort." Operational management isn't the same as deployment or integration expertise -- and not all resellers maintain enough staff to manage an "as a service" set of platforms adequately.
• Not every reseller is effective with the marketing and business-development model of a cloud-based business. Sure, they could offer services to their existing customers who are considering "the cloud," but they could also resell those services with far less effort, unless it really is core to their business model.

What most successful VARs/SIs really offer is "expertise" combined with relationships and situational awareness of customer environments. After all, they probably installed most of the IT systems and will assuredly be the first called when something breaks.

But, when ESG asked IT decision-makers who they wanted to purchase backup as a service from, local VARs/SIs were near the bottom of the list, as were telco providers. Telco providers typically do know how to run an "as a service" infrastructure and market to a cloud consumer, but telcos don't know customers' IT environments, nor do most have the depth to help during an actual disaster, other than ensuring the BaaS platform is available for data restores upon request.

In many cases, to actually be successful in converting a VAR/SI to enable cloud services, VAR/SIs should partner with telcos or MSPs, who understand backup as a service and want to partner with the local resellers. The resellers stay involved with their customer (bringing expertise and environmental experience); the MSP/telco delivers the reliable service and the customer benefits from cloud-based data protection. In other words, the VAR/SI should be involved in selection, deployment and management of BaaS, but not the actual delivery of the service.

Resellers are not always a good proxy for vendors looking for customer opinions

Vendors assume that any VAR/SI with 50 customers must have nearly 50 times (or even just 10 times) the insight into what customers are looking for. Some vendors will solicit their partners as proxies for what customers want in sales initiatives, marketing messages or even product development. Yes, partners definitely have insights and can see things at a macro level, but they are biased in two distinct ways.

First, partners often have a long history with their primary vendors, which can affect the objectivity of their consensus of feedback. And second, partners are looking for profitability, which means that the products they want to sell may not (in many ways) resemble what customers want to buy.

Partners have unique insights that absolutely have to be listened to and considered as vendors try to outperform in the congested data protection marketplace, but customers' viewpoints are unique and are very difficult to quantify. If the vendor's favorite long-time partner is answering on its customers' behalf, it won't provide any insight into the opinions of prospective customers who aren't currently aligned to that partner's services.

Over the years, VMware has contributed much to server virtualization and made an impact on the IT industry. A great competitor, VMware has been and in my view made Microsoft a stronger and better IT solution provider. Both have been trying hard to help enterprise IT deliver much with less. And a great news is that competitions and open dialogues benefit tremendously to our customers and the IT industry in general. The two companies in my view have however a fundamentally different perspective in addressing cloud computing challenges. Let me be clear. This blog post is not about feature parity. This blog presents my personal view on important considerations for assessing a cloud computing solution platform and is intended to help IT technical leadership and C level decision makers look into the fundamental principles which will ultimately have a profound and long-term impact on the bottom line of adopting cloud computing. The presented criteria apply to Microsoft as much as to any other solution providers in consideration.

Virtualization vs. Fabric

In cloud computing, resources presented for consumption are via abstraction without the need to reveal the underlying physical complexities. And in current state of cloud computing, one approach is to deliver consumable resources via a form of virtualization. In this way, a server is in fact a virtual machine (VM), an IP address space can in reality logically defined through a virtual network layer, and a disk drive appearing with a continuous storage space is as a matter of fact an aggregate of the storage provided by a bunch of disks, or JBOD. All cloud computing artifacts eventually consist of resources categorized into three pools, namely compute, networking, and storage. The three resource pools are logically simple to understand. Compute is the ability to execute code and run instances. Networking is how instances and resources are glued or isolated. And storage is where the resources and instances are stored. And these three resource pools via server virtualization, network virtualization, and storage virtualization collectively form an abstraction, the so-called fabric, as detailed in “Resource Pooling, Virtualization, Fabric, and Cloud.” Fabric signifies the ability to discover and manage datacenter resources. Sometimes we refer the owner of fabric which is essentially a datacenter management solution as fabric controller which manages or essentially owns all the datacenter resources, physical or virtual.

Cloud computing is about providing and consuming resources on demand. It is about enabling consumption via the management of resources which happen to be virtualized in this case. In cloud computing, we must go beyond virtualization and envision fabric as the architectural layer of abstraction. Fabric management needs to be architected as a whole into a solution. Such that the translation between fabric management and virtualization operations in each resource pool can be standardized, automated, and optimized.

So, at an architectural level, look into a holistic approach of fabric management, i.e. a comprehensive view of how the three resource pools integrated and complementary to one another. Let me here recognize that virtualization is very important, while fabric is critical.

A Mindmap for VMware Data Recovery

This PDF Flash Clickable utility can drive you to solve your issue faster. What it does. Once downloaded, inside of the PDF there is an embedded flash object, which is clickable. By selecting and clicking the area of where you’re having issues, you’ll get further and KB articles with links are provided to help you with the issue. There are four main areas covered with the tool for solving issues with VDR.

• Connectivity
• Backups
• Restore
• Snapshots

Assume you’re running MySQL with Innodb tables and you’ve got crappy hardware, driver bug, kernel bug, unlucky power failure or some rare MySQL bug and some pages in Innodb tablespace got corrupted. In such cases Innodb will typically print something like this:

InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
080703 23:46:16 InnoDB: Page dump in ascii and hex (16384 bytes):
… A LOT OF HEX AND BINARY DATA…
080703 23:46:16 InnoDB: Page checksum 587461377, prior-to-4.0.14-form checksum 772331632
InnoDB: stored checksum 2287785129, prior-to-4.0.14-form stored checksum 772331632
InnoDB: Page lsn 24 1487506025, low 4 bytes of lsn at page end 1487506025
InnoDB: Page number (if stored to page already) 7,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 6353
InnoDB: Page may be an index page where index id is 0 25556
InnoDB: (index “PRIMARY” of table “test”.”test”)
InnoDB: Database page corruption on disk or a failed

and crash with assertion failure.

So what can you do to recover such a table ?