Sometimes a user can diagnose a hard drive failure simply from the symptoms that the hard drive is exhibiting.

Typical data loss scenarios...

In this article we examine typical symptoms of hard drive failure and possible causes. What are the signs to look out for? While there are few sure-fire signs of impending disk failure there are some warning signals that give us the hint. Watch out for: disappearing files, very long wait while accessing files, files/folders whose contents appear to be strangely scrambled; reoccurring error messages while moving/copying/deleting/creating files, and strange but frequent crashes of your OS.

a. Hard drive is recognised, but grinds/scratches/clicks. Almost certainly a mechanical failure. Without opening the drive in a clean room, it is difficult to determine whether it is bearings, motor or heads. Try to keep it cool using a desk fan (DO NOT put in fridge or freezer) and copy your most critical data. You may have minutes before drive completely crashes.

Steps to protect your data...

A common cause of data loss is hard drive failure which at best means considerable downtime, whilst you restore backups or at worst, considerable expense of data recovery. However there are many steps the user can take to protect themselves.

There are a number of precautions the user can take to avoid hard drive failure and extend the life of their hard drives.

Always use a surge protector to protect against power spikes – these are very cheap to purchase from most electrical shops or computer suppliers.

Never keep computers or servers on the floor or underneath desks as the fan will draw in much more debris. All hard drives have a breather hole to equalise pressure and any dust, smoke particles, etc that enter through the breather hole will inevitably cause a head crash.

The majority of workers in the UK agree that the loss or theft of their digital data is inevitable at some point.

This is according to a survey of 2,000 Brits conducted by Citrix, which found 71 per cent of respondents have accepted the fact they will fall victim to this problem sooner or later.

Younger individuals were found to be more alert to the risks, with a third of 16 to 25-year-olds saying they felt more vulnerable to attacks than in the past, compared with just 15 per cent of over-65s.

However, despite this, a large number of people are still relying on outdated solutions when it comes to backing up their most valuable data.

Nearly a third of respondents (30 per cent) said they still used USB sticks to back up key information, while just nine per cent have turned to a cloud-based service to do this.

Chris Mayers, chief security architect at Citrix, said: "Many [workers] are still reliant on dated practices such as using USB sticks to store and protect their information, when more advanced and robust measures are available."

Reference: http://www.krollontrack.co.uk/company/press-room/data-recovery-news/data-loss-inevitable,-brits-say531.aspx

SQL Server 2000 offers three recovery models for each database: full recovery, simple recovery and bulk-logged recovery. The recovery models determine how much data loss is acceptable in case of a failure and what types of backup and restore functions are allowed.

Most people either select full or simple for all of their databases and just stick with the same option across the board. In most cases, selecting the full recovery model is the smartest option, because it gives you the greatest flexibility and minimizes data loss in the event a restore has to take place.

Although using the full recovery model makes logical sense, there are reasons why the other two options are available. We will further define why there are three options and when you might want to use the different options to protect your databases. First, let's take a closer look at each model.

Simple

The simple recovery model allows you to recover data only to the most recent full database or differential backup. Transaction log backups are not available because the contents of the transaction log are truncated each time a checkpoint is issued for the database.

Full

The full recovery model uses database backups and transaction log backups to provide complete protection against failure. Along with being able to restore a full or differential backup, you can recover the database to the point of failure or to a specific point in time. All operations, including bulk operations such as SELECT INTO, CREATE INDEX and bulk-loading data, are fully logged and recoverable.

To determine whether a database needs to be repaired run:

dbcc checkdb('DB-NAME') with no_infomsgs

replacing 'DB-NAME' with the name of the database.
If this completes without displaying any errors then the database does not need to be repaired.
If the errors that come back contain lines saying:

... Run DBCC UPDATEUSAGE

Then the database does not need to be repaired, simply run:

dbcc updateusage('DB-NAME')with no_infomsgs

If a database does need to be repaired then:

1. if you can identify why the database needs to be repaired. Look in the windows system and application event logs to see if any problems have been logged which might account for the problem. For example is the problem caused by a failing disk? Often you will not be able to identify the cause, but if you can then remember to address it.
2. it is suggested that instead of repairing the database it be restored from the last reliable backup.

To repair a database the database must first be placed into single user mode:

alter database DB-NAME set SINGLE_USER

if the database is the MASTER or MSDB then instead consult.

once the database is in single user mode it can be repaired. There are a number of repair options but the two typically used are "REPAIR_REBUILD" and "REPAIR_ALLOW_DATA_LOSS". I suggest in the first instance using: