Backup Windows Server to NAS

Question

I have a Windows Server 2012 R2 that I want to backup to a synology NAS (412+) network share.

I've created a shared folder on the NAS.

In windows backup when I select "Backup Schedule..." and go through the wizard I select:

• Back up to a shared network folder
• I add "\nas\backup\etc..." under the Location: field (I can browse to that directory via windows exporer and create files in it).
• Then I press "Next" and I get Windows Security showing me a dialog to provide my credentials.
• I click "Finish" and then I get: "Creating backup schedule..."
• a few moments later: "The user name being used for accessing the remote share folder is not recognized by the local computer".

which fails the backup.

My nas is added to the domain (so I enter a domain user credentials, that has access to the folder)

I've also tried different ways to sign in (user, local server user, nas user, domain\user, user@domain, [email protected], domain.local\user, ...) everytime with the same message.

I've mapped a network drive but in Windows Backup I cannot select that mapped network drive (e.g. Z:\ ) to backup.

At synology support, I don't know if they don't care but their suggestions don't work (and sometimes they think I want to backup my nas, instead of creating a backup of a server to a nas.).

Anyone who has more info to solve this? (I've also disabled SMB 2 and Large MTU)

Solution 1

Synology DSM 5.2 (beta) now supports SMB 3. Hooray! :-)

SMB 3 encryption for secure transmissions

Support for SMB 3 encryption allows your DiskStation to secure file transfers to Windows 8 and Windows Server 2012 or later, reducing the possibility of tampering and eavesdropping when data moves across your company's network. Protect your sensitive information without installing or spending resources on extraneous third-party encryption solutions.

More info: https://www.synology.com/en-us/dsm/5.2beta/

Solution 2

A domain user should be used to do the backup. Because the NAS is belong to a domain, you should give access to a share folder to a domain user, and use DOMAIN\username. This use the correct format.

Alternatively, make a new user in active directory with the same name as the local user on your NAS Drive (QNAP) and then make the user a member of admins or backup operators.

Any other combinations than the two above are very unlikely to work.

Solution 3

I was able to get by the error by creating a local user on my 2008 VM server that matched the Synology user name and password. After that I was able to schedule the server backup successfully. (I did join the NAS to the domain before I tried creating the local user, but that did not solve the problem. I am not sure it is even necessary for the fix to work)

Comments

[Ivan Viktorovic]

If you are using the NAS only for backup purpose i would recomend to create a ISCSI Volume with a LUN and attatch the nas using the ISCSI_initiator. Doing this the NAS appears to the server like it is a normal hard drive.

[Kinnectus]

Can you create a local user on the NAS that has RW access and then you can try the username preceeded by the NAS hostname, e.g. NAS1\nasuser? Not ideal, but a workaround. Have you also checked that your domain users have RW on the NAS, I'm assuming it's SAMBA so you may need to add your domain groups to the SAMBA config.

[juFo]

@IvanViktorovic nas also have other things, so I can't do that.

[juFo]

@BigChris I've already tested this and yes my domain group/user has RW access (via windows explorer I can create, modify and delete files).

[Kinnectus]

Is the domain user a local admin or backup operator on the Windows Server?

[rrirower]

Did Synology support suggest Cloud Station?

[Travis]

I just wanted to add that after you create the local admin account on the NAS and on the domain, you do not use the domain\user or nas\user. Simply use the username and password.

[Ravindra Bawane]

If you'd read the existing answers you would see this has been resolved by an updated released by Synology. Please read existing answers to make sure the answer you're considering is still valid.

[AlwaysLearning]

SMB v3 encryption is not the answer. When using network targets/shares, VSS requires Resliency Support, i.e.: SMB v2.1 or better.

[juFo]

can you explain a bit further about the VSS requirement?