This PR fixes an issue introduced with a rewrite of the MSSQL logic.
The issue is caused by MSSQL having a concept of "default instance" vs "named instance". Logically, the "default instance" has a name, but it is presented differently throughout.
The code was updated to correctly handle "named instance", but this broke support for "default instance".
The paths look similar to this:
- Default instance: `%MSSQL%\Server\Database`
- Named instance: `%MSSQL%\Server\Instance\Database`
This is slightly problematic because given a path with three parts, you cannot know if it targets "default instance + database" or "named instance".
To account for this the code has been rewritten to explicitly keep track of which case we are in, and were there is ambiguity, both cases are tested. In the odd case where both match, this is treated as an error.
The filters were being applied slightly differently than the regular filters, by applying include, then exclude, and allowing include to add new elements.
This has been standardized so we now apply the filters the same way as for regular filters where "first match wins", and only source paths can introduce a new database.
Verified with both "default instance" and "named instance" on the same machine.
This fixes#6551
This fixes#6969
This PR introduces a filter that redacts paths in log messages that are sent outside the current machine. This reduces the possibility that sensitive information is accidentially reported to an external party.
For self-hosted solutions, the option `--allow-paths-in-log-messages=true` will skip the redaction step and report the original path.
This PR fixes a bug where a script could write a new filter, but the filter was never applied to the backup.
This also fixes an issue where the filter string was not available in scripts or emails, except on the initial call.
This PR updates the logic so the `run-script-after` and `run-script-post-backup` also have access to the filter string, if needed for reporting or other.
This fixes#5143
This PR adds a new `--run-script-post-backup` option that allows running a script after the main backup operation has completed, but before locking, compacting and verification is done.
The use for this is intended for cases where you want to stop or pause some service, run a backup, and then resume the service. Prior to this PR you would need to wait for the entire backup operation to complete, but with the new option you can resume as soon as the source data is no longer needed.
This is done by making the operation update class public so they can be accessed outside of the main library, and the progress updater is passed down from the controller.
This adds a new Template result format that uses Handlebars.Net for
flexible report customization. Users can now create fully customized
reports using Handlebars syntax, replacing the limited token-based
approach.
Features:
- New Template export format with Handlebars support
- Built-in templates: default, email, html, slack
- Custom template support via file path or inline content
- Helper functions for formatting: formatSize, formatDuration,
formatDate, eq, statusClass, eachProperty
- Full access to result data, log lines, and exceptions
Kenneth Skovhede