Skip to content

Conversation

andreasjordan
Copy link
Contributor

Not the best solution, but it should work for now.

We need a new lab to test all the Copy- commands (and all commands related to AGs and Mirrring) with 4 maschines: 2 with the source and targe SQL Server instance, one from where we run dbatools and one with the fileshare. We then might find some more bugs...


# The exported files are only readable by the source instance account
# But for the restore they need to be readable by the targe instance account
# Current solution is to try to make them readable to everyone and remove them after the restore
Copy link
Contributor

@niphlod niphlod Sep 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't the whole premise to use a share that has certs in there useful for disaster recovery scenario ? the deletion in here changes decisevely, as "before" it was just in case of errors (catch), while now it's in each and every case (finally)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only newly created cert files that where created by the backup part are deleted. If there are cert files present, then $usingtempfiles is true and the files are not deleted. In our tests we don't have files there so we can only test the Copy- (backup + restore) path.

@potatoqualitee potatoqualitee merged commit d51e543 into development Sep 6, 2025
4 checks passed
@potatoqualitee potatoqualitee deleted the fix_Backup-DbaDbCertificate branch September 6, 2025 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants