Posey's Tips & Tricks
Performing File-Level Backups from the Command Line
If you can't back up your data in an air-gapped solution, here's an alternative to saving your files.
In my own organization, I back up my data using a continuous data protection system. In addition, I also create air-gapped backups to protect my data against ransomware attacks. These air-gapped backups are essentially just backups written to removable hard drives. When such a backup is complete, I unplug the hard drive and store it in a safe place. That way, the data on the removable drive will remain safe, even if my system was compromised.
Although this particular backup method normally works really well, I ran into a situation recently that required me to temporarily adopt a completely different backup method. This temporary method was far from being ideal, but it got the job done.
The reason why I had to temporarily switch to an alternative backup method was that I performed a hardware refresh in my production environment. Because of my schedule and because of the nature of this particular hardware refresh project, my continuous data protection solution was offline for about three weeks.
Even though the volume of data that I created during this time was minimal, going three weeks without a backup would have been unacceptable. As such, I had to use a rather unconventional method to back up my data.
Before I explain what I did, there are a couple of things that you need to know about my environment. First, nearly all of my data is file data. That's important because the technique that I am about to show you won't typically work for protecting structured data.
The other thing that you need to know is how I generally create air-gapped backups. My production environment consists of virtual machines running on Hyper-V. I use the Hyper-V replication feature to maintain a synchronized replica of anything important. That way, if I were to experience a failure, then I have a secondary copy of my virtual machines and my data that I can fail over to.
Hyper-V hosts that are acting as replica servers have the ability to perform test failovers. Test failovers allow you to mount a recovery point and verify that the replica copies of your virtual machines are healthy. However, when you perform a test failover, the virtual hard drives are treated as read only for the duration of your test. All inbound replication data is written to HRL files, which are essentially special purpose checkpoint files used solely for the replication process. The contents of these files are later merged with the virtual hard disk files once the failover test is over, bringing the virtual hard disk back in sync with the primary copies on the source host.
My air-gapped backups take advantage of the fact that replica virtual hard disks are treated as read only during test failovers. I simply perform a test failover, and then copy the replica virtual hard disk files (the VHDX files) to a removable hard disk. Because these files are treated as read only, I don't have to worry about them being modified during the copy process.
As previously explained, the particulars of my hardware refresh kept me from being able to back up my data in the usual way for a few weeks. Since I already had multiple air-gapped backups, I decided to protect my data by simply updating my air-gapped backups at the end of each day.
To accomplish this, I would plug a removable hard disk into a PC on my network and then mount one of the virtual hard disk files that were stored on the removable disk. Windows allows you to simply right click on a VHDX file and then choose the Mount command from the resulting shortcut menu. This will cause a drive letter to be mapped to the virtual hard disk and its contents will become accessible. Incidentally, you should never mount a virtual hard disk for which checkpoints exist because doing so will cause significant damage and will likely result in data loss.
With the virtual hard disk mounted, I used the XCOPY command to copy any new or updated data from my network to the mounted copy of the virtual hard disk. The command that I have been using is:
XCOPY Q:\ G:\ /E /D /Y
The first two parameters are just drive letters and paths. I am copying data from Q:\ (a network drive) to G:\ (the mounted backup copy of my virtual hard disk). The next three parameters control the XCOPY command's behavior.
The /E switch tells XCOPY that you want to copy all directories and subdirectories, including empty ones. The /D switch tells XCOPY to overwrite older files with any newer versions that may exist. Finally, the /Y switch suppresses the "are you sure?" prompt, allowing the backup operation to run without intervention.
Keep in mind that there are only two users on my network. In an environment with multiple users, there are a couple of additional parameters that you would probably want to include. Most notably, you would probably want to use the /O switch. This causes XCOPY to retain file ownership data and any ACL permissions that might exist. There is also a /X switch that you can use to copy audit settings associated with the files. You may also opt to include the /C switch, which tells XCOPY to continue copying files, even if errors occur.
There are many more parameters that you can use with the XCOPY command. I have only discussed those that I consider to be the most useful for performing file-level backups. You can acquire the full list of available switches by typing XCOPY /? at the Windows command prompt.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.