Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.databases.ms-sqlserver > #2275 > unrolled thread

Backup to a network share

Started byAnton Shepelev <anton.txt@g{oogle}mail.com>
First post2026-01-22 17:21 +0300
Last post2026-01-23 18:55 +0300
Articles 3 — 2 participants

Back to article view | Back to comp.databases.ms-sqlserver


Contents

  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

#2275 — Backup to a network share

FromAnton Shepelev <anton.txt@g{oogle}mail.com>
Date2026-01-22 17:21 +0300
SubjectBackup 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]


#2276

FromErland Sommarskog <esquel@sommarskog.se>
Date2026-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]


#2277

FromAnton Shepelev <anton.txt@g{oogle}mail.com>
Date2026-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