The short answer is that you can, and it certainly provides a level of protection.
But your safety net has a hole in it.
There are definitely things you’re missing that a managed backup would catch and back up for you … things you’ll really care about should the worst happen.
Copying C: to another drive
To be clear, the scenario here is that you’re attempting to backup C: by just copying all of it to another drive, like F:. If you’re familiar at all with the Windows Command Prompt, it might be something like this:
C:> xcopy /e /h c:\ f:\
There may be other options that would make sense, but I’ve included the important ones to copy the contents of all files and folders from the root of the C: drive to the root of the F: drive, and copy hidden and system files as well.
In theory it seems simple, and in many ways it’s fairly close (at least in concept) to what a backup program actually does.
But there are some important things missing.
What copying misses
There are files that will not be backed up by this approach.
Most importantly, any files that are “in use”, meaning opened in running programs, will not be copied.
And some files are always in use. Like the Windows registry – the storehouse for millions of Windows and other application settings and configurations. If Windows is running, the operating system keeps the files that contain the registry open and locked from outside access.
If your hard drive were to die – even if you’ve backed up everything else on your machine – without the registry, you’re still looking at a complete reinstall of Windows, plus your applications, onto a replacement drive.
The registry is just the most obvious example, but it’s only the tip of the iceberg. Windows may have other files open that you can’t back up with a simple copy. In addition, other applications you may be running could also have files open, and those files will not get copied.
A back-up program catches more
A back-up program uses Windows functionality specifically designed to gain access to the protected files.
In other words, a back-up program will back up everything that a simple file copy cannot.
There are a couple of other benefits to using a back-up program that aren’t quite as critical, but still very handy.
I personally find back-up programs easy to “set and forget”. Once configured, they simply run and back up automatically. Depending on where you’re backing up, you won’t have to waste much energy thinking about your backups on a regular basis – they just happen.
But there’s an interesting scenario in which a back-up program can save the day that doesn’t involve a hard disk crash or other catastrophic failure.
Backing up incrementally
Let’s say on day one you create an important file, and that night your “file copy” backup places it on your back-up drive.
On day two, you make some changes to the file, perhaps deleting a section that you figured you no longer needed. At the end of day two, your back-up software once again copies the updated file to your back-up drive, overwriting the previous day’s back-up copy.
On day three, you realize the changes you made the day before were a huge mistake. Ideally what you want is the copy of the file at the end of day one, before you deleted everything. Unfortunately, even your backup no longer has that, as it dutifully overwrote it with day two’s work.
Back-up programs almost always include a feature known as “incremental backup”, which would solve this potential snarl. Each night, they back up only those things that have changed since the previous backup.
I’ll use my Windows configuration as an example.
On the first of every month, my back-up program takes a complete snapshot of my entire C: drive, a “full image backup”.
Each day thereafter, it saves the changes that happened since the previous day’s backup. For example, on the second day, only files that have changed since the first day are backed up. On the third day, only files that changed since the second day are backed up, and so on. This is called an “incremental” backup, and each is carefully tracked and stored separately (which means each can be accessed and restored separately).
The result is that on my machine, a full backup is about 45 gigabytes, but each day’s incremental backup varies between 2 and 6gb, depending on how busy I was on that particular day.
At the end of the month, I have the complete snapshot of the 1st as a starting point, and around 30 of these collections of incremental changes from each day to the next.
The downside is that if, on the 30th, I need to restore my hard disk to its most recent backup, the restore software needs to start with the full image of the 1st, and then apply each incremental change from 2nd through the 30th in turn. Fortunately, that only happens on a full restore.
The huge upside, from my perspective, is this: if, on the 30th, I decide I need a copy of a particular file as it was on the 15th, I can simply use the recovery tool to only apply the changes through the 15th, and pick up that file as it was on that day.
Now, aside from the files in use that I talked about earlier, you could probably devise a system using batch files and copy operations to mimic all this. In fact, that’s pretty close to what I did for a long time. But let me tell you, a back-up program that does this as its job is much more reliable, easier to use, and, in my opinion, worth every penny.
File copies can work
To be fair, there are some scenarios where simple file copies work, and work well enough.
For example, I have a couple of drives that contain only data, and no files are in use in the middle of the night, when my back-up scripts run. So I do indeed copy those drives to other drives each night, using a simple file-copy operation, much like the command line example shown earlier. There’s no need to set up a more sophisticated backup, and rather than being in a potentially proprietary backup format, the mirrored back-up drive is simply there, on my network, ready to be used at any time.
Copying files to back up can also be a space saver, under two conditions:
- You know – and I mean really know – what files should be backed up and which ones you don’t need. Often that’s as simple as having all of your data on a separate drive or partition.
- Your system drive is either backed up using a back-up program, or you plan on reinstalling the operating system and all applications from scratch in the case of a catastrophic failure.
It’s important to realize that for many people, a complete reinstall would be a couple of days of lost work that a back-up program could have taken care of in an hour or so.
And that actually brings me to my final point about using copy operations as backups: restoration.
Restoring your copied files
As we’ve seen, a “reverse copy” of the original example, of D: back to C: would not restore your system. Certain critical files, such as the registry, would be missing. Your “restored” drive won’t boot. You can recover data files reliably, and perhaps some other files, but that’s about it. It won’t be nearly enough to restore your entire system.
If your intent is to back up everything, so that in the case of a failure you can simply and quickly replace a hard drive and restore everything, then a back-up program is really the only way to go.