NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Backup error. Write operation failed. The specified network name is no longer available.
We have been sucessfully running a ReadyNAS Pro Business Edition (Radiator 4.2.27) for one level of network backups each day. Normally the NAS has been powered-on all the time. A scheduled backup jo...
Were you also using Macrium Reflect when the NAS was left running continously?
Macrium Reflect uses an elevated user status for scheduled backups. I suspect, but don't know for sure, that it uses standard user credentials when run manually. So, I suspect that the elevated user does not have NAS access and the normal user does. But if you've always used Macrium with a schedule, then that's not it.
Thank you for your contributions to-date.
To answer responder questions so far :
1. WOL - We wait at least 3 minutes for the NAS to be ready from a WOL event. We have tried waiting 5 minutes, 10 minutes, 20 minutes and 30 minutes to see if this improves the ability to run a backup task but it does not. Our minimum time test is based on when it appears ready in Frontview and we can browse and write to shares on the NAS.
2. Running the backup job within a Macrium Reflect session or as a background task (pre-scheduled via Macrium Reflect) incorporating a WOL step all fail first-up.
3. Making Use Of Backup Jobs On The NAS - We did consider this and run a few experiments, however, the NAS scheduler is restrictive and a single backup job cannot capture disparate folders across the server.
We are testing a work-around at the moment given the flexibility Macrium Reflect affords in creating script files.
What we are trying is a four step backup sequence 1. WOL 2. Sacrifical Backup 3. Main Backup 4. Shutdown NAS.
Given the history of the first backup failing following a WOL of the NAS (and as long as we keep the NAS awake) subsequent backups being successful, we added a sacrificial overwrite backup of a single ~ 1Gb file from the server to the NAS. We ignore whether it is successful or not. It does not add much time or space to the backup process / storage but it does the job of clearing the way for the main backup. After some single pass testing we have set it up to repeat x5 sets of the 1-4 sequence as a single script using ~1Gb sacrificial file and ~6Gb main full backup file / verify.
If we get no errors we will increase the size of the main backup file to something more meaningful to our application.
What command do you use in your script to shut down the NAS?
If you add a test in your script after WoL but before starting the backup to test the availability of the share, like trying to access the share in a while loop exiting when successful, does the share eventually become available? How long does it take?
Do you see anything specific in dmesg after WoL, when your script fails to write to the share?
Thank you for your suggestions.
We are using Plink.exe NAS_IP -l username -pw "password" -ssh -P 22 - 2 -m "C:\shutdown.txt" in a batch file .
The text file "shutdown.txt" simply contains the instruction shutdown -h now
We have been successful so far with pre-conditioning the main backup with a small backup ~ 1Gb (ignoring whether this is successful or not).
Once we get our backup regime more on track we will go back and investigate dmesg for differences.
It would be possible to adjust the script to wait until a successful write reponse fron the NAS but we would need to be able to manage the situation where we fail to get a response from the NAS and how that erro is handled.
'The specified network name is no longer available' does show up in the Windows event log so we are not ruling out something on the SBS2003 server side which needs to be refreshed or stopped / restarted to re-establish a good / fresh connection to the NAS when it reappears on the network.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
