Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.databases.ms-sqlserver > #2275 > unrolled thread
| Started by | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| First post | 2026-01-22 17:21 +0300 |
| Last post | 2026-01-23 18:55 +0300 |
| Articles | 3 — 2 participants |
Back to article view | Back to comp.databases.ms-sqlserver
Backup to a network share Anton Shepelev <anton.txt@g{oogle}mail.com> - 2026-01-22 17:21 +0300
Re: Backup to a network share Erland Sommarskog <esquel@sommarskog.se> - 2026-01-22 23:06 +0100
Re: Backup to a network share Anton Shepelev <anton.txt@g{oogle}mail.com> - 2026-01-23 18:55 +0300
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2026-01-22 17:21 +0300 |
| Subject | Backup to a network share |
| Message-ID | <20260122172111.aa47435016e93d0e505cb230@g{oogle}mail.com> |
Hello, all (however few that may be). While setting up backup via maintenance plans, we have found that we cannot specify a Windows network directory as backup target, because the MSSQL service runs as the standard local user MSSQL$<instance> , which (naturally) has no access to it. Our administator suggests re-configuring it to run as domain-level user (with access to the requrired network share), or even use a two-stage backup, with a separate step of moving the backup files from the local machine to the network. The only other way we know to make that share accessible to MSSQL is to give it permissions for /everyone/, which we should rather avoid. What are some best (or least tolearable) practices of backing up MSSQL to a network share on Windows? -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [next] | [standalone]
| From | Erland Sommarskog <esquel@sommarskog.se> |
|---|---|
| Date | 2026-01-22 23:06 +0100 |
| Message-ID | <XnsB3DCEB1D22B49Yazorman@127.0.0.1> |
| In reply to | #2275 |
Anton Shepelev (anton.txt@g{oogle}mail.com) writes:
> While setting up backup via maintenance plans,
> we have found that we cannot specify a Windows network
> directory as backup target, because the MSSQL
> service runs as the standard local user MSSQL$<instance> ,
> which (naturally) has no access to it.
>
> Our administator suggests re-configuring it
> to run as domain-level user
> (with access to the requrired network share),
> or even use a two-stage backup,
> with a separate step of moving the backup files
> from the local machine to the network.
>
> The only other way we know to make that share
> accessible to MSSQL is to give it permissions
> for /everyone/, which we should rather avoid.
>
> What are some best (or least tolearable) practices
> of backing up MSSQL to a network share on Windows?
Run with a gMSA, I guess. That is, rather a machine-local MSA,
an MSA that exists in the AD and therefore can be granted access
to the network share.
One more alternative to the list above is to grant access to
the machine account, that is DOMAIN\MACHINE$, but that is
less secure.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2026-01-23 18:55 +0300 |
| Message-ID | <20260123185513.298e72ae7a415f6c93377ba1@g{oogle}mail.com> |
| In reply to | #2276 |
Erland Sommarskog to Anton Shepelev: > > What are some best (or least tolearable) practices > > of backing up MSSQL to a network share on Windows? > > Run with a gMSA, I guess. That is, rather a machine- > local MSA, an MSA that exists in the AD and therefore > can be granted access to the network share. > > One more alternative to the list above is to grant > access to the machine account, that is > DOMAIN\MACHINE$, but that is less secure. Thanks. We have gone the latter route, as the middle ground between ease and security. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [standalone]
Back to top | Article view | comp.databases.ms-sqlserver
csiph-web