Understanding MultiBooting
and Booting Windows from an Extended Partition

by Dan Goodell
Introduction Appendixes: Links Notes Backup Strategies Virtual PC

This page has been many years in the making. I first published my backup strategy during the Win98-XP era as part of my multi-boot treatise. Since then, when I've been asked about my personal backup plan I've gradually refined or revised many of those details when crafting email responses. That has eventually lead to this new page, a wholesale rewrite of that earlier webpage.

One point I came to realize from all those email "drafts" is that people seemed to grasp the issues more quickly if I first just layout what I do before going into details why. It seems like it ought to be more logical the other way around--first elaborating the issues that need to be addressed, then describing my solution to those issues--but that hasn't been the case.

So, then, here we go, starting with what I do . . .
My Backup Strategy Further Discussion
My Backup Infrastructure
My hard disk is partitioned into at least two partitions: one for the Windows operating system and application programs, and a separate partition for data. My Windows user folders (email, Documents, Pictures, et al) are on the data partition. The OS partition contains only Windows and installed programs.

(Actually, my systems all multi-boot, so I have many more than just two partitions. But that's not relevant to this discussion, the basic premise of which is that user data should not be comingled with the operating system.)

The OS partition is backed up with a partition imaging program. I prefer Terabyte Image, though there are a number of similar programs like it. My user data, on the other hand, is backed up via simple zip files.

Backup destinations include folders (in my case, "Backups" and "Recovery Images") on my internal data partition, plus folders ("Backups", "Recovery Images", "Archives") on an external hard drive, and folders ("Recovery Images" and "Archives") on a second external drive that is normally stored in my bank safety deposit box.

My Backup Timetable
Data files are backed up every day. I back them up by gathering them into ordinary zip files, name them by date, and store the zip files in the "Backups" folder on the data partition. This process is automated via command scripts and Windows' Task Scheduler, and runs daily without user intervention.

The automated script makes a full backup of all user data at the beginning of each month, then throughout the month it makes daily backups only of files that have been added or changed. Note this strategy provides some versioning, as files that change can be captured in different daily backups (though not more than once per day).

Every two weeks the files in the internal "Backups" folder are duplicated to "Backups" on the external hard drive.

Every three months I purge backups that are more than three months old from both the internal and external backup locations, and burn them to DVDs. I don't often need to restore a data file that is more than 3 months old, but when I do it's there on a shelf of DVDs.

I make an interim image of the OS partition about every 3 to 6 months, or whenever I'm about to make significant changes--such as if doing a bunch of program updates or installing a major new program. This gives me a known good recovery point in case something goes wrong during the update process. These interim images will be purged once a year.

The most recent images are stored in the "Recovery Images" folder on the internal data partition, and older images are gradually duplicated, and then moved, to the external drive as newer images are made. This gives me ready access to the most recent image for quick restores but retains the opportunity to use an earlier image if the most recent image isn't usable for some reason.

At the end of the year I wipe the OS partition and do a "rolling clean install". The image of this "pristine", fresh Windows installation is my long-term gold standard, so it's replicated in the "Recovery Images" folder in all three places--the internal data partition plus both external drives.

Interim images older than the last rolling clean install serve no further purpose, so they are purged after a new pristine image is made and verified as good.

Once every year or two, I tidy up my user data folders by archiving old files. Inactive pictures, old work files, etc., are moved from the data partition to the "Archives" folder on the external drive. Since they are being removed from the internal drive, the external archive folder is synced with the second external hard drive (normally stored in the bank vault) so that I always have two copies of anything archived, with one copy in a secure, off-site location.

To summarize:
The "rolling clean install" strategy allows me to start the year with a pristine Windows installation that's lean and clean, and guaranteed to be free of accumulated detritus or viruses.

Periodic interim backups of the OS are created throughout the year and stored in at least two "Recovery Images" locations--the most recent couple of images readily available on the data partition and older generations on the external drive. Interim images are purged when a new pristine image is made.

The most recent data backups are initially only on the internal drive, then on both internal and external drives for a period of time, and eventually moved to DVDs.

Archived data files are always in at least two places--one on each external drive, and possibly on old DVDs as well, where they may have been interspersed with routine data backups before the files were archived.

The "Rolling Clean install"
Let's face facts: Windows will eventually get messed up. No matter how careful you are, it always will. Leftover temp files; detritus from program crashes; incompletely uninstalled programs; malware infections; corrupted files; files abandoned or superceded by Windows or program updates; updates to updates; and so on, and so on. The garbage increases the longer any Windows installation is in use.

It happens with all Windows versions, but to use Windows 7 as an example, a clean and freshly updated Windows installation is around 20-25 GB in size, yet it's not uncommon to see 4- or 5-year old systems that have ballooned to 40-60 GB, or more. It's no wonder computers seem to slow down after several years of use. Employing cleanup and optimization tools may help a little, but they'll never get rid of all the bloat or fix every problem. No matter how diligently you back it up, Windows won't be running its best if you're backing up the garbage, too.

When Windows bogs down too much or no longer works correctly, the only real solution is to wipe the OS partition and start over with a "clean install". That's guaranteed to give you the cleanest, speediest Windows installation again. In fact, it surprises most people that their computer will again run as fast as it did on Day 1 ... but why shouldn't it? It's not like the hardware itself is any slower; electrons still move at the same speed they always have. It's Windows that bloats up and bogs down, and a clean install is a method of starting over with a fresh installation of Windows.

Once you put it back into regular service, though, it will start building up junk again. Periodically performing clean installs will keep your Windows running smoothly for the life of the hardware. Unfortunately, they're also enough of a hassle that most people will avoid doing them.

A clean install nominally involves saving all your data, reformatting the OS partition, reinstalling Windows anew, reinstalling hundreds of Windows updates, reinstalling all your programs, configuring everything to your liking again, and restoring all your data. That can take days to do. If you had the wisdom to segregate your data in the first place, you can omit the first and last steps and save a little time, but the rest of the process can still be grueling and time-consuming. And for some people, who might no longer have the media to reinstall all of their programs, a clean install would be problematic.

What's needed is a clean install procedure that is less onerous. Herewith, then, is what I've dubbed the "rolling clean install".

Start with a traditional clean install, or perhaps a factory restore on an OEM machine. Install any necessary Windows updates, then create an image of this installation and set it aside. This is your first "pristine" image. It's a known perfect starting point, guaranteed to be free of malware and detritus because it hasn't been put into service yet.

Now put the computer into daily use and install whatever apps you normally use. However, for everything you install, KEEP THE INSTALLER! Whether this be an installation CD or a setup file downloaded from the internet, the point is you want to be able to reinstall that same program again later. Whenever a program downloaded from the internet gives you the choice of "Save or Run", always choose "Save" and make a copy of the downloaded installer before running it. (Tip: some installers delete themselves after they run to completion, so make a copy before running them.)

After the system has been in service for a year, take stock of your system and review the programs you installed during the year. Decide which programs you want to keep (the "keepers") and which programs you no longer want. Some may have seemed exciting at first but as time went by your enthusiasm cooled. There may also be some programs you're not sure about--maybe they're not "keepers" but you're not ready to ditch them just yet. Let's call them "maybes".

Locate the installers you had saved for the "keepers" and the "maybes" during the year.

Now wipe the OS partition and restore from the year-old pristine image. Apply the intervening year's worth of Windows updates, and reinstall the programs you decided were "keepers". Configure everything to your liking, then make a new pristine image and set that aside for another year.

What you've just done is the equivalent of a clean install. By starting from an image of an installation that had never been in service, you now have an up-to-date image that still has never been in service.

Now reinstall your "maybe" programs, and put the system into service for another year. Note the "maybes" haven't been embedded into your pristine image, leaving you the option of dumping them next year.

At the end of the next year, again review any new programs installed during the year, as well as the previous year's "maybes". Some of last year's "maybes" might now be "keepers", or maybe you're ready to get rid of them this time.

Locate the installers you kept for the new "keepers" and "maybes".

Wipe the OS partition and restore from the year-old pristine image. That image already had the prior year's "keepers" and Windows updates on it, so now you only have to update it with any new "keepers" and just a single year's worth of Windows updates. Make another new pristine image.

Again, you've done the equivalent of a clean install, but it hasn't taken as much time as a complete clean install from scratch.

Reinstall your "maybes", and put the system into service again.

Repeat this routine every year. Each year you're starting over with the equivalent of a clean install--a system that has never been sullied by daily use so has not started collecting garbage. Yet you're not having to do a complete, time-consuming clean install from scratch every year.

I find yearly intervals to be about right for the rolling clean installs. That's short enough that the rebuild process doesn't become too onerous, and long enough to give me time to live with programs long enough to evaluate whether I really want to commit them to my long term pristine image.

Further Discussion
Use a Separate Data Partition
User data (Documents, Pictures, Music, Videos, etc.) should never be comingled with the OS on the same partition. It should always be stored on a separate partition. It doesn't matter whether that separate partition is on a second internal hard disk or on the same disk as the OS partition.

Disregard Microsoft's offical policy or the advice of "computer experts" who would claim otherwise. Anyone who fails to understand this basic premise is either foolish, reckless, or too much a noob to have thought through the pros and cons. (If it's your data they're charged with protecting, hopefully they'll have an epiphany before they lose too much of it.) The advantages of segregating data far outweigh any disadvantages.

One advantage is that with data segregated from the operating system, each part can be backed up on different time intervals.

The OS doesn't need to be backed up that frequently. The OS consists of gigabytes of files but they don't change that rapidly, so frequent backups can result in inefficient use of resources--a waste of time and storage space. Even if you were to have to resort to recovering from an OS image that is several months old, it is seldom so outdated that you aren't back up and running in a short amount of time.

Your data, on the other hand, consists of files which may change on a daily basis. Those should be backed up more frequently. In contrast to the OS, if you had to restore an Excel file or an extensively edited photo from a backup that was only a week old, that might still represent hours or even days of lost work. It's important to backup your data much more frequently than the OS.

Another advantage from segregating user data is that the OS can be restored without having to worry about overwriting recent data files. If the OS and data are comingled, you would first have to carefully backup existing data, then restore the OS, and finally put the data files back where they started. It's much quicker and easier when you can skip two of those steps . . . and that in turn means you're more likely to turn to your backup image when Windows throws a tantrum, rather than wasting time trying to figure out what went wrong.

And let's not even talk about how one would accomplish that first step (backing up existing data) if the OS was so badly damaged that Windows won't boot at all. Yeah, it can be done, but that just raises the difficulty factor a few notches.

Segregating data also makes it easier to identify what to backup. Anything and everything on the data partition belongs to the user and is not part of the OS, so it's easier to keep track of what needs to be backed up and how often.

By segregating your data, images of the OS partition are much smaller and consequently take less time to create or restore. That means you're more likely to do them. And smaller images means it's easier to maintain multiple generations, so you have the protection of multiple recovery epochs.

And not to belabor the point, but just imagine how idiotic it would be to have to mount and open an image of comingled OS and data that might be hundreds of GBs large, just to recover last week's Excel file that you accidentally overwrote.

I can't stress this enough: Keep your user data out of your OS images!

Use the Right Tool for the Job
With data segregated from the OS, each part can be backed up using different methods.

Imaging utilities are ideal for backing up the OS, while there are a whole assortment of file backup programs better suited for backing up your data. These file backup utilities may also allow greater control of exactly what you want backed up (you can choose selected folders instead of the entire partition), and typically have easy methods of accessing or restoring individual files from the backup. Imagers, on the other hand, are "all or nothing"--you have to backup an entire partition, not just part of it.

Some users may not grasp how fundamentally different the operating system is from a user's data files. The operating system can't be copied or restored just by dealing with files. It also involves a boot sector, the registry, and an assortment of files that require some fancy tricks to backup if they are "in use" by Windows--such as might be the case if you're backing up from within Windows itself.

Fortunately, partition imaging utilities are designed for this unique and specific purpose. Essentially, they take a snapshot of the entire partition and compress it into a giant file (or set of files) that can subsequently be used to recreate the source partition when necessary, boot sectors and all.

For what it's worth, some imaging tools include "incremental" backup options--backing up only the changes since the last complete image. This seems to work well enough for those who appreciate that feature, though it stretches the definition of what an "image" is. If this strategy is used, recovery can require multiple restores--first the full image and then one or more incremental restores.

Furthermore, in my opinion the "one-size-fits-all" rationale of some imaging utilities (that is, using the same tool to backup either OS or data) doesn't serve either function as well as tools designed specifically for each job.

While imaging programs are perfect for backing up your OS, they are the wrong tool for backing up your data. Data files are merely files, and I can see no rationale for committing your data to an imaging program's proprietary format when it doesn't need to be. Ideally, you should be able to retrieve individual files quickly and whenever you want, without having to install or launch some proprietary program just to get a few files back.

Using an imager on a partition with OS and data comingled means you'll either waste time and disk space with frequent backups to keep up with your ever-changing data, or not backup often enough to keep up with your data. I've heard people brag about how they image their systems daily, but since 99% of what you are imaging won't have changed from yesterday, I consider that wasteful in both time and resources.

In summary, keep your data segregated so you can back it up without proprietary formats, preferably with either straight copies or ordinary zip files that Windows can natively read.

Typical Arguments Against Separate Partitions
"But Microsoft recommends one giant partition."
Microsoft would also rather see you buy a new computer, too--with a new copy of Windows, every couple years. Remember, it's not in their self interest to help you keep your computer running at peak efficiency for longer than that.

It's also easier for customer service reps if everything--OS, programs, and data--is all in one "bucket", so to speak, because then they don't have to deal with the inevitable customers who will ineptly split their partitions into less than optimal sizes.

People use their computers for varied purposes and have computers with a wide assortment of hard drive sizes, so in a practical sense it would be impossible for Microsoft to recommend optimum partition sizes, anyway. The optimum split may be different for different users or different computers. Regardless, though, that never translates to "everything-in-one-partition" being a better idea.

And lastly, Microsoft would like you to believe that Windows never fails. And if everything always worked as Microsoft intended, then you'd never have to worry about losing your data due to a Windows failure, would you? Real world users, though, know better.

"Splitting your hard disk into separate partitions can result in you running out of space on one partition while there is still plenty of space on the other partition."
Okay, so you picked the wrong partition sizes. That doesn't negate the substantial advantages of segregating your data. Get a bigger hard disk or readjust your partition splits, and chose wiser splits next time.

"If you're going to segregate data, use a second hard disk. Putting data on a separate partition on the same hard disk won't help if the hard drive dies."
Well, yeah . . . but how does that translate into one giant partition being a good idea?

It's amazing how many times I've heard this argument. I think some people confuse the argument about where you put your data with where you put your backups. It's true that backups are safer if not on the same disk drive as their source, but that rationale doesn't extend to whether or not to comingle the data and the OS.

Some seem to intuitively feel that data is safer on a separate hard disk vs. a separate partition on the same disk, but there's no logical basis for that. The risk of your second hard disk dying is no greater than the risk of your first disk dying. It doesn't matter whether your data is on a separate hard disk or merely a separate partition on the same hard disk. The risk of data loss from a disk failure is the same either way.

Besides, the threat of disk failure is a comparatively low risk, anyway. Home users have a greater risk of data loss from malware, from software updates gone awry, from new software that doesn't install correctly, from fire or theft, and from user error--such as accidentally deleting or overwriting the wrong file. Using separate disks won't help against any of those threats.

While it's not a high risk factor, it is true that, as a backup strategy, putting images and zip files on a different disk drive will protect against the risk of mechanical failure of the source disk.

That may be hard to do, however, if you're working with a laptop. External USB drives can be an alternative if you only have one internal disk drive, but for me external storage would complicate my automated daily backup program. Due to it's convenience and time savings, as well as a realization of the greater threats I'm worried about, it's more important to me to have frequent, consistently reliable backups with a minimum of effort. That means it's worth using an internal drive to store fully automated backups, even if they are on the same hard disk as their sources.

Ultimately, it's a matter of whether your backup strategy is costing you more time than it saves. So I'm okay with storing frequent, fully automated backups on the same hard disk, but I'm also more diligent about periodically offloading them to the external drive.

While this strategy may not be foolproof, the most I'd ever lose is a couple weeks of work--and then only in the worst case scenario of a sudden hard disk failure that occurs without warning and when I hadn't backed up in awhile. That's never happened to me, however. Every hard disk failure I've experienced has given enough forewarning for me to start moving data off the internal drive before it failed completely.

In contrast with disk failures, I have far more often had to recover files because of software problems. Accordingly, it's extremely convenient to have the latest data backups right there on the internal hard drive for quick and easy access. If I accidentally overwrite the wrong Excel file, for example, I can quickly restore it from yesterday's backup without having to fumble around for external drives or a backup CD. Or if a major upgrade doesn't go right, I can quickly restore Windows from the latest backup image without having to worry about whether the rescue media will recognize a USB drive or network locations.

Why segregate just data? Why not segregate programs and applications, too?
Some advocates will take things one step further and not only separate user data onto its own partition, but also separate apps and programs onto its own partition, as well. I used to do that, too, a couple decades ago. It didn't take me long, though, to realize it offered no advantages whatsoever.

Many programs are deeply intertwined with Windows. They add entries to the Windows registry, add files to the user's %appdata% folder on the OS partition, add their own DLL files to the Windows system folders, or replace existing DLL files with different versions. If an image of an apps partition is restored that is non-contemporaneous with the OS partition, programs may not function correctly if files or registry entries are mismatched. There's no assurance that an OS partition backed up at one time will work properly with an apps partition backed up at a different time.

You can only be sure it will work if you backup both the OS and apps partitions at the same time, and always restore them together at the same time. But if you always have to backup and restore them together, then there is no point to segregating them in the first place.

I recommend keeping apps and programs on the same partition as Windows.

How often should the OS be imaged?
In general, you want to weigh the cost in time to reestablish an up-to-date system versus the time spent creating and managing backups. If spending a few hours less making backups only results in 10 more minutes at restore time, is it worth spending those extra hours making more backups?

Restoring my system involves restoring from a backup image and then applying any tweaks or updates that may have been made since the backup image was created. If few changes have been made a 5- or 6-month old image can still be viable, but if several programs have been added since the last image it may be better to have a fresher image to restore from.

Since imaging is largely a manual process, the less often it has to be done, the better. For me, 3-6 month intervals work fairly well, though it's dependent more on how much the system has changed rather than on the calendar.

Other people may prefer different intervals, depending on how radically their systems change, how much disk space they have to commit to images, or the capabilities and options for automation of their preferred imaging utility. Any interval should be acceptable if it isn't so long that the last image becomes too outdated to be useful, nor so frequent that backup maintenance becomes a time sink.

What about RAID mirroring?
"I have a RAID system, so I don't need to worry about backups."

I've actually heard this argument--and more than a few times! RAID does not obviate the need for backups of both your OS and your data!

Personally, I neither use nor recommend RAID in home systems. RAID is an enterprise solution that rarely can be justified in a home/SOHO system. Too many people seem to assume that just because big corporations use it, RAID must be a good idea, if you can afford it. On the contrary, for home/SOHO users it's a waste of money.

The purpose of RAID level 1 ("mirroring") is data redundancy. It requires two disks of equal size, duplicating data redundantly onto the second disk in real time. Since one disk is a mirror of the other, usable disk space is only half of what the two disks would otherwise provide.

Pros: RAID-1 protects data in the event of a sudden failure of one hard disk.

Cons: two disks doubles the disk noise, doubles the heat, increases the fan noise, doubles the cost (since usable disk space is only half the entire disk space you paid for), and most important of all, RAID-1 fails to protect the user at all in the most common data-loss scenarios.

Don't discount the noise factor. Disk whine may not be that noticeable in a standard office environment, but can be more distracting in a quiet home setting. If the whine from one disk is even a bit noticeable, the noise from two disks can be downright annoying. And chassis fans working harder to expel the additional heat just adds even more noise.

RAID-1 is costly.

To illustrate, consider this example:

Suppose you bought a computer in 2013 with two 1TB disks in a RAID-1 array. Because one disk is mirroring the other, your usable disk space is 1TB. Now let's suppose in 2015 one disk fails. Your data is protected because of the redundancy, and you merely need to replace the failed disk and let the RAID array rebuild itself on the new disk.

But at what cost?

At mid-2013 prices you probably paid $100 for that extra 1TB disk, even though you didn't actually need it until two years later. Now that one of your disks has failed you've got to replace it, but because of mirroring the replacement must be the same size as the remaining original disk. A 1TB disk in 2015 cost around $70, so for a total cost differential of $100+70, you're back up and running . . . albeit, still with 1TB of usable storage space.

OTOH, what if you had chosen a non-RAID configuration back in 2013? You would have initally saved $100 by not buying the second disk, and would not now be limited to a 1TB replacement or prevented from exploring other disk sizes. In 2015 a 3TB disk might cost only around $110. So for $110 you'd be back up and running with 3TB of space vs. the RAID system's 1TB for $170.

And that's after only two years. The price disparity keeps increasing the longer it goes before a disk failure occurs.

It's stupifying how many RAID advocates choose to ignore the simple economics here.

Furthermore, don't overlook the fact that two disks means twice the MTBF failure rate. This doesn't mean a RAID array has a higher risk of data loss, but it does pretty much guarantee you'll be replacing disks more often just to keep the mirror working.

Don't believe that? Consider this example: suppose you have disk-A and disk-B in a RAID-1 array, and disk-B breaks. What if you had bought a non-RAID system with only disk-A in the first place? You'd still be happily running along without having had to replace anything. IOW, the RAID option wouldn't have been any better.

And if it's disk-A that breaks? Well, then you're replacing one disk either way. So that's the same, RAID or non-RAID.

So if disk-A breaks, you're replacing one disk whether or not you had a RAID system, while if disk-B breaks you were better off not having a RAID system to begin with. Choosing RAID means the chances are twice as high that you'll be replacing one of the disks. RAID means two disks to maintain, so you'll be replacing one disk or the other, twice as often.

The bottom line is that RAID mirroring is not cost-effective for home/SOHO systems.

What about the data protection RAID-1 promises?

Mirroring provides protection only from drive failure. But that's only one threat to your data, and a relatively minor one, at that. There are many other risks for which RAID-1 provides no protection at all.

Home users have a greater risk of data loss from malware, from software updates gone awry, from new software that doesn't install correctly, from fire or theft, and from user error--such as accidentally deleting or overwriting the wrong file.

Mirroring provides zero protection against those other threats. In 35 years of working with computers, I have often resorted to my backups to recover data, but nearly all cases were due to non-hardware causes.

Because RAID-1 does not protect you from the vast majority of threats, it does not alleviate you from your responsibility to maintain good backups. And if you need to have a full backup of your system to address these other risks anyway, then RAID-1 adds no extra protection.

You can easily restore a non-RAID system from a good backup in no more than an hour or two, so is the extra cost of a RAID array justifiable?

The one and only benefit to mirroring is rapid recovery from sudden disk failure. "Rapid" and "sudden" are key words here. Many hard disk failures are not sudden and provide warning signs beforehand. Even in a single disk system, the user often has a chance to backup the system before the disk drive fails completely--provided one doesn't ignore the warning signs.

Again, this assumes you're maintaining reasonably good backups . . . but if you're not, then you're not protected from the vast majority of threats, either--and RAID vs. no RAID is going to be the least of your worries.

It's true that recovering from a disk failure can be faster with RAID-1 than a non-RAID system, but how important is a little bit of time over the span of however many years it takes before such a disk failure occurs? Is it really that crucial to save perhaps an extra hour, relative to restoring from a traditional backup? And is it worth all RAID's cons--the extra expense, the extra heat, the extra noise that you have to live with, day in and day out for years, while waiting for a disk failure? In a corporate environment (where, I might add, the heat and noise is usually confined to a server room) an extra hour's downtime might be critical, but in a home environment an hour's downtime once in several years is seldom that vital.

Back to Top
author: Dan Goodell
last revised: 05/28/2017