How to Combine Altaro Hyper-V Backup and Microsoft SQL Backup into a Data Protection Powerhouse

After even a small amount of experience with database backup and recovery, you quickly learn that it presents unique challenges. One or a few large files contain vital information that changes frequently. They have a high level of interdependency with server components and sometimes other large, frequently changing files. They might span storage volumes. They commonly hold data that spans years. Just about the only other thing in your datacenter fitting that description is – backup. Caring for SQL databases can feel like backing up a backup. Unlike backups, these databases contain front-line data, so we must protect them. This article shows how to leverage Altaro VM Backup and the native backup tool in Microsoft SQL Server to provide a supercharged data protection solution.

Software and Configuration Prerequisites

To follow this article exactly as written, you will need:

• • A Hyper-V environment with Altaro VM Backup

• • A Windows virtual machine running a supported version of Microsoft SQL Server, non-Express edition

• • Microsoft SQL Server Management Studio

If your environment has variances, you can still follow along, but you’ll need to adjust your operations accordingly. For instance, the concepts presented here will still work if you have a VMware environment and Microsoft SQL installed on Linux. If you have an exceptional understanding of SQL tools, then you can get by without SQL Management Studio. Microsoft SQL Server Express edition does have some backup capabilities, although not nearly as rich as the premium editions. Some non-Microsoft SQL servers might even have capabilities that can utilize this process. Adapting the information in this article to such differences is left as an exercise for the reader.

This article was written using SQL Server 2019 and SSMS 18.9.2. The backup configuration has not changed meaningfully in a very long time, so the presented steps should work on any currently supported version of SQL Server and SSMS. They will likely work perfectly on older versions as well.

Knowledge Prerequisites

To remain in scope and keep the length within reason, this article will not spend much time on foundational details. You should have a functional familiarity with Altaro VM Backup, Hyper-V virtual machines, and Microsoft SQL maintenance. You do not need expert-level qualifications on any of these tools. You do not need to know a meaningful level about T-SQL queries.

Goals and Solution Rationale

Any time that you start on a new IT initiative, you should first establish, in simple terms, what the project must accomplish. Then, you must go through the effort of investigating options and choosing a solution. Finally, you must prepare an explanation for selecting that approach from the alternatives.

This article sets a goal of creating an economical backup environment that allows thorough and rapid recovery from Microsoft SQL failures. It assumes a limited budget and resources. It seeks to mesh the capabilities of Altaro VM Backup with Microsoft SQL Server backup into a comprehensive solution that utilizes the strengths of both products.

You may have different goals for your SQL backup. Read through this article, adapt what applies to you and discard what doesn’t. It will present alternatives where applicable.

Process Overview

An overview of the general plan this article presents:

1. 1. Decide on and implement a “complete loss” protection scheme
   2. Enable and configure SQL backup accordingly
   3. Configure Altaro VM Backup to match the chosen SQL scheme
   4. Outline and demonstrate restore procedures

Designing a SQL Protection Scheme

To make a comprehensive SQL protection plan, we break it into three components:

• • Operating system

• • Microsoft SQL Server software

• • Data

We distinguish these three because they can have independent backup and restoration processes.

Planning for Windows Server Backup and Recovery

You do not necessarily need to backup Windows Server at all. If the installation becomes damaged, you can repair it. If repair attempts fail or would require substantial effort, you can reinstall from an image or a deployment server. Aside from monthly patches, Windows changes infrequently. Thanks to Microsoft’s model of monthly cumulative updates, it does not take much effort to update a disk image to current.

That approach will not work for everyone. It works best when:

• • You have a rapid OS deployment process (e.g., MDT)

• • Customizations happen quickly and automatically (e.g., scripting, GPOs)

• • You separate the operating system from data via different virtual disks

• • You have a rapid application deployment process

With traditional backup applications, you could take an especially fine-grained approach. With virtual machine protection tools such as Altaro VM Backup, you usually need to include or exclude an entire virtual hard disk.

Guideline: if creating and implementing a protection and restoration system that excludes the operating system causes a great deal of effort, then back up the operating system.

In all cases that apply in the scope of this article, we presume that a Windows installation does not require frequent backups.

Planning for SQL Application Backup and Recovery

SQL has a robust deployment infrastructure. Personally, I prefer to have the SQL install wizard create an installation configuration file every time I build a new system. If you did not select that option and would like to generate a file for an existing installation, Microsoft provides documentation on generating the script for an existing installation. That same link shows you how to use an install script in multiple situations, including capturing SQL with its Windows installation using Sysprep.

You do have the option of manually reinstalling SQL from scratch to recover from failure. However, even with no modifications, a manual installation of SQL server requires a significant time investment that might violate your recovery time objectives. Even classroom deployments rarely use all defaults and have no customizations. Making those changes by hand and then patching the installation adds even more time. Use this process as a last resort.

Use the same guideline for SQL Server as for the operating system: if you can rebuild the application quickly and without a lot of headaches, then you can forego the backup.

Planning for SQL Data Backup and Recovery

Now we come to the part that you cannot quickly recover from install media or documentation: your SQL data. Furthermore, it changes frequently. Because it has such radical differences from the OS and the application, we can treat it specially. We will not deal with low-volume, low-change databases in this document. If you have a quiet, stagnant database, you do not need to give it the same attention as a highly utilized data store.

The per-VHDX operation comes back into the conversation at this point. If you intend to capture the complete data store, then you may have to plan appropriately to capture multiple drives.

This document shows an alternative solution. Do not back up the data storage volumes using Altaro VM Backup at all. Use SQL Server’s native backup to place its BAK files on a virtual disk and have the Altaro product protect that. As promised in the introduction, this allows products to operate under their best conditions. It even allows you to get around the persistently pesky problems of backing up VHDS (virtual hard disk sets) if you deployed SQL in a virtualized cluster. Having regular BAK backups also gives you substantial flexibility in migration and support situations.

We’ve talked about the system databases a few times in this article. Consider placing them on their own VHDX and allowing Altaro VM Backup to protect it. If you suffer a complete failure, you will need to have master.mdf and mastlog.ldf where SQL Server expects or the service will not start. That prevents you from restoring any other databases. You would need to use or create a separate SQL installation and restore the files (under a different name so as not to collide with the restoring server) then move them to their homes on the recovered server. The system databases change infrequently, usually even in high utilization environments.

Procedural Overview for a Potential SQL Protection Scheme

All those choices add up to more possible scenarios than we can possibly describe. This article takes the following approach:

1. 1. Capture an initial and infrequent backup of the operating system and SQL server application installation
   2. Configure daily full data backups using native SQL tools
   3. Configure hourly transaction log backups using native SQL tools
   4. Configure Altaro VM Backup Continuous Data Protection to guard the virtual disk that holds SQL’s data backups

The article will take a somewhat novel approach to implementing an option from these choices, but nothing binds you to follow it. If you already know how to configure these items and you like this plan or the discussion to this point has inspired you to design your own, then you do not need to read the remaining configuration parts of this article. It does have sections that work through recovery using this scheme if that interests you.

Note: This will come up again in the article, but consider keeping regular file backups of your system databases. You can recover the master database from BAK, but only with another SQL instance. If you place the system databases in a location that Altaro VM Backup captures, then you can easily use the process in this article for only your user databases.

Conceptual Overview for a Potential SQL Protection Scheme

After considering the available options and software capabilities, we have designed a functional solution. It has these traits:

• • Installs Windows and the application components of SQL on the same VHDX

• • Operates SQL data and logs on a single VHDX

• • Keeps SQL data backed up on a separate VHDX

• • Uses a scripted process to maintain an infrequent backup of the operating system and application VHDX

• • Uses Altaro VM Backup to continuously back up the VHDX that contains the SQL backup

• • VHDX extension and addition provides horizontal growth options

As mentioned, this design leverages the VM and VHDX-based nature of the Altaro VM Backup product and the powers of SQL’s native backup in a way that plays to both of their strengths.

Virtual Machine and SQL Server Configuration

Virtual CPU and memory settings do not matter in these directions. Drive configuration does. The sample virtual machine has the following build:

• • C: drive: Windows Server and SQL Server

• • D: drive: SQL data and logs

• • S: drive: SQL backup

• • T: drive: SQL temporary database

If you intend to use this with an existing deployment that has an incompatible configuration, then you primarily need to have a VHDX devoted to holding backup data. You can add that without interrupting operations.

If the database files reside on the same volume as Windows or SQL server components, relocate them if possible. If this would cause an unacceptable impact, review the options from earlier and your available software solutions for protecting the non-data items.

Note: this is the leanest possible build and shows ALL databases in the same location. Because it only protects backup files and not database files, it makes complete recovery difficult. To ease your work, you can place the system databases, particularly the master, on a location protected by a file-based backup. You cannot start SQL Server without a copy of the master database.

Configuring SQL Backup

This article shows how to configure SQL backup with SQL Server Manager Studio. You have other options, such as scripts.

To make the best use of the plans presented here, set your critical databases’ recovery mode to “Full”. System databases and databases that change infrequently can use “Simple” mode.

Verify SQL Service Settings and Folder Permissions

Before proceeding, make certain that you have set the “SQL Server Agent” service that applies to your SQL instance(s) to “Automatic” and started it. You do not need the agent to capture backups, but you do need it to control them from SQL jobs.

For the backup configuration in this article, we will create a System and User subfolder under the server’s default backup location. Do that now.

While there, make sure that the account “NT Service\MSSQLServer” has Full Control over the root backup folder and that subfolders inherit. If you have more than the default instance, add each instance’s server account as well.

In most cases, the SQL installation will properly configure permissions for our purposes. If jobs have trouble running, check the SQL server and agent logs for “Access denied” errors. Remember that the SQL server and agent each have one account per instance.

Create a SQL Backup with the Maintenance Plan Wizard

SQL Server Management Studio provides two visual methods for creating maintenance plans. We will start with the wizard.

In this walkthrough, we will create a daily job to back up the server’s system databases. Each of these operate in the “simple” recovery mode, so they do not generate regular transaction logs. With this configuration, the Altaro VM Backup configuration that we will show later will make one copy of the system databases each day.

To configure using the wizard:

• In SQL Server Management Studio, connect to the SQL Server.
• In the Object Explorer pane, expand the server’s Management tree.

• Right-click Maintenance Plans and select the Maintenance Plan Wizard.

• The first screen, if it was not previously disabled, shows an overview of the wizard. Read its contents and click Next.

On the Select Plan Properties screen, give the plan a descriptive name and, optionally, a longer description. For this walkthrough, we use “Backup System Databases Daily” as the name. Do not click Next yet.

• Still on the Select Plan Properties screen, click the Change button at the lower right next to the Schedule text box. This opens the New Job Schedule dialogue where you establish the desired schedule. For this walkthrough, we will simulate a typical small professional services organization and use a Weekly frequency with backups at 7 PM Monday-Friday. This captures the system databases roughly at the end of the business day. Click OK once you have completed your schedule configuration.

• Leaving the schedule dialogue returns you to the Select Plan Properties wizard page. Click Next.
• On the Select Maintenance Tasks page, select Backup Database (Full) and Maintenance Cleanup Task.

• On the Select Maintenance Task Order page, leave the tasks configured so that the backup runs first, then the cleanup. Click Next.

• Assuming the order above, you should now see the Define Back Up Database (Full) Task page. It has three sub-tabs: General, Destination, and Options.
• On the General sub-tab, next to the Databases: label, click the <Select one or more> drop-down. Set the radio button to System databases. Click OK.

• Switch to the Destination sub-tab. Change the destination to the System subfolder of the default location that you created during the prerequisite work. Checking the option to Create a sub-directory for each database makes output easier to navigate, but you can leave it empty if you prefer. Leave the Backup file extension as bak.

• Change to the Options sub-tab. You can leave all these items as-is and your backups will work perfectly well. Of note, Verify Backup Integrity had value when writing to tape, but much less for disk targets. If you like, you can also instruct SQL to encrypt the backup. This has obvious value, but a proper discussion exceeds the parameters of this article. Remember that Altaro VM Backup also encrypts. SQL encryption uses a certificate/key known to the SQL server; Altaro uses a passphrase. There are many other considerations. Exploring them is left as an exercise for the reader.

• Once you are satisfied with the backup configuration settings, click Next to move to the Define Maintenance Cleanup Task dialogue page. You want to configure this page to delete files with the bak extension from the system database backup location. If you chose to have the backup create sub-folders for each database, check the Include first-level subfolders option. For File age, choose the shortest lifetime in your comfort range. Remember that Altaro VM Backup will do the heavy lifting on data protection, so these should serve as nothing more than convenience backups. This walkthrough uses two days as its limit. Click Next when you have completed this dialogue page.

• The Select Report Options page tells the task what to do with completion information. By default, it will write a text report of the task to the indicated folder. If you have configured SQL operators and enabled database mail, it can also e-mail a report. Things to note before deciding:

1. 1. 1. The options that you select here always occur and the task will almost always succeed. That means, if you opt for an e-mail report, you will receive an e-mail from this job every day.
      2. The text files accumulate. SQL administrators commonly add a Maintenance Cleanup Task to delete txt files from the indicated folder or use a general History Cleanup Task in a separate plan.
      3. No matter what you set here, the task uses the BACKUP DATABASE command and SQL Server will track that event and its outcome in the server log.
      4. After you set up the maintenance task, you can configure options on the job itself. It has far more options than the task. As an example, you can configure it to only send you an e-mail when the job fails.

• The final page shows a summary of your selections. You can go back and make modifications, but be warned that some pages, notably the Define Back Up Database Task page, clear their settings if you go to an earlier page. Click Finish when ready.

• The wizard shows the task creation and will generate a report at the end. You probably won’t find a lot of use for the report unless something goes wrong.

Your created plan will now appear under the Maintenance Plans heading in Object Explorer. The job that controls it will appear in the Jobs node of the SQL Server Agent heading. Only use the item in Jobs to change settings exclusive to that setting. Modify the plan to change things such as the name and the schedule. SQL administrators often use the job’s properties to change the owner of a task-created job to SA or another generic account. You will find the option to send failure notification e-mails on the Notifications page of the job properties.

You will see more about maintenance plans in the next section on directly creating a plan.

Note: SQL Maintenance Plans are SSIS packages and can be viewed by connecting to the Integration Services management service.

Create a SQL Backup with the Maintenance Plan Designer

The previous section showed plan creation using a wizard. This section shows direct creation using the designer.

We used the wizard section to demonstrate creating a daily job for the system databases. In this section, we will create a daily full backup of all user databases.

Note: To create a backup that targets only user databases, at least one user database must exist. If you will not have a “real” database until later but want to set up the job in advance, create an empty throwaway database. It will consume almost no backup space and you can delete it later.

To directly create a SQL maintenance plan:

• In SQL Server Management Studio, connect to the SQL Server.
• In the Object Explorer pane, expand the server’s Management tree.

• Right-click Maintenance Plans and select New Maintenance Plan.

• You will see a small dialogue asking for the plan name. For this walkthrough, we use “Backup User Databases Daily” as the name. Click OK when ready.

• You will now see the design page for your freshly created job. Notice that its name has an asterisk next to it in SSMS’s document well. You can add a description if you like.
• Double-click the Subplan_1 item in the subplan list. You can leave the name as-is or change it to something more descriptive. This walkthrough will change the name to “Daily” with an empty description. Do not close this dialogue yet.

• Still in the Subplan Properties dialogue, click the button with the calendar icon in the Schedule row. If you followed the wizard in the previous section, you will recognize the New Job Schedule window. Still following the example of our fictional Monday-Friday professional services company, we will set this backup to run every weekday after hours and at a time that does not conflict with the system database backup (not strictly necessary). Click OK when complete, then click OK to close the Subplan Properties dialog.

• The design page should contain an updated entry for the subplan. If it looks like same as before (generic name and no schedule), double-click and verify.
• Move your mouse to the left of the screen and click the Toolbox tab. When it opens, expand the Maintenance Plan Tasks node.

• Double-click the Backup Up Database Task or drag it to the large empty area underneath the subplan list. A task should appear with a red X icon.

• If you single-click the Back Up Database Task line at the top, you can rename the task. This is optional. You and other administrators can likely figure out the task from context and its default name.
• Double-click the task to open its details. This dialogue has three sub-tabs: General, Destination, and Options.
• On the General tab, next to the Databases: label, click the <Select one or more> drop-down. Set the radio button to All user databases. If the UI won’t allow it, then create an empty database and try this dialogue again. Click OK.

• Switch to the Destination tab. Change the destination to the User subfolder of the default location that you created during the prerequisite work. Checking the option to Create a sub-directory for each database makes output easier to navigate, but you can leave it empty if you prefer. Leave the Backup file extension as bak.

• Change to the Options tab. You can leave all these items as-is and your backups will work perfectly well. Of note, Verify Backup Integrity had value when writing to tape, but much less for disk targets. If you like, you can also instruct SQL to encrypt the backup. This has obvious value, but a proper discussion exceeds the parameters of this article. Remember that Altaro VM Backup also encrypts. SQL encryption uses a certificate/key known to the SQL server; Altaro uses a passphrase. There are many other considerations. Exploring them is left as an exercise for the reader.

• Click OK to close the Back Up Database Task window. Back in the design window, your task should now show some more information and have lost its red X icon.
• Open the Toolbox window again. Double-click the Maintenance Cleanup Task item or drag it to a spot below the backup task.

• Click the backup task to select it. When the arrow appears below it, click that. Connect it to the new maintenance cleanup task box. This sets the operation order so that the tasks do not run simultaneously.

• As with the backup task, you can single-click on the Maintenance Cleanup Task to rename it if you wish.
• Double-click the new maintenance cleanup task to configure it. Use this window to delete files with the bak extension from the user database backup location selected in step 14. If you chose to have the backup create sub-folders for each database, check the Include first-level subfolders option. For File age, choose the shortest lifetime that is in your comfort range. Remember that Altaro VM Backup will do the heavy lifting on data protection, so these should serve as nothing more than convenience backups. This walkthrough uses two days as its limit. Click OK when complete.

• If you do nothing else, the plan will record its actions in a dated text file in SQL Server’s default data path in the Log subfolder. If you want to modify what it does on completion, click the Reporting and Logging button on the designer’s toolbar.

You can change the settings here. Remember that SQL does not automatically clean up these reports. You can add a Maintenance Cleanup Task to clean txt files from the displayed folder or create a separate plan to run a general History Cleanup Task. As for e-mail notification, you must configure Database Mail first. You will find better notification options on the automatically created job that we’ll revisit after these steps.

• You can change anything else about the plan that you like. When ready, press CTRL+S or use the File->Save menu item. That will clear the asterisk from the title in the document well. To make it appear in the plan list, select Maintenance Plans in Object Explorer and press F5.

To review the automatically created job, look under the Jobs sub-node of the SQL Server Agent node of Object Explorer. You may wish to change its owner to SA or something other than your own account. You can also find the notification options on the related page. They have more granular options than the maintenance task. Do not use the job dialogue to make schedule changes; use the plan designer.

Configure SQL Transaction Log Backup

At this point, you should have a daily job to back up your system databases and another to back up your user databases. Now you want to create a job to back up the transaction logs of your user databases. Use either the wizard or designer for this purpose, following the procedures shown above. The list of items to change appears at the end of this sub-section after a couple of notes.

This walkthrough will generate transaction log backups every hour. That sets the recovery point objective (RPO) for your user databases to a maximum of one hour if the backup VHDX survives a problem or one hour plus the maximum CDP frequency in Altaro VM Backup (we will revisit that in the section on configuring Altaro VM Backup). If you desire a different RPO, adjust the schedule accordingly.

Note: To create a backup that targets only user databases, at least one user database must exist. If you will not have a “real” database until later but want to set up the job in advance, create an empty throwaway database. It will consume almost no backup space and you can delete it later.

Configuration items for a transaction log maintenance plan:

• • Scheduling

• • • Occurs: Daily

• • • Occurs every: 1 hour starting at 1:00 AM

• • • Start date: << any time after the first full backup >>

• • Backup Database Task:

• • • Backup type: Transaction Log

• • • Databases: All user databases

• • • Destination: folder for user database backups created during prerequisites

• • • Create a sub-directory for each database: yes (optional)

• • • Backup file extension: trn

• • Maintenance Cleanup Task (run after backup job completes)

• • • Folder: folder for user database backups created during prerequisites

• • • File extension: trn

• • • File age: 2 days

You do not necessarily need to establish a special start time for the transaction log backup, but these jobs will always end in error if they do not have a full backup to work from.

Pay special attention to the backup type and file extension. These are the most common mistakes when setting up this type of plan. You do not necessarily need to use the trn extension, but it makes things easier to figure out especially if you don’t look at any of this again until years from now.

Your finished plan should look something like this:

Check over the matching job, as well.

Configuring Altaro VM Backup to Protect Microsoft SQL Server

A recap of our journey thus far:

• • Our SQL Server installation handles its own data backup

• • The SQL Server data backup files reside on their own VHDX attached to the virtual machine that operates SQL Server

• • SQL captures a full backup of its system databases once per day

• • SQL captures a full backup of its user databases once per day

• • SQL captures a transaction log backup of all user databases using the “Full” recovery model once per hour

That list describes what we have. This list describes what we do not have:

• • A backup of the Windows operating system

• • A backup of the SQL Server application

• • A backup of SQL data that resides apart from the server instance

Of these three items, the last matters the most. In this section, we will configure Altaro VM Backup to protect the SQL data in a way that uses its strengths.

Note: The instructions in this article show Altaro VM Backup version 8.26.2.0.

Fortunately, you don’t have nearly as much work to do in the Altaro product as you did for the SQL backup. Follow these steps (remember to click Save Changes as you move between pages):

• If you have not already done so, add the SQL system to the desired backup location in Setup->Backup Locations.

• Clear the Application-Consistent setting for the VM under Backup Settings->VSS Settings.

• Go to the Backup Settings->Advanced Settings tab and click the Exclude Drives… or # Excluded Drives link for your SQL virtual machine.

• Click Exclude for every VHDX except the backup drive so that your screen appears something like the following:

• Go to Backup->Schedule Settings and ensure that the SQL virtual machine does not appear in any of the active onsite schedules. If you find it in any, use the blue X icon at the end of its row to remove it.
• Go to Backup->CDP Settings. Enable CDP for the SQL virtual machine and set a reasonable frequency. Remember that you will need to add the maximum frequency here to the time between transaction log backups to determine your true RPO.

• Switch to the Dashboard. Your first CDP job has likely already been completed.

You will need to monitor the virtual machine for potential performance impacts. Disabling application consistency for the virtual machine backup minimizes backup checkpoint impact. Since we allow SQL to worry about backup consistency, Altaro only needs to capture static file contents.

A deeper explanation of what we have done: with the simple tools available to us, we cannot synchronize the SQL backup to the CDP backup. We need Altaro VM Backup to check the VM more frequently than we capture transaction logs. I do not know what heuristics it uses to decide to run a backup, but you should assume that it will generate a Hyper-V backup checkpoint at every CDP interval whether it needs to capture something or not. Single-level checkpoints usually have no discernible performance impact, and this configuration should reduce it to its absolute minimum.

If CDP proves too disruptive, you do have the option to craft a scripted solution wherein the SQL backup job triggers the Altaro VM Backup API. This has the benefit of perfect timing between the two products, the fewest possible checkpoint operations, and effective elimination of the RPO lengthening caused by the CDP interval. As far as I know, no such scripts exist today, so it would fall to the community to produce them.

Backing Up Windows Server and the SQL Server Application

To quickly recap the introduction, you do not have to do this at all. You can rely on reinstallation from media, installation from a deployment system, or keeping a sysprepped VHDX available.

We don’t want the system volume to our CDP backup because it essentially wastes time and space. It will capture meaningless changes like temp files and the page file. You can make changes to mitigate these problems, but such approaches have side effects and present more nuisances than value.

Out of the possible solutions, I chose to make a manual copy of the system VHDX. First, I turned to a technique shown in an earlier article to create a regular online copy of the system VHDX. Of those, the shadow copy option is the safest, but it’s also tedious and I can imagine that most administrators wouldn’t want to go that level of trouble. But, if you read the comments, Juri asked about the possibility of taking a virtual machine snapshot and copying the VHD while the VM ran from an AVHD. I don’t know if I didn’t understand the question or was overly sceptical at the time, but on review for this article, I couldn’t think of a reason why it wouldn’t work. So, I tried it. And, sure enough, it works just fine. So, I present you with a prototype script:

$VMName = ‘svsql1‘

$BackupTarget = ‘\\svstore01\Backups\VHDX‘

$SystemCaptureCheckpoint = Checkpoint-VM –VMName $VMName –SnapshotName ‘SystemDiskCapture‘ -Passthru

$VirtualDisk = Get-VMHardDiskDrive –VMName $VMName | Where-Object –Property Path -match ‘system‘

$RootVHD = Get-Vhd –Path $VirtualDisk.Path

while($RootVHD.ParentPath)

{

    $RootVHD = Get-Vhd –Path $RootVHD.ParentPath

}

Copy-Item –Path $RootVHD.Path –Destination $BackupTarget -Force

Remove-VMSnapshot –VMSnapshot $SystemCaptureCheckpoint

If you change the $VMName and $BackupTarget parameters and your SQL machine’s system VHDX’s file name can be appropriately matched with the -match ‘system’ criteria, then that’s all that you need to make this work.

The script does the following:

1. 1. Takes a checkpoint of the virtual machine. To minimize the impact, make sure that you have set this virtual machine to take “Production” checkpoints.
   2. Locates the C: drive of the SQL virtual machine by assuming that no other attached VHDX filename will match against the pattern “system”. For instance, the root path of my SQL system’s VHDX is “\\svstore01\vms\virtual hard disks\svsql1_system.vhdx”. No other VHDX for that virtual machine has “system” anywhere in its name. If you need to build your own pattern, remember that this will try to match against an AVHDX with a random GUID, not the VHDX.
   3. Walks the selected AVHDX’s parent chain until it finds the topmost, which will be the VHDX.
   4. Copies the root VHDX to the backup location.
   5. Deletes the checkpoint. Note that I used Remove-VMSnapshot instead of Remove-VMCheckpoint because the *-VMCheckpoint cmdlets exhibit a quirk where PowerShell just randomly forgets that they exist.

This approach presents a minor risk of performance impact. We must take that risk because, due to the CDP operation, we should expect the VM to already have a checkpoint or receive one while we work. This process captures its own checkpoint, makes sure that it traverses to the root regardless of the number or structure of checkpoints, and deletes only the checkpoint that it created. As long as no one else deletes our checkpoint during the copy, the VHDX will copy cleanly and safely.

I normally present scripts as complete functions. I chose not to this time because I suggest that you carefully consider the ramifications of automation. It doesn’t perform any logging, error trapping, or error correction. For the minor convenience of keeping a backup of an OS/application drive, you run the risk of creating snapshots of a production SQL server that no one notices for a very long time. I recommend that you run this script infrequently and manually.

The Recovery Process

Having so many different backups for the same system adds several phases to a complete recovery. Much of your challenge lies in remembering where to get the different pieces. What you do to restore depends on what you lost.

Recovery of SQL Data Only

We architected this to benefit the most common situation: loss due to human activity. Usually that just means an error. Occasionally it means sabotage. In the conditions that we address first, that means that you have damage to one or more database tables, but the operating system and SQL application continue to function as normal. Everything that you need sits in those BAK and TRN files that you’ve been dutifully creating.

Microsoft has created extensive documentation on restore operations that we cannot improve upon here. I linked you to the topmost article of that section. You may have particular interest in restoring a database in simple mode or restoring a database with transaction logs. If you haven’t spent much time learning about the various options for SQL restores, bookmark these pages.

Complete Restore Operations

At the other end of the spectrum, let’s consider a situation in which you have nothing except your backup data. If you have followed this walkthrough, then you have:

• • A backup of the virtual machine definition in Altaro data

• • A backup of the system and application VHDX in storage

• • A backup of the VHDX that holds your BAK and TRN files

You do not have the VHDX files that hold the SQL data and logs. In my case, I separated out SQL temporary files onto a VHDX which I also would not have.

Our order of operations for complete recovery:

1. 1. Bring host and storage hardware online
   2. Use Altaro VM Backup to restore the virtual machine definition and backup disk file
   3. Use regular file copy to recover the system and application VHDX
   4. Attach the OS volume to the recovered virtual machine.
   5. Create and attach empty VHDXs to replace the data/log and temp disks
   6. Boot up the VM
   7. Use SQL recovery tools to return the databases to operational status

Recovering the Virtual Machine Setup and Configuration

We’ll start with the Altaro VM Backup restoration part. It requires you to have a functioning Hyper-V environment with sufficient storage for your replacement SQL virtual machine.

• From the left side menu in Altaro VM Backup, open the Restore menu and click Restore VM as Clone.

• In the main pane, select the storage location that holds your VM backup and click Next at the bottom right of the window.

• Select your SQL virtual machine.

• Select the name and restoration options. This walkthrough assumes recovery after complete failure, so we use the original name and enable the virtual network card.

• After clicking Restore, you can go to the dashboard to monitor the progress of the backup job.
• Check the condition of the restored virtual machine. Note that it only shows the drive that we selected for CDP, but otherwise all settings recovered successfully. It even restores the drive back to its same controller and location, meaning that you won’t need to do any shuffling in later steps.

• If desired, move the virtual machine to a permanent location, add it as a clustered resource, or make any other changes desired.

Review the virtual machine status before proceeding. Our next steps will make it bootable.

Recreating the Virtual Machine Disk Structure

Next, we need to recover the disk structure. The system and application drive takes up most of our concerns. In this walkthrough, we kept a standard copy of the VHDX, so a simple file copy will put that back.

If you chose an alternative, such as reinstalling from image, then you’ll need to add an empty VHDX to the virtual machine and go through the system and software installation process.

The GUI is probably the easiest way to handle drive attachment/creation quickly. Make sure that you’ve got the necessary controller selected and add disks until you get back to your original configuration.

Don’t forget to select the correct boot volume. At first, it won’t allow changes:

Click the Apply button to commit your drive additions. Then you can fix the boot order.

Now you have a bootable virtual machine. However, you still need to prepare the disks to hold data. Since you created all-new VHDXs, SQL can’t yet use them.

Boot up the virtual machine and go through Disk Management, PowerShell, or whatever tool you like to initialize and format the replacement volumes.

Try to use the same drive letters as before to reduce your work in SQL. If you did not need to recover your operating system from scratch, it should have automatically re-assigned the same letter to your backup volume.

Restoring the SQL Databases

If you rebuilt a SQL installation, then you have a functional but empty environment. If you followed this walkthrough, then you have a lot of services that won’t start and tools that won’t connect. We need to start with the infrastructure. Follow these steps.

1. Open SQL Server Configuration Manager (it may have your SQL version number in the title).
2. Select SQL Server Services in the left pane.
3. In the main pane, right-click SQL Server (MSSQLSERVER) and click Properties.
4. Switch to the Startup Parameters tab. This shows all the paths where SQL Server expects to find the pieces of the master database and where to write logs. If these folders do not exist, create them.

• Ensure that NT Service\MSSQLSERVER has Full Control permissions on the SQL directories. NT Service\SQLSERVERAGENT requires Full Control on the JOBS and Log subdirectories.

• The walkthrough did not place any special significance on protecting the master database or any of the other system databases. In that case, you will need to use a functioning installation of the same or higher SQL version to restore them using alternative names. Copy them to the locations that you rebuilt in steps 4 and 5. The restored files have these names (your system may have more). Remember to place .mdf files in the -d location and .ldf files in the -l location:

1. 1. 1. Master.mdf
      2. Mastlog.ldf
      3. Model.mdf
      4. Modellog.mdf
      5. Msdbdata.mdf
      6. Msdblog.ldf

• Try to start the SQL Server service and then the SQL Server Agent service. If either won’t start, use Event Viewer for troubleshooting. If all system databases recovered successfully, then it’s likely that the service account does not have permission to a folder.
• Check Event Viewer for Event ID 5123 or 17204 from MSSQLSERVER. They can tell you where the temp directory was if you have forgotten. You only need to recreate the location and give SQL proper permission to use it. It will handle the file. Remember that you may have multiple temp locations; recover them all. Once you have the locations rebuilt, restart the SQL Service and verify that it successfully rebuilt its temp files.

• Open SQL Server Management Studio and expand the Databases node. It shows your database(s) as Recovery Pending.
• Right-click on the database, expand Tasks, then expand the Restore submenu. Notice that you can only choose Database.

 

Change the backup Source to Device and use the three-dot button to browse.

• On the Select backup devices window, make sure that it selected File for the media type, then click Add.
• Browse to your backup location where you should find two days’ worth of TRN and BAK files. Select the newest BAK and click OK.

• The general tab should now show the file source and the database name as both source and destination. It should also show the auto-generated name of the backup that it found within the BAK that you selected.

• Switch to the Files tab and verify the Restore as column contents. Retarget files or create folders as necessary. The destination path must exist or the job will fail.

 

• On the Options tab, change the Recovery state to RESTORE WITH NORECOVERY (only for databases that have transaction logs, otherwise leave in “with recovery” mode). Click OK when ready.

• The time length of the job depends on the size of your database and the speed of your hardware. It should soon reward you with:

• Refresh the interface, and SSMS will show your database as Restoring. Go through the Tasks and Restore menu to the Transaction Log item.

• Option 1, the worst: You have the option to use the GUI to step through each TRN file individually. As you did for the BAK file, change the source selection to Device, use the three dots button to get the device selection dialog, and click Add. This time, select a TRN file after the BAK that you restored from. After making sure that you have set the NORECOVERY option, run the restore. Repeat until you have reintegrated all TRN files. If you try to select multiple, the dialog will allow it, but clicking OK will cause it to error and you get to start over from the beginning.

Option 2: Let PowerShell and SQL do the heavy lifting. I crafted the following script with some defaults that you will want to change. The $TRNPath variable holds a folder where I copied only the TRN files after the BAK that I used.

$TRNPath = ‘D:\TRNTemp‘

$DatabaseName = ‘CorporateCentral‘

$TRNFiles = Get-ChildItem –Path $TRNPath –Filter ‘*.trn‘ | Sort-Object –Property LastWriteTime

for($i = 0; $i -lt $TRNFiles.Count; $i++)

{

    $RestoreParams = @{

        ServerInstance = ‘.‘

        Database = $DatabaseName

        BackupFile = ($TRNFiles[$i].FullName)

        RestoreAction = ‘Log‘

        NoRecovery = [bool]($i -lt ($TRNFiles.Count – 1))

    }

    Restore-SqlDatabase @RestoreParams

}

• Refresh the view in SQL Server and verify that the database looks as expected. Check logins, stored procedures, etc. Also compare against the primary Security tree to ensure that the server and the database agree on accounts.
• Repeat for all other user databases.

After you get through everything, clean up your temp files and double-check all the SQL Server settings. If you carefully followed all the steps, everything should work perfectly.

Keeping It Going

Now that you’ve recovered, you need to make sure that you can survive this again. Most importantly, configure Altaro VM Backup again. Remember that it restores a clone, so even if your Altaro instance survived, it won’t know to back up the “new” system. It will attempt to back up the “old” one until you set it right.

Above all, write down what you learned. I tested each step thoroughly, but your environment will have at least one difference that matters. Document, document, document.

Hopefully, you read all this as a possibility. If you don’t have problems, great! If yes, FOLLOW THE STEPS. If you don’t try this out, you might encounter questions or problems in the middle of a disaster. Use Altaro VM Backup’s ability to recover a disconnected clone and see if you can follow these directions as written or if they would have led you to calamity. Hone the process until you can run it smoothly.