Backup Encyclopedia:: B

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z | View All

B-tree (or b-tree)

A b-tree is a structure for storing database indexes. Each node in the tree contains a sorted list of key values between the listed values. To find a specific data record given its key value, the program reads the first node, or root, from the disk and compares the desired key with the keys in the node to select a sub-range of key values to search. It repeats the process with the node indicated by the corresponding link. At the lowest database, a system can thus rapidly search through index entries that contain the location of the desired records or rows.
With respect to the Master File Table (MFT), each file uses one file record. However, if a file has a large number of attributes or becomes highly fragmented it might need more than one file record. In this case, the first record for the file, the base file record, stores the location of the other file records required by the file. Folder records contain index information. Small folder records reside entirely within the MFT structure, while large folders are organised into b-tree structures and have records with pointers to external clusters that contain folder entries that cannot be contained within the MFT structure.
The benefit of using b-tree structures is evident when NTFS enumerates files in a large folder. The b-tree structure allows NTFS to group, or index, similar file names and then search only the group that contains the file, minimising the number of disk accesses needed to find a particular file, especially for large folders. Because of the b-tree structure, NTFS outperforms FAT for large folders because FAT must scan all file names in a large folder before listing all of the files.
See: Attribute (Resident & Non-Resident), Attribute List, and Master File Table (MFT).

Backup: (Why Should I?)

The process of duplicating a coherent copy of a program, a disk, or data, made either for archiving purposes, for safeguarding valuable files or a library (or data within robotic silos) from loss in case the archive copy is damaged, destroyed or lost, onto a separate piece of data storage media is imperative. Backups differ from an archive in that the data are duplicated rather than moved and may be referred to as a backup copy.
Backup is performed for various reasons, and those reasons very often dictate the investment made in accomplishing the backup. The assurance of data availability is the primary reason for creating backups. The higher the data availability requirements, the more investment needs to be made. For any IT project it is important to have management support; to authorise the budget necessary for the backup and recovery or restoration plan, otherwise it is doomed to fail.
Data archival also is used to meet legal and other needs in which the data does not have to be accessible immediately but can be produced on demand in a reasonable amount of time, measured in hours, days, or weeks.
Backups are sometimes used to transport data, e.g., when deciding to create another data centre at a distant geographical location. A similar motivation is to migrate data to new hardware or, more rarely, a different server platform.
Backup operations have evolved in terms of both user requirements and the technology used to accomplish backups. Usage requirements have dictated that backups be made more frequently, yet without disrupting an applications access to data. Backup operations evolved from stand-alone backups to backup operations happening across a local area network (LAN) to backup operations happening in a network attached storage (NAS uses hard disk drive storage that is set up with its own network address rather than being attached to the computer that is serving applications to a network's workstation users). By removing storage access and its management from the server, both application programming and files can be served faster because they are not competing for the same processor resources. The NAS device is attached to a LAN, typically, an Ethernet network, and assigned an IP address using protocols such as Microsoft's Internetwork Packet Exchange and NetBEUI, Novell's Netware Internetwork Packet Exchange, and Sun Microsystems' Network File System. File requests are mapped by the main server to the NAS file server. NAS consists of hard disk drive storage, including multi-disk RAID subsystems, and software for configuring and mapping file locations to the NAS device. NAS can be a step toward and included as part of a more sophisticated storage system called storage area network (SAN). SAN is a high-speed special-purpose network (or subnetwork) that interconnects different kinds of data storage devices with associated data servers on behalf of a larger network of users. Typically, a SAN is part of the overall network of computing resources for an enterprise supporting disk mirroring (making concurrent copies), backup and restore, archival and retrieval of archived data, data migration from one storage device to another, and the sharing of data among different servers in a network. SANs can incorporate subnetworks with NAS systems) or as part of a tiered storage system (the assignment of different categories of data to different types of storage media in order to reduce total storage cost. Categories may be based on levels of protection needed, performance requirements, frequency of use, and other considerations. Tier 1 (class A or level Platinum) data, e.g., mission-critical, recently accessed, or top secret files stored on expensive and high-quality media such as double-parity RAIDs; tier 2 (class B or level Gold) data, e.g., financial, seldom-used, or classified files stored on less expensive media in conventional SANs. As the tier number increases, cheaper media may be used. Therefore, tier 3 (class C or level Silver) data in a 3-tier storage system might contain event-driven, rarely used, or unclassified files on recordable optical discs or tapes for long-term retention, environment. One problem that backup applications need to solve is backing up open files being accessed by active programs while the backup is being done. Note: For completeness the final tier is 4 (class D or level Bronze).
Do you as a computer user or as a small or large commercial enterprise have a proper contingency plan in the event of an information technology disaster? If the answer is 'no', you join a sizable chunk of end users and businesses that still do not have one either.
Small and midsized businesses (SMBs) and distributed enterprises can benefit from a backup and recovery strategy that requires as little manual intervention as possible. Typically, businesses have limited IT resources. They cannot afford to devote excessive time, and effort managing backups and restores that are needlessly complex. They need a backup and restore strategy that is easy to set up and requires minimal ongoing maintenance.
End users, and in particular companies large and small, know that the information they hold is their most important asset, and to lose it would severely damage their commercial activities, maybe even paralyse the business in the event of data loss caused by computer viruses, Trojans or malware infections, system and/or equipment failure, power outrage, robbery, fire, natural disaster, security breaches, terrorist attack, human error, organised or deliberate disruptions, and legal programs – the list is endless. Many companies do use rudimentary backup solutions and routines that will safeguard a small portion of their important information. However, what are the negative ramifications of an incomplete backup strategy or routine? A likely outcome is longer recovery times in the event of any type of incident, increase variable maintenance costs, anxiety for both the management and IT staff, and data loss. In order to control all personal or company data, not only on servers themselves but also on client machines and laptops, it is imperative to have a proper well thought out backup policy (procedures and rules for ensuring that adequate amounts of time and types of backups are created, including suitably frequent testing of the process of restoring the original production system from backup copies) that will safeguard critical data against any eventuality. These precautions go beyond just preventing data loss; they ensure a professional, secure mentality, with positive knock-on effects such as decreasing downtime and improved productivity. For example, an employee may unduly or maliciously modify a file or add inappropriate data to an accounting program that will change all the remaining data and reports. For this reason it is sensible to have a well-defined and clearly documented backup and recovery plan so that anyone can follow it, when the next disaster strikes. There are many different risks that can destruct the normal run of an organisation; a risk assessment should be performed to figure out which risks a specific company is susceptible to, some of the reasons have already been mentioned.
Unfortunately, data is being stored and lost at a geometric rate. For this reason a backup policy has never been more important than it is today.
To recover data is beyond the expertise of most end users. For the small businesses, a specialised data recovery laboratory will hit profit margins so hard that they will have to decide whether recovery of lost data is affordable. Without data a company risks going out of business. All this upheaval could be prevented with a simple backup solution, backup plan and strategy. For large enterprises with the resources on hand the cost of a specialist data recovery laboratory, although expensive, is the lesser of two evils. The cost of a recovery incident ranges from US$500 to US$2,500, depending on the filesystem (servers, RAID (RAID a multi-hard disk drive storage subsystem for data replication (concurrent copying)) arrays, and UNIX are more expensive), the type of repair, the time required, the type of data to retrieve (text is easier to recover than a corrupted databases), and the probability of success and therefore payment costs. Some extreme cases, including those requiring onsite support, can cost tens of thousands of dollars. Worldwide, it is estimated that the market for data recovery in 2005 was over US$100 million. Do not be a statistic, think smart, think ahead and backup your data regularly.
The backup software industry is big business, as is the professional recovery business. For this reason there are many systems and packages to choose from. Some backup software, applications used for performing the backing up of data, i.e., the systematic generation of backup copies, although feature-rich can far exceed the cost of purchasing a Genie Backup Manager (GBM) product. In some cases Genie-soft’s Backup Manager family of products can perform as well as or better than more expensive alternatives. High-end applications designed for professional environments offer almost all the options one could possibly imagine for backing up servers, organising the rotation of backup tapes (carry out house-keeping functions; also rotate and clean them (cartridge and device)); avoid extreme temperatures and electromagnetic fields), other storage media, and fully controlled PCs installed on networks. Nevertheless, these applications can only provide the highest level of backup and data security, as long as they are configured correctly. GBM provides high-end features, without the high-end costs involved within an uncluttered clean interface that belies its advanced powerful features not found in some higher priced products, yet catering for the needs of novice and expert alike. Settings are laid out in a clear manner and backup jobs can be created with ease. Moreover, by using Genie-soft’s Backup Manager Family of products as your backup solution it is possible to totally restore a machine or server quickly with minimum impact on existing configurations or users’ work in progress.
It follows that with expensive backup software comes expensive site licenses and upgrade fees. Genie-soft prides itself on a pricing policy that is reasonable, sensible and fair. Site licenses and upgrades will not be excessive, therefore new version releases can be immediately taken advantage of. For this reason, besides many others, it is prudent to turn to a low cost feature-rich solution such as Genie-soft’s Backup Manager Family of products that are more suitable for your personal or business needs. What is the point of paying over the odds?
One feature that most backup software enjoys, no matter how expensive, is the capacity to create full, incremental and differential backups. Another important aspect is automation. This is an essential feature, since it means that all tasks (also called backup jobs) will be carried out automatically behind the scenes without user interaction. Genie Backup Manager provides (Genie Backup Manager Home does not support the differential backup type) these features as well as being able to organise and rotate backup tapes and treat them for longevity; keeping data unharmed from any unforeseen eventuality.
When choosing a product that will ultimately safeguard data, the complex and delicate issue of backing up machines on a complex business network requires a great deal of thought, attention and consideration. Choose wisely. Choose from Genie-soft’s Backup Manager family of product.
Today, the most economical option for dealing with a malfunctioning hard disk drive is to replace it with a new one. The new hard disk drive will likely be larger, cheaper, faster and use advanced technology. In fact, it is typically the data itself – even for the home user – that is much more valuable than the hard disk drive itself. Increasingly, the home user's hard disk drive is filled with often-precious photographs and data. The time it takes to recover data from a failed hard disk drive can also be more costly than the hard disk drive itself – even when backups are available. However, backups typically represent a snapshot of the data some time ago (last night, last week, last month). Therefore all recent work and transactions are still lost. Avoid the often repeated practice of not validating the data or verify that it can be restored successfully and in a timely manner in the event of a disaster. Sometimes the backups themselves are corrupted. Even in redundant systems or storage subsystem, such as hard disk drive arrays (RAID arrays), data loss due to multiple-hard disk drive failures is not uncommon. For these reasons, no matter what precautions have been taken, a hard disk drive may need the services of a data recovery company. Therefore it is important to backup and test restoring your backups. There is no point having a backup only to find it is corrupt or has encountered an unforeseen problem during the backing up process, aforementioned.
Side note: When a hard disk drive containing valuable data no longer responds, the last hope is to send it to a data recovery company that specialises in hard disk drive hardware failures. There is a general perception that data recovery companies have "magic machines" for retrieving data in almost any situation. The reality is less glamorous. The most sophisticated, commercially successful recovery techniques involve careful part-replacement, in a clean room environment, of the heads, the spindle motor and base casting, the electronics board, and/or the hard disk drive's firmware and parameter tables. Part-replacement has historically been successful for data recovery about 40% to 60% of the time. Claimed data recovery success rates are much higher. While they may, in fact, approach 100% for some hard disk drive models, for other models the success rate is near zero. Drive-independent data recovery methods are required to read these hard disk drives. Furthermore, as the data density of hard disk drives continues to increase, the number of unrecoverable hard disk drives is expected to grow.
The reason for this lack of successful recovery can be traced to the methods hard disk drive manufacturers must employ to achieve both high data density and high production yields. Specifically, current hard disk drives are "hyper-tuned" in the factory to optimise the performance of each section of each hard disk drive. The data format, head, disk, electronics, and firmware parameters are all optimised together. This means that it is less likely that a head stack, electronics board or parameter tables from one hard disk drive – even of the same model – will work well when used as a replacement in a failed hard disk drive.

Essential hard-and-fast rules for good backups: (BACKUP CHECKLIST)

The foundation of a successful self-maintaining backup strategy is a carefully planned, robust and reliable backup and restoration software with built-in automation technology that simplifies many of the common tasks associated with setting up, scheduling, and maintaining backups. A carefully designed backup strategy augmented by such automation technology can protect the maximum amount of data with minimum time and IT resources - a perfect combination for individuals, SMBs and distributed enterprises. GBM’s intuitive wizards help users and businesses set high-level backup and restoration policies. Ensure that regular, scheduled backups, preferably when the system is idle so that it does not impact on network performance or users’ work in progress. Any information that changes on a daily basis needs to be backed up daily; if information remains static, back it up less often. Using GBM, a business can set up automated disk-based backups in five steps.

The following points should be considered. Preparing checklists for worst case situations is a strategy that may well alleviate a condition that on the face of it looks hopeless.

Estimate required disk space. Each of the different media has benefits and drawbacks. Consider the cost per gigabyte when comparing media solutions.
Determine the amount of disk space that will be required to hold daily backups of networked computers by adding the amount of disk space used on all computers and multiplying by two. This approximation permits a reasonable number of restore points for each computer.
Organise computers into groups.
Create groups that will later be populated with servers, desktops, and notebooks. While creating these groups, consider the kinds of backup policies that are required for the different kinds of data being protected. For example, an e-mail server could be placed in its own group to facilitate the enforcement of e-mail retention policies. Data from the financial department might need to be stored in another group to facilitate compliance with regulatory guidelines. Moreover, the assignment of different categories of data to different types of storage media in order to reduce total storage cost, value or importance, can be implemented as part of a tiered (classed or levelled) storage system. Categories may be based on levels of protection needed, performance requirements, frequency of use, and other considerations, rather than managed uniformly. Tier 1(class A or level Platinum), data, e.g., mission-critical, recently accessed, or top secret files stored on expensive and high-quality media such as double-parity RAIDs; tier 2 (class B or level Gold) data, e.g., financial, seldom-used, or classified files stored on less expensive media in conventional storage area networks (SANs). As the tier number increases, cheaper media may be used. Therefore, tier 3 (class C or level Silver) in a 3-tier storage system might contain event-driven, rarely used, or unclassified files on recordable optical discs or tapes. Note: For completeness the final Tier is 4 (class D or level Bronze).
Install the backup and restoration application on the backup computer and its client agent on any networked computers being protected.
From within the backup application, assign the networked computers to backup groups.
An automated (scheduled/unattended) backup should be considered, as manual backups can be affected by human error.
Set up a backup schedule for each of the groups. The backups should be sent to disk with a data grooming policy enabled.
Avoid the often repeated practice of not validating the data or verify that it can be restored successfully and in a timely manner in the event of a disaster.
Periodic backups improve data recovery reliability.
Making two copies of backup can potentially increase security for data recovery, to avoid accidents such as fire and physics randomness.
Multiple media backup, for just one content, can be done with independent indexing to optimize individual data recovery.

The more importance placed on data the greater the need for backing up.

Onsite & Offsite: onsite provides a quick and convenient method of isolating backups in the same vicinity as the original backup, if possible. Backup to hard disk drive media can be leveraged to deliver the fastest possible but ever decreasing backup window. Unlike tapes, hard disk drives can absorb data transmissions that arrive in bursts, making it a much faster media for backing up multiple computers simultaneously over a network. Because a hard disk drive backup is faster, it protects more data than tape during a limited backup window. Later, the data can be periodically transferred to tape (or possibly to an optical storage system such as a DVD or magnetic optical device), which is a more cost-effective media for offsite backups and archiving storage. This approach is called disk-to-disk-to-tape (D2D2T). Traditionally, many businesses have backed up directly to relatively inexpensive tape systems. However, for many computer applications, it is important to have data immediately ready to be restored from a secondary disk if and when the data on the primary disk becomes inaccessible, e.g., server failure. The time to restore data from tape would be considered unacceptable. On the other hand, tape is a more economical alternative for long-term storage (archiving). Because it is also more portable, tape is often used for offsite backup and restoration in case of a disaster. Disk-to-disk-to-tape is often used as part of a storage virtualization system. In such a system, data that is more likely to require restoration from a backup device may be kept on an onsite or offsite disk storage system; data, such as e-mail, that has less value over time, may be migrated on a set schedule to tape. The storage administrator can express a company's needs in terms of storage policies rather than in terms of the physical devices to be used.
This second transfer of data is also more efficient. The data streams rapidly from the backup hard disk drive to tape, and the transfer is performed without affecting the network, applications, or users. Hard disk drive backups also deliver fast and easy restores. Hard disks drives stored onsite can be easily accessed because they are already loaded and online. They offer fast random access. Tapes require time to advance to the relevant data, and offsite tapes must be located and returned onsite before a restore can take place. Even in cases where archived data must be retrieved from tape, the restores are more efficient if the tapes have been created from an intermediate backup to hard disk drive, because the intermediate stage of hard disk drive backups keeps related files and folders together on the backup media for faster restores. It is preferably to store backups off site for safety purposes, otherwise there is the risk of losing the backup copy in the event of a disaster such as fire or theft. If tape is to be used for offsite storage, establish an offsite rotation strategy. Some tapes will be stored offsite temporarily and then returned onsite to be reused. Others will be permanently archived in a secure offsite location to provide a history of restore points for recovering past data. The process of creating and tracking tapes needs to be fast, easy to manage, and as effortless as possible. Tracking backup tapes for offsite storage can be a complex and time-consuming process. Many tape rotation strategies force IT staff to juggle multiple sets of tapes that must be moved offsite, returned onsite, and used in a precise order. Schedules are tracked precisely and a great deal of planning, maintenance, and careful attention to detail is required to ensure that each backup is placed into the correct folder, and that folders are reused correctly. Most SMBs and distributed enterprises do not have IT staffs that can spare the time or effort required to maintain this strategy effectively. An effective and easy-to-manage solution for moving data from hard disk drive to tape is to select backup software like GBM, which stores backup data in a manner that is independent of the kind of media being used. GBM allows data to be transferred quickly from hard disk drive to tape and makes it easy to create and track multiple sets of backup media. Because GBM can store backup data on hard disk drive, even span it, there is no need to purchase expensive tape library emulation technology (a feature incorporated in GBM Professional and Server) or create a complex hierarchy of folders each of which represent a tape for storing the data.

Trend: Hard disk drives continue to replace tape as a primary backup medium. The ratio of hard disk drive-to-tape capacity fell to 1.5 in 2005 from 2.0 in 2004. Suggesting that within two years, hard disk drive usage could exceed tape usage while there is continuing growth in the use of hard disk drive products also. Moreover, traditionally, storage decisions have been driven due to media and media formats. But once all storage becomes searchable, the specific media on which information is stored will be less important as storage and retrieval becomes more “intelligent”.

In an organisation, make sure the backup policy is clearly documented and supported by managers, not just the IT department. You do not want to discover six months after the person responsible for managing backups has left that nobody has any idea where the data is backed up, how frequently it is backed up, what is backed up and how.
Verify that a backup has been successful – you do not want to restore a copy only to find it is corrupt or incomplete. Seldom are backup copies tested, and occasionally they are found to be corrupt.
Check the life expectancy of the media used to store backups on. Ensure that the media has a life expectancy that exceeds and legal requirements in holding data for a period of time.
Consider using an online backup service if you do not wish to invest in the products and media, paying instead a subscription fee to store data offsite.
Create multiple copies of your data.
Take care of your backup media before and after it is used, e.g., do not drop it, expose it to sunlight, heat, coolness, damp, and so forth.
Performs fast, automated, easy-to-manage backups and onsite restores.

To the storage subsystem, the file is simply a collection of bits and bytes grouped together as blocks of data by the filesystem and application that created the file.
Note: The emergence of low-cost disk-drive technology is making D2D2T storage infrastructures more commonplace. In fact, the cost-effectiveness of D2D2T infrastructures is a cornerstone among many Information Lifecycle Management (ILM) strategies. The reason being is that it supports ILM's idea that companies can move data onto less costly storage as it ages, eventually archiving it onto tape.
One of the primary challenges for companies that try to implement ILM is the data-migration management process; the challenge being when data should be moved. Typically, with ILM and its antecedent, Hierarchical Storage Management (HSM), data migration has been part of storage management. However, the line between data management and storage management is blurring. Data-management technology providers are increasingly including storage-management functionality in their products, while there are signs that storage-management vendors are moving more aggressively into what was once the domain of database and application vendors.
Side Note: Backup operations have evolved in terms of both user requirements and the technology implemented to achieve backups. Usage requirements have given order in that backups are made more frequently, yet without disrupting applications accessing data. Backup operations evolved from stand-alone backups-to-backup operations happening across a local area network (LAN or Lan) in a storage area networked (SAN or San) environment. One problem that backup applications need to overcome is backing up open files being accessed by active programs while the backup is being performed. Moreover, backup applications have had to deal with a multitude of APIs that are specific to an application, and operating system. Yet another trend has been to create the initial backup from disk-to-disk, via a snapshot operation. Backup to tape is increasingly becoming a secondary backup operation, from the snapshot volume to tape. The Windows VSS copy service provides an efficient way to create snapshots. The architecture provides for all important components, including major applications such as databases and messaging servers to participate in the snapshot creation. Microsoft provides only the infrastructure to create a snapshot. Software vendors may use this infrastructure to build an application that can create and manage multiple snapshots. Once a snapshot has been created, a backup may be created from the snapshot.
See: Automatic Backup Scheduling, Data, Data Loss & Data Recovery, Open File, Storage Area Network (SAN), and Volume Shadow Copy (NTFS filesystem for Windows XP Professional & Server 2003 only).

Backup Types (Thou shalt make regular and complete backups)

Storage industry experts have identified backup and recovery as a major area of concern for small and midsize businesses (SMBs) and distributive enterprises. These businesses, usually with limited IT staff on site, must protect an ever-growing amount of data in an ever decreasing backup window.
Backup and restoration implementations have always been driven by five key criteria: time, speed, size, certainty, and cost. How long does it take to complete a backup operation, and how long must data be retained? How long does it take to restore lost data? How much data must be backed up? How certain are you that backup operations have succeeded and data can actually be restored? Finally, how much does it cost?
For a long time, before the World Wide Web began to affect business operations, large companies would perform backups nightly. Smaller companies would often back up data once a week or even less.
As Web-based operations and a new breed of enterprise-level applications have emerged, the traditional backup scenario has begun to break down rapidly. As companies stay "open for business 24/7" they generate more data, the backup window shrinks while more information is managed. Many companies cannot backup their data in the allotted backup window, while once-a-day seems inadequate as too much data is generated each day. New backup and restoration implementations are now available to overcome these problems. Genie-soft’s Backup Manager Family of products is one solution worth considering, ensuring a good backup and restoration business-continuity insurance.
The purpose of backing up business-critical data is to enable an accurate restore when data loss occurs. Backups have to run as quickly as possible in order to protect the multiple gigabytes of data that reside on typical networks of servers, desktops, and notebooks. A reliable backup strategy must be built on business-class backup software that is easy to use and understand, creates reliable backups and allows accurate restores/recovery from disaster. Backup software needs to provide complete protection for all computers, applications, settings and so forth. In addition, backup software needs to utilise automated backup technology, allowing small and midsize businesses to protect data without requiring extensive IT resources or unnecessary expenditures to train employees in complicated backup and restore procedures.
The choice of backup methods greatly influences the restoration scenarios that can be supported. Consequently, the backup type chosen determines which data is backed up and how it is backed up. There are five backup types: copy, daily, differential, incremental, and normal.
The best way to increase the speed of a backup job is to selectively back up only those files that have changed or been created since the last backup. Traditional Windows backup applications rely on a file attribute known as the ‘archive bit’ to determine whether or not a file has already been backed up. Any time a file is modified, the archive bit is turned on (set to 1). When a backup application later copies that file, the archive bit is reset (set to 0), except in the case of differential backups, where the archive bit is not reset following a backup. Speed and accuracy of backups and restores are critical in assessing the desirability of a backup method.
Backups are intensive operations that can place severe demands on I/O subsystems, memory utilisation and network bandwidth.

Copy and Daily backups are a way of backing up rather than belonging under backup type per se.

Copy backup: a backup that copies all selected files but does not mark each file as having been backed up - in other words, the archive attribute is not cleared. Copying can be carried out between normal and incremental backups because copying does not affect these other backup operations.
Daily backup: a backup that copies all selected files that have been modified during the day, the daily backup is performed. The backed up files are not marked as having been backed up - in other words, the archive attribute is not cleared.

An alternative way of classifying backup applications is based on the functionality that is achieved in the backup process and classifying backups based on the architecture/schemes that can be categorised in different ways, i.e., file-level or application-level. Note: A data centre typically uses at least two and very often all types of backups types, e.g., full, differential, and incremental. In short, the categorisation of backups should not be taken to be mutually exclusive.
Typically, a specified amount of space is allotted on hard disk drive(s) for storing backup data. Two primary types of backup are Incremental or differential which are used as a concession to the time constraints that exists in most businesses, accomplishing the same goal of backing up and restoring in different ways. Fast backups are achieved by running an initial full backup followed by periodic incremental or differential backups. They can run on a regular schedule within a reasonable amount of time, allowing an end user or company a safeguard for the most recent information on all computers. Restoring from these two backup methods is more complex and the restore is always flawed when restoring more than a single file. During a restore the files and folders from the full backup are returned to the hard disk drive, followed by data from the series of incremental backups or from the latest differential backup. This method of performing restores is flawed because the process restores all the contents of the full backup plus all the contents of the required incremental or differential backups, including previously deleted, moved, or renamed files and folders. The only way to get the benefits of incremental or differential backups and still have accurate restores is to use backup software, such as Genie-soft’s Back Manager family, that catalogues pertinent information and in doing so is able to return the exact files and folders that existed at that particular point in time. As a backup practice, both incremental and differential backups accomplish the goal but accomplished different ways; reducing the resources needed to backup data.

Differential backup: a (architecturally defined file-based) backup that cumulatively copies/archives all files or objects (and associated metadata) created or changed since the last normal/full or differential backup. It does not mark the file as having been backed up. In other words, the archive attribute is cleared only after a full backup is performed. Performing a combination of normal and differential backups, restoring files and folders requires that the last normal as well as the last differential backup is available. The main advantage of differential backup is that the backup takes a lot less time than a normal/full backup but longer than for incremental, yet are easier to restore – a full restore only requires the last full backup and the last differential. On the other hand, the disadvantage is that recovering from a disaster takes more time than a normal backup, but far less time than for incremental. A disaster recovery operation involves running at least two restore operations, one corresponding to a full backup and one corresponding to a differential backup. Because the amount of changed data increases over time, differential backups consume increasingly more time and media, until it becomes more efficient to run another full backup and begin the differential backup cycle again. With low-end storage deployed, file-based differential backups are used when the applications by nature tend to create multiple small files and change or create just a few of them since the last full backup. In addition, when low-end storage is deployed, file-based differential backups are not typically used with database applications, because database applications, by their very nature, tend to make changes in small parts of a huge database file. Hence a file-based backup would still have to copy the whole file. Differential backups are typically easier to restore, but incremental backups allows for a more granular restore.

Incremental backup: a (architecturally defined file-based) backup that copies/archives only those files created or changed since the last normal (full) or incremental backup. An incremental backup is also referred to as a cumulative incremental backup. It marks files as having been backed up. In other words, the archive attribute is cleared/reset after each incremental backup is performed. This creates a series of relatively small backup media sets, each containing the information that changed since the previous backup. Performing a combination of normal and incremental backups to restore previously backed up data requires the last normal backup and all incremental backup sets. The obvious advantage is that this backup takes less time and resources because items not modified since the last full or incremental backup do not need to be copied to the backup media. The disadvantage is that a disaster recovery operation will take longer because restore operations must be done from multiple media sets, corresponding to the last full backup followed by the various incremental backups. For example, normal (full) backup of Monday but incremental of Tuesday, Wednesday, Thursday and Friday. In the absence of high-end storage, file-based incremental backup is used only when a different set of files is typically created or modified. Incremental backup allows for a more granular restore, but differential backups are typically easier to restore.

In most cases, a full backup will be performed weekly while an incremental or differential backup will be performed daily.
Without an accurate restore, the time saved by running incremental or differential backups is clearly not of benefit, because it is difficult or even impossible to clean up the hard drives after the otherwise flawed restore. This flaw is irrelevant when using Genie Backup Manager (GBM).

Normal backup: the final primary backup type and a (architecturally defined file-based) backup that copies the complete set of selected files on the system. This may or may not include the file allocation tables, partition structure and boot sectors, depending on whether the backup is a block-level backup or just a file copy. This backup type marks files as having been backed up. In other words, the archive attribute is cleared/reset after each backup is performed. With normal backups, only the most recent copy of the backup file set is needed to restore all the files. Normal backups are typically performed the first time a backup is carried out. When restore precision is paramount, traditional backup applications require ongoing full backups. The advantage of having a full backup is that only one media set is needed to recover everything in a disaster situation. The disadvantage is that the backup operation takes longer because everything needs to be copied.

Side Note: With file-level backups, as opposed to image- or block–level backups, the backup software makes use of the operating system, e.g., server, and filesystem to back up files. One advantage of this approach is that a particular file or set of files can be restored relatively easily. Another is that the operating system and applications can continue to access files while the backup is being performed. A disadvantage is related to security. The problem is that the restore is typically done through an administrator account or backup operator account rather than a user account. This security shortcoming is irrelevant when using GBM. This is the only way to ensure that multiple files belonging to different users can be restored in a single restore operation. The key is that the file metadata, such as access control and file ownership information, must be properly set. Addressing the problem requires some Application Programming Interfaces (API) support from the operating system and filesystem involved (NTFS) to allow the information to be set properly on a restore operation. In addition, of course, the restore application must make proper use of the facility provided.
With Application-level backup and restore it is performed at the application level, typically an enterprise application level, e.g., Microsoft SQL Server or Microsoft Exchange. The backup is accomplished via APIs provided by the application. Here the backup consists of a set of files and objects that together constitute a point-in-time view as determined by the application. The main problem is that the backup and restore operations are tightly associated with the application. If a new version of the application changes some APIs or functionality of an existing API, it is imperative to obtain a new version of the backup/restore application. Applications either use a raw disk that has no filesystem associated with the volume/partition or simply have a huge file allocated on hard disk drive and then lay down their own metadata within this file. A good example of an application that takes this approach is Microsoft Exchange. Windows XP and Windows Server 2003 introduced an important feature in NTFS to facilitate restore operations for such files. The file can be restored via logical blocks, and then the end of the file is marked by a new Win32 API called SetFileValidData.
GBM Home, Professional and Server are capable, besides many other functions, of automatically making backup copies of data files using the backup types described, for single users or corporations.
A major limitation of many backup programs relates to open files. If files are open/in use/locked, e.g., e-mails, databases, Customer Relationship Management (CRM), and accounting for business-critical server applications such as Microsoft Exchange Server and Microsoft SQL Server that run continuously, a backup program cannot gain access to the file’s contents. Open file backups can be problematic for desktop and notebook computers too. Even if the backup program can access an open file, it runs the risk of creating an inconsistent backup. For this reason most backup programs skip open files altogether. Genie-soft has developed its own online backup program that complements its backup program family called File Access Manager (FAM). Under Window XP Professional and Windows Server 2003, FAM is shadow-copy aware enabling it to receive freeze and thaw notifications to ensure that backup copies of data files are internally consistent.
To the storage subsystem, the file is simply a collection of bits and bytes grouped together as blocks of data by the filesystem and application that created the file.
See: Archive Bit, Data, Data Loss & Data Recovery, Fault Tolerance, Network Attached Storage (NAS), Storage Area Network (SAN), and Open File.

Backward Compatibility

The design of software and hardware to work with previous versions of the same software and hardware.

Bad Block or Bad Sector

A bad sector is a sector on a hard disk drive that can no longer be used for data storage, usually due to media damage/flaw or imperfections. While a small number of read errors, due to bad blocks, may have minor consequences and prevent access to one or more files, large blocks of unreadable sectors can prevent access to individual volumes or even an entire hard disk drive.
In addition to the recovery features mentioned, NTFS uses redundant storage for vital filesystem information so that if a sector on the hard disk drive goes bad, NTFS can still access the volume’s critical filesystem data. This redundancy of filesystem data contrasts with the on-disk structures of both the FAT filesystems. On these FAT filesystems, if a read error occurs in one of these critical sectors an entire volume can be lost.
An interesting fact is that bad sectors account for more data loss than from virus damage. One preventative measure is not to move or knock an operational computer.
See: Bad Block or Bad Sector, Bad-Cluster File, Data Loss & Data Recovery, Dynamic Cluster Remapping, and NTFS (New Technology Filesystem).

Base File Record

Usually, each Master File Table (MFT) record corresponds to a different file. If the file has a large number of attributes or becomes highly fragmented, however, more than one record may be required for a single file. In such a case, the MFT first record, which stores the location of the others, is called the base file record. The base file record is the first record in the MFT for a file that has multiple file records. The base file record is the record to which the file’s file reference corresponds.
See: Attribute (Resident & Non-Resident), Attribute List, and Master File Table (MFT).

Basic Disk

Windows introduced the concept of basic and dynamic disks. Windows calls disks that rely exclusively on the two types of partitioning scheme, and in turn define the volumes, MBR-style (basic) or GPT-style (dynamic) disks. When an x86 processor boots, the computer’s BIOS reads the MBR and treats part of the MBR’s contents as executable code (boot code). The BIOS invokes the MBR code to initiate an operating system boot process after the BIOS performs preliminary configuration of the computer’s hardware. In Windows, the MBR also contains a partition table. A partition table consists of four entries that define the locations of as many as four primary partitions on a hard disk drive. The partition table also records partition type. Numerous predefined partitions exist, and a partition type exists under FAT32 and NTFS. A special partition type, an extended partition, contains another MBR with its own partition table. The equivalent of a primary partition in an extended partition is called the logical dos drive. By using extended partitions the Windows operating system overcomes the apparent limit of four partitions per disk. The recursion that extended partitions permit can continue indefinitely, which means that no upper limit exists to the number of possible partitions on a hard disk drive. The operating system must have one primary partition on the primary disk as active. The Windows code stored in the first sector of the active partition (both boot volume and boot partition) into memory and then transfers control to the code. Because of the role in the boot process played by this first sector in the primary partition, Windows designates the first sector of any partition as the boot sector. Every partition formatted with a filesystem has a boot sector that stores information about the structure of the filesystem on that partition.
Basic volumes include primary partition and logical dos drives within an extended partition. By default, Windows NT family operating systems initialise a hard disk drive’s volume(s) as a basic disk(s). It is permissible to create up to four partitions in the free space of a hard disk drive; one of these can be an extended partition to create one or more logical drives. It is permissible to create and delete primary and extended partitions; create and delete logical dos drives within an extended partition; format a partition and mark it as active; delete a volume, stripe, mirror, or strip set with parity. Unless the user requires multi-partition functionality of dynamic disks, the basic disk format is used as a matter of course.
Because Windows does not support the creation of multi-partition volumes on basic disks, a new basic disk partition is equivalent of a volume.
See: Active Volume, Basic Disk, Basic Volume, Dynamic Disk, Dynamic Volume, Master Boot Record (MBR), NTFS (New Technology Filesystem and Partition.

Basic Input/Output Subsystem (BIOS)

When a computer is powered on to operate, each power supply unit (PSU) completes internal checks and tests before allowing the system to start. If the tests are completed successfully without incident, the PSU sends a special signal to the motherboard called the Power_Good (or Power_OK or POK) signal. It takes a few moments to generate reliable power (between 0.1 to 0.5 seconds) for the rest of the computer. If the POWER_GOOD signal is not continuously present, the computer will not run. In short, the PSU actually prevents the computer from starting up or operating until all the correct power levels are present.
There was a time when the System BIOS (that all motherboards have); rudimentary yet very important software that boots the system initially, contained all the device drivers such as, keyboard, video adapters, serial and parallel ports, floppy controller, hard disk drive controller for the entire system, Power-On Self Test (POST) routine and bootstrap loader all burned (programming the memory chip at a higher voltage than normal, akin to optical media) into one or more non-volatile motherboard (True or Mask) ROM (Read-Only Memory) chips - anything up to six single ROM chips. However, the old styled motherboard ROM chip is no longer used as more advanced non-volatile memory chips are used, e.g., PROM (Programmable ROM), EPROM (Erasable PROM: pronounced "E"-PROM and a popular variation of the PROM, but erasable by exposure to intense Ultraviolet light through a clear quartz window above the die) and EEPROM (Electrically EPROM; also called "flash ROM"). In essence, the device drivers were once self-contained, preloaded into memory and accessible anytime the PC was powered on.
The BIOS chip typically consists of two rows of pins that insert into the socket or holes of the motherboard printed circuit board (PCB). They are referred to as DIP, meaning Dual-Inline Package. The advantage of the DIP (number of pins commonly used are 24 through to 32 depending on the capacity of the chip) is that it is easy to remove and install a chip, unless soldered in. EEPROM, using the same technology as EPROM but more transistors, is the most recent non-volatile memory chip. The advantage of the EEPROM chips is that it can be electrically programmed partially or completely while in situ. Since 1994, motherboards have tended to use EEPROM chips for their reprogramming ease as well as being faster; they deal with blocks of memory rather than in single bytes. The difference in speed is not significant.
Regardless of the type of ROM used in a system it is still non-volatile (does not reguire a continuous source of power) and data remains indefinitely unless overwritten/reprogrammed: ROM is a type of memory chip but non-volatile unlike RAM.
Nowadays, it is impossible to self-contain all necessary device drivers in the System BIOS within a motherboard's ROM chip (128KB of RAM in two 64KB portions: E0000-EFFFF and F0000-FFFFF, while video and other auxiliary BIOS routines are located at C0000-CFFFF and D0000-DFFFF; video in particular is located at C000h-C780), because as new devices are introduced this would require the BIOS chip to be firmware updated each time with device drivers. Moreover, a BIOS chip has a finite amount of space allocated to it. For this reason the BIOS, discussed later, has grown across three physically distinct locations.
One of the responsibilities, during POST, of an operating system and disk format independent Plug and Play (PnP) System BIOS is to isolate and initialise all PnP cards and assign them a valid Card Select Number (CSN) - PnP devices have a 3-character vendor specific device ID stored in the hardware so that the operating system can recognise it. After a CSN has been assigned, the System BIOS can designate resources to the cards such as I/O ports, IRQs, DMA channels, and memory locations. The BIOS is only responsible for the configuration of boot devices. Note: For all other PnP devices detection runs asynchronously during the logon process. The PnP Manager determines which drivers are required to support a particular device and loads these drivers. Any un-configured PnP devices are configured by the appropriate application software for example. At this point, the operating system is loaded and takes control over PnP system resources. Advanced Configuration and Power Interface (ACPI) is designed not only to control power, but also all PnP hardware configurations throughout the system. With ACPI, system configuration (PnP) as well as power management configuration is no longer controlled via the BIOS Setup; it is entirely controlled within the operating system instead, from Windows 98 onwards. Moreover, ACPI also uses the PnP BIOS data structures and controls PnP interfaces, providing an operating-system-independent interface for configuration and control.
On a modern x86 computer (or 80x86, the generic name of a micro-processor architecture) the System BIOS is stored on an EEPROM memory chip sitting on a Firmware Hub (FWH interface) or Serial Peripheral Interface Bus (SPI interface), so that it can, when the computer is powered on, begin its complex and convoluted POST sequence of duties when the CPU is reset, i.e., powered on, cold or warm boot. To ascertain a warm boot or a cold boot the ROM BIOS - (as the BIOS is stored in the main portion of the ROM, it is often called the ROM BIOS, located at F000:0000 and F000:FFFF) - starts up routines to check the value of two bytes located at memory location 0000:0472. Any value other than 1234h or 0x1234 (indicating a warm boot) indicates that it is a cold boot, or the absence of the PSU's POWER_GOOD signal instigating a power reset.
As mentioned, the first set of startup instructions is the POST, with the main duties of POST being carried out by the BIOS, with some of these duties performed by other programs designed to initialise very specific peripheral devices, notably, for video, SCSI (pronounced scuzzy) and ATA/IDE host initialisation. These other duty-specific programs are generally known collectively as option ROMs or individually as the video BIOS, SCSI BIOS, Network Interface Card BIOS and RAID BIOS and so forth. The first to be summation checked and released is the video BIOS; each following thereafter. Option ROMs, stored on EEPROM chips, contain auxiliary BIOS routines and drivers needed by the particular adapter card; complementing or superseding the System's BIOS code for the given component. An add-in adapter usually requires an option ROM if it is necessary for it to be used prior to the time that the operating system loads or are complex enough not to be handled by the main BIOS directly, e.g., video and SCSI adapters. An IDE/ATA hard disk drive's BIOS will be found at C8000h: for built-in video and additional ROM drivers configured such as onboard devices and SCSI or network adapters, the range is from C8000h to DFFFFh.
Most computers scan and test many of their motherboard circuits e.g., various system components such as RAM (Random Access Memory; also known as physical memory), discover, initialise, and catalogue all system buses and devices, hard disk drives and optical disc drives, keyboard and mouse and so forth. Add-on cards/adapters carry out their own BIOS/firmware internal diagnostic tests. The BIOS must carry out an inventory of the hardware installed; then communicates or interrogates the hardware to ensure that it is functioning correctly. Modern BIOSes have the additional functionality to automatically collect settings: memory timings (based on the memory type found), dynamically set a hard disk drive's parameters and access modes, display an onscreen message for each device detected and configured in this way. The BIOS must integrate the plethora of competing, evolving, and even mutually exclusive standards and initiatives for the matrix of hardware and operating systems the general-purpose computer (PC) is expected to support. To the end user, all that will be evident as POST and BIOS activity is the simple visible memory test and setup text in the form of detected hard disk drives, optical drives and adapter cards, where applicable. This is the final stage of the BIOS POST routine.
Once all tests have been completed a beep sound comes from the internal speaker if this initial test indicates devices are properly connected, and operating for proper system performance. If problems are found these routines alert the user with a series of beeps or a message, often accompanied by a diagnosis numeric value. If POST is successful, it passes control to the bootstrap loader. Note: During the POST, one of the primary duties of the BIOS is to determine the reason it is executing. For example, for a cold boot, it may need to execute all of its functionality. On the other hand, systems supporting power savings or quick boot methods, the BIOS may be able to circumvent (by-pass) the standard POST device discovery, and simply program the devices from a pre-loaded system device table.
Today, all Windows NT family operating systems have been designed so that all 32-bit device drivers are loaded from disk to replace all the device drivers that once resided in the motherboard ROM (but 16-bit drivers are still used in part in real mode), such as drivers for graphics adapters, sound cards, scanners, printers, SCSI host board adapters (HBA), and many more hardware devices that are installed over time. The motherboard ROM exists only to initialise the system startup, to initialise specific hardware, to offer security in the way of a power-on-pass-word, and to perform some basic install configuration. Under these operating systems the motherboard ROM and option ROMs are used simply to get the system functional long enough to get the initial 32-bit device drivers to take over and the operating system loaded, at which point any 16-bit drivers are shut down and no longer required. 64-bit operating systems require all 64-bit device drivers to be loaded without exception. No 32-or 16-bit device drivers are used.
For example, once Windows XP is loaded, the BIOS may be mostly in ROM, but at this time it resides entirely in RAM.
The BIOS consists of all the individual driver programs that operate between the operating system and the actual hardware. Consequently, the operating system does not communicate directly with the hardware but through the appropriate operating system specific driver supplied normally by the hardware manufacture. This provides a consistent way to communicate with the hardware and a consistent way that an operating system can be used with different hardware. There is no perceptible different to the computer user using the operating system because the drivers provide the same basic functions, so applications will be perceived as identical from system to system, but the hardware can differ substantially. Consequently, many device drivers can be loaded once the operating system is loaded.
The BIOS Setup configuration information is stored on a motherboard chip called the RTC/NVRAM digital clock chip (Real-Time Clock/Non-Volatile RAM) or confusingly CMOS RAM chip (Complementary Metal Oxide Semiconductor RAM), where CMOS configuration information is stored and POST can refer to the hardware setup information. Note: The RTC/NVRAM is strictly volatile as it requires a small amount of power (supplied by a Lithium coin battery) in order for the BIOS Setup information to be retained; its advantage is speed over other types of non-volatile memory, even EEPROM.
The vast majority of motherboard suppliers license a BIOS "core" and toolkit from a commercial third party such as American Megatrends (AMI) or Phoenix Technologies, which creates and maintains such a core. The motherboard manufacturer then customises these BIOSes to suit its own hardware. Even so, in order to access the BIOS Setup, containing menus and submenus of configuration options, prior to POST, for AMI press "Delete" and for Phoenix press "F2". If these standardised keystrokes do not allow access to the BIOS Setup consult the motherboard manual.
As is quite evident, the BIOS has developed considerably over time and in parallel with the development of more complex operating systems; initially self-contained in a ROM chip to one that seeks out option ROMs, special files such as IO.SYS and CONFIG.SYS to load device drivers on the boot volume into RAM during the early stages of the boot process and then linking the collective whole of the BIOS that could be called upon when necessary. The BIOS, once contained entirely in a single location within the motherboard ROM chip, is now constructed of programs located in three different physical locations in the system; yet it functions as a single entity because all the programs are linked together via the BIOS subroutine calling system-of-software interrupts. The combination of the motherboard BIOS, option ROMs and device drivers loaded from disk contribute to the BIOS as a whole. The portion of the BIOS contained within the motherboard ROM and option ROM chips are often referred to as firmware.
Specifically, before an operating system can be loaded the (x86) central processing unit (CPU) attempts to begin the process of processing data. However, as the system memory is empty, the processor will not have anything to execute, or even begin to know where to look for it. Therefore, to ensure that the system will boot regardless of the BIOS programming instructions, both CPU and BIOS manufacturers together developed code so that the processor, once turned on, always started executing its first instruction at the default location (reset vector); initiated by a jump instruction/command at memory address/location FFFF:0000h. The actual reset vector is a pointer or address for x86 CPUs at memory address 0xFFFFFFF0, although the value of the CS register at reset is 0xF000 and the value of the IP (instruction pointer) register at reset is 0xFFFF0. Without the system's RAM address space being mapped into one of the ROM chips and its location, exactly 16 bytes from the end of the first megabytes of RAM space, as well as the ROM space itself, on powering off, the CPU would have its location to execute instructions but no instructions would exist. As it stands now, on powering off, the CPU will execute instructions on each system power on.
On modern machines, generally, the bootstrap loader, a program also referred to as interrupt 19 (INT 19) runs automatically when a computer is turned on. As mentioned, the first set of startup instructions is the POST. At the completion of the system's POST, assuming there are no fatal problems, INT 19 is called. Generally, INT 19 is a routine that tries to read the first physical sector from the first floppy diskette drive. If a boot sector (in this case the boot record) is found on the floppy diskette, the boot sector is read (in other words it is loaded) into memory at location/address 0000:7C00 - INT 19 jumps, initiated by a jump instruction. However, if no boot sector is found on the first floppy diskette, INT 19 tries to read the first physical sector of various hard disk drives searching for a valid Master Boot Record (MBR) from the first hard disk drive's absolute sector zero in CHS mode and zero in LBA mode. If, during this INT 19 process, any other essential boot devices BIOSes are found, they are executed, i.e., SCSI ROM that potentially has a hard disk drive with a valid MBR. If on meeting certain minimum criteria (ending in a signature byte or signature word, 55AAh or 0x55AA) indicating the start of a ROM is detected, the code within the MBR is executed. If no valid MBR is found, the ROM puts into effect interrupt 18 (or INT 18) displaying a message and the boot process will stop.
The essence of all these messages is that none of the bootable devices in the bootable sequence were found to contain signature byte indicating a valid MBR in their first physical sector.

"NO ROM BASIC - SYSTEM HALTED" or "No boot device available, strike F1 to retry, F2 for setup utility" or "No boot sector on fixed disk, strike F1 to retry boot, F2 for setup utility" or "Non-System disk or disk error, replace and strike any key when ready" or "DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER". (Solution: set a primary partition to "active", partition the hard disk drive and the set the primary partition to "active". Each partition table entry is 16-bytes long, with a maximum of four entries, each with a Boot Indicator byte: these bytes are at offset 446 (partition table entry #1 (0x1BE or 1BEh)), at offset 462 (partition table entry #2 (0x1CE or 1CEh)), at offset 478 (partition table entry #3 (0x1DE or 1DEh)), and finally at offset 494 (partition table entry #4 (0x1EE or 1EEh)). These Boot Indicators are used to determine if the partition is active (bootable) by checking for the value 0x80 or 80h. The remaining Boot Indicators will have a value of 0x00 or 00h. Consequently, if all four table entries have 00h then the MBR returns control to the motherboard ROM). This is a non-fatal POST error message.
"Invalid partition table". The source of the error message is the MBR. There is more than one Boot Indicator byte with a value of 0x80 or 80h - more than one partition marked "active." (Solution: deactivate the non-booting partitions. However, a thorough investigation of the partition table may be necessary, since the actual problem may be more complex). This is a non-fatal POST error message.
"Missing operating system” or “Operating system not found". The source of the error is BIOS related. The MBR is corrupted due to any of the reasons mentioned above. However, it is primarily related to small capacity hard disk drives where the translation settings are changed from LBA to CHS. The bootstrap loader in the BIOS translates drive sector locations differently and possibly incorrectly. For this reason the valid MBR's location and in turn the VBR will not be where they are expected to be; they are lost. (Solution: firstly, for hard disk drives of 528MB (504MiB) through to 8.4GB (7.9GiB) reverse the translation mode. Alternatively, rebuild the MBR and partition table using the Recovery Console command "fixmbr". Any boot problems can be corrected using "fixboot").
"Error Loading Operating system". The source of the error message is the MBR. An error was returned from the BIOS when the boot loader attempted to read the active partition's boot sector into memory. (Solution: In many cases this will be due to a "soft" ECC error and can be repaired by rewriting the boot sector.)
"BOOT: couldn't find Ntldr". (Solution: See Boot.ini entry pertaining to the /rebuild (Windows XP Recovery Console (RC) command).
"NTLDR missing". The boot loader was unable to locate NTLDR. Very often this indicates a corrupted file system. (Solution: Using the RC, copy a new NTLDR file from directory \i386 on the Windows XP/2000/Server 2003 Setup CD-ROM using CD \, then ATTRIB -C NTLDR. Otherwise use the bootcfg /rebuild (Windows XP Recovery Console command)).
"NTLDR is compressed". The NTLDR file is compressed. As NTLDR is necessary prior to the operating system loading, normal booting is prevented as there is no way to decompress the compressed NTLDR file. (Solution: Using the RC, copy a new NTLDR file from directory \i386 on the Windows XP/2000/Server 2003 Setup CD-ROM using CD \, then ATTRIB -C NTLDR. Otherwise use the bootcfg /rebuild (Windows XP Recovery Console command)).

Firstly, it should be mentioned that all option ROM within adapter cards start with the signature bytes 55AAAh; otherwise, the motherboard will not recognise them. The valid MBR code then continues the boot process by reading the first physical sector of the bootable volume; the start of the Volume Boot Record (VBR). The VBR (also known as the volume boot sector or partition boot sector) then loads the first operating system startup file: IO.SYS for non-Windows NT family operating systems and Ntldr.exe (NT Loader) for Windows NT family operating systems, upon which the operating system is then in control and continues the boot process. CMOS is a small area of memory (64-bytes) which is maintained by a small amount of power supplied by a Lithium coin battery attached to the motherboard. Most importantly for the ROM BIOS startup routines CMOS indicates the order in which devices should be examined for an operating system to load, e.g., floppy diskette device first, or optical device first, or hard disk drive first.
Note: When running in Dos or Windows in Safe Mode the system is running almost solely on ROM based BIOS drivers as none are loaded from disk.
To conclude, on new x86 computers, the BIOS will have a number of important functions:

Power-On Self Test (POST).
BIOS setup configuration, allowing for important hardware to be setup or tweaked.
PnP System BIOS starts the bootstrap loader. Bootstrap Loader (Interrupt 19 or INT 19).

ROM BIOS upgrades can improve a system in a number of ways, such as improved performance and more features that were previously unsupported, e.g., support for larger capacity hard disk drives, newer and faster CPUs, improvements in ACPI power management, fan speed monitoring and control, PnP support and compatibility, POST and other software and hardware related issues. The BIOS firmware update must be carried out correctly and competently.
The vast majority of motherboard suppliers license a BIOS "core", and toolkit from a commercial third party such as American Megatrends (AMI) or Phoenix Technologies, which creates and maintains such a core. The motherboard manufacturer then customises these BIOSes to suit its own hardware - for this reason firmware BIOS updates are normally obtained directly from the motherboard manufacturer. Ensure that the correct firmware update for the specific motherboard (or motherboard revision) BIOS is correct, otherwise the BIOS may need re-flashing with the correct firmware update or the BIOS chip replaced.
Even less comforting than a boot sector virus is the fact that a virus could be written directly to the BIOS EEPROM chip via an operating system infection. However, modern-day motherboards have a security algorithm that limits the possibility of any unauthorised updates occurring.
Some motherboards have two single-chip BIOSes, the second for recovery or if the first BIOS fails or is corrupted.
Note: BIOS can also stand for Basic Integrated Operating System.
See: BIOS Parameter Block (BPB), Boot.ini (non-Windows NT-based & Windows NT-based operating system system startup file #2), Boot Record, Boot Sector, Boot Sector Virus, Bootstrap, Bootstrap Loader, IO.SYS, LBA (Logical Block Addressing), Master Boot Record (MBR), Ntldr (NT Loader; Windows NT-based operating system system startup file #1), POST (Power-On Self Test), S.M.A.R.T (Self-Monitoring Analysis and Reporting Technology), System Volume, Volume Boot Records (VBR), Windows NT-Based Startup Phases.

Basic Volume (Simple Volume)

A basic volume is a volume on a basic disk. Basic volumes include primary partitions and logical drives within an extended partition. Because Windows does not support the creation of multi-partition volumes on basic disks, a new basic disk partition is equivalent of a volume.
See: Basic Disk, Basic Volume, Extended Partition, and Partition.

Binary Number Base System

Most modern computer systems operate using binary logic. The computer represents values using two voltage levels (usually 0V: logic 0; either +3.3V or +5V: logic 1). With two levels exactly two different values can be represented. These could be any two different values, but by convention the two bit binary digits used are zero (0) and one (1) and are refereed to as bits. Since there is a correspondence between the logic levels used by the computer and the two digits used in the binary numbering system, unsurprisingly computers work within the binary number base system.
Although the bit is a very important unit of measurement within the computing fraternity the problem with the binary system is its verbosity. When dealing with large values, binary numbers quickly become too unwieldy. The hexadecimal (base 16: include only digits zero (0) through to nine (9) and the letters, A, B, C, D, E, and F) numbering system solves these problems.
See: Bit Binary Digit, Byte, and Hexadecimal Number Base System.

BIOS Parameter Block (BPB)

The BIOS Parameter Block (BPB) provides information that enables the executable boot code to locate Ntldr. The BPB always starts at the same offset, so standard parameters are in the known location. Disk size and geometry variables are encapsulated in the BPB. As the first part of the boot sector is an x86 jump instruction, appending new information can extend the BPB in the future. The jump instruction needs only a minor adjustment to accommodate this change.
The BPB describes the physical parameters of the volume: the extended BPB (EBPB) begins immediately after the BPB. As a consequence of the differing field types and the amount of data they contain, the length of the BPB is different for FAT16, FAT32, and NTFS boot sectors.
Disk device drivers use the information in the BPB and the extended BPB to read and configure volumes. The extended BPB typically contains executable boot code, which performs the actions necessary to continue the startup process.See: Boot Code (executable instructions within the MBR), Ntldr (NT Loader), Volume Boor Record (VBR), and Windows NT-based operating system system startup file #1).

Bit Binary Digit

A bit binary digit (data element), or bit for short, is either of the two digits zero (0 = off) and one (1 = on) in the binary number base system. Any other digit would make the number an invalid binary number. The x86 computer works within the binary number base system. Something is set (on) or something is clear (off), something is either true or false etc. The two states zero (0) and one (1) are referred to as bits.
Bits, or groups of bits, are used in computing for the complex internal representation of numbers, characters, and instructions and so forth - data. For example, 8 bits grouped together as a byte with individual values of 0 0 1 1 0 0 0 1 (hexadecimal-base 31, or decimal-base 49) would represent the character 1. This example uses little endian notation (used by most computer systems), which indicates the order that the sequence of bytes is stored in a computer's memory.
To the storage subsystem, the file is simply a collection of bits and bytes grouped together as blocks of data by the filesystem and application that created the file.
The bit is therefore a very important unit of measurement within the computing fraternity.
Notice the switch on the power supply unit, and other electrical appliances, uses the binary bit language symbols, “0” for off and “1 or I” for on.
See: Binary Number Base System, Byte, and Hexadecimal Number Base System.

Bitmap File

A system NTFS metadata file (filename: $Bitmap) in which NTFS records the allocation state of the volume. The data attribute for the bitmap file contains a bitmap, each of whose bits represents a cluster on the volume, identifying whether the cluster is free or has been allocated to a file.
See: Master File Table (MFT).

Boot

To boot (or booting) is a bootstrapping process that starts a sequence of events in to operation in order for a program such as an operating system to be loaded. As most operating system can only execute code from memory (either ROM or RAM) results in a paradox. The bootstrap loader, a program also referred to as interrupt 19 (INT 19) runs automatically when a computer is turned on but prior to this a very important event must occur to overcome the paradox. The (x86) central processing unit (CPU) attempts to begin the process of processing data. However, as the system memory is empty, the processor will not have anything to execute, or even begin to know where to look for it. Therefore, to ensure that the system will boot regardless of the ROM BIOS programming instructions, both CPU and BIOS manufacturers together developed code so that the processor once turned on always started executing its first instruction at the default location (reset vector); initiated by a jump instruction/command at memory address FFFF:0000h. Without the system’s RAM address space being mapped into one of the ROM chips and its location, exactly 16 bytes from the end of the first megabytes of RAM space, as well as the ROM space itself, on powering off, the CPU would have its location to execute instruction but no instructions would exist. As it stands now, on powering off, the CPU will execute instructions on each system power on. The first set of startup instructions is the POST. At the completion of the system's POST, assuming there are no fatal problems, INT 19 is called. Generally, INT 19 is a routine that tries to read the first physical sector from the first floppy diskette drive. If a boot sector (in this case the boot record) is found on the floppy diskette, the boot sector is read (in other words it is loaded) into memory at location/address 0000:7C00 - INT 19 jumps, initiated by a jump instruction/command. However, if no boot sector is found on the first floppy diskette, INT 19 tries to read the first physical sector of various hard disk drives searching for a valid Master Boot Record (MBR) from the first hard disk drive's absolute sector zero in CHS mode and zero in LBA mode. If, during this INT 19 process, any other essential boot devices BIOSes are found, they are executed, i.e., SCSI ROM that potentially has a hard disk drive with a valid MBR. If on meeting certain minimum criteria (ending in a signature byte or signature word, 55AAh or 0x55AA) indicating the start of a ROM is detected, the code within the MBR is executed. The valid MBR code then continues the boot process by reading the first physical sector of the bootable volume; the start of the Volume Boot Record (VBR). The VBR then loads the first operating system startup file: IO.SYS for non-Windows NT family operating systems and Ntldr.exe (NT Loader) for Windows NT family operating systems, upon which the operating system is then in control and continues the boot process.
The term bootstrap, shortened to boot, comes from the phrase “pulling a boot on by the bootstrap” in the early 1950’s by way of Heinlein’s short story “By his Bootstraps” first published in 1941.
See: Basic Input/Output System (BIOS), Bootstrap, and Bootstrap Loader.

Boot Code (executable instructions within the MBR)

Instructions executed when a system is booted.
See: Boot, Boot Sector, and Master Boot Record (MBR).

Boot Device Drivers

Any important device driver required to boot an operating system successfully, of which there are 80 for Windows NT family operating systems.See: Boot, and Windows NT-Based Startup Phases

Boot.ini (non-Windows NT-based & Windows NT-based operating system system startup file #2)

A boot.ini file is a hidden system file (all .ini files consist of sections headed by text in square [ ] brackets using Advanced RISC Computing (ARC) specifications that are used to define a path to a Windows operating system’s installation), in NTFS it is a metadata file (filename: $Boot) at the root of the system partition, storing the bootstrap code (located at a specific hard disk drive physical and logical address), which specifies the path to the Windows installation (by default, C:\WINDOWS), created by Windows Setup.
The path to each Windows installation is described in a single line in the Boot.ini file for x86-based computers. However, for multiple installations of a Windows NT family operating system’s installation, the Boot.ini file has a one-line definition ARC path for each installation in it.
There are two basic forms in which an ARC path can appear, one starting with MULTI() - one-line definition with ARC path; the other SCSI() - four-line definitions with ARC paths. Both forms are used on x86-based computers.
The following generic examples show two possible Boot.ini file ARC paths that are used to define the path to a Windows NT family operating system’s installation on an x86-processor-based computer.

multi(X)disk(Y)rdisk(Z)partition(W)\<winnt_dir>
scsi(X)disk(Y)rdisk(Z)partition(W)\<winnt_dir>

Both generic ARC-path examples shown above allow any Windows NT family operating system’s installation to find the %SystemRoot% directory containing the essential system boot files necessary to carry out the boot process. Note: multi() and scsi() are both present on x86-based architecturally designed computers. However, only scsi() is present on RISC-based architecturally designed computers when Windows NT family operating systems are installed.

The X, Y, Z, and W parameters have the following meaning when using the multi() and scsi() syntax.

X: An ordinal number of the adapter (scsi(), identified by the Ntbootdd.sys driver residing on the system partition) that should always be the number zero.
Y: Always the number zero if the ARC path starts with multi(), because multi() invokes the INT 13 call and therefore does not require the disk() parameter information. (scsi() it is the SCSI ID for the target hard disk drive).
Z: An ordinal number for the disk on the adapter usually between zero and three. (The SCSI logical unit number (LUN) of the target hard disk drive. This number is almost always 0 (zero)).
W: Is a partition always with the number one, unlike X, Y and Z which are always zero. All partitions receive a number except for type number five (MS-DOS Extended) and type number zero (unused), with primary partitions being numbered first and then logical dos drives. (Pertains to scsi()).
multi: If the system uses IDE, enhanced IDE (EIDE), or Enhanced Small Device Interface (ESDI) hard disk drives, or if the system uses a SCSI (pronounced scuzzy) adapter that does not have a built-in BIOS, scsi is replaced with multi.
scsi: The term scsi(0) means that the primary controller, typically the only controller, is responsible for the device. If there are two SCSI controllers and the hard disk drive is associated with the second controller the controller is named scsi(1).
disk: The term disk(0) refers to the SCSI logical unit number (LUN) to use. This may be a separate hard disk drive. Typically, SCSI setups have only one LUN for each SCSI ID.
rdisk: The term rdisk(0) refers to hard disk drive 1.
partition: The term partition(1) is the partition on the first hard disk drive in the computer. If there are two partitions, partition C is partition(1) and partition D is partition(2).
\<winnnt_dir>: %SystemRoot% of the operating system. By default, the operating system loader screen only shows progress dots.

A multi(X) syntax indicates to any Windows NT family operating system that it should rely on the computer’s BIOS to load the system files. This means that the operating system will be using INT 13 BIOS calls to find and load Ntoskrnl.exe and any other files needed to complete the boot process.
Within Windows, to view edit or save the boot list, right-click on My Computer, then select Properties>Advanced>Startup and Recovery>Settings.

Example 1 is of a default Boot.ini file with Windows XP Professional installed.

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

Example 2 is of the above Boot.ini file with a previous installation of Windows 2000 on a separate partition. It is now classed as a multi-boot or dual-boot system.
[boot loader]
timeout=30
default=multi(0)disk(1)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(1)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows 2000 Professional" /fastdetect

Example 3 is of a default Boot.ini file with Windows XP Professional installed via a SCSI adapter (embedded or host board adapter (HBA)).

[boot loader]
timeout=30
default=scsi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
scsi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect

The "timeout" variable specifies how long Windows waits before choosing the default operating system.
The "default" variable specifies the default operating system.

Although it is theoretically possible for the syntax to start any Windows system, this would require that all hard disk drives be correctly identified through the standard INT 13 interface. Since support for this varies across hard disk drive controllers and that most System BIOSes only identify a single hard disk drive controller through INT 13, in practice it is only prudent to use this syntax to start a Windows operating system from the first two hard disk drives connected to the primary hard disk drive controller, or the first four hard disk drives in the case of a dual-channel EIDE controller. For a pure IDE system, the MULTI() syntax will work up to a maximum of four hard disk drives on the primary hard disk drive controller and secondary channels of a dual-channel controller. For a pure SCSI system, the MULTI() syntax will work for up to a maximum of two hard disk drives on the first SCSI controller (that is, the controller whose BIOS loads first). For a hybrid IDE and SCSI system, the MULTI() syntax will work only for the IDE hard disk drives on the first controller. Each SCSI driver under a Windows operating system’s installation has its own method of ordering controllers, although generally they conform to the order that the BIOS on the controllers load (that is, if the BIOS is loaded).
Ntldr reads the Boot.ini file from the system volume. If the Boot.ini file contains any pre-existing operating system Windows installation (multiple-boot systems), user choices are displayed on the boot startup menu (or boot-selection menu). The user then selects the appropriate boot partition that loads the operating system (starting with the registry, Ntoskrnl.exe, Bootvid.dll (boot video driver), Hal.dll and the boot start device-drivers) into memory to continue the boot process while turning on paging. If there is more than one boot-selection entry in the Boot.ini file it presents the user with the boot-selection menu. If there is only one entry, Ntldr bypasses the menu and continues, displaying the startup progress bar. Selection entries in the Boot.ini file direct Ntldr to the partition on which the Windows system directory of the selected installation resides. If Bootsect.dos contains a valid DOS (DOS stands for Disk Operating System) boot sector, the first entry the Boot.ini file creates is to boot into DOS. In a Boot.ini file the Windows directory is specified in a special syntax that conforms to the ARC naming convention, mentioned in detail above.
During formatting the format command defines the area in which the Boot.ini file resides as a file by creating a file record for it. Creating the boot file allows NTFS to adhere to its rule of making everything on the disk a file. The boot file as well as NTFS metadata files can be individually protected by means of the security descriptors that are applied to all Windows objects. Using this “everything on the disk is a file” model also means that the bootstrap can be modified by normal file I/O, although the boot file is protected from editing.
If the Boot.ini file entry refers to a DOS installation (that is, by referring to C:\ as that system partition), Ntldr reads the contents of the Bootsect.dos file into memory, and switches back to 16-bit real mode, and calls the MBR code in Bootsect.dos. This action causes the Bootsect.dos code to execute as if the MBR had read the code from disk. Code in Bootsect.dos continues a DOS-specific boot, such as is used to boot Windows 9x and Millennium, on a computer on which these operating systems are installed with Windows.
Entries in the Boot.ini file can include optional arguments that Ntldr and other components involved in the boot process interpret.
On starting the computer if the Boot.ini file is miss-configured (contains incorrect entries), missing or damaged, the following messages can appear “Invalid boot.ini”, “Windows could not start because of a computer disk hardware configuration problem”, “Could not read from selected boot disk”, “Windows could not start because the following file was missing or corrupt: Windows\System32\Hal.dll” or “Check boot path and disk hardware” after the BIOS Power-On Self Test (POST) at a black screen.
The reason these messages appear relates to the Boot.ini file being missing, damaged, or it no longer references (as it is miss-configured, containing incorrect entries) the boot volume because the addition of a partition has changed the ARC name of the volume.
Please read the detailed description pertaining to the Recover Console (RC). By booting into the RC and executing the bootcfg /rebuild command, it will invoke the RC to scan each volume looking for the WindowsNT/2000 and XP installation(s). When the RC finds a Windows installation, it will ask the user whether it should add it to the Boot.ini file as a boot option and what name it should display for the installation in the boot menu.
A second example: The entries in the Boot.ini file can include optional arguments that Ntldr and other components involved in the boot process interpret.
Now Ntldr loads the appropriate kernel and HAL images (Ntoskrnl.exe and Hal.dll). If either of these important system files fail to load, Ntldr displays the on screen message “Windows could not start because the following file was missing or corrupt”, followed by the name of the file. Ntldr reads the SYSTEM registry hive, \Windows\System32\Config\System, so that it can determine which device drivers need to be loaded to accomplish the boot, scans the in-memory SYSTEM registry hive and locates all the boot device drivers that are necessary to boot the system, adds the filesystem driver that is responsible for implementing the code for the type of partition (FAT, FAT32, or NTFS) on which the installation directory resides, aforementioned, to the list of boot drivers to load, loads the boot drivers, which should only be drivers like the filesystem driver for the boot volume and so forth. While this is occurring Ntldr updates the progress bar as each driver is loaded (not initialised at this time). The final stage that Ntldr takes part in is to prepare the CPU registers for the execution of Ntoskrnl.exe and calls on Ntsokrnl.exe to perform the remaining system initialisation. As is evident, Ntldr is a very important system file.
The solution to “Windows could not start because the following file was missing or corrupt”, followed by the name of the file, is to read the detailed description pertaining to the RC herein. In addition to rebuilding the boot list, bootcfg will repair most “Invalid boot.ini”, “Windows could not start because of a computer disk hardware configuration problem”, “Could not read from selected boot disk”, “Windows could not start because the following file was missing or corrupt: Windows\System32\Hal.dll”, “…Windows\System32\xxxx.xxx”, “Check boot path and disk hardware”, “…\WINDOWS\SYSTEM32\CONFIG\SYSTEM”, “NTLDR is compressed” or “NTLDR is Missing”. The command process may apply to other types of Hive/system files/.exe/.dll related Stop Errors, Blue Screens, Stop Messages, Exception Errors, or Fatal System Errors.
For “…\WINDOWS\SYSTEM32\CONFIG\SYSTEM”, see the entry Windows Registry also.
Again from the RC, with respect to any system file, and using Hal.dll as the example, expand the file from the Windows CD-ROM, if necessary. The command would be expand d:\i386\hal.dl_ c:\windows\system32\hal.dll. Substitute d for the drive letter of the optical device.
Now use the command RC command “copy”, as follows (where d represents the location of your optical device).

First option:
C:\>COPY(space)C:\Windows\ServicePackFiles\System32\HAL.DLL(space)C:\Windows\System32\hal.dll

Second option:
C:\>COPY(space)d:\i386\hal.dl_(space)C:\Windows\System32\hal.dll

If the file to copy over means that an overwrite message appears, accept by depressing the “y” key. If the file to copy over is missing the file will just be copied.
Once the file has been expanded, if applicable, exit the RC and restart the computer.

Where the above procedure fails to fix the problem, follow the procedure below:

There are eight commands that need to be entered in sequence to repair any of the issues mentioned previously. These commands are as follows:

CD.. (takes the command prompt one level up)
ATTRIB –H C:\boot.ini
ATTRIB –S C:\boot.ini
ATRIB –R C:\boot.ini
del boot.ini
BOOTCFG /Rebuild
CHKDSK /R /F
FIXBOOT

At the C:\> prompt, modify the attributes of the Boot.ini file using the following commands. This ensures that the Boot.ini file is no longer hidden, removes the flag that sets it as an undeletable system file, and removes the flag that sets it as a Read-only file and cannot be amended to.

ATTRIB –H C:\ boot.ini
ATTRIB –R C:\ boot.ini
ATTRIB –S C:\boot.ini

At the C:\> prompt delete the Boot.ini file using the following command:
1. del boot.ini

By booting into the RC and executing the bootcfg /rebuild command (Windows XP Recovery Console command), used to manipulate the Boot.ini file or add if one does not exist, it will invoke the RC to scan each volume looking for the WindowsNT/2000 and XP installation(s) when run from a Windows XP CD-ROM (clicking on Recovery Console), or installed locally from a Windows XP CD-ROM (selecting the command from the Boot menu) only. When the RC finds a Windows installation, it will ask the user whether it should add it to the Boot.ini file as a boot option and what name it should display for the installation in the boot menu. The one caveat being that due to file compatibility problems with an original Windows Setup CD-ROM it will not be possible to proceed further. For example, if the original or Windows Setup CD-ROM XP SP1 is use to carry out the repair, you will get a message that the upgrade is newer than the version to be extracted from the CD. To overcome this problem, the solution is the use a “slipstreamed” setup CD, which adds the newer files to the original Windows Setup CD. The slipstreamed (a constantly up-to-date) Windows Setup CD will simply fix all future installations and CD-based repairs. The command bootcfg/ list and then ENTER with present the contents of the Boot.ini file. It is possible to use the command line utility, Bootcfg.exe.
Boot into the RC and executing the bootcfg /rebuild command as before, it will invoke the RC to scan each volume looking for the WindowsNT/2000 and XP installation(s). When the RC finds a Windows installation, it will ask the user whether it should add it to the Boot.ini file as a boot option and what name it should display for the installation in the Boot menu. Use a “slipstreamed” setup CD.

You will be prompted with a message (the exact verbiage will depend on your setup) that states that the Total Identified Windows Installs: 1; [1] C:\Windows. Assuming that the information is correct, enter “y for Yes”. You may have to enter the Administrator account password; if the Administrator account password does not have one, press ENTER and Bootcfg will begin the process of rebuilding the boot list to include the indicated Windows installation.

You will be asked, “Enter Load Identifier”. This is the name of the operating system that will appear in the Boot menu. For consistency with the standard nomenclature used by Microsoft, enter “Windows XP Professional” or “Windows XP Home”. Enter Operating System Load Options: (that is: /fastdetect, is a must; for Intel’s XD or AMD’s NX CPU buffer overflow protection, and for only these CPUs, also include /noexecute=option. See the screenshot above).

"Windows XP Professional" /fastdetect or “Windows XP Home" /fastdetect (for non-Intel XD & AMD NX CPUs).

"Windows XP Professional" /fastdetect /noexecute=option or “Windows XP Home" /fastdetect /noexecute=option (for Intel XD & AMD NX CPUs).

Although not essential it may be prudent to include the following command:
1. CHKDSK /R /F
Where boot sectors of important filesystem’s critical structures that a computer uses to start up are located and may be suspected of being damaged, run the command fixboot (without any parameters). Executing the fixboot, command simplifies the boot process on multi-booting machines, removing non-essential boot variables, which in turn will help ensure that the repair of the operating system installation will have the best opportunity of carrying out a successful boot into Windows. Hit “y” to “Sure you want to write a new boot sector to the partition C:?”, then ENTER.
Exit and leave the RC.

Additional Information:
It is possible to repair any Windows NT family operating system even without the necessary Emergency Repair Disk (ERD) that can otherwise created using Windows backup application called NTBackup. It is wise to create an ERD however.

Insert the first of the three Windows floppy diskettes to boot the system.
It is possible to boot your system using the Windows Setup CD-ROM, if the CD-ROM supports bootable CD’s (the EI Torito CD-ROM specifications).
Once setup commences, select the “R” (Repair) option to repair the Windows NT family operating system’s installation.
You will be asked for your ERD, which you may not have, select “no” and setup will search the Boot.ini file (described in detail in the main entry above) for the installation path.
Setup will attempt to locate and repair the directory from that path (%SystemRoot%\Repair) and use the registry files in the directory for repairs.
There are no guarantees this procedure will work in all cases.

Note: Maximum Number of Lines in [Operating Systems] of Boot.ini is 10.
See: Bootsect.dos (multiple-boot system; Windows NT-based operating system system startup file #3 (if necessary only)), Bootstrap, Master File Table (MFT), Ntldr (NT Loader; Windows NT-based operating system system startup file #1), Windows Registry, and Recovery Console (RC).

Boot Partition

The partition that contains core (system) operating system files. The boot partition is identified by the system at startup. The code (Master Boot Record (MBR) program code starts at offset 0000) in the MBR scans the primary partition table until it locates the partition containing a flag (or marker) that signals the partition is bootable. When the MBR finds at least one such flag, it reads the first sector from the flagged partition into memory and transfers control to code within the partition.
See: Active Partition, Active Volume, Boot.ini (non-Windows NT-based & Windows NT-based operating system system startup file #2), Bootsect.dos (multiple-boot system; Windows NT-based operating system system startup file #3), Device Drivers (location - systemroot\System32\Drivers - Windows NT-based operating system system startup file #9), Hal.dll (location - systemroot\System32 - Windows NT-based operating system system startup file #7), Master Boot Record (MBR), Ntbootdd.sys (Windows NT-based operating system system startup file #5), Ntdetect.com (Windows NT-based operating system system startup file #4), Ntldr (NT Loader; Windows NT-based operating system system startup file #1), Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6), Partition, Partition Table, System Registry file (location - systemroot\System32\Config\System – operating system system startup file #8), and System Volume.

Boot Record

The boot record is the first sector on a hard disk drive or partition that contains disk parameter information for the BIOS and operating system as well as bootstrap loader code instructing the system how to load the operating system files into memory, thus beginning the initial boot sequence to boot the computer.
See: Boot Record, Bootstrap, Bootstrap Loader, Basic Input/Output Subsystem (BIOS), and Windows NT-Based Startup Phases.

Boot Sector

The majority of information within the boot sector, at sector one (absolute sector 0 or CHS: 0, 0, 1) of each volume, describes the physical characteristic of a hard disk drive, e.g., the number of sectors per track and sectors per cluster. In addition to the location of the file allocation table (for FAT volumes) or Master File Table (MFT) (for NTFS volumes) the layout and exact information included in the boot sector depends on the hard disk drive format used. The format program also allocates the first 16 sectors for the boot and bootstrap code. The Master Boot Record (MBR) contains the partition table for that hard disk drive and a small amount of code used to read the partition table and find the system partition for the hard disk drive. Once the MBR executable code (boot code) locates the partition, the MBR loads a copy of that partition’s boot sector into memory at location/address 0000:7C00; eventually loads another copy of itself directly from the hard drive into memory location 0D00:0000 (or 0000:D000) and continues loading all remaining 15 sectors of the boot record immediately after until at memory location 0D20:000 (or 0000:D200) it is executed. If the hard disk drive is not bootable, the boot code is not loaded.
The boot sector is created when a volume is formatted and always contains a 2-byte structure called the signature word (or byte) or end of sector marker, which is always 0x55AA or 55AAh (referred to as the Magic Number, and is at offset 01FE). (0x denotes that the value proceeding it is in hexadecimal notation. h denotes the value preceding it is in hexadecimal notation).
Starting and Ending Cylinder, Head, and Sector fields (collectively known as the CHS fields) are additional elements of the partition table. These fields are essential for starting the computer. The master boot code uses these fields to find and load the boot sector of the active partition.
Initially, the startup process is independent of disk format and operating system. The unique characteristics of operating systems and filesystems become important when the boot sector’s executable code (boot code) starts. The MBR transfers CPU execution to the boot sector, so the first bytes of the boot sector must be valid executable x86-based CPU instructions. This includes a jump instruction that skips the next several non-executable bytes. Following the jump instruction is the 8-bit OEM ID, a string of characters that identifies the name and version number of the operating system that formatted the volume. Note: Windows NT family operating systems do not use the OEM ID field in the boot sector except for verifying NTFS volumes (if the partition is in NTFS form, Windows writes NTFS-capable code). Following the OEM ID is the BIOS Parameter Block (BPB), which provides information via the processor execution in 16-bit real mode that enables the executable instructions (boot code) that reads the root directory to locate and load Ntldr. The role therefore of the boot code, containing just enough information (read-only filesystem code), is to give Windows information about the structure and format of a volume and to read in the Ntldr file from the root directory of the volume. The BPB always starts at the same offset, so standard parameters are in the known location. Disk size and geometry variables are encapsulated in the BPB. As the first part of the boot sector is an x86 expandable jump instruction; appending new information can extend the BPB in the future. The jump instruction needs only a minor adjustment to accommodate this change.
Although the name boot sector suggests this sector has something to do with booting, which indeed can be the case as the boot sector may contain executable code for booting the operating system, it plays a more important role as the 'mother of the filesystem structures'. A damaged boot sector can lead to unexplainable access problems and partitions becoming invisible. Windows may ask “Do you want to format this partition” if the boot sector is damaged, but was ok the previous Windows Logon session.
In contrast to the partition table structures, a boot sector is operating system dependant: a boot sector for an FAT32 partition is different from a boot sector for an NTFS partition.
Every partition's first sector contains important metadata describing the filesystem structures within the partition. Boot sector boot code is operating system specific.
Boot sector corruption can appear as if it is MBR corruption where the system hangs after the BIOS Power-On Self Test (POST) at a black screen. The essence of all these messages is that the operating system will not load.

A disk read error occurred.
"Error loading operating system". The source of the error message is the MBR. An error was returned from the BIOS when the boot loader attempted to read the active partition's boot sector into memory. (Solution: In many cases this will be due to a "soft" ECC error and can be repaired by rewriting the boot sector.)
"NTLDR missing". The boot loader was unable to locate NTLDR. Very often this indicates a corrupted file system. (Solution: Using the RC, copy a new NTLDR file from directory \i386 on the Windows XP/2000/Server 2003 Setup CD-ROM using CD \, then ATTRIB -C NTLDR. Otherwise use the bootcfg /rebuild (Windows XP Recovery Console command)).
"NTLDR is compressed". The NTLDR file is compressed. As NTLDR is necessary prior to the operating system loading, normal booting is prevented as there is no way to decompress the compressed NTLDR file. (Solution: Using the RC, copy a new NTLDR file from directory \i386 on the Windows XP/2000/Server 2003 Setup CD-ROM using CD \, then ATTRIB -C NTLDR. Otherwise use the bootcfg /rebuild (Windows XP Recovery Console command)).

table

Table: 80 bytes (12Ch through to 17Bh) contain error messages and message offsets in memory within the boot record of the MBR.

The reason for boot sector corruption can be related to hard disk drive errors, disk errors as a result of a driver bug while Windows is running or intentional scrambling due to a virus infection. Please read the detailed description pertaining to the RC. By booting into the RC and executing the fixboot command, this will rewrite the boot sector of the problem volume. If the system and boot volumes are on different volumes then the command must be carried out for both.
At the end of the boot sector is a 2-byte structure called the signature word (or byte) or end of sector marker, which is always 0x55AA or 55AAh (referred to as the Magic Number, and is at offset 01FE) – see diagram below. Note: A word equals 2 bytes read in reverse order, and a dword equals two words read in reverse order.

A value proceeding 0x denotes it is in hexadecimal notation. A value preceding h denotes it is in hexadecimal notation.

Signature Bytes
Offset	Length	Description
IFEh.510	2 bytes	Boot Sector signature (55A.Ah) or 0x55A.AH or 0x55AA

Magic number is a special constant used for some specific purpose. It is called magic because it is hardcoded in and its value or presence is inexplicable without some additional knowledge.
See: Basic Input/Output Subsystem (BIOS), BIOS Parameter Block (BPB), Boot Code, Boot Sector Virus, Hexadecimal Number Base System (HEX), Master Boot Record (MBR), Metadata, Partition Table, Recovery Console (RC), and Root Directory.

Boot Sector Virus

The master boot code (the boot sector’s executable code) runs automatically when an x86-based computer starts up, creating vulnerability that can be exploited by virus writers as the location of the MBR is constant (unused in cylinder 0, head 0, sectors 2...n).
Boot sector viruses can activate before an operating system is loaded and run when the master boot code in the Master Boot Record (MBR) identifies the active primary partition, activating the executable boot code for the volume. For this reason, it is unwise to use the undocumented FDISK /MBR command or even the RC fixmbr command. The reason being is that although these commands will only rewrite a new boot code in the first 446 bytes (boot loader code) of the MBR, leaving the 64-byte table (starting at offset 0x1be (1BEh = 446) alone, if the partition table is damaged or changed restoring the boot code to an original boot code using the commands mentioned, may result in vital information stored elsewhere by the virus becoming compromised, undermining access to this vital information too. Many viruses update the boot sector with their own code and move the original boot sector to another location on the hard disk drive. After the virus is activated, it stays in memory and passes the execution to the original boot sector so that the startup appears normal. Some viruses do not relocate the original boot sector, making the volume available but inaccessible. If the affected volume is the primary active partition, the system cannot start. Other viruses relocate the boot sector to the last sector of the hard disk drive or to an unused sector. If the virus does not protect the altered boot sector, normal use of the computer might overwrite it, rendering the volume available but inaccessible or preventing the system from restarting. Newer viruses have the power to make restoring an uninfected MBR more intractable. In this case the first port of call is to run a pre-Windows commercial anti-virus program. There is no guarantee that full or partial boot file disinfection will be possible.
If the signature byte was damaged, you would know – the system would not boot and would act as though there were no partitions at all. Other possible messages such as “Invalid partition table”, “Error loading operating system” and “Missing operating system” may be displayed. You should set your anti-virus program to run in online mode. Also scan for viruses with an up-to-date anti-virus program and definition database regularly. Use it to guide repairs.
It is always important, especially nowadays, to take adequate precautions to protect a system and the data on it from viruses and other variants that can cause problems. Many computer viruses exploit a hard disk drive and/or filesystem’s critical structures that a computer uses to start up by replacing, redirecting or corrupting the code and the data that starts the operating system.
A boot sector editor can be used to edit the boot sector and code, for example, any free or commercial hex editor. Moreover, with the necessary understanding and expertise to locate the MBR and substructures, convert hexadecimal data to decimal values and interpret the different fields, makes the disk editor is an extremely powerful tool for manipulating the hard disk drive operating system contents independently. Conversely, it is potentially destructive and should be used cautiously.
Even less comforting is the fact that a virus could be writing directly to the BIOS EEPROM memory chip via a system infection. However, modern-day motherboards have a security algorithm that limits the possibility of any unauthorised updates occurring.
See: Boot Sector, and Master Boot Record (MBR).

Bootsect.dos (multiple-boot system; Windows NT-based operating system system startup file #3 (if necessary only))

A hidden system file at the root of the system partition that the NT Loader (Ntldr.exe) loads for any of the Windows NT family operating system’s multiple-boot configuration: this may include DOS, Windows 9x and/or Millennium. Bootsect.dos contains the boot sector for these operating systems. For example, on installing a second Windows operating system, Windows Setup checks to see whether the boot sector it will overwrite with a Windows boot sector is a valid DOS boot sector. If it is, Windows Setup copies the boot sector’s contents to the file Bootsect.dos in the root directory of the partition.
Ntldr reads the Boot.ini file from the system volume. If the Boot.ini file contains any pre-existing operating system Windows installation (multiple-boot systems), user choices are displayed on the boot startup menu (or boot-selection menu). The user selects the appropriate boot partition and then loads the Windows NT family operating system (starting with the registry, Ntoskrnl.exe, Bootvid.dll (video device driver), Hal.dll and the boot start device-drivers) into memory to continue the boot process and turns on paging. If there is more than one boot-selection entry in the Boot.ini, it presents the user with the boot-selection menu, but if there is only one entry, Ntldr bypasses the menu and continues, displaying the startup progress bar. Selection entries in the Boot.ini direct Ntldr to the partition on which the Windows system directory (pre-Windows NT C:\WINDOWS, Windows NT/2000 C:\WINNT and Windows XP and Windows Server 2003 C:\WINDOWS) of the selected installation resides. If Bootsect.dos contains a valid DOS boot sector, the first entry Boot.ini creates is to boot into DOS. If the Boot.ini entry refers to a DOS installation, that is, by referring to C:\ as that system partition, Ntldr reads the contents of the Bootsect.dos file into memory, switches back to 16-bit real mode and calls the MBR code in Bootsect.dos. This action causes the Bootsect.dos code to execute as if the Master Boot Record (MBR) had read the code from disk. Code in Bootsect.dos continues a DOS-specific boot that is used, for example, to boot Windows 9x and Millennium on a computer with these operating systems installed with Windows.
See: Master Boot Record (MBR), and Windows NT-Based Startup Phases.

Bootstrap

A technique, process or device designed to bring (start) itself into a desired state by a sequence of events by means of its own actions to be loaded; such as an operating system. Bootstrap is the term used to describe the process by which a device such as a general-purpose computer goes from its initial power-on condition to a running condition without human intervention; it actually begins the initialisation of the operating system, e.g., Ntldr (NT Loader; Windows NT-based operating system system startup file #1)
See: Basic Input/Output System (BIOS), Boot, Bootstrap Loader, and Ntldr (NT Loader; Windows NT-based operating system system startup file #1).

Bootstrap Loader

A program (also referred to as Interrupt 19 or INT 19) runs automatically when a computer is turned on. The first set of startup instructions is the Power-On Self Test (POST). At the completion of the system's POST, assuming there are no fatal problems, INT 19 is called. The BIOS code begins searching hardware by searching for a graphic card's built in option ROM, normally found at location C000h in memory, and if found runs it. The System BIOS executes the video card’s BIOS, which in turn initialises the video card. Once video has been enabled, the BIOS begins searching for other devices that may have their own option ROM and whether that ROM has its own BIOS code. Generally, INT 19 tries to read the first physical sector from the first floppy diskette drive. If a boot sector, in this case the boot record, is found on the floppy diskette, the boot sector is read (in other words loaded) into memory at location/address 0000:7C00 - INT 19 jumps, initiated by a jump instruction. However, if no boot sector is found on the first floppy diskette, INT 19 tries to read the Master Boot Record (MBR) from the first hard disk drive (an IDE/ATA hard disk drive’s BIOS will be found at C8000h but the SCSI ROM may be implicated in the booting of the first hard disk drive). If on meeting certain minimum criteria (ending in a signature byte 55AAh or 0x55AA) is detected, the code within is executed. The MBR code then continues the boot process by reading the first physical sector of the bootable volume; the start of the Volume Boot Record (VBR). The VBR then loads the first operating system startup file: IO.SYS for non-Windows NT operating systems and Ntldr.exe (NT Loader) for the Windows NT family operating systems, upon which the operating system is then in control and continues the boot process.
If during this INT 19 process any other specific-device BIOSes are found they are executed as well, and carries out an inventory of the hardware installed; then communicates or interrogates the hardware to ensure that it is functioning correctly. Modern BIOSes have the additional functionality to automatically collect settings: memory timings (based on the memory type found), dynamically set a hard disk drive’s parameters and access modes, display an onscreen message for each device detected and configured in this way, and so forth. The final stage of the BIOS POST is to display onscreen a summary of the system’s configuration.
The computer's hardware alone cannot perform the complex actions of which an operating system is capable, such as loading a program from disk; so a seemingly irresolvable paradox is created. The solution to the paradox involves using a special small program, called a bootstrap loader or boot loader. This program doesn't have the full functionality of an operating system, but is tailor-made to load enough other software for the operating system to start.
After first performing a few basic hardware tests, the bootstrap loader loads and passes control to a larger loader program, which typically then loads the operating system, e.g. Ntldr. The bootstrap loader generally resides in the computer’s read-only memory (ROM).
See: Basic Input/Output System (BIOS), Boot, Bootstrap, and Ntldr (NT Loader; Windows NT-based operating system system startup file #1).

Boot Volume

The volume that contains the Windows operating system and its support files. The boot volume can be, but does not have to be, the same as the system volume. For Windows operating systems the boot volume is where Windows stores the system files.
See: Active Partition, Active Volume, Basic Disk, Basic Volume, Boot Volume, MBR Disk, and Partition.

Byte (symbol B) or “octet”

A byte (a group of 8 bits) is a fixed number of bits that can be treated as a unit by the computer hardware. A collection of bits usually comprises of 8 bits although 6, 7, or 9 bits are occasionally encountered. For example, when referring to system RAM (also known as physical memory) an additional partition (error-checking) bit is also stored, making the total 9 bits.
The x86 computer likes to "think" in 'groups' of eight (8) (hexadecimal number base system) digits instead of ten (decimal number base system).
To the storage subsystem, the file is simply a collection of bits and bytes grouped together as blocks of data by the filesystem and application that created the file.
The byte is therefore a very important unit of measurement within the computing fraternity.
See: Bit Binary Digit, and Hexadecimal Number Base System.