Preparing BMR Backups

Bacula Enterprise Only

This solution is only available for Bacula Enterprise. For subscription inquiries, please reach out to sales@baculasystems.com.

Preparing Bacula Installation

Now it is time to configure your Bacula installation to add the WindowsBMR services. We will not discuss the details of normal configuration of Bacula here because we assume that your Bacula Enterprise is already installed and configured.

The BMR procedures require you to add some resources to the Director’s configuration. The required additions can be grouped into several categories. You may freely choose Passwords and names for File Sets, and Clients etc.

WindowsBMR Plugin for Windows Clients

As noted, in versions later than 6.2.6 or 6.4.2, Bacula Enterprise includes the WindowsBMR plugin with the main installer bacula-enterprise-win32-x.x.x.exe or bacula-enterprise-win64-x.x.x.exe.

A BMR Enabled Client Job

Below is typical Job resource for a BMR-enabled backup:

Job {
  Name = "WinBMR-job"
  JobDefs = "DefaultJob"
  Level = Incremental
  Client = your-windows-fd
  File Set = "WinBMR-set"
}

For those users who have used a WindowsBMR prior to version 3.0, please be aware that the new WindowsBMR version 3 is packaged as a plugin and does not need or use the Client Run Before Job setting in the Job resource as it was the case with previous versions.

File Set Considerations

The second part of setting up your WindowsBMR job is to include the WindowsBMR plugin in your Fileset resource.

Since BEE version 16.0.9, it is recommended to use the new version=2 option, see below. You don’t need to upgrade your old Fileset, it will continue to work as before.

The File Sets used to back up Windows systems for BMR purposes must contain the Plugin = winbmr line to enable the WindowsBMR plugin. When option version=2 is not used, the plugin searches for and includes all drive letters automatically.

It is important for the backup to include all the files that are required by the system. A common mistake is to exclude files based only on their file extension, as illustrated in:

WildFile = "*.ldf"

Instead, you should specify a full path to limit the exclusion to a directory:

WildFile = "D:/Data/*.ldf"

Although we do not recommend it, if you are careful, you may exclude some drives by using the Exclude subresource. However, take care to exclude only existing drives, because unused letters are assigned by WindowsBMR to “hidden” partitions during the time of the backup. If you exclude one of the letters used by WindowsBMR then the matching partition will not be backed up and the system will probably not boot at restore time.

Fileset {
  Name = "WinBMR-set"
  Enable VSS = yes # default, but make sure it's enabled!
  Include {
    Options { Signature = MD5 }
    Plugin = winbmr
    # Plugin = "winbmr:exclude=F,G"  # not recommended
  }
}

Above, we show an example of the “exclude” option. Be careful to use the exact same notation, the double quotes are important.

The new version=2 option has been designed to be used specifically in conjunction with the File=/ directive inside the Fileset.

When the option version=2 is used, the winbmr plugin will:

not modify the Fileset that will be used by the File Daemon. This is a major difference with the normal winbmr behavior. When the “version=2” option is not used, the normal winbmr behavior will add the system/recovery disk if there is any present in the system.
ignore any exclude=XXX option of the plugin as it cannot apply it to the Fileset because of the previous rule. You must use an exclude option block instead.
mount any system/recovery partitions (if not already mounted) before the beginning of the backup and dismount it after the end of the backup (if it was not mounted). This behavior doesn’t change.
If the directive File=/ is used, Bacula will include any system/recovery partition that is mounted at the time of the backup. Else, you must include it yourself usually using a File=T: directive in the Fileset. Be careful, the T: letter depends on the drive letters available when the plugin mounts the partition.
Copy the content of the EFI partition (if any) into “C:BaculawinbmrpartitionsEFI”. You must of course be sure that C: is backed up. File=/ always backs up C: (if it is not excluded). If that’s not the case, you have to add the File=”C:” directive to your Fileset yourself.

Remember that in a Windows Fileset, the “File=/” directive will back up all the drive letters. If OneFs=no is specified (in the last Option block because others are ignored), all the mount points below the selected drives will also be included and recursively. A drive or a mount point will be selected only if it is not listed in the Exclude block. VSS will only snapshot the volumes (drives or mount point) that have been selected.

A typical Fileset using this new option looks as follows:

Fileset {
      Name = "Winbmr2-Fileset"
      Enable VSS = yes
      Include {
             Options {
                    signature = MD5
                    compression = LZO
                    # Implicitly Include directories that are mount point for other Filesystems
                    OneFs = no
             }
             Options {
                # In this Option block, excludes files and directories
                    # that are not mount points or drives
                    Exclude = yes
                    OneFs = no # only the last one matter

        WildDir = "*/$Recycle.Bin"
        WildDir = "*/$RECYCLE.BIN"
        WildDir = "*/System Volume Information"
     }
     # use the new "version=2 " winbmr option with the File=/ directive
     Plugin = "winbmr: version=2"
     File = "/"
  }
  Exclude {
     # exclude mount points and drives here
     File="F:"
     File="C:/mount"
  }
}

This Fileset will also work well without the winbmr plugin line, of course you will lose the “BMR” feature, but the backup will be valid.

If for some reason you don’t want to use File=/, you can replace it with something like:

File = "C:" # always if you are doing a winbmr backup
File = "D:"
File = "T:" # if you have a system partition, you must include it manually and verify that the drive name match the one used by the winbmr plugin

And to answer a question that you have: If you have 3 volumes with mount points that are stacked on each other:

H:/ (volume1)
H:/mnt (volume2)
H:/mnt/submnt (volume3)

and a Fileset like this one:

Fileset {
  Name ="XXX"
  Enable VSS = yes
  Include {
    Options {
      Exclude = yes
      OneFs = no
    }
    File="H:"
  }
  Exclude {
    File="H:/mnt"
  }
}

it will back up the content of H:/ and H:/mnt/submnt but not goes into H:/mnt. It will create a snapshot for H:/ and H:/mnt/submnt but not for H:/mnt

Note that there was a bug in the winbmr plugin in version prior to 16.0.12 when using the “estimate” command. The system/recovery filesystem that have been mounted by the plugin were not dismounted. This doesn’t not disturb the next winbmr backups. Since version 16.0.12, “estimate” doesn’t mount any filesystem and doesn’t update the partition layout.

Restore Job Considerations

The Windows BMR restore process requires a restore Job resource without any RunScript directives. The user can select an appropriate Job from the list presented during the restore process (see figure SelectJob). The default Bacula configuration includes one Restore Job resource, which meets these requirements.