A new version of dbatools Restore-DbaDatabase command was released into the wild this week. One of the main aims of this release was to make it easier to debug failures in the restore process, and to drag information out of the pipeline easily (and anonymously) so we can increase our Pestering of the module with Unit and Integration tests.
So I’d like to share some of the features I’ve put in so you can take part.
The biggest change is that Restore-DbaDatabase is now a wrapper around 5 public functions. The 5 functions are:
These can be used individually for advanced restore scenarios, I’ll go through some examples in a later post.
For now it’s enough to know that Restore-DbaDatabase is a wrapper around this pipeline:
Get-DbabackupInformation |Select-DbabackupInformation | Format-DbabackupInformation | Test-DbabackupInformation | Invoke-DbaAdvancedRestore
and it’s other function is passing parameters into these sub functions as needed.
With version of
Restore-DbaDatabase you were restricted to throwing data into one end, and seeing what came out of the other end, with some insight produced by Verbose messages. Now things can be stepped through, data extracted as need, and in a format that plugs straight into out testing functions.
This is the function that gets all of the information about backup files. It scans the given paths, and uses Read-DbaBackupHeader to extract the information from them. This is stored in a dbatools BackupHistory object (this is the same as the output from Get-DbaBackupHistory, so we are standardising on a format for Backup information to be passed between functions).
So this would be a good place to check that you’ve gotten the files you think you should have, and is also the first place we’d be looking if you had a report of a break in the LSN chain
To get the output from the pipeline at this point we use the GetBackupInformation parameter:
Restore-DbaDatabase - -GetBackupInformation gbi
This will create a globally scoped variable
$gbi containing the ouput from
Get-DbaBackupHistory. Note, that when passing the name to
Restore-DbaDatabase you do not need to specify the
If you want to stop execution at this point, then use the
-StopAfterGetBackupInformation switch. This will stop
Restore-DbaDatabase from going any further.
This is also a good way of saving time on future runs, as the BackupHistory object can be passed straight in, saving the overhead of reading all the file heasers again:
$gbi | Restore-DbaDatabase [Usual Parameters] -TrustDbBackupHistory
Here we filter down the output from Get-DbaBackupInformation to restore to the point in time requested, or the latest point we can. This means we find :
– the last full backup before the point in time
– the latest differential between the full backup and the point in time
– and then all transaction log backups to get us to the requested time
This is done for every database found in the BackupHistory object
Here is where we’d begin looking for issues if you had a ‘good’ LSN chain from Get-DbaBackupInformation and then it broke.
To get this data you use the
SelectBackupInformation parameter, passing in the name of the variable you want to store the data in (without the
$ as per
There is also a corresponsing
StopAfterSelectBackupInformation switch to halt processing at this point. We stop processing at the first stop in the pipeline, so specifying multiple
StopAfter* switches won’t have an effect
This function performs the transforms on the BackupHistory object per the parameters pushed in. This includes renaming databases, and file moves and rename. For everything we touch we add an extra property of
Orignal to the BackupHistory object. For example the original name of the database will be in
OriginalDatabase, and the target name will be in
So this is a good spot to test why transforms aren’t working as expected.
To get data out at this pipeline stage use the
FormatBackupInformation paramter with a variable name. And as normal it has an accompanying
StopAfterFormatBackupInformation switch to halt things there
Before passing the BackupHistory object off to be restored we do some checks to make sure everything is OK. The following checks are made:
- LSN chain complete
- Does a destination file exist, if owned by a different database then fail
- Does a destination file exist, if owned by the database being restored is
- Can SQL Server see and write to all the destination folders
- Can SQL Server create any destination folders missing
- Can SQL Server see all the backup files
If a database passes all these checks then it’s backup history is marked as restorable by the
IsVerified property being set
To get the data stream out at this point use the
General Errors with restores
Once we’re past these stages, then our error reporting is at the mercy of the SMO Restore class. This doesn’t always provide an obvious cause straight away. Usually the main error can be found with:
$error | Select-Object *
As usually the dbatools terminating error will be in
Providing the information for testing or debugging.
If you’re running in to problems then the dbatools team may ask you to provide the output from one of these stages so we can debug it, or incorporate the information into our tests.
Of course you won’t want to share confidential information with us, so we would recommend anonymising your data. My normal way of doing this is to use these 2 stubbing functions:
So if we’ve asked for the Select-DbaBackupInformation the process would be:
Restore-DbaDatabase -[Normal parameters] -SelectBackupInfomation sbi -StopAfterSelectBackupInformation Filter-DbaToolsHelpRequest $sbi $sbi | Export-CliXml -Depth -Path c:\some\path\file.xml
And then upload the resulting xml file.
This method will anonymise the values in ComputerName, InstanceName, SqlInstance, Database, UserName, Path, FullName, FileList, OriginalDatabase, OriginalFileList, OriginalFullName and ReplaceDatabaseName. But will produce the same output for the same input, so we can work with multiple database sets at once.