New parameter proposal @Tag

[nltgpeterskoglund]

Hi Ola,

first of all, thank you for your fantastic SQL Server Maintenance Solution – we use DatabaseBackup heavily and it has been rock solid for us.

I’d like to propose a small enhancement to dbo.DatabaseBackup to make it easier to organize and govern backups across many databases and environments.

New parameter proposal

Add a new optional parameter:

@tag nvarchar(50) = NULL

Behavior:

When @tag is NULL (default), DatabaseBackup should behave exactly as it does today.

When @tag is not NULL, only databases that have a database-level extended property with that tag value should be considered for backup.

One simple convention could be:

Extended property name: Tag

Extended property value: the string we pass in @tag

Example: only back up databases tagged with Tag = 'Critical'.

This would allow us to logically classify and group databases using Extended Properties, without having to maintain complex @databases lists in jobs or wrapper procedures.

Example usage

Tagging a database:

EXEC sys.sp_addextendedproperty
@name = N'Tag',
@value = N'Critical',
@level0type = N'DATABASE',
@level0name = N'MyImportantDatabase';

Running backups only for databases with that tag:

EXEC dbo.DatabaseBackup
@databases = 'USER_DATABASES',
@Directory = 'C:\Backup',
@BackupType = 'FULL',
@tag = 'Critical',
@verify = 'Y',
@compress = 'Y',
@Checksum = 'Y';

In this example, even though @databases = 'USER_DATABASES', only user databases that have the extended property Tag = 'Critical' would be backed up.

Possible implementation idea (pseudo-T-SQL)

When building the internal list of databases to back up, the procedure could apply an additional filter if @tag is specified, for example (simplified):

-- Existing list of selected databases into #Databases / @DatabasesSelected

IF @tag IS NOT NULL
BEGIN
;WITH TaggedDatabases AS (
SELECT
d.name
FROM sys.databases AS d
JOIN sys.extended_properties AS ep
ON ep.major_id = d.database_id
AND ep.minor_id = 0 -- database-level
AND ep.class = 0 -- database
AND ep.name = N'Tag'
AND CONVERT(nvarchar(50), ep.value) = @tag
)
-- Intersect the existing selection with TaggedDatabases
SELECT ...
END

(Exact implementation details would of course follow your existing style and internal temporary tables.)

Why this is useful

Tags are an important part of managing, organizing, and governing SQL backups, especially when:

An instance hosts many databases owned by different teams / applications.

We want to align backups with data classification, RPO/RTO tiers, or regulatory rules.

We want to move certain groups of databases to specific backup schedules or storage targets (e.g. cloud, cheaper storage, longer retention, etc.).

With a @tag parameter:

We can keep the core logic in your procedure.

We avoid having to duplicate large @databases lists across multiple Agent jobs.

We can control inclusion/exclusion simply by setting or changing a database extended property.

Thank you for considering this feature – and again, thanks for all your work on the maintenance solution.

Best regards, Peter Skoglund