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.

The post How to Combine Altaro Hyper-V Backup and Microsoft SQL Backup into a Data Protection Powerhouse appeared first on Altaro DOJO | Backup & DR.

In the depths of Windows Server Failover Clustering (WSFC), where the graphical interface cannot reach, network traffic shaping tools await the brave administrator. Most clusters work perfectly well without tuning network parameters, but not all. If you have low-speed networking hardware or extremely tight bandwidth requirements, then prioritization might help. This article shows how to leverage these advanced controls.

The Basics of Network Prioritization

If you have spent any time researching cluster network prioritization, then you likely noticed that most material dates back about a decade. This topic concerned us when networking was more primitive and unteamed gigabit connections pervaded our datacenters. Several superior alternatives have arisen in the meantime that requires less overall effort. You may not gain anything meaningful from network prioritization and you might set traps for yourself or others in the future.

Network Speed Enhancements in Windows

Windows Server versions beyond 2008 R2 provides network adapter teaming solutions. Additionally, 2012 added SMB multichannel which automatically works for all inter-node communications. These tools alone, with no special configuration, cover the bulk of network balancing problems that you can address at the host.

Speed Enhancements in Networking Hardware

For demanding loads, you have hardware-based solutions. Higher-end network adapters have significant speed-enhancing features, particularly RDMA (remote direct memory access), which comes on InfiniBand, RoCE, and iWarp. If that’s not enough, you can buy much faster hardware than 10 gigabit. These solutions solve QoS problems by providing so much bandwidth and reduced latency that contention effectively does not occur.

Software QoS Solutions

You can also configure software QoS for Windows Server and for Hyper-V virtual machines. This has similar challenges to cluster network prioritization, which we’ll discuss in the next section. Sticking with the QoS topic, networking hardware offers its own solutions. Unlike the other techniques in this article, QoS within the network extends beyond the hosts and shapes traffic as it moves between systems. Furthermore, Windows Server can directly interact with the 802.1p QoS standard that your hardware uses.

Drawbacks of WSFC Network Prioritization

Research the above options before you start down the path of cluster network shaping. This solution has a few problems that you need to know about:

• • It only works for networking traffic that Windows Server Failover Clustering understands. Virtual machine traffic does not benefit.

• • The use of cluster network shaping is non-obvious. It appears nowhere in any GUI or standard report. You must clearly document your configuration and ensure that anyone troubleshooting or reconfiguring knows about it.

• • WSFC network prioritization has no effect outside the cluster, which can make it even more limited than software-only QoS solutions.

• • WSFC network prioritization knows nothing about true QoS solutions and vice versa. Combining this technology with others leads to unknown and potentially unpredictable behavior.

• • The most likely answer that you will receive if you ask anyone for help and support will be: “Revert network prioritization to automatic and try again.” I do not know of any problems other than the obvious (poor tuning that inappropriately restricts traffic), but I have not seen everything.

Essentially, if you still have all-gigabit hardware and QoS solutions that do not shape traffic the way you want, then WSFC network prioritization might serve as a solution. Otherwise, it will probably only provide value in edge cases that I haven’t thought of yet. (let me know in the comments if you know one)

Cluster Networking Characteristics

While many of the technologies mentioned in the previous section have reduced the importance of distinct cluster networks, you still need to configure and use them properly. This section outlines what you need to configure and use for a healthy cluster.

Cluster Network Redundancy

At its core, cluster networking depends on redundancy to reduce single-point-of-failure risks. What you see here shows the legacy holdover of unteamed and non-multichannel technologies. However, even these advanced solutions cannot fully ensure the redundancy that clustering desires, nor will everyone have sufficient hardware to use them.

WSFC networks operate solely at layer 3. That means that a cluster defines networks by IP addresses and subnet masks. It does not know anything about layer 2 or layer 1. That means that it cannot understand teaming or physical network connections. In classical builds, one network card has one IP address and belongs to one Ethernet network, which might give the impression that network clustering knows more than it actually does.

When the cluster service on a host starts up or detects a network configuration change, it looks at all IP addresses and their subnet masks. It segregates distinct subnets into “cluster networks”. If one host contains multiple IP addresses in the same cluster network, then WSFC chooses one and ignores the rest. It then compares its list of cluster networks and IP addresses against the other nodes. This discovery has four possible outcomes per discovered network:

• • The cluster finds at least one IP address on every node that belongs to the discovered network and all are reachable in a mesh. The cluster creates a cluster network to match if a known network does not already exist. It marks this network as “Up”. If a node has multiple addresses in the same network, the cluster chooses one and ignores the rest.

• • The cluster finds an IP address on at least one, but not all nodes, that belong to the discovered network and all are reachable in a mesh. The cluster will treat this network just as it would in the first case. This allows you to design clusters with complex networking that contain disparate networks without getting an error. It also means that you can forget to assign one or more IP addresses without getting an error. Check network membership.

• • The cluster finds an IP address on one or more nodes, but the mesh connections between them do not fully work. If the mesh pattern fails between detected addresses, the cluster marks the network as “partitioned”. This only means that the layer 3 communications failed. You usually cannot tell from this tool alone where the problem lies.

• • The cluster fails to detect any members of a previously discovered network. Removing all the members of a network will cause WSFC to remove it from the configuration.

You can view your networks and their status in Failover Cluster Manager on the Networks tab:

In the lower part of the screen, switch to the Network Connections tab where you can see the IP addresses chosen on each node and their status within the cluster. In a two-node cluster like this one, any unreachable network member means that it marks all as unreachable. In a three+ node cluster, it might be able to detect individual node(s) as having trouble.

This article will not go into troubleshooting these problems. Understand two things:

• • Cluster networking understands only layer 3 (TCP/IP).

• • Cluster networking understands only cluster traffic. It works for internode communications and clustered roles with IP addresses known by the clustering service.

If you do not fully understand either of these points, stop here and perform the necessary background research. For the first, we have some introductory networking articles. I will call out some of the specific implications in the next section. For the second point, I mostly want you to know that nothing that we do here will directly impact Hyper-V virtual machine traffic. In a cluster that runs only Hyper-V virtual machines, networks marked as “Cluster Only” and “Cluster and Client” have no functional difference.

Cluster Network Roles and Uses

In pre-2012 clusters, we recommended four network roles. Depending on your hardware and configuration, you should employ at least two for complete redundancy. This section covers the different roles and concepts that you can use for optimal configuration.

Management Cluster Network

If you create only one cluster network, this will be it. It holds the endpoints of each node’s so-called “management” traffic. This network has a great deal of misunderstanding surrounding it. Even the typical “management” name fits only by usage convention. Traditionally, the IP endpoint that holds a node’s DNS name also marks its membership in this network. As a result, traffic inbound meant for the node, not a cluster role, goes to this address.

The cluster will also use the management network for its own internode purposes, although, by default, it will use all other networks marked for cluster traffic first.

Absolutely nothing except convention prevents you from creating a network, excluding cluster traffic, and using that for management. I would not consider this an efficient use of resources in most cases, but I could envision some use cases.

Cluster Communications Network

You can specify one or more networks specifically to carry cluster traffic. While some documentation suggests, or outright states, otherwise, this encompasses all types of internode traffic. Three general functions fall into this category:

• • Node heartbeat

• • Cluster configuration synchronization

• • Cluster Shared Volume traffic

The most common error made with this network comes from the widespread belief that CSV traffic has some distinction from other cluster traffic that allows you to separate it onto a network away from the other cluster communication functions. It does not.

Cluster Application Networks

The relationship between clustered objects and cluster networks leads to a great deal of confusion, exacerbated by unclear documentation and third-party articles based on misunderstandings. To help clear it up, understand that while the cluster understands networking for some applications, it does not understand all. Applications within a cluster have three different tiers:

• • Per-role cluster IP address. You will see this for roles that fully integrate with clustering, such as SQL Server. Check the properties of the role within Failover Cluster Manager. If you see an IP address, the cluster knows about it.

• • Client network binding. When you mark a network with the “Cluster and Client” role, the cluster can utilize it for hosting simple roles, such as scripts.

• • No cluster awareness. A cluster can host roles for which it does not control or comprehend the network configuration. Chief among these, we find virtual machines. The cluster knows nothing of virtual machine networking.

We will revisit that final point further on along with network prioritization.

Live Migration Network

The Live Migration cluster network represents something of an anomaly. It does not belong to a role and you can exclude it from carrying cluster traffic, but you control it from the cluster, and it only “works” between cluster nodes.

You configure the networks that will carry internode Live Migration traffic from the Network tree item in Failover Cluster Manager:

As with any other IP endpoint, nodes can use their members of Live Migration networks for any non-cluster purpose.

Non-Cluster Communications

Everything not covered above falls outside the control of the cluster service. Individual nodes can operate their own services and functions separate from the cluster. Due to common confusion, I want to call out three well-known items that fall into this category:

• • Virtual machine traffic

• • Storage traffic (host-to-storage connections, not internode CSV traffic)

• • Host-level backup traffic

The cluster knows nothing of the Hyper-V virtual switch. Furthermore, the virtual switch behaves as a layer 2 device and WSFC networking only operates at layer 3.

In fair weather, each node controls its own I/O. If a node has a problem connecting to storage and that storage is configured in one or more CSVs, then the cluster can redirect CSV traffic across the network via a node that can reach the CSV. However, the cluster classifies that traffic under the general “cluster” type.

I do not know of any backup tool that utilizes the cluster service to perform its duty. Therefore, each node handles its own backup traffic.

Once you understand what traffic the cluster cannot control, you next must understand that cluster network prioritization only impacts it indirectly and partially. The reasons will become more obvious as we investigate the implementation.

How to Discover and Interpret Cluster Network Prioritization

Before configuring anything, look at the decisions that the cluster made. Open a PowerShell prompt either in a remote session to a node directly on a node’s console and run:

1. 1. Get-ClusterNetwork | ft Name,AutoMetric,Metric,Role

This will output something like the following:

The “Name” and “Role” columns mean the same thing as you see in Failover Cluster Manager. “AutoMetric” means that the cluster has decided how to prioritize the network’s traffic. “Metric” means the currently assigned metric, whether automatic or not. Lower numbered networks receive higher priority.

To reiterate, these priorities only apply to cluster traffic. In other words, when the cluster wants to send data to another node, it starts at the lowest numbered network and works its way upward until it finds a suitable path.

Consider the real-world implications of the configuration in the screenshot above. The cluster has marked the “Management” network with the highest priority that can carry cluster traffic. The “Cluster” network has the lowest priority. The displayed cluster runs only Hyper-V virtual machines and stores them on an SMB target. It has no CSVs. Therefore, cluster traffic will consist only of heartbeat and configuration traffic. I have used Failover Cluster Manager as shown in a preceding section to prioritize Live Migration to the “Live Migration” network and set the Cluster and Management networks to allow Live Migration as second and third priorities, respectively. Therefore:

• • Internode traffic besides Live Migration will use the Cluster network if it is available, then the Live Migration, and as a last resort, the Management network.

• • Internode Live Migrations will prefer the Live Migration network, then the Cluster network, then the Management network.

• • Because cluster and Live Migration traffic use the Management network as a last resort, they should leave it wide open for my backup and other traffic. Due to isolation, non-cluster traffic does not have any access to the Cluster or Live Migration networks.

• • None of the preceding traffic types can operate on either Storage network.

The cluster automatically made the same choices that I would have, so I do not see any need to change any metrics. However, it does not make these decisions randomly. “Cluster only” networks receive the highest priority, then “Cluster and client” networks. Networks marked “None” appear in the list because they must, but the cluster will not use them. As for the ordering of networks with the same classification, I have not gathered sufficient data to make an authoritative statement. However, I always give my “Cluster” networks a lower IP range than my “Live Migration” networks, and the cluster always sorts them in that order (ex: 192.168.150.0/24 for the “Cluster” network and 192.168.160.0/24 for the “Live Migration” network) and my clusters always sort them in that order. But, “L” comes after “C” alphabetically, so maybe that’s why. Or, perhaps I’m just really lucky.

I want to summarize the information before I show how to make changes.

Key Points of Cluster Network Prioritization

We covered a lot of information to get to this point, and some of it might conflict with material or understanding that you picked up elsewhere. Let’s compress it to a few succinct points:

• • Cluster network prioritization is not a quality-of-service function. When the cluster service wants to send data to another node, it uses this hierarchy to decide how to do that. That’s it. That’s the whole feature.

• • The cluster service uses SMB to perform its functions, meaning that SMB multichannel can make this prioritization irrelevant.

• • In the absence of redirected CSV traffic, a cluster moves so little data that this prioritization does not accomplish much.

• • Cluster network prioritization does not “see” network adapters, virtual switches, or non-cluster traffic. It only recognizes IP addresses and only cares about the ones that carry cluster traffic.

• • You can only use cluster network prioritization to shape non-cluster traffic via the process of elimination as discussed in the real-world example. Due to the low traffic needs of typical cluster traffic, you may never see a benefit.

How to Set Cluster Network Prioritization

Hopefully, you read everything above and realized that you probably don’t need to know how to do this. That said, a promise is a promise, and I will deliver.

The supported way to manually configure cluster network priority is through PowerShell. You can also use the registry, although I won’t directly tell you how because you can wreck it that way and I’m not sure that I could help you to put it back. I think you can also use the deprecated cluster CLI, but I never learned how myself and it’s deprecated.

Unfortunately, even though PowerShell is the only supported way, the PowerShell module for Failover Clustering remains surprisingly primitive. Much like PowerShell 2.0-era snap-ins, it usually requires you to acquire an object and manipulate it. It implements very few variables beyond “Get-“, and the ones that it has do not expose much functionality. Furthermore, the module implements the extremely rare “packet privacy” setting, which means that you must carry out most of its functions directly on a node’s console or in a first-hop remote session. I believe that the underlying CIM API exposed by the cluster service imposes the packet privacy restriction, not PowerShell. I do not know what problem packet privacy solves that makes it worth the potential administrative frustration. Just know that it exists and how to satisfy it.

So, with all of the caveats out of the way, let’s change something. Again, I will work with the network list as displayed earlier:

Let’s imagine that my manager does not trust the auto-metric to keep the “Cluster” network at first priority and wants me to force it. To do that, I must manually give the “Cluster” network a metric lower than anything that the cluster might pick for itself. As you can see, the cluster uses very high numbers, so I can hit that target easily.

First, acquire an object that represents the “Cluster” network:

1. 1. $ClusterNetwork = Get-ClusterNetwork -Name ‘Cluster’

Second, modify the acquired object’s “Metric” value:

2. 2. $ClusterNetwork.Metric = 42

Third, verify:

3. 3. Get-ClusterNetwork | ft Name, AutoMetric, Metric

You should see something like the following:

I performed the object acquisition and parameter setting in two discrete steps for clarity. If you only want to modify the metric property, then you do not need to keep the object and can perform it all on one line. I will demonstrate this by reverting to the auto-metric setting:

1. 1. (Get-ClusterNetwork -Name ‘Cluster’).AutoMetric = $true

By using Get-ClusterNetwork to place the object into the $ClusterNetwork variable in the first demonstration, I could continue on to make other changes without reacquiring the object. In the second demonstration, I lose the object immediately after changing its setting and would need to acquire it again to make further changes. Also, I find the second form harder to read and understand. It might perform marginally faster, but it would cost more time to prove it than it could ever be worth.

Changes to the cluster network priority take effect immediately.

Going Forward with Cluster Network Prioritization

Ordinarily, I would wrap up the article with some real-world ideas to get you going. Really, I don’t have any for this one except don’t. You probably have a better way to solve whatever problem you face than this. Hopefully, this article mainly serves as an explanation of how newer features have made this one obsolete and that much of the existing material gets a lot of points wrong. If you have clusters configured under the patterns from 2008 R2 and earlier, review them to see if you can successfully employ the auto-metric setting. Happy balancing!

The post Backup Network Prioritization Best Practices appeared first on Altaro DOJO | Backup & DR.

On-premises SharePoint deployments need to be regularly backed up according to long-established best practices. However, backing up SharePoint Online (the version of SharePoint that is included with Microsoft 365) is equally important. This article explains why Office 365 SharePoint backup is so important and how to backup SharePoint.

Why is it Important to Back up SharePoint Online?

The main reason why it is so important to back up SharePoint Online (which I will be referring to simply as SharePoint for the remainder of this article) is that if you don’t back up SharePoint, no one else will. Including the big M. Microsoft uses a shared responsibility model for its Microsoft 365 platform. This shared responsibility model essentially states that Microsoft is responsible for keeping the Microsoft 365 applications and the underlying infrastructure running, but Microsoft 365 subscribers are responsible for securing and protecting their own data. If an organization were to suffer a data loss event within the Microsoft 365 cloud, it is up to the organization, not Microsoft, to recover the lost data. That’s why Microsoft 365 backups are so important.

The other reason why it is so important for an organization to protect its data that resides within the Microsoft 365 cloud is that although Microsoft does indeed go to great lengths to protect the Microsoft 365 cloud, there are still a number of ways that data could potentially be lost.

Ransomware represents one of the single biggest threats to SharePoint data. At one time, ransomware was designed to target the contents of the victim’s hard drive. Over time, however, ransomware has evolved into something far more sophisticated. While it is true that ransomware capabilities vary from one type of ransomware to the next, any data repository that a user is connected to could potentially be at risk of being encrypted. This includes data that is hosted on SharePoint sites. Regular backups are easily the best defence against the damage caused by a ransomware attack.

A data loss event does not necessarily have to stem from malicious activity. A user may delete a file by accident, or perhaps overwrite good data with something that is incorrect. SharePoint has native versioning capabilities, as well as a recycle bin, and both of these features (which will be discussed later on) can help a user to get their data back if a file was accidentally deleted or modified. Even so, these tools have their limitations. If a user were to accidentally delete a file, for example, the recycle bin will only store the file for so long. The user must realize that the file was gone and retrieve it from the recycle bin before the retention period expires.

Of course, it is entirely possible that a user may have malicious intent. We have probably all heard stories of disgruntled users or even administrators who take it upon themselves to delete vast amounts of data just before leaving the organization. In such a situation, a disgruntled employee might also empty the recycle bin as a way of making it more difficult for the organization to get its data back. Even if the employee doesn’t empty the recycle bin, however, the SharePoint recycle bin was never intended to be used as a bulk data recovery tool. A regular backup is much better suited to the task of recovering large amounts of data.

One more reason why an organization might need a SharePoint backup is that organizations that operate within regulated industries are typically required to retain data for a specific length of time. Although such regulations usually leave it up to the individual company as to how they will comply with the various regulatory requirements, a backup is often the least expensive and least complex option for dealing with data retention requirements.

What Are the Backup and Recovery Options Available?

There are four primary options for protecting data in a SharePoint environment. As you would probably expect, there are advantages and disadvantages to each of the options. Three of the options that are discussed below are native to SharePoint and are not true backup replacements. Even so, they will be discussed because they are tools that some organizations use to protect their SharePoint data. Additionally, it is important to understand what level of protection each of these options does and does not provide.

The SharePoint Recycle Bin

The SharePoint Recycle Bin is not a backup and recovery substitute by any stretch of the imagination, but it is the easiest and most convenient mechanism for recovering accidentally deleted files. As such, it seemed appropriate to at least mention it.

When a user deletes a file, the file is automatically moved to the Recycle Bin. To recover the file, go to the team site where the file previously resided, and click on the Recycle Bin tab. Now, just right click on the file and choose the Restore option from the shortcut menu, as shown in Figure 1.

Right-click on the file within the SharePoint recycle bin and choose the Restore option.

There are numerous reasons why the SharePoint recycle bin is not a true backup substitute. First, deleted items only remain in the recycle bin for 93 days. At that point, they are permanently deleted. Microsoft Support can perform restorations of deleted items within 14 days, but in order to do so, they must restore entire site collections or subsites. Microsoft cannot recover individual files, lists, libraries, etc.

Another reason why the SharePoint recycle bin isn’t a good backup substitute is because while it might protect you against accidental file deletions, it won’t protect you against malicious activity such as a ransomware infection, or a mass deletion by a rogue administrator who decided to permanently delete SharePoint files. Additionally, even if data is recoverable from the recycle bin, the recycle bin is not well suited to performing bulk recovery operations and files can only be recovered if their container objects are present (although it may be possible to restore a container and then restore the files within it).

eDiscovery

The Microsoft 365 E3 and E5 plans include access to an eDiscovery tool that some organizations use as an alternative to traditional backups. The eDiscovery tool was primarily designed to help organizations gather and/or retain data that is related to legal proceedings. During litigation, for instance, opposing counsel might subpoena all of an organization’s data that is related to a particular client or event. The eDiscovery feature can help the organization to locate that data and to hold the data so that it is protected against accidental deletion or modification. It is this ability to retain data as it existed at a particular point in time that has led to some organizations using eDiscovery as a backup alternative, even though Microsoft never intended for the feature to be used in this way.

You can find the eDiscovery feature in the Microsoft 365 Compliance Admin Center. To use it, choose the Core eDiscovery option and click the Create a Case button. At that point, you are prompted to enter a case name and description. Once you have created a case, click on it and then select the Hold tab. Click the Create button to create a new legal hold. Enter a name and an optional description for your new hold, and then enable the hold for SharePoint sites. You will need to click the Choose Sites link to specify which sites should be placed on hold. As you can see in Figure 2, you can also place a hold on Exchange mailboxes and public folders. From there, you have the option to specify keywords and conditions that determine which individual items will be included in the hold.

You will need to place a hold on SharePoint sites.

One of the biggest disadvantages to using eDiscovery as a backup alternative is that creating an eDiscovery hold is a manual process, whereas backups are generally automated.

In spite of the automation issue, eDiscovery might initially work well as a backup alternative, especially in smaller organizations. Eventually, though, organizations will likely run into storage limitations. Each Microsoft 365 user has a specific amount of storage space available within the Microsoft 365 cloud. Data that is placed under legal hold counts against that storage limit, which can cause users to quickly run out of space.

Retention Policies

Another Microsoft 365 feature that organizations sometimes use as an alternative to regular backups is retention policies. Retention policies are sometimes referred to as the versioning feature because the policies store immutable copies of previous file versions. As such, if an organization needs to go back to an earlier point in time then it can restore an earlier version of a file.

To create a retention policy, open the Microsoft 365 Compliance Admin Center and then click on Policies, followed by Retention. When prompted, click the New Retention Policy button. At this point, you will be prompted to enter a name and an optional description for your retention policy. Next, you will be prompted as to what types of data to include in the retention policy. As you can see in Figure 3, SharePoint sites are automatically included.

SharePoint sites are automatically included in retention policies.

Once you have specified the types of information to include within the retention policy, you will be taken to another screen that asks you how long the data should be retained, and what to do with the data once the retention period expires. You can opt to have old data deleted automatically, or you can retain data indefinitely, as shown in Figure 4.

You will need to specify how long data should be retained.

Because retention policies store all previous file versions, they would initially seem to be an ideal solution for backing up Microsoft 365 data. After all, they allow you to revert a file back to a previous state (which can help to protect the data against ransomware) and they allow data to be protected against deletion. However, there are several disadvantages to using retention policies as opposed to a traditional backup.

Like eDiscovery, using retention policies can rapidly erode the space that you have available in the Microsoft 365 cloud. This is especially true if large files are updated frequently and need to be retained for a long period of time.

Another major disadvantage to using retention policies is that restoring a previous file version is not as straightforward as you might expect. You can’t just restore a previous file version. Instead, you have to export the file version and then manually place it into the SharePoint document library. This process isn’t usually a big deal for recovering a single file, but imagine what would happen if an organization were to suffer a ransomware attack and needed to recover hundreds of thousands of files. The sheer number of files that need to be recovered would make a manual export completely impractical. The organization’s only option at that point would probably be to create a complex PowerShell script to automate the export and import processes.

Traditional Backups

The third option for protecting your SharePoint data is to use a third-party backup application. Although there is a cost associated with licensing a third-party backup product, organizations must consider the fact that a backup application is specifically engineered for data backups. In contrast, native Microsoft 365 features such as eDiscovery and retention policies were designed to assist with compliance, not data protection. As such, these features can be used in a pinch, but they are not good long-term data protection solutions.

One of the most compelling reasons for adopting a dedicated third-party backup solution is that native tools such as eDiscovery, retention policies, and even the SharePoint recycle bin can offer a degree of protection for files that are stored in SharePoint libraries. However, there is more to SharePoint than just libraries. The native features do little to protect against the loss of an entire SharePoint site.

Another reason why an organization should consider using a third-party backup solution is that eDiscovery and retention policies do not work for protecting non-Microsoft 365 data. This means that an organization that relies on native features for protecting its SharePoint data would effectively be creating data siloes. SharePoint data would be somewhat protected by the native tools, but the organization would have to use a different data protection solution to protect any data that resides outside of the Microsoft ecosystem. It is far more efficient to use a single backup solution to protect everything. Perhaps more importantly, a piecemeal data protection strategy has the potential for gaps in coverage and for inconsistent data protection policies across data types.

Can you Back up SharePoint?

SharePoint can and should be backed up. Microsoft’s shared responsibility model states that it is the subscriber’s responsibility to protect their own data, hence necessitating the need for backups. Although the native tools can protect SharePoint to some degree, they are not a backup substitute.

Does SharePoint Automatically backup?

While Microsoft does perform backups of SharePoint, these backups are not readily accessible. To initiate a restoration, organizations must contact Microsoft support within 14 days of when the deletion occurred. Even then, Microsoft will only restore site collections or subsites. They do not restore individual files, lists, libraries, etc. As such, Microsoft’s automated backup is a last resort option. Organizations should protect their own SharePoint data using a third-party backup application.

How do I Back up my SharePoint Library?

The best option for backing up a SharePoint document library is usually to use a third-party backup application. It is possible to manually back up SharePoint libraries by manually downloading the files and saving them to a secure location, however, this is a tedious manual process. A backup application can automate the backup process, ensuring that the latest library data is always protected.

How is Data Stored in SharePoint?

SharePoint Online stores all of its data inside of Azure SQL Databases, which are hosted in the Microsoft Azure cloud. This data includes files and documents, lists, sites, and metadata. The data is not stored in just one database, but rather across multiple content databases. Incidentally, organizations that use Microsoft 365 need to back up SharePoint even if they do not actually use SharePoint because some of the other Microsoft 365 Applications leverage SharePoint as a data storage mechanism. Microsoft Planner, for example, does not have its own data repository, but rather stores data in Exchange, SharePoint, and other locations. All of this is to say, that when you backup Microsoft 365, you should be backing up all of the various Office applications, even if there are some applications that you do not use because those applications likely contain data tied to other applications.

The Best Practice for SharePoint Backup

While the way in which you protect this data is up to you as the system admin, there are easy-to-use and fully featured M365 backup applications available on the market today. A good example of this would be Total Protection Enterprise Backup from Hornetsecurity. Total Protection Enterprise Backup makes the backup and recovery of your M365 data simple and quick. Not only does the service protect your M365 data, but it also provides several other critical security services for your M365 tenants ranging from spam and malware filtration to encryption and advanced threat protection. Additionally, the service includes backup and recovery services for the endpoints in your organization as well, which enables end-to-end protection for your organization’s M365 data.

Be sure to let us know in the comments section below if you have follow-up questions, or if you’re still not convinced, tell us why! We’d love to hear your stance and your story! What do you think about backup and recovery for SharePoint Online?

Thanks for reading!

The post Why You Should be Backing up SharePoint Now appeared first on Altaro DOJO | Backup & DR.

Over the last several years, snapshots (or checkpoints as they are sometimes called) have become a popular alternative to backups. Checkpoints allow a system to be instantly rolled back to a previous state, without the hassles of managing tapes or waiting for restoration to complete. Despite all of its capabilities, however, checkpoints are not a true alternative to backups. In fact, checkpoints have several major shortcomings, and IT pros should seriously consider whether they are making the best use of checkpoints, but first, let’s quickly define the difference between checkpoints and snapshots.

What is the Difference Between a Checkpoint and a Snapshot?

The short answer is that there is no difference from a technical perspective. They are one and the same. The term snapshot was largely made popular with the VMware vSphere platform, which is the virtualization platform that many IT Pros cut their teeth on. Hyper-V followed the snapshot terminology for some time but eventually settled on the term checkpoint as an alternative. So, again, they are the same thing, but platform-dependent. VMware = Snapshot. Hyper-V = Checkpoint.

When Should I Use Snapshots?

As previously mentioned, checkpoints allow a system to be rolled back to a previous state almost instantly. The reason why a snapshot is able to do this is that, unlike a backup, a snapshot does not make a copy of your data.

This is not to say that checkpoints should never be used. Checkpoints do have their place. Checkpoints tend to work really well as a tool for protecting a virtual machine just prior to a configuration change. If a configuration change were to cause problems for a virtual machine, then the snapshot could be applied, effectively undoing the change.

Checkpoints are also useful to those who are performing software upgrades. If, for example, an operating system upgrade were to leave a virtual machine in an unbootable state, a snapshot can be applied, thereby reverting the virtual machine’s operating system to its pre-upgrade state. The same basic concept also applies to application upgrades and to the installation of patches.

The Anatomy of a Snapshot

In order to understand why checkpoints are not suitable replacements for backups, it is necessary to understand how checkpoints work. There are a few different types of checkpoints, but for the purposes of this discussion, I will talk about the way that checkpoints work in Microsoft’s Hyper-V.

The vast majority of Hyper-V virtual machines make use of one or more virtual hard disks. A virtual hard disk is simply a VHD or VHDX file that acts as a hard disk for a virtual machine. Like a physical hard disk, a virtual hard disk file can include volumes, file systems, and of course, files. Under normal circumstances, the virtual hard disk file is read/write, meaning that the virtual machine can write data to and read data from the virtual hard disk. While this probably seems obvious, it is actually an important point.

When an administrator creates a checkpoint for a Hyper-V virtual machine, it does not make a backup copy of the virtual hard disk file. Instead, Hyper-V puts the virtual hard disk into a read-only state. Because the virtual hard disk is now read-only, Hyper-V creates a differencing disk that becomes a part of the virtual machine. This differencing disk is essentially just a virtual hard disk file that has a parent/child relationship with the virtual machine’s original virtual hard disk file. A layout of this configuration can be seen below.

Because the virtual machine’s original virtual hard disk is now read-only, all write operations are directed to the differencing disk. This ensures that the original virtual hard disk file’s contents remain unchanged.

Now, suppose that an administrator created a checkpoint for a Hyper-V virtual machine and then attempted to upgrade an application that was running on the VM. Let’s also pretend that the application upgrade process has failed and that the virtual machine has been left in an undesirable state. The administrator can easily put things back the way that they were by applying the checkpoint.

When the administrator applies the checkpoint, Hyper-V deletes the differencing disk and resumes read/write operations on the original virtual hard disk (there are actually a few different options for how checkpoints are applied, but this is the simplest use case). At this point, the virtual machine is back to normal.

Why Checkpoints Are Not Backup Replacements

The most fundamental reason why checkpoints are not effective backup replacements is that the checkpointing process does not create a copy of the virtual hard disk. As such, checkpoints do nothing to protect against physical disk failure or against damage to the virtual hard disk file. If a virtual machine’s virtual hard disk were to be damaged or destroyed, the virtual machine’s checkpoints would be useless because they have a dependency upon the virtual hard disk file.

Another thing to consider is that the differencing disks used by the checkpoint process are usually stored on the same physical volume as the virtual hard disk. Hence, if the volume were to be damaged, there is a good chance that both the virtual hard disk and the differencing disks would be lost.

Limited Recoverability

Another key reason why checkpoints are a poor substitute for backups is that they do not allow for single item recovery. A checkpoint can be used to roll back an entire virtual machine, but it cannot be used to roll back an individual file or application on that virtual machine.

This brings up another important point. Checkpoints can cause significant problems for application servers. Early versions of Hyper-V were known for causing data corruption problems when checkpoints were applied to virtualized application servers. Microsoft eventually fixed this problem through the introduction of production checkpoints. Even so, production checkpoints do not address all of the potential consistency problems that checkpoints can cause.

Most application servers have dependencies on other servers. An application might, for example, be tied to a SQL Server, a Web front end, or perhaps an LDAP server. If a checkpoint were to be used to roll back an application server, there is a chance that a consistency problem would occur because other dependency servers were not rolled back. Of course, the chances of this happening vary depending on the application and the role that the virtual machine is performing, but application consistency should always be a consideration when using checkpoints.

Checkpoints Can Hurt Virtual Machine Performance

One of the biggest reasons why you should use checkpoints sparingly is because checkpoints can significantly degrade the performance of your virtual machines. The performance impact probably won’t be all that noticeable at first, but as additional checkpoints are created, the virtual machine’s performance tends to drop off sharply.

The reason why checkpoints can hurt performance has to do with the way that checkpoints work. As previously noted, checkpoints redirect write operations to a differencing disk. So with that in mind, consider what happens when a virtual machine performs a read operation.

When a read occurs, the VM attempts to read data from the differencing disk (remember, the differencing disk contains the most recent data). If the VM does not find what it is looking for on the differencing disk, then it attempts to read the data from the original virtual hard disk.

Now, suppose for a moment that an administrator creates an additional checkpoint for a virtual machine. Hyper-V will then treat the existing differencing disk as read-only and will create a new differencing disk. All future write operations will now be directed to this differencing disk. Here is a brief diagram showing this in action:

Now, when the virtual machine attempts a read operation, it will first look for the data on the most recently created differencing disk. If that differencing disk does not contain the requested data, then the virtual machine will look to the previously created differencing disk. If the data cannot be found there, then Hyper-V will attempt to read the data from the original virtual hard disk. Hence, each checkpoint that is created has the potential to further degrade read performance for the virtual machine. This ultimately ends up providing diminishing returns.

All said, checkpoints and snapshots are great for their intended use-case (Not backups!), but you have to keep them properly managed and maintained.

The post Why Can’t I Use Snapshots Instead of a Backup Application? appeared first on Altaro DOJO | Backup & DR.

Anyone who has ever had to replace a hard disk because their old disk was simply too small to accommodate all of their data understands that there is a direct cost associated with data storage. In an effort to reduce storage costs, many organizations turn to data reduction technologies such as deduplication and compression.

What is Deduplication?

Data deduplication is a technology for decreasing physical storage requirements through the removal of redundant data. Although deduplication comes in several forms, the technology is most commonly associated with backup applications and associated storage.

Storage volumes are made up of individual storage blocks containing data (although it is possible for a block to be empty). Deduplication works by identifying blocks containing identical data and then using that information to eliminate redundancy within the backup.

Imagine for a moment that you needed to back up a volume containing lots of redundant storage blocks. It does not make sense to back up what is essentially the same block over and over again. Not only would the duplicate blocks consume space on the backup target, but backing up redundant blocks increases the duration of the backup operation, as well as the amount of bandwidth consumed by the backup process (which is an especially important consideration if you are backing up to a remote target). Rather than backing up duplicate copies of a storage block, the block can be backed up once, and pointers can be used to link data to the block on an as-needed basis.

There are three main ways in which the deduplication process occurs. First, deduplication can occur inline. Inline deduplication is a process in which data is deduplicated in real-time as the backup is running. When inline deduplication is used, only non-redundant storage blocks are sent to the backup target.

The second form of deduplication is post-process deduplication. When post-process deduplication is used, all storage blocks are backed up, regardless of whether they are unique or not. Later, a scheduled process deduplicates the data that has been backed up. Post-process deduplication is effective, but it requires the backup target to have sufficient capacity to accommodate all of the data that is being backed up at its original size. Furthermore, data is not deduplicated prior to being sent to the backup target, which means that bandwidth consumption is higher than it would be with inline deduplication.

The third main type of deduplication is global deduplication. Global deduplication is essentially a combination of inline and post-process deduplication. Imagine, for example, that you needed to back up a dozen different servers, and you use inline deduplication to reduce the volume of data that is being sent to the backup target. Even though deduplication has been used, redundancy may still exist on the backup target because there may be data that exists on multiple servers. If, for example, all of the servers are running the same operating system, then the operating system files will be identical from one server to the next. Because redundancy could exist within the backup target, post-process deduplication is used as a secondary means of eliminating redundancy from the backup target.

Disadvantages of Deduplication

Deduplication can be a highly effective way to reduce the backup footprint. However, deduplication only works if redundancy exists. If every storage block is unique, then there is nothing to deduplicate (although some deduplication algorithms work on the sub-block level).

A secondary disadvantage to deduplication is that the deduplication process tends to be resource-intensive. Inline deduplication, for instance, usually requires a significant amount of memory and CPU time, whereas post-process deduplication requires memory and CPU time, and also creates significant storage I/O. As such, it is necessary to ensure that you have sufficient hardware resources to support the use of deduplication.

What is Compression?

Like data deduplication, compression is a technique that is used to reduce the storage footprint of data. Whereas deduplication commonly occurs at the block level, however, compression generally occurs at the file level.

Data compression can be classified as being either lossy or lossless. Lossy compression is used in the creation of digital media files. The MP3 format, for example, allows an entire song to be stored in just a few MB of space but does so at the cost of audio fidelity. The lossy conversion process reduces the recording’s bitrate to save storage space, but the resulting audio file may not sound quite as good as the original recording.

In contrast, compression is also used in some data backup or data archiving applications. Because data loss is undesirable in such use cases, lossless compression is used.

Like lossy compression, lossless compression reduces a file’s size by removing information from the file. The difference is that the information removal is done in such a way that allows the file to be reconstructed to its original state.

There are numerous lossless file compression algorithms in existence, and each one works in a slightly different way. Generally speaking, however, most lossless file compression algorithms work by replacing recurring data within the file with a much smaller placeholder.

How Does Compression Work?

Compression can be used to reduce the size of a binary file, but for the sake of example, let’s pretend that we have a text file that contains the following text:

“Like lossy compression, lossless compression reduces a file’s size by removing information from the file. The difference is that the information removal is done in such a way that allows the file to be reconstructed to its original state.”

The first step in compressing this text file would be to use an algorithm to identify redundancy within the file. There are several ways of doing this. One option might be to identify words that are used more than once. For example, the word ‘compression’ appears twice, and the word ‘the’ appears four times.

Another option might be to look at groups of characters that commonly appear together. In the case of the word compression, for example, a space appears both before and after the word, and those spaces can be included in the redundant information. Similarly, the block of text uses the word lossy and the word lossless. Even though these words are different from one another, they both contain a leading space and the letters l, o, s, and s. Hence “ loss” could be considered to be part of the redundant data within the text block.

There are many different ways of identifying redundancy within a file, which is why there are so many different compression algorithms.

Generally speaking, once the redundancy is identified, the redundant data is replaced by a placeholder. An index is also used to keep track of the data that is associated with each placeholder. To give you a simple example, let’s pretend that we wanted to compress the previously referenced block of text by eliminating redundant words and word fragments (I won’t worry about spaces). Normally the placeholders would consist of an obscure binary string, but since this block of text does not include any numbers, let’s use numbers as placeholders for the sake of simplicity. So here is what the compressed text block might look like:

“Like 8y 1, 8less 1 reduces a 2’s size by 9ing 6 from 32. 3 difference 45369al 4 done in such a way 5 allows 327 be reconstructed 7 its original state.”

By compressing the data in this way, we have reduced its size from 237 bytes to a mere 157 bytes. That’s a huge reduction, even though I used a super simple compression technique. Real-life compression algorithms are far more efficient.

Of course, in reducing the data’s footprint, I have also rendered the text unreadable. But remember that one of the requirements of lossless compression is that there must be a way to reconstruct the data to its original state. For that, we need a reference table that maps the removed data to the placeholder values that were inserted in place of the data. Here is a very simple example of such a table:

1 = compression

2 = file

3 = the

4 = is

5 = that

6 = information

7 = to

8 = loss

9 = remove

Keep in mind that the index also has to be stored, and the overhead of storing the index slightly reduces the compression’s efficiency.

Disadvantages of Compression

Even though compression can significantly reduce a file’s size, there are two main disadvantages to its use. First, compressing a file puts the file into an unusable state, as you saw with the compressed text block above. Second, not all data can be compressed.

A file can only be compressed if there is redundancy within the file. A compressed media file such as an MP3 or an MP4 file is already compressed and usually cannot be further compressed. Similarly, a file containing random data may not contain a significant amount of redundancy and may therefore not be significantly uncompressible.

These Technologies in Action

We’ve discussed how these technologies work and have also discussed some disadvantages to plan for, but we haven’t really talked about the real-world benefit of deduplication and compression. As mentioned earlier, the main place you see these technologies in use is in the realm of backup. Backup, being an archival type service, aims to keep large amounts of data for long periods of time. The more efficient you can utilize the storage, the lower the cost.

For example, let’s say we have a working data set of 50TBs, with a similarity of data of roughly 20%. The like blocks are first deduped, bringing in our data set to 40TBs. Then let’s say we get a compression ratio of 30%. Combined, this would bring the storage requirements for the base set of data down to 28TBs as opposed to 50+.

It’s important to keep in mind that all data dedupes and compresses differently. On top of that, certain kinds of deduplication technologies work better in certain situations. For example, when you’re sending data to an offsite location, in-line deduplication is far superior because only the blocks that need to go are actually going across the wire.

It’s important to remember that your mileage may vary depending on your particular organization, but in all cases, both technologies will provide cost savings in terms of storage needed.

The post What are Backup Deduplication and Compression? appeared first on Altaro DOJO | Backup & DR.

Having the ability to backup to Azure Blob storage can result in considerable cost savings. Azure Blob storage is the most cost-effective type of storage offered within the Azure cloud. Furthermore, the fact that Azure Blob storage is natively supported by numerous backup and storage vendors, including Altaro VM Backup, for example, means that costs can be further reduced since a cloud-based VM is not required. Finally, features such as compression and deduplication allow cloud storage to be used as efficiently as possible.

In addition, using Azure Blob storage allows for geographic flexibility. Your cloud storage can be centralized, or it can be distributed across regions for the optimal protection of your data.

Creating an Azure Storage Account

Before you can back your VMs up to Azure Blob storage, you will need to create an Azure Storage account. This is a relatively straightforward process:

From within the Azure Portal, click on the Storage Accounts service. If this icon does not exist, then you will need to click on All Services, and then click on the Storage tab on the left side of the screen, and then click on the Storage Accounts option, as shown in Figure 1 below.

Figure 1

Click on the Storage Accounts option.

When you arrive on the Storage Accounts page, click the Create Storage Account button. This will take you to the Create Storage Account page, shown in Figure 2.

Figure 2

This is the interface used to create a storage account.

The first thing that you will need to do on this screen is to select your subscription and choose the resource group within which you wish to create the storage account. Next, Provide a name for the new storage account, and verify its location.

The next thing that you will have to specify is the type of storage account that you want to create. Since the goal is to back up your Hyper-V virtual machines to Blob storage, select the Blob Storage option. Finally, choose the type of replication that you want to use, and then click on the Review + Create button. The Azure portal will perform a quick validation test and will then display a summary of the options that you have chosen. Take a moment to review these options. Assuming that everything looks good, click the Create button to create the new storage account.

It may take a few minutes for the storage account to be created. When the creation process eventually completes, however, you can view the storage account by clicking on the Go to Resource button, shown in Figure 3. Figure 4 shows what the Storage Account overview screen looks like.

Figure 3

Click the Go to Resource button.

Figure 4

This is what the storage account overview screen looks like.

While you are on the storage account overview screen, click on the Access Keys tab, found in the Settings section. Upon doing so, you will see two keys listed, and the portal will also display a connection string for each key. Initially, these keys and their corresponding keys will be hidden, as shown in Figure 5. However, you can reveal them by clicking on the Show Keys button. Once the keys have been revealed, be sure to copy one of the connection strings to the clipboard, because you will need it when you configure Altaro VM Backup to use Azure storage.

Figure 5

Click the Show Keys button to reveal the keys and their connection strings.

Example of using Altaro VM Backup to Push Backups to Azure

Recover to a Nested Hyper-V Instance inside of Azure

One of the advantages of performing a backup to Azure storage is that the backup resides in the cloud, and can therefore be easily recovered to the cloud. This can be an especially effective disaster recovery technique given that Microsoft now supports nested Hyper-V in Azure. Azure’s nested Hyper-V capabilities allow administrators to deploy Hyper-V inside of an Azure virtual machine, thereby allowing Hyper-V virtual machines to run in the cloud. Having this capability means that it is possible to restore your VM backups a cloud-based Hyper-V server, and to run the newly recovered virtual machine in the Azure cloud, either temporarily or permanently.

In order to be able to perform this type of recovery, there are three things that you will need to do:

• You will have to create an appropriately sized Azure virtual machine, enable nested virtualization within that VM, and then install Hyper-V.
• You will need to create an Azure gateway (if you do not already have one). The Azure gateway’s purpose is to enable seamless communications between resources residing on-premises and resources that exist within the Azure cloud.
• You are going to need to install the Altaro Hyper-V Host Agent onto the Azure-based Hyper-V server. This will allow Altaro VM Backup to interact with the Azure-based Hyper-V server in the same way as if it were running on-premises.

When properly configured, restoring a VM to an Azure-based Hyper-V server is done in essentially the same manner as restoring a VM to an on-premises Hyper-V server, simply follow the documented process here

The most obvious use case for restoring a VM to a cloud-based Hyper-V server is disaster recovery. If you experience a datacenter level disaster (or even something as simple as a catastrophic hardware failure on one of your Hyper-V hosts), then restoring to the cloud gives you an easy way to bring the affected workloads back online.

As important as it may be to have disaster recovery capabilities, disaster recovery is not the only use case for recovering a VM to a cloud-based Hyper-V server. You could conceivably use this same basic technique as a way of migrating Hyper-V virtual machines to the cloud.

Starting with version 7.0 and newer, Altaro VM Backup supports backing up your virtual machines to the Azure cloud. Although Altaro has technically allowed backups to Azure for quite some time, an Azure-based VM was previously required. Now, it is possible to back your virtual machines up directly to Azure Blob storage.

Do you see this option being useful? Any questions or roadblocks you see? Let us know in the comments section below!

The post How to Backup and Restore VMs to and from Azure Blob Storage appeared first on Altaro DOJO | Backup & DR.

One of the most important decisions you will make when planning your backup strategy is whether to use full, differential, or incremental backups to protect your data.

While there are numerous variations of these, such as synthetic full, reverse incremental, and incremental forever, they are still based on these three core types.  At a high level, a full backup takes a complete copy of the data, making it easy to restore, but this option consumes a lot of storage capacity.  An incremental backup first takes a full backup, then it tracks and stores only the changes since the last backup, and then again since that last backup.

Incremental backups use much less storage capacity since they are not copying duplicate data but can take a long time to restore since the “chain” of backup files must be merged together.  A differential backup also takes a full backup first, and then it tracks the changes since the last full backup.  This uses more storage than an incremental backup as any data since the last full backup is saved. Still, it is faster to recover since it must only merge two backup files, the full backup, and the most recent differential backup.  This article will go into depth to help you understand the use cases and best practices for each.

The following table provides a summary of the tradeoffs between the three main backup types.

As you can see from this table, the full backup is the easiest, yet you will need to optimize your storage capacity and network management.  The incremental backup is the slowest to recover, so you’ll need to optimize your processing power and network transfer speed during recovery.  The differential backup offers a balance between the other options.  For a thorough understanding of how backup works in an enterprise, check out Altaro’s blog on an introduction of backup and recovery.

General Backup Best Practices

For all types of backup, make sure you consider a follow these best practices:

• Make Copies of your backups in Multiple Locations – Keeping your backup files on the local server provides the benefit of a faster recovery, especially if the backup files are large. However, you should still copy your backups to shared storage (SAN) within your datacenter and also to a secondary site (or public cloud storage) through a secure connection.  This provides you with resilience if your server crashes and a disaster recovery option in the event that you have a datacenter outage.  While the data transmission to cloud storage may be slow, and you will pay for the network bandwidth and storage, it will ensure that your business can survive a major outage.  Some backup providers provide built-in tools to support copying backup files to multiple locations, which is known as duplication.
• Test Recovery on Different Hardware and Sites – Make sure you are considering the scenario where you are unable to restore a backup to the same server because the physical hardware is no longer available. Be sure that you have tested recovery to the same server, a different server, and even a server in a different datacenter to ensure that you are minimizing your downtime and maximizing your chances to recover your data successfully.
• Delete Old Backup Files – Delete files that you no longer need to free up storage capacity and reduce the security risk from data loss if your datacenter is compromised. If you operate in a regulated industry, you may be required to delete old backup after the retention period expires.  This best practice is applicable to all backup types and is often called data grooming.
• Use Solid State Drives (SSDs) – SSDs provide faster read and write speeds than traditional disks as there are no mechanical parts. If you are having trouble completing your backup during the backup window, then writing to faster media will help.  More importantly, SSDs provide a quicker recovery time as the data can be read from them much faster.
• Prioritize Backup Network Traffic / Quality of Service (QoS) – If your physical or virtual hardware supports network traffic prioritization, consider using this for your recovery traffic. You can often assign the outbound backup traffic from a server as a lower priority so that it does not interfere with production data (assuming that you can complete your backups within your backup window) and assign inbound recovery traffic as the highest priority.
• Use Compression – A majority of backup providers will include built-in compression tools so that the backup files take up less space on the disk. However, the tradeoff is that compression slows down the backup process, and decompression will slow down recovery.
• Use Encryption– Since backup files will often contain sensitive information, many organizations will want to protect them with encryption automatically. This is particularly important if those backup files are stored in a remote location or transmitted across public networks.  Be aware that this slows down the backup process, and decryption will slow down recovery.
• Use Deduplication– This feature may be offered by your backup provider, operating system, or storage vendor. It will scan your backups and detect identical files or blocks of data, and only retain one copy, removing the duplicate files.  This process can save a significant amount of storage space since many backup files contain identical and redundant content.  This will add more time to the recovery process if a deduplicated file needs to be merged with another file to recreate a full copy of the data.
• Use Item-Level Backup and Recovery – Instead of protecting and recovering an entire database, some backup ISVs will provide more granular options for specific workloads. For example, with Exchange Server, it is a common practice to offer the ability to recover a specific mailbox for a single user, rather than restoring the database with all mailboxes for all users.  This will make backup and recovery faster if only specific files need to be protected and restored.

Best Practices for Using Full Backup and Recovery

The most common type of backup is a full backup, where all the protected data is captured in its entirety in a single backup operation.  A full backup was the first type of backup created many decades ago when data was still stored on tape drives, and it simply required copying the data to other tape drives.  Since tape data had to be read sequentially, it lacked the ability to randomly access data, which is now offered with today’s hard drives.  A full backup will happen will almost always happen as a fundamental step for other backup types, including incremental and differential.  Generally, the backup software will copy all the data files, but sometimes it will include metadata, user data, or other system settings to ensure that the backup can be restored to the same (or similar) state as to when it was captured.  With the explosive growth of data in modern businesses, using only full backups probably isn’t practical due to the high costs of processing and storing it. All storage provides such as Altaro will support full backups.

Taking a full backup performs the following steps:

• The backup is requested by a user, program, or automatically on a schedule.
• The backup software will identify the type of component which needs to be protected. The disk, application, or database is usually selected by the administrator, and the backup software will determine if it must also protect any associated files.
• The backup software will wait for the component to be in a healthy state so that a complete backup can be created. This may involve pausing the component, flushing any transactions which are in memory (“quiescing”), or closing a file.  It is important that the file is in a “consistent” state so that it is healthy when it is restored.  Additionally, any other data in which the file needs will be captured, which could include metadata, system settings, boot settings, and the disk layout.
• The backup is taken.
• The backup files are stored in a designated location.
• The backup software is notified that the backup was completed successfully.

Restoring a full backup is fairly straightforward and quick and involves the following steps:

• The need for recovery is detected by a user or automatically.
• Through the backup software, the most recent (or appropriate) backup file is selected.
• The destination server or computer for the backup file is selected. The backup file will be copied here if the data is not local.
• The backup software will copy the backup file to the destination server.
• The backup will be applied, which includes restoring the data and could also include metadata, system settings, boot settings, and disk layout.
• The backup software is notified that the recovery was completed successfully.

Advantages of Using Full Backups

This section provides a list of benefits when taking a full backup.

• Reliability and Stability – Creating a full backup is straightforward, and it is stored as a single file, making it easier to manage. It is the most reliable and stable type of backup as it has the fewest components.
• Fastest Recovery Speed – Since the full backup uses only a single complete backup file, it is quickest and easiest to restore and uses the least processing power.
• Ease of Use – As the most common type of backup, it is easy to use and understand. If you are working with inexperienced users who need to manage their own backups (and recovery), then this may be the best option.  Version control is simple because it can be determined by using the timestamped on the backup file, and there is only one type of backup file.
• Recommended for Major Upgrades – If you are making a significant software or hardware change, such as updating an operating system, then always take a full backup so that you can restore to a healthy point if you need to roll back the changes.
• Ease of Replicating Backups – Since a full backup contains a single file, it is very each to copy or replicate this backup file to other locations, such as a secondary site or onto an archival tape drive.

The Disadvantage of Using Full Backups

This section provides a list of challenges to consider when taking a full backup.

• Uses More Storage Capacity – Each time you take a full backup, all of the data is captured and stored. This means that if you are taking multiple full backups at a high frequency, you could expend your storage quota quickly.  You are also likely backing up redundant copies of identical data. Make sure you are taking advantage of storage optimization techniques by using compression and deduplication.
• Uses More Network Bandwidth – Each time you create a backup, the data should be copied to a SAN or secondary site, so you must be transferred a large file through your network. Larger files mean that more data must be transmitted, so more network bandwidth is being used.
• Longer Backup Time – The duration to take a full backup is longer than other methods. This means that during this period, the computer will be allocated more computing power to the backup process, so other operations may be slower.
• Increased Need for File Security – If a full backup file is stolen, a thief can have access to the entire database. Make sure that you always encrypt your backup files.

Other Best Practices when Using Full Backups

The large size of the backup files will be your biggest challenge when using full backups, so take advantage of the storage capacity and network bandwidth optimizations mentioned earlier. Since full backups will be part of your backup strategy even if you are also using incremental or differential backups, be sure to also follow these best practices:

• Run Full Backups during Off-Hours – Backups take up a lot of processing power on your servers, and transferring the backup files over the network can consume bandwidth. Do this during off-hours to minimize the disruption of your production systems.
• Understand your Backup Windows – Make sure you know how long a full backup takes in case you need to trigger it in an emergency. For example, if you usually backup over the weekend during extended off-hours, it is important to know if it is even possible for you to take a midweek backup during a shorter backup window.

Best Practices for Using Incremental Backup and Recovery

An incremental backup will protect the data which has changed since a previous backup was taken, removing the need to take full backups each time.  This method still requires an initial full backup, but each subsequent backup is faster and uses less storage space as it only changes since the last backup is tracked and saved.  Many organizations will use the extended off-hours over the weekend to take the full backup and then take incremental backups every night.  Most leading storage provides likeAltaro will support incremental backups.

An incremental backup performs the following steps:

• The backup is requested by a user, program, or automatically on a schedule.
• The backup software will identify the type of component which needs to be protected. The disk, application, or database is usually selected by the administrator, and the backup software will know if it must also protect any associated files.
• The backup software will wait for the component to be in a healthy state so that a complete backup can be created. This may involve pausing the component, flushing any transactions which are in memory (“quiescing”), or closing a file.  It is important that the file is in a “consistent” state so that it is healthy when it is restored.  Additionally, any other data in which the file needs will be captured, which could include metadata, system settings, boot settings, and the disk layout.
• If a full backup has not been taken, then take a full backup and save the backup file using the steps above. If a full backup has been taken, then only changes since the last incremental backup will be saved in an incremental backup file.
• The full backup (if needed) and the incremental backup file is stored in a designated location.
• The backup software is notified that the backup was complete successfully.

The main downside is that when incremental backups are restored, they are much slower because each backup file must be sequentially merged together as they are structured like a “chain” of backup files.

Restoring an incremental backup involves the following steps:

• The need for recovery is detected by a user or automatically.
• Through the backup software, the most recent (or appropriate) backup file is selected. The user will usually just select the most recent timestamp, and they should not need to think about the underlying backup files.
• The destination server or computer for the backup file is selected. The backup files will be copied here if the data is not local.
• The backup software will merge all of the incremental files with the full backup file. This may happen on a dedicated backup server or on the destination server, depending on your backup software.
• The backup will be applied, which includes restoring the data and could also include metadata, system settings, boot settings, and disk layout.
• The backup software is notified that the recovery was completed successfully.

Advantages of Using Incremental Backups

This section provides a list of the main benefits of using incremental backups compared to full backups.

• Uses Less Storage Capacity – After you’ve taken the full backup, each time you take an incremental backup, only the data since the last change is captured and stored. This is the most storage efficient option of the three main backup types.
• Uses Less Network Bandwidth – After you’ve taken the full backup, each time you take an incremental backup, you must only transfer the backup file with the changed data from your servers through your network, so less network bandwidth is needed compared with the other backup types.
• Short Backup Time – After you’ve taken the full backup, each subsequent backup should be quicker as less data needs to be protected. This means that the server will be allocating less compute resources towards creating the backup.  If an application needs to be temporarily paused (quiesced), this period should also be shorter.

The disadvantage of Using Incremental Backups

This section provides a list of challenges to consider when using incremental backups compared to full backups.

• Slower Recovery Speed – The recovery of an incremental backup requires merging two or more files. The time to complete the recovery takes longer than other options. If you are merging many incremental backup files, this process could take significant time.
• Complexity of Use – Since an incremental backup requires managing multiple backup files and possibly different backup file types, it can be challenging for inexperienced users. Backup software will try to hide this complexity, but troubleshooting incremental backups can be hard.  Version control is much harder when there are multiple files with different timestamps.
• Greater Risk of Corruption – Incremental backups are restored by merging a “chain” of backup files together. However, if one of those files becomes corrupt or gets deleted, any backup files which were created after this point cannot be used.
• Complexity of Replicating Backups – Since incremental backups contain multiple files, it is more complex to copy or replicate these backup files to other locations, such as a secondary site or onto an archival tape drive. However, since each of the replicated files is smaller, the replication time should be quicker.

Other Best Practices when Using Incremental Backups

Recovery time will be your biggest challenge when using incremental backups, so use faster storage such as SSDs, assign extra processing power to the backup server, and prioritize network traffic.  If you decide that using incremental backups should be part of your backup strategy, then consider these best practices to follow:

• Maximize Processing Power of the Recovery Server – During recovery, incremental backups need to merge files, sometimes dozens of them. This is a compute-intensive process and takes time, which slows down the recovery.  Prioritize the backed processes for the server, which is merging these files to get a faster recovery time.
• Use a Combination of Backup Strategies – Since an incremental backup will always require a full backup, consider a hybrid strategy when you will schedule both types. Because the initial full backup may take significant time to complete, companies will often execute the full backup over a weekend, then set up incremental backups throughout the week.
• Use Different Incremental Backup Levels – Different backup providers will offer different levels of granularity. Essentially this is the smallest unit that they will backup when changed.  These can include:
  • File-Level – If any file within the backup set is changed, only that file will be incrementally backed up. This works well with small files, like office documents, but is less efficient with large files like databases.
  • Block-Level – The filesystem on a disk contains many fixed-sized blocks of data. A single file may contain multiple blocks of data.  If any of these blocks are changed, then only that part of the disk is incrementally backed up.  This is generally faster and uses less storage than backing up entire files since the blocks are smaller than files.  The main limitation is whether the backup provider supports block-level management through your filesystem and SAN.
  • Byte-Level – For an even more granular backup option, byte-level will track individual bytes of data that have changed. This results in the smallest incremental backups, which are easy to store and transmit.  This can, however, create excess processing overhead in the backup server, and not every backup provider will support it.
• Use Incremental Backup Variations – There are some more advanced backup types to consider. However, availability will vary by backup provider. The most common include:
  • Incremental Forever Backup – This option may be useful for organizations using only disks as storage media as it will not work with sequential tape drives. The backup software will only take one full backup, and then it will only take incremental backups, never taking a full backup again.  Since the data can be randomly accessed on the disk, it will also get regularly rearranged to optimize read speed.
  • Reverse Incremental Backup – If you use this variation, you will start with a full backup, then take regular incremental backups. Each incremental backup will be merged with the most recent full backup to create a new full backup.  This method lets you recover faster by always having a recent full backup available but saves on storage by not having multiple full backups.
  • Synthetic Full Backup – This variation will essentially take the full backup and any subsequent incremental backups and logically merge them, so they behave like full backups. The files are not actually merged, but the backup software is able to let users manage them like they are a single file. This is popular for organizations that have so much data that it is not realistic to take a full backup during off-hours or businesses that are always online.

Best Practices for Using Differential Backups and Recovery

Differential and incremental backups are similar since they require taking a full backup then taking smaller subsequent backups.  The main difference is that with a differential backup, each of the additional backups tracks every change since the full backup, whereas the incremental backup tracks the changes since the last incremental backup.  Most storage provides such as Altaro will support differential backups.

A differential backup performs the following steps:

• The backup is requested by a user, program, or automatically on a schedule.
• The backup software will identify the type of component which needs to be protected. The disk, application, or database is usually selected by the administrator, and the backup software will know if it must also protect any associated files.
• The backup software will wait for the component to be in a healthy state so that a complete backup can be created. This may involve pausing the component, flushing any transactions which are in memory (“quiescing”), or closing a file.  It is important that the file is in a “consistent” state so that it is healthy when it is restored.  Additionally, any other data in which the file needs will be captured, which could include metadata, system settings, boot settings, and the disk layout.
• If a full backup has not been taken, then take a full backup and save the backup file using the steps above. If a full backup has been taken, then only changes since the last full backup will be saved in a differential backup file.
• The full backup (if needed) and the differential backup file is stored in a designated location.
• The backup software is notified that the backup was complete successfully.

Differential backups can be restored quicker than incremental backups because only two backup files must be merged together.

Restoring a differential backup involves the following steps:

• The need for recovery is detected by a user or automatically.
• Through the backup software, the most recent (or appropriate) backup file is selected. The user will usually just select the most recent time; they should not need to think about the underlying backup files.
• The destination server or computer for the backup file is selected. The backup files will be copied here if the data is not local.
• The backup software will merge the selected differential file with the full backup file (1 merge between 2 files). This may happen on a dedicated backup server or on the destination server, depending on your backup software.
• The backup will be applied, which includes restoring the data and could also include metadata, system settings, boot settings, and disk layout.
• The backup software is notified that the recovery was completed successfully.

Advantages of Using Differential Backups

This section provides a list of the main benefits of using differential backups compared to full backups.

• Uses a Less Storage Capacity– After you’ve taken the full backup, each time you take a differential backup, all the data since that last full backup is captured and stored. This is more efficient than taking a full backup each time, but it will use more storage than incremental backups.
• Uses Less Network Bandwidth– After you’ve taken the full backup, each time you take a differential backup, you will transfer the changes from that last backup from your servers through your network, so less network bandwidth is needed than with using only full backups. It will use more network bandwidth than incremental backups since the files are still larger.
• Shorter Backup Time– After you’ve taken the full backup, each subsequent backup should be quicker as less data needs to be protected. This means that during this period, the computer will be allocating fewer resources creating the backup.  If an application needs to be temporarily paused (quiesced), this period should also be shorter.

The disadvantage of Using Differential Backups

This section provides a list of challenges to consider when using differential backups compared to full backups.

• Slower Recovery Speed– The recovery of a differential backup requires merging two files. The time to complete the recovery takes longer than a full backup. It is usually faster than an incremental backup, which may require merging numerous files.
• More Complex– Since a differential backup requires managing two backup files and possibly two file types, it can be challenging for inexperienced users than full backups. Backup software will try to hide this complexity, but troubleshooting differential backups can be challenging.  Version control is much harder when there are multiple files with different timestamps.
• Harder to Replicate– Since differential backups contain multiple files, it is more complex to copy or replicate these backup files to other locations, such as a secondary site or onto an archival tape drive. However, since each of the replicated files is smaller, the replication time should be quicker.

Other Best Practices when Using Differential Backups

Differential backups give you a balance between the speed of full backups and storage optimizations of incremental backups, and the best practices for each can still be applied to differential backups.  If you decide that using differential backups should be part of your backup strategy, then consider these best practices to follow:

• Use a Combination of Backup Strategies – Since a differential backup will always require a full backup, consider a hybrid strategy when you will schedule both types. Because the initial full backup may take significant time to complete, companies will often execute the full backup over a weekend, then set up differential backups throughout the week.
• Understand your Backup Windows – The file size of each differential backup will grow larger and larger with time, as more data has changed since the initial full backup was created. This means that the time the backup takes will take longer too.  If you have a strategy to run the full backup over the weekend, and differential backups each weekday, keep in mind that towards the end of the week, the backup time will take longer, so make sure that it does not exceed your backup window.

You should now have a good understanding of Full, Differential, and Incremental backups, their benefits, and their tradeoffs.  If you have any questions about these best practices or have any of your own to add, please post a comment down below!

The post Best Practices for Full, Differential and Incremental Backup appeared first on Altaro DOJO | Backup & DR.

Most applications have specific backup needs that should be optimized to make protection and recovery as fast and successful as possible.  Inexperienced administrators often wrongly assume that by simply copying data from an entire volume or virtual machine that their backup will be application-consistent, or safe to use.  If the application is restored in an inconsistent state, the database may not function correctly as its data could be corrupted. Understanding the processes which are triggered when a backup is requested helps administrators make the best decisions for how to protect their workloads.  To create a consistent SQL backup, a series of tasks will be triggered to complete any open transactions, temporarily pause any new write requests, and flush any buffers or caches.

Windows Server users can request that their backups are consistent by using the Volume Shadow Copy Service (VSS) framework.  When a backup for an application is requested VSS will trigger the tasks needed to make the backup application-consistent.  Windows Server does include a basic backup utility (Windows Server Backup) and several applications include a built-in backup process (SQL Server Maintenance Plan), but large organizations will likely need to use an enterprise backup provider that supports VSS.  Enterprises may need to back up their databases differently based on different compliance requirements, corporate policies, schedules, recovery time objectives, and recovery point objectives, to separate the application’s data from the VM it is running inside, protect a subset of databases, set different offsite replication schedules and more. Instead of focusing on Volume Shadow Copy as a whole, this blog post will explain the importance of using application-consistent backups for enterprise Microsoft applications such as Active Directory, Hyper-V, SQL, and Exchange.

A Brief History of Backup Consistency

Early backup tools could only take a snapshot of a single file that worked fine for isolated services or end-user applications as there were no dependencies on other files.  This did not work for distributed applications using multiple files as the workload could be left in an inconsistent state if the data across their files were at different points in time.

The next generation of backup tools offered “crash-consistent” backups, which meant that any linked files would be backed up simultaneously.  This ensured that all the files were at the same point in time when they were protected which created a backup that could recover from a crash and function correctly.  However, there could still be some data loss if other types of transactions were in flight over the network or stored in a cache that had not yet written the data to a disk.

Most enterprises require “application-consistent” backups to ensure that all the data for a specific service is protected and recoverable.  This means that the backup provider will pause all new requests (quiesce the file system) and flush every cache or buffer which the application is using to ensure that all data is captured.  Many applications have unique requirements and will provide VSS or its backup requestor with a customized file to trigger each of the tasks needed for an “application-consistent” backup.

Volume Shadow Copy Service (VSS)

Microsoft’s backup framework, VSS, is used by its own applications (Active Directory, Hyper-V, SQL, and Exchange, etc.) as well as third-party ISVs that develop software that runs on Windows Server.  VSS is described in detail in this Altaro blog about Understanding Application Backups with Volume Shadow Copy Service (VSS).  Windows Server includes 34 built-in VSS writers for application-consistent backups.  For any backup provider that your organization is considering, make sure that they support VSS with application-consistent backup for each of your line-of-business workloads.  As one of the industry leaders in protection, Altaro Software supports …

Application-Consistent Backups with Active Directory

Consistency is important for the Active Directory (AD) database because identity management and security are critical for all organizations. With each component of AD, full backups are always recommended since so many problems that can arise from inconsistent database recoveries, including the disappearance of new users, password not being updated, and stale security policies.  Make sure that you use the built-in VSS writer for Active Directory and pay attention to Microsoft’s recommendations for how to handle Active Directory Tombstones after a restore.  For security reasons, it is a good best practice to encrypt the backup file for AD.  There are in-box VSS writers for Active Directory Domain Services (NTDS) VSS Writer, Active Directory Federation Services Writer, Active Directory Lightweight Directory Services (LDS) VSS Writer, and Active Directory Rights Management Services (AD RMS) Writer.

Application-Consistent Backups with SQL Server

Application-consistent backups are important for your writable databases so make sure that you are using a VSS writer with SQL Server.  If an inconsistent backup is created, then during recovery it may have an error, be inaccessible, have corrupt data, or otherwise be unusable.  To increase the disk access speed, SQL Server will usually not write directly to the disk, but use write-optimized log files which cache the writes and flush them at different times so this gets purged during a VSS-induced backup.  Additionally, the Database Engine locks the data file, so part of the VSS process will permit the SQL Writer Services to access and copy the data files while SQL is still running.  Whether you are using the built-in SQL Server Maintenance Plan or a third-party backup provider, make sure that it supports VSS.  Some additional recommendations are given by Microsoft for the SQL Writer Service.

Application-Consistent Backups with Exchange Server

Exchange Server has similar considerations to SQL Server since the application does not write directly to its database, but instead uses logs.  This provides crash-consistency, ensuring that the database does not become corrupt if the service is unexpectedly shut down. However, any data in the log files or caches which has not been written to the main database will be lost.  An inconsistent Exchange Server can result in lost messages, meetings, security policies, or contacts. Exchange Server also has built-in backup utilities which should also be evaluated when a backup plan is created.  There are many design considerations that may vary depending on the Exchange version and configuration, so it is strongly recommended to learn more about Exchange backups, restore and disaster recovery directly from Microsoft.

Application-Consistent Backups with Hyper-V

Virtual Machines (VMs) should always use application-consistent backups, or they may become corrupted and not be able to restart after an unplanned shutdown.  When Hyper-V triggers an application-consistent backup, called a “Saved State”, all of the transactions and data which are in transit or in memory are flushed to the disk.  This includes the data for both the VM and the virtualized application running inside the guest operating system.  If this guest application has its own VSS writer, then make sure that is installed so that it can participate in the backup process.  This backup is called a “Child VM Snapshot” which ensures that the data within the VM is also in an application-consistent state.  For additional details, check out Microsoft’s best practices for backing up and restoring VMs.

Alternatives to Application-Consistent Backups

Sometimes it may not be possible to request an application-consistent backup, such as when the software does not come with its own VSS writer, or if your organization has created its own distributed application.  The easiest solution is to run your application inside a Hyper-V virtual machine and call the VSS writer for Hyper-V.  This will always result in a backup that is at least crash-consistent, so it can be restored to a previous point in time where it is fully operational, however, data loss can occur.

If you need to take an application-consistent backup for a custom application, the easiest option is to temporarily shut the application down, then take the backup.  This can be done by creating a script that is called before the backup begins to gracefully shutdown the application and its dependent services which should quiesce the file system and flush any data that is inflight.  After the backup is successfully completed, a second script should be triggered to automatically restart the application in the appropriate startup order, then verify it is back online.

For organizations with developers, another alternative is to create their own VSS writer.  Microsoft has documented this process and the VSS APIs in detail, and it has been used by dozens of third-party enterprise ISVs.  No matter what application you are running, always make sure you understand the separate backup tasks which are happening.  This helps you ensure that the service is crash-consistent and application-consistent so that you can detect errors with your backup or recovery.

The post What are Application-Consistent Backups? appeared first on Altaro DOJO | Backup & DR.

For any enterprise application that you deploy on your Windows Server infrastructure, if data integrity and consistency are important, then one of the first things you need to verify is whether it supports backups using the Volume Shadow Copy Service (VSS).  Data consistency means that the information for the application or file is complete and not corrupted so that when it is restored from a backup, it works as expected.  For example, if you restore a Hyper-V virtual machine (VM), you want to make sure that it is not corrupted and runs normally, or else the backup effectively worthless.  Being able to take a backup of an application, rather than the entire disk, is also advantageous because it provides more flexibility when creating the backup, more granularity when restoring the application’s data, and it can save storage space.

This article will explain how VSS works with applications and some common tools used to manage the process.

Volume Shadow Copy Service (VSS) Components

The Volume Shadow Copy Service (VSS) is a set of Windows COM interfaces and commands that create complete backups while the target application continues to run.  Since enterprise applications need to continually serve customers and are rarely taken offline, they need to be backed up while they are online and still generating data.  This means that the data files are often large, remain open, and in an inconsistent state, while the data is constantly changing.  VSS provides coordination between the running enterprise application (such as a Hyper-V VM), backup application (such as Altaro VM Backup), the storage management software (such as Windows Server), and the storage hardware.  VSS is built into both Windows and Windows Server.

Volume Shadow Copy Service consists of the following components:

• VSS Service – The Windows Service which coordinates and communicates between the application and backup components.
• VSS Requester – This is the backup software that creates and manages the VSS copies. Windows Server Backup and System Center Data Protection Manager are commonly used in the Microsoft ecosystem, but almost every third-party backup solution for Windows also supports VSS, including Altaro VM Backup.
• VSS Provider – This is the component that creates and manages the shadow copies and can run in either the software on the operating system or in the hardware.
• VSS Writer – This application-specific component ensures that the data is consistent when it is backed up and is usually included with each enterprise application. As a best practice, make sure that your application includes a VSS writer as it typical with all Microsoft enterprise applications.

Due to the component/segmented feature nature of Windows, Windows Server includes the following 34 built-in VSS writers right out of the box:

• Active Directory Domain Services (NTDS) VSS Writer
• Active Directory Federation Services Writer
• Active Directory Lightweight Directory Services (LDS) VSS Writer
• Active Directory Rights Management Services (AD RMS) Writer
• Automated System Recovery (ASR) Writer
• Background Intelligent Transfer Service (BITS) Writer
• Certificate Authority Writer
• Cluster Service Writer
• Cluster Shared Volume (CSV) VSS Writer
• COM+ Class Registration Database Writer
• Data Deduplication Writer
• Distributed File System Replication (DFSR)
• Dynamic Host Configuration Protocol (DHCP) Writer
• File Replication Service (FRS)
• File Server Resource Manager (FSRM) Writer
• Hyper-V Writer
• IIS Configuration Writer
• IIS Metabase Writer
• Microsoft Message Queuing (MSMQ) Writer
• MSSearch Service Writer
• NPS VSS Writer
• Performance Counters Writer
• Registry Writer
• Remote Desktop Services (Terminal Services) Gateway VSS Writer
• Remote Desktop Services (Terminal Services) Licensing VSS Writer
• Shadow Copy Optimization Writer
• Sync Share Service Writer
• System Writer
• Task Scheduler Writer
• VSS Metadata Store Writer
• Windows Deployment Services (WDS) Writer
• Windows Internal Database (WID) Writer
• Windows Internet Name Service (WINS) Writer
• WMI Writer

As mentioned in the definition of VSS writer above, these writers allow the targeted applications/features to gracefully “pause” in such a way that allows the backup application to back up the associated configuration and data without bringing the application or service down. This could be a VM running on Hyper-V, an on-prem Exchange server, a SQL box, a domain controller running AD. Any constantly running service or application that you want to run backups against should have a supported VSS writer. Without a supported VSS writer for an application, the application will be backed up in whatever state it’s in at the time of backup.

For example, let’s say you have a MySQL Database. There currently is no supported VSS writer for MySQL. In this situation, let’s say you run a backup against it. All may seem fine on the surface, but there is a good chance that there were pending data writes in memory as the backup was happening. When you go to restore the database, the tables associated with that pending data will likely be wrong. Worst case, you could run into full-blown corruption of the MySQL database upon restoration, which is not a good time to be finding out about database corruption. The alternative in this situation, where you have no supported VSS Writer, is to use a scheduled task to gracefully stop the service in question prior to the backup and then start it again after the backup has been completed. This certainly isn’t an ideal scenario, but if you’re using an application with no supported VSS writer (they are few and far between anyway), your hands are somewhat tied.

Alternatively, if you run into this situation, it would be a good point in time to take a good hard look at the affected application and ask yourself if it can be replaced with something that has a supported VSS writer. In the long-term, a legacy application like this will not scale well for your organization and will continue to cause headache after headache.

System, Software, and Hardware Providers

Organizations can select from several options for the VSS provider, including the built-in system providers, a third-party software provider, or a hardware provider.  The system provider comes with Windows Server as Windows Server Backup using the volsnap.sys driver and swprv.dll library.  This provider is perfectly fine to use if you do not have any advanced backup utilities and only need basic functionality.

Third-party software-based providers have a richer feature set than the system provider and may have more backup options, such as defining the location where shadow copies are stored or the number of copies, and when restoring from backups, there may be options to restore specific files or items.

Hardware-based providers are recommended if they support VSS.  By running the backup process from the hardware, it offloads the resource-intensive operation backup task from the server operating system so that more processing cycles can be consumed by the application.

How Volume Shadow Copy Service (VSS) Works

In terms of a textbook description, it’s hard to beat Microsoft’s exhaustive documentation on this well-established service. So I suggest you read that if you want an ultra-comprehensive look into the inner workers of VSS. That said, if you want a quick overview that will cover 90% of situations, then read on!

When a backup is created using VSS, a series of actions are triggered to coordinate the snapshot across the service, provider, requester, and writer.

1. When a user creates a manual backup or a task triggers an automatic backup, the requester (backup application) asks VSS to prepare the system.
2. The writer gathers metadata about the application and data that needs to be backed up, how the application will be restored, and provides a list of application components that can be individually backed up.
3. Once the components are selected by the requester, the writer will prepare the data so it is in a consistent state and can be successfully restored.  This will usually include completing open transactions, temporarily pausing any new write requests, and flushing any buffers or caches.  Since the application is still running, it can still accept new read requests.
4. Once the application’s data is effectively “frozen,” the VSS service tells the provider to create the shadow copy, which can last up to a maximum of 10 seconds.
5. The backup is now complete.

NOTE: If the freeze takes longer than 60 seconds or the shadow copy commitment takes longer than 10 seconds, then the operation is aborted and will be retried later, ideally at a time when the application is processing less data so the operation can be completed faster.

Once the backup is complete or if the task has been aborted, then the application is unfrozen or “thawed.”  First, the VSS service will release then flush all the paused file system write requests, and the application returns to its normal disk writing behavior.  The VSS service then returns the file location back to the requestor so that it can be tracked and recovered in the event of a disaster.

Volume Shadow Copy (VSS) Tools

There are two free tools provided by Microsoft to help administrators manage their snapshots, VssAdminandDiskShadow.  Additionally, there are several registry settings that can be configured.

VssAdmin is a tool used to manage shadow copies and includes commands to create a shadow copy, delete a shadow copy to reclaim storage space, list all registered VSS providers, list all registered VSS writers, and change the size of the storage area.  However, this tool will only work with the built-in system provider, so if you are using a third-party provider, you would use that storage management utility.

DiskShadow is a VSS requester used to manage any software or hardware snapshots on Windows Server.  It lets admins perform a variety of tasks for shadow copies, including listing all writers, providers, and shadow copies, setting file data and metadata, loading metadata, listing writers, adding volumes, creating a shadow copy, starting a full backup, ending a full backup, starting a restore, ending a restore, simulating a restore, deleting a shadow copy, importing a shadow copy, and managing volume drive letters.

There are three registry settings that admins may also want to change using the Regedit utility.VssAccessControl is a security setting that defines which users have access to the shadow copies.  MaxShadowCopiesspecifies the maximum number of shared copies for shared folders, which can be stored on each volume of the computer.  MinDiffAreaFileSize defines the initial size of the shadow copy storage area.

By using Volume Shadow Copy tools, you can ensure that your running applications can be backed up successfully with data consistency.  For more information about the Volume Shadow Copy Service, check out Microsoft’s official documentation at https://docs.microsoft.com/en-us/windows/desktop/vss/volume-shadow-copy-service-portal.

The post Application Backups with Volume Shadow Copy Service (VSS) appeared first on Altaro DOJO | Backup & DR.